Not working on any ICS device

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start with H264 encoding option
2. Start vlc with command vlc rtsp://xxxxx
3. Nothing appears on the vlc player screen

What is the expected output? What do you see instead?
The video header is damaged & picture size is invalid

What version of the product are you using? On what operating system?
4.0

Please provide any additional information below.
Works well with Gingerbread devices only :(
VLC player logs attached with for ICS devices.

Original issue reported on code.google.com by arunmahe...@gmail.com on 22 Jun 2012 at 9:27

Attachments:

• logs.txt

[GoogleCodeExporter]

Nalulength returns a huge value (something like 10234230) and no NAL unit is 
been created and sent on ICS devices.
Tested on 5 ICS phones.

Original comment by arunmahe...@gmail.com on 23 Jun 2012 at 6:29

[GoogleCodeExporter]

I noticed that too. it seems that nalulength calculation/lookup is problematic 
in some instances. As a workaround, if it is greater than 1000000 (random 
number, still researching how to handle nalulength properly) or less than or 
equal to 0, just skip.

with this, it works most of times. it works on HTC One X (ICS 4.0.3).

it seems on HTC phones (both 4 or 2.3) have occasional issues on nalulength 
calculation.

Original comment by xianzhan...@gmail.com on 25 Jun 2012 at 5:48

[GoogleCodeExporter]

Ok !
I will commit a little fix soon !

Thank you

Original comment by FyHertz on 26 Jun 2012 at 9:17

[GoogleCodeExporter]

 xianzhang.gu, when you say you skip it, you mean that you just wait for 4 more bytes and try to recompute the naluLength ?
In other words, the HTC sometimes sends a wrong naluLength and then sends a 
correct one ?

Original comment by FyHertz on 26 Jun 2012 at 9:31

[GoogleCodeExporter]

most of times, HTC gives the right value. right now, I have not figured out why 
wrong value was present or probably current code does not take into all special 
cases. I'm researching how to better handle it. at the moment, yes I just let 
it try next 4 more bytes. I just want to avoid crash so it has a chance to 
re-try. from logcat, it did seem to recover and resume streaming. my guess is 
that could be just messed up stream.

Original comment by xianzhan...@gmail.com on 27 Jun 2012 at 8:34

[GoogleCodeExporter]

I am afraid to say but when i try to read next 4 bytes, it doesn't give me the 
nalu length either.
So i tried to hardcode 'nalulength = chunksize -4' W.O.R.K.E.D
But the video quality seems to be poorer then h263 even :(

Original comment by arunmahe...@gmail.com on 27 Jun 2012 at 9:34