GNOME Bugzilla – Bug 681819
baseparse: property to disable passthrough
Last modified: 2013-08-14 13:44:26 UTC
Testpipeline: gst-lauch -v filesrc location=test.mpg ! mpegpsdemux ! h264parse ! fakesink misses to set the buffer flags /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (53089 bytes, timestamp: 0:00:03.420033333, duration: none, offset: -1, offset_end: -1, flags: 1 ro ) 0xbca78" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (41399 bytes, timestamp: 0:00:03.453400000, duration: none, offset: -1, offset_end: -1, flags: 1 ro ) 0xbcd48" / .....and endlesss 'flags: 1'.... A quick fix (just for testing) is the following patch: diff --git a/gst/videoparsers/gsth264parse.c b/gst/videoparsers/gsth264parse.c index cf81657..9dd8b51 100644 --- a/gst/videoparsers/gsth264parse.c +++ b/gst/videoparsers/gsth264parse.c @@ -1656,7 +1656,7 @@ gst_h264_parse_set_caps (GstBaseParse * parse, GstCaps * caps) } if (format == h264parse->format && align == h264parse->align) { - gst_base_parse_set_passthrough (parse, TRUE); + gst_base_parse_set_passthrough (parse, FALSE); /* we did parse codec-data and might supplement src caps */ gst_h264_parse_update_src_caps (h264parse, caps); Output with patch applied: /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (62658 bytes, timestamp: 0:00:05.805711111, duration: none, offset: 7351588, offset_end: -1, flags: 257 ro delta_unit ) 0xbcc78" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (46709 bytes, timestamp: 0:00:05.839066666, duration: none, offset: 7414246, offset_end: -1, flags: 257 ro delta_unit ) 0xbcce0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (131011 bytes, timestamp: 0:00:05.872433333, duration: none, offset: 7460955, offset_end: -1, flags: 0 ) 0xbcdb0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (52341 bytes, timestamp: 0:00:05.922477777, duration: none, offset: 7591966, offset_end: -1, flags: 257 ro delta_unit ) 0xbcd48" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (37758 bytes, timestamp: 0:00:05.955855555, duration: none, offset: 7644307, offset_end: -1, flags: 257 ro delta_unit ) 0xbcc10" I think the problem was introduced by the following commit: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst/videoparsers/gsth264parse.c?id=6a8d66728f0c88c4e087d489084ecc31071dc251 As fix for: https://bugzilla.gnome.org/show_bug.cgi?id=650228 I think the fakesink element accept the new caps and as consequence the h264parse is disabled by the gst_base_parse_set_passthrough (parse, TRUE); call......
Not sure how much "a bug" this is. It makes sense for h264parse to get out of the way if input == output. Also, in this (diagnostic) case/pipeline, h264parse could be triggered by setting an appropriate capsfilter, rather than modifying code. That said, the underlying problem is probably that there are many interpretations and levels of 'passthrough'; whether that refers to leaving all of the input intact, or only the data-units and still setting/modifying metadata (what kind of metadata then, flags and/or timestamps ?) etc.
With the new baseparse classes, it would be nice if the user could manually disable passthrough if he wants.
Making this a generic bug.
*** This bug has been marked as a duplicate of bug 705621 ***