roufshah / spydroid-ipcamera

Automatically exported from code.google.com/p/spydroid-ipcamera
GNU General Public License v3.0
0 stars 0 forks source link

Not working on any ICS device #52

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
Ok !
I will commit a little fix soon !

Thank you

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

GoogleCodeExporter commented 8 years ago
 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 commented 8 years ago
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 commented 8 years ago
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