GNOME Bugzilla – Bug 687548
h264parse: SPS/PPS NAL units not created correctly if format is bytestream
Last modified: 2012-12-18 17:28:08 UTC
Created attachment 228006 [details] [review] Fixes SPS/PPS generation for bytestream format Looks to be introduced in commit 7f72b99426e8615cc16bff1c8157cd7d6efdba54 Attached patch corrects 2 things: - don't rewind to the NAL length size in bytewriter if the format is bytestream - put back the gst_byte_writer_put_buffer() call for PPS (presumably got deleted accidentally) ps. first-time caller so apologies if this isn't the preferred way of reporting/submitting
Thanks for the patch! The preferred format is actually in "git format-patch" format, so including author and commit message, but we can add that if needed. I presume this fixes the issue you mentioned on the mailing list? > The following pipeline (to turn .mp4 into .ts) works fine for me in > GStreamer 0.10: > > gst-launch-0.10 filesrc location=/tmp/temp.mp4 ! qtdemux ! > h264parse ! mpegtsmux name=mux ! filesink location=/tmp/output.ts > > But the same pipeline with GStreamer 1.0.2 produces an output.ts that VLC > won't play. As far as I can see in the TS output, there don't seem to be any > SPS/PPS startcodes (they are present in the output from 0.10). > > The output from the h264parse element appears to be identical between the > two versions. > > I looked at the source for the latest mpegtsmux, and there is no longer any > mention of SPS/PPS anywhere. In fact, a whole file mpegtsmux_h264.c seems to > have disappeared.
Yes, it fixes that. Looks like the mpegtsmux restructuring was a red herring. I was going to update the mailing list once it was confirmed as a sensible fix here. Apologies - I'm not too familiar with git. Do you have everything you need this time with the current patch? Thanks.
Yes, I think we do, thanks again. (http://gstreamer.freedesktop.org/wiki/SubmittingPatches has some rudimentary instructions, in case you're interested). I believe the stuff in mpegtsmux_h264.c was there to make mpegtsmux accept AVC as well as byte-stream as input, duplicating what h264parse does, just more incomplete and buggier (though may work fine for some cases of course). I could be making this up entirely of course, I didn't look at the code.
Ah that makes sense. Thanks for the patch info, will use this in future!
commit b3abd51656dd5883066fada3d29953111437c1bf Author: Thibault Saunier <thibault.saunier@collabora.com> Date: Tue Nov 6 12:40:05 2012 -0300 h264parse: don't rewind to the NAL length size in bytewriter if the format is bytestream Fixes https://bugzilla.gnome.org/show_bug.cgi?id=687548 Signed-off-by: Kevin Thornberry