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 752816 - Can't mux stereo H.264 to qtmux
Can't mux stereo H.264 to qtmux
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-24 09:21 UTC by Jan Schmidt
Modified: 2018-11-03 15:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Jan Schmidt 2015-07-24 09:21:45 UTC 
There's a disconnect between h264parse and qtmux when it comes to handling stereoscopic/multiview H.264.

Initially, h264parse outputs caps with video/x-h264...profile=high. Later, when it sees the Subset-SPS packet and knows it is handling stereo or multiview content, it changes the caps.

However, at that point qtmux does:
0:00:00.296990888 19789 0x7fb0000025e0 WARN                   qtmux gstqtmux.c:4052:gst_qt_mux_video_sink_set_caps:<mp4mux0> pad video_0 refused renegotiation to video/x-h264, stream-format=(string)avc, alignment=(string)au, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)10000000/333667, multiview-mode=(string)frame-by-frame, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, parsed=(boolean)true, profile=(string)stereo-high, level=(string)3.1, codec_data=(buffer)0180001fffe200196764001fac56805005b3ff0001000110005176301312d0094000156f80001f4b15a014016cffc000400040abf8fc2a4402000468ce3c8000046848e3c8

and everything halts.

I'm not sure how it should be resolved. It might be possible to make qtmux allow caps changes until some data has been muxed, and refuse after. It's likely more difficult to make h264parse delay the caps setting until later "just in case" a subset SPS comes along.
Comment 1 Thiago Sousa Santos 2015-07-24 13:25:18 UTC 
Delaying configuring the caps and allowing it to change until the first buffer makes sense for me.
Comment 2 Jan Schmidt 2015-07-24 14:40:45 UTC 
Urk, turns out the first buffer arrives before the SSPS is seen by H.264 and the caps are changed, so qtmux already has received a buffer.
Comment 3 GStreamer system administrator 2018-11-03 15:02:32 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/206.