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 768923 - h264parse: byte-stream to avc conversion outputs caps without codec_data
h264parse: byte-stream to avc conversion outputs caps without codec_data
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.9.1
Other Linux
: Normal blocker
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-18 13:24 UTC by Deyan
Modified: 2016-07-20 16:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gst-launch-1.0 rpicamsrc num-buffers=10 ! gdppay ! filesink location=rpicamsrc-hdmi2csi.gdp (102.16 KB, application/octet-stream)
2016-07-18 13:24 UTC, Deyan
Details

Description Deyan 2016-07-18 13:24:47 UTC
Created attachment 331709 [details]
gst-launch-1.0 rpicamsrc num-buffers=10 ! gdppay ! filesink location=rpicamsrc-hdmi2csi.gdp

When doing rpicamsrc ! h264parse ! flvmux ! rtmpsink and reading back, flvdemux complains about h264 data before codec_data and playback does not start.

Replacing rpicamsrc with videotestsrc for example makes it work fine.

Attaching some buffers dump.
Comment 1 Tim-Philipp Müller 2016-07-18 13:37:54 UTC
gst-launch-1.0 filesrc location=rpicamsrc-hdmi2csi.gdp ! gdpdepay ! h264parse ! flvmux ! fakesink -v
...
flvmux0.video: caps = video/x-h264, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, stream-format=(string)avc, alignment=(string)au, profile=(string)baseline, parsed=(boolean)true, level=(string)4

no codec_data in caps ?!
Comment 2 Olivier Crête 2016-07-19 18:09:40 UTC
rpicamsrc is not part of the GStreamer project, report bugs to it's page on github.
Comment 3 Olivier Crête 2016-07-19 18:10:01 UTC
ah you think it's h264parse that's broken?
Comment 4 Tim-Philipp Müller 2016-07-19 18:16:26 UTC
> ah you think it's h264parse that's broken?

Yes. I haven't investigated enough to be sure, but I'm baffled about h264parse outputting stream-format=avc caps without codec_data, that's never right.
Comment 5 Tim-Philipp Müller 2016-07-20 12:37:21 UTC
This looks like a regression from 1.8, it seems to work fine in 1.8.2:

gst-launch-1.0 'https://bugzilla.gnome.org/attachment.cgi?id=331709' ! gdpdepay ! h264parse disable-passthrough=false ! flvmux ! decodebin ! xvimagesink -v | grep avc | grep flvmux
Comment 6 Deyan 2016-07-20 14:44:29 UTC
Confirmed: recompiling gst-plugins-bad using git checkout 1.8.2 makes it work as expected
Comment 7 Jan Schmidt 2016-07-20 16:33:47 UTC
The problem here is rpicamsrc, in conjunction with commit 92e7e3 in gst-plugins-bad, which changed the way h264parse handles incoming streams with alignment=AU. rpicamsrc has incorrect caps with alignment=AU, where it should be alignment=nal.

Fixed in gst-rpicamsrc:

commit 43a38970f0d2e98c20b36339c282e51341627b57
Author: Jan Schmidt <thaytan@noraisin.net>
Date:   Thu Jul 21 02:29:57 2016 +1000

    rpicamsrc: MMAL gives buffers with nal alignment, not AU
    
    Fix the output caps, our buffers are not AU aligned, since
    the SPS / PPS are given in separate packets at the start.