Vmobile problem with new Android 4.0.3 notepad.

[Pucco]

I just started with Qnap 859pro+ and want to start home surveillance.
My new ASUS Transformer Pad with Tegra3 and Android 4.0.3 shows corrupt video in Vmobile.
Lower half of the videos have horizontal coloured lines. It looks like a video compression-codec problem.
The videos are correctly viewed on a windows system in IE9.

Android.JPG

I don't know where to go from here. Is this a Android OS/hardware problem or a Vmobile software problem.

[schumaku]

Please add details like camera(s), and the configuration (in ecordings) for Video Compression: MPEG4 or Motion JPEG, Resolution, Frame Rate, and Quality.

[Pucco]

It is two Foscam FI8918W set to 640x480 at 15 Hz, MJPEG. Your question about camera, resolution and coding made me investigate further.

If I change resolution in the camera to 320x240 30 Hz the problem is solved for large pictures but remains for small ones.
With one camera visible both 320x240 and 640x480 images are up scaled. Images are shown correct.
With two cameras, 320x240 is up scaled and correct and 640x480 down scaled and corrupt.
With three or more cameras, both 320x240 and 640x480 are down scaled and corrupt.

This is on a 1280x800 screen driven by Tegra3 and running Android 4.0.3

It seems that the down scale conversion is corrupting the picture.
I have tested other surveillance apps that connect directly to the camera at 640x480 15 Hz and they work properly on my Android pad.

I don't know if the video stream is sent unaltered from the QNAP and all image processing is done in the receiving notepad. If so I will have a problem with bandwidth when connecting over internet. For the moment I am experimenting locally in my house so neither video bit rate and hard disk space is a problem.
The camera only have two settings, 640x480 @ 15Hz and 320x240 @ 30Hz with MJPEG coding.
That gives a file size on my NAS of about 50-85 Mbyte/5minutes @ 640x480-15Hz and 20-30 Mbyte @ 320x240-30Hz
VLC's mediainfo reports 640x480@30Hz (should be 15 Hz) MJPEG 4:2:2 YUV.
Maybe I have to change camera to something other (more expensive) with more options. I want the higher resolution but don't need the frame rate.

Edit: Running software version 3.7.1 Build 20120615 on my 859PRO+

[schumaku]

Have not much experience with the the video scaling on Vmobile (Android).

Do oyu have freed-up any other concurrent views or recording from the camera, so only Surveillance Station and Vmobile is in the play? I see some failures in connecitons and/or streaming on the lower-cost cams, ie from iPUX here when there are to many sytems try to connect.

Can't come behind it... why?

First, I don't see any dedicated camera sessions from the mobile device IP on the camera. This is good - simply to protect the ressources on the camera side.

Second, I see Vmobile does show a lower resolution on the Galaxy Nexus (HD sceen, but small) from some cameras, but not from others. No, not becuae of the picture quality - because the scaling of the camera-included title bar is clearly different from what I see on recording (set to 640x480 here, too) ie. on the Cisco PVC300, while for example the Cisco WVC210 seems to represent the full resolution:

Screenshot_2012-07-17-15-52-12.png

Ok, the screen is small - however the resolution is similar to your tablet - so I _assume_ Vmobile should show about the same.

Worth mentioning... Android (up to Jelly Bean/4.1/API level 16) does not come with a generic hardware acceleration API support ie. for harware accelerated video or audio processing. Everything is done in soft-decoding by the pure CPU - excpeto of some (Android hardware) vendor implementation or sponsored activities (ie. XBMC for Android sponsored by Pivos).

[Pucco]

Some more testing done. I have no other cameras or connections to my NAS.
I am still configuring and testing and has not started to use it yet.

It looks like the NAS actually is compressing the video before sending it to VMobile.
As you can see on the image about 4.5 Mbit/s is transferred from the two cameras to the NAS.
When I start VMobile with 1 camera shown, the CPU usage for nvrd goes up 4-5% and 550 kbit/s data i transmitted.
If I then selects two cameras to show, CPU is up 9-10% and data rate it 1.1 Mbit/s.
Increasing to 3 or more displayed cameras will shrink the images and reduce CPU and data.

Network1.png

If I start Surveillance Station in IE9 on my PC no extra CPU is required but data seem to be copied from the original stream.

Network2.png

There is definitely a problem with the combination of coding in Qnap and decoding in Android when using VMobile.
Where the error is created I can't say.
One other thing is that VMobile is not created for the high resolution of a notepad. The whole app is up sampled and fuzzy.

[schumaku]

It looks like the NAS actually is compressing the video before sending it to VMobile.
As you can see on the image about 4.5 Mbit/s is transferred from the two cameras to the NAS.
When I start VMobile with 1 camera shown, the CPU usage for nvrd goes up 4-5% and 550 kbit/s data i transmitted.
If I then selects two cameras to show, CPU is up 9-10% and data rate it 1.1 Mbit/s.
Increasing to 3 or more displayed cameras will shrink the images and reduce CPU and data.

Yes, the resizing of the video streams is obvious. The part that I was curious about is the fact that the camera-geneated headers are in once case rescaled/compressed, where the other does shsow the almost "full-resolution" one. the only thing I can think about is that some cameras are providing this in different streams (Vivotek and thier OBMs?), while with others it's handled as a part of the video stream.

There is definitely a problem with the combination of coding in Qnap and decoding in Android when using VMobile. Where the error is created I can't say.

Might be caused by the rescaling of your camera streams. I'm still missing sosme more detail on your cameras, the camera, and the recording configuration.

One other thing is that VMobile is not created for the high resolution of a notepad. The whole app is up sampled and fuzzy.

Well - the key problem is that it's aimed for mobile access - and here you can't build on having at least a constant 4 Mbit/s or more available - what wowuld be required when forwarding the full resolution and picture rate as configured - compare to the bandwidth when the full surveillance Station is up on IE9. As well, not all NAS where Surveillance is supported bring the ame CPU power - sos the variation options are limited.

This is the old story when designing applications for streaming. Everybody expectes perfect ful HD or better quality nowadays - and does foroget almost everything is highly variable. The problem starts on the Web cams, where the video streams (from very different sensor qualities) are compressed for the first time. The "perfect" solution would be to adopt dynamically to the latency and the bandwidth available.

[Pucco]

More info. Foscam FI8918W can only encode MJPEG. No settings for compression quality.
Surveillance Station resolutions:
640x480 @ 15, 10, 5, 4, 3, 2, 1 Hz
320x240 @ 30, 20, 15, 10, 5, 4, 3, 2, 1 Hz
IE9 connected to web server on camera:
640x480 @ 15, 10, 5, 4, 3, 2, 1, 1/2, 1/3, 1/4, 1/5 Hz
320x240 @ 30, 20, 15, 10, 5, 4, 3, 2, 1, 1/2, 1/3, 1/4, 1/5 Hz

Interesting is that when changing frame rate from 15 Hz to 5 Hz the bit rate from the two cameras only dropped from 4.4 Mbit/s to 2.5 Mbit/s.
Even more interesting is that bit rate to VMobile only changed by 5%.
Image corruption with colour stripes in the lower half of the video is still there.

Regarding the fuzzy look of VMobile i didn't mean the video but the surrounding graphics like text, buttons and background patterns.

[schumaku]

Regarding the fuzzy look of VMobile i didn't mean the video but the surrounding graphics like text, buttons and background patterns.

Oh yes, you are perfectly right - instead of using the full available display space. As there is sooooooooooooooo much on these devices

[churchil]

I have exactly the same problem, I have the same category Foscam and a qnap TS110.
Also on an ipad device he gives these stripes.