Caps provided by parsers
Locked
 
|
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 ? -- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by Mikko Hurskainen
Hi Mikko,
On Fri, Nov 19, 2010 at 10:33 AM, Mikko Hurskainen <[hidden email]> wrote: Hi, The h263 depayloader covers the functionalities as specified in rfc2190 (http://www.faqs.org/rfcs/rfc2190.html) which afaik are not requiring to extract information about the frame size. This information is usually extracted from the decoder itself or carried within the container format / signalling protocols. My codec requires these settings. If you're using the decoder for an RTSP/VoIP session it's likely you got the codec-data (aka sprop-parameters-set) during the signalling phase. If you're getting them in-band you don't likely need a parser (and maybe you're dealing with an under-performing decoder). I'm not 100% sure h263 carries codec-data in band though :\ (note for me: read again ITU-T h263 specs). So the question is, should the parsing functionality be Usually, the best place to process encoded data is within a decoder. Processing it twice (e.g. first into a parser, then into a decoder) is, at best, less efficient. My personal opinion is that wherever you need a parser for a decoder to work either you're working with a raw stream or with a broken decoder. In the first case, it's better if either you payloaded or multipex your data, in the second it's good if you get a better decoder ;). Regards
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |