[gst-devel] Caps provided by parsers
Wim Taymans
wim.taymans at gmail.com
Fri Nov 19 10:13:17 CET 2010
On Fri, 2010-11-19 at 09:33 +0100, Mikko Hurskainen wrote:
> Hi,
>
> There seems to different behaviour with different parsers what comes to
> the resolutions etc. E.g. for H.263 stream quicktime parser gives
> resolution and rtph263depay gives only stream type. My codec requires
> these settings. So the question is, should the parsing functionality be
> implemented by the codec or by parser in general ? Is there somewhere a
> description what is expected from a codec ?
In general, parsers and depayloaders should not start parsing codec
data, that's up to the decoders. If your decoder needs info from inside
the encoded data, it should not rely on other elements to parse it out.
The case of qtdemux: the width and height are those stored in the
container and may or may not be the same as the encoded dimension in the
encoded video. We use these dimensions to clip the resulting output.
The case of rtph263depay: there is not (always) an indication of
width/height at the RTP level.
If you need to received parsed or framed input, you might want to use
parsers before the decoder. with the right caps, this could be enforced
automatically.
Wim
>
> -- Mikko
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list