You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now this application has a simple compress method and uses a work around for the rotation (setting orientation parameter wasn't working on certain devices, so we are using Shared Preferences for the back and front camera to set a different angle for each of them).
But with pictures above a resoution of 640x480 it may happen that the device will get memory leaks ... so we integrated a setup, to connect always with the lowest resolution to find your optimum on your own. (640x480 produces around 600 kB/s - 720p creates around 1,1 MB/s data traffic)
Future Works: Maybe try to use Rendering Possibilities to decrease the amount of picture data? Or maybe with higher APIs there are already new ways to reduce the problem?
Using certain streaming Codecs will increase the amount of delay and right now it's something like a MJPEG stream without the header for initialisation of the Stream and for each picture (this content is important if you use a certain application like VLC) - To decrease the overhead.
The text was updated successfully, but these errors were encountered:
MCBird
changed the title
Old Devices: Setting/Update the PictureStream with a certain amount of Size can cause Memory Leaks
Old Devices: Setting/Update the PictureStream with a certain Size can cause Memory Leaks
Mar 1, 2016
Right now this application has a simple compress method and uses a work around for the rotation (setting orientation parameter wasn't working on certain devices, so we are using Shared Preferences for the back and front camera to set a different angle for each of them).
But with pictures above a resoution of 640x480 it may happen that the device will get memory leaks ... so we integrated a setup, to connect always with the lowest resolution to find your optimum on your own. (640x480 produces around 600 kB/s - 720p creates around 1,1 MB/s data traffic)
Future Works: Maybe try to use Rendering Possibilities to decrease the amount of picture data? Or maybe with higher APIs there are already new ways to reduce the problem?
Using certain streaming Codecs will increase the amount of delay and right now it's something like a MJPEG stream without the header for initialisation of the Stream and for each picture (this content is important if you use a certain application like VLC) - To decrease the overhead.
The text was updated successfully, but these errors were encountered: