After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 665418 - h264parse produce AVC: nal size -1702885365
h264parse produce AVC: nal size -1702885365
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal blocker
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-12-02 17:40 UTC by Nicola
Modified: 2011-12-05 12:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdp dump that show the problem (336.00 KB, application/octet-stream)
2011-12-02 17:40 UTC, Nicola
Details

Description Nicola 2011-12-02 17:40:22 UTC
Created attachment 202637 [details]
gdp dump that show the problem

h264parse produce a lot of this warning when saving an h264 stream from an axis camera with a pipeline like this:

gst-launch -e -v -m -t rtspsrc location=rtsp://<ip>/axis-media/media.amp ! rtph264depay ! h264parse ! qtmux ! filesink location=/tmp/test.mov

or 

gst-launch -e -v -m -t rtspsrc location=rtsp://<ip>/axis-media/media.amp ! rtph264depay ! h264parse ! matroskamux ! filesink location=/tmp/test.mkv

I can see output like this when I play the produced file with vlc o mplayer:

[h264 @ 0x7f48e29645e0]concealing 1200 DC, 1200 AC, 1200 MV errors
V:   4.2   0/  0  8% 36%  0.0% 0 0 
[h264 @ 0x7f48e29645e0]AVC: nal size -1702885365
[h264 @ 0x7f48e29645e0]concealing 1200 DC, 1200 AC, 1200 MV errors
V:   4.3   0/  0  8% 35%  0.0% 0 0 
[h264 @ 0x7f48e29645e0]AVC: nal size -1700787701
[h264 @ 0x7f48e29645e0]concealing 1200 DC, 1200 AC, 1200 MV errors
V:   4.5   0/  0  8% 34%  0.0% 0 0 
[h264 @ 0x7f48e29645e0]AVC: nal size -1709178357
[h264 @ 0x7f48e29645e0]concealing 1200 DC, 1200 AC, 1200 MV errors
V:   4.6   0/  0  8% 33%  0.0% 0 0 
[h264 @ 0x7f48e29645e0]AVC: nal size -1702885365
[h264 @ 0x7f48e29645e0]concealing 1199 DC, 1199 AC, 1199 MV errors
V:   4.7   0/  0  8% 32%  0.0% 0 0 
[h264 @ 0x7f48e29645e0]AVC: nal size -1700787701
[h264 @ 0x7f48e29645e0]concealing 1200 DC, 1200 AC, 1200 MV errors
V:   4.8   0/  0  8% 32%  0.0% 0 0 
[h264 @ 0x7f48e29645e0]AVC: nal size -1696592373
[h264 @ 0x7f48e29645e0]concealing 1200 DC, 1200 AC, 1200 MV errors
V:   4.9   0/  0  8% 31%  0.0% 0 0 

attached is a gdp dump captured with:

gst-launch -e -v -m -t rtspsrc location=rtsp://192.168.2.136/axis-media/media.amp ! gdppay ! filesink location=/tmp/test.gdp


I think this problem is reproducible with any axis h264 cameras

the latest released gstreamer version doesn't show this issue
Comment 1 Mark Nauwelaerts 2011-12-05 09:39:38 UTC
Unable to reproduce.  In particular, following pipeline produces a file that plays fine using mplayer, vlc or totem (only with an acceptable 'missing reference picture' complaint given the circumstances):

filesrc location=test.gdp ! gdpdepay ! rtph264depay ! h264parse ! mp4mux ! filesink location=test-gdp.mp4

There have been a few fixes to h264parse (git) recently, and will assume those took care of this.  If they somehow do not, please provide a dump that allows to reproduce using above pipeline.

As a side-note, above AVC nal size complaints are similar to what is seen in bug #653649 when ffdec_h264 is used on avc input with multi-threaded decoding enabled, so it is possible libav is having a bad MT-decoding day (in any of the mplayer etc settings).  Using e.g. totem while making sure that MT-decoding is disabled in gst-ffmpeg could set one at ease here.
Comment 2 Nicola 2011-12-05 09:54:02 UTC
Mark, I'm using current git in an uninstalled setup and your pipeline give to me the reported warnings if I play test-gdp.mp4 with vlc or mplayer from a default ubuntu 11.10 install.

If I use the same pipeline but using the installed gstreamer version (bad 0.10.22)  instead of the uninstalled one, mplayer and vlc can play the produced file without any warning
Comment 3 Mark Nauwelaerts 2011-12-05 12:19:48 UTC
Oops, minor oversight, since the most unlikely of code change managed to break h264parse (again).

Following commits unbreak h264parse (a bit more).

commit ef24518b6056c09ea4bbb3d75fc26be281f8ee81
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon Dec 5 12:57:47 2011 +0100

    h264parse: optimize slice nal processing
    
    Only minimal slice info is needed here to determine real frame start,
    so no need to parse extensively.
    
    Fixes #665418.

commit 91e054ba58c2bf3ace0ff22c3c5832733b6efb47
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon Dec 5 12:53:59 2011 +0100

    codecparser: unbreak h264 slice header parsing
    
    .. introduced by refactoring in commit 177451c9216f4e3959e7358675fbb9731d2c81a2