[Bug 702327] h264parse: Fixate to upstream format when possible

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702327
  GStreamer | gst-plugins-bad | unspecified

--- Comment #3 from Edward Hervey <bilboed at gmail.com> 2013-06-17 07:40:14 UTC ---
discussion with sebastian about this issue

<slomo> bilboed: basically decodebin uses a capsfilter after parsers to allow
it to negotiate some stream format that is accepted by decoders... this
capsfilter contains first the highest ranked decoder's sinkpad caps, then the
next highest ranked, ... and in the end the src template caps of the parser (to
prevent negotiation to fail and get negotiation error instead of "missing
plugin")
<slomo> bilboed: this is done because the parser has downstream not linked
before it doesn't set the srcpad caps. and it can't set the correct srcpad caps
before it doesn't know what stream format downstream wants
<slomo> bilboed: now if you prefer passthrough... you will always passthrough
<slomo> bilboed: maybe now that we can intercept queries properly in decodebin
this capsfilter hack can be removed... and instead the CAPS query can be
answered for the parser, not including the parser srcpad template caps
<bilboed> it should reconfigure itself when it gets RECONFIGURED (which should
happen when it's actually linked), no ?
<bilboed> I didn't know about that capsfilter hack though
<bilboed> and don't really understand its purpose
<slomo> it is done because the parser has downstream not linked before it
doesn't set the srcpad caps. and it can't set the correct srcpad caps before it
doesn't know what stream format downstream wants
<slomo> and yes, h264parse should renegotiate. but doing that without losing
data is not trivial and not implemented either
<bilboed> (before it doesn't set ? what does that mean ?)
<slomo> decodebin only plugs the decoder after the parser after the parser has
sent the CAPS event
<bilboed> ... *sigh*
<slomo> it's the same problem over and over again in different situations :)
<bilboed> well... my point is that with byte-stream we never do passthrough
<slomo> why not?
<bilboed> because in the fixation ... it always ends up fixating stream-format
to the first choice ("avc")
<bilboed> maybe the parser source pad caps query should return those fields
sorted by "upstream-first" ?
<bilboed> or wouldn't that make a differenc e?
<bilboed> I guess it wouldn't :(
<slomo> but if downstream only can do bytestream, it will do passthrough,
right?
<bilboed> yes, but some decoders support both
<bilboed> maybe the parser source pad caps query should return those fields
sorted by "upstream-first" ?
<bilboed> or wouldn't that make a differenc e?
<bilboed> I guess it wouldn't :(
<slomo> but if downstream only can do bytestream, it will do passthrough,
right?
<bilboed> yes, but some decoders support both
<slomo> only if downstream can handle both (in the same structure!) it will
prefer avc over passthrough... but that is something you could handled
specifically in the parser negotiation
<bilboed> gst-inspect-1.0 avdec_h264
<bilboed> you'll see what I mean
<slomo> so you don't do the normal fixation stuff... but if the first structure
contains an array for the stream-format, you chose passthrough
<slomo> it's all not ideal though... and especially if you have a hardware
decoder that can do bytestream ranked highest, and avdec_h264 after that, you
really don't want h264parse to negotiate to avc. as then decodebin will not
even try to use the hardware decoder

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.