GNOME Bugzilla – Bug 771707
avidemux: h264 variant itu, regression from 0.10
Last modified: 2018-11-03 15:11:44 UTC
I have an avi with h264 variant itu, here are the caps: video/x-h264, variant=(string)itu, framerate=(fraction)120/1, width=(int)320, height=(int)240, codec_data=(buffer)2000000127644014ac2b40a0fd8088000003000800000301e42000000128ee1f2c0000000000000000000000000000000000 this file works fine in 0.10 but in 1.0 give not negotiated, in 0.10 ffdec_h264 show sink caps as: SINK template: 'sink' Availability: Always Capabilities: video/x-h264 width: [ 16, 4096 ] height: [ 16, 4096 ] framerate: [ 0/1, 2147483647/1 ] while in 1.0 the format are restricted: SINK template: 'sink' Availability: Always Capabilities: video/x-h264 alignment: au stream-format: { avc, byte-stream } if I change avdec_h264 so that gst-inspect shows this: SINK template: 'sink' Availability: Always Capabilities: video/x-h264 then the file plays fine, is this acceptable? Do you have other suggestions for a better patch?
That doesn't look acceptable, no. Could you make the file available?
here is a sample file http://195.250.34.59/temp/test_h264_itu.avi plays fine in 0.10, vlc, ffplay ecc.. but not in 1.0
h264parse should handle this variant too, actually it errors out with something like this: h264parse gsth264parse.c:2487:gst_h264_parse_set_caps: video/x-h264 caps with codec_data but no stream-format=avc
Created attachment 335932 [details] [review] avidemux: make sure H264 caps always have stream-format set Instead of letting downstream guess based on presence or not of a codec_data field.
works fine, thanks!
but if you do something like avidemux ! h264parse this still does not work: gsth264parse.c:2677:gst_h264_parse_set_caps:<h264parse0> refused caps video/x-h264, variant=(string)itu, framerate=(fraction)120/1, width=(int)320, height=(int)240, codec_data=(buffer)2000000127644014ac2b40a0fd8088000003000800000301e42000000128ee1f2c0000000000000000000000000000000000, stream-format=(string)avc, alignment=(string)au
Tim, what do you think about making h264parse work in passthrough mode in this case? You can play and even remux the file just fine whitout using h264parse
(In reply to Nicola from comment #7) > Tim, what do you think about making h264parse work in passthrough mode in > this case? You can play and even remux the file just fine whitout using > h264parse any opinions?
I don't know what "this case" is. Why is it refusing it? And why does playback work then, where h264parse is also plugged after avidemux? It sounds like there's something after h264parse causing problems.
after applying the patch to avidemux, these pipeline work: filesrc ! avidemux ! fakesink filesrc ! avidemux ! avdec_h264 ! xvimagesink this one does not work filesrc ! avidemux ! h264parse ! fakesink h264parse fails with this error: h264parse gsth264parse.c:2672:gst_h264_parse_set_caps:<h264parse0> wrong avcC version so h264 contained in this file can be handled by ffmpeg but is not handled in h264parse, the ideal solution would be to properly handle this format in h264parse too, a temporary solution could be to let h264parse work in passthrough mode when it does not recognize the h264 stream and no conversion (avc-> byte stream ecc..) is required
Ah, I can reproduce this. I think the patch is not quite right actually. The codec_data contains a byte-stream sync marker, but not at the beginning, so I wonder what format/packing that codec_data is. Needs more investigation then.
-- 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/299.