[Bug 728379] appsink/appsrc: caps negotiation/parsing regression

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=728379
  GStreamer | gst-plugins-base | git

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO
                 CC|                            |t.i.m at zen.co.uk

--- Comment #1 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2014-04-16 22:32:08 UTC ---
It is not possible to restore this behaviour, and it is also not really
desirable IMHO.

If you push data into an appsrc, you should know what format that data is. And
you do from your caps filter anyway, so I'm not sure why you can't set it from
the start.

h264parse can't detect/recognise AVC stream-format from the data, you must set
caps when you push AVC. That's just how it is. Use byte-stream if you want
something that doesn't require out-of-band signalling.

It is actually the other way round than you describe: in 0.10 you could only
know the format of the stream once you got a first buffer. In 1.0 you can know
the format even before any data is sent (a CAPS event will be sent before any
buffers are sent). appsink doesn't expose API for that, but you can hook into
it differently if you want to (e.g. by connecting to the notify::caps event on
the sink pad, or installing a pad probe).

It is not clear to me how 1.0 is any more or less convenient than the 0.10 was.
You get both buffer+caps from the appsink, so just set the caps on appsrc
before you push the first data. What is inconvenient about that?

-- 
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.