IEC958 caps
Locked
 
|
Hi,
some HDMI implementations can use the EDID information to find out what is supported by the audio receiver. The idea is that a sanity check is run before actually playing, to make sure a given stream is supported downstream. One issue with gstreamer is that such a check isn't really possible: even though some existing elements support IEC958 formats, such as ac3iec958 and alsasink, they all rely on the same "audio/x-iec958" capability. Nice, but limited, since the actual payload format is lost. There's no way to signal that the data is actually an AC3, E-AC3, DTS or MPEG format, and as a consequence no means for the sink to check it can actually handle the data. So the question is: how does one go about extending capabilities? Can I just go ahead and define new fields, eg "audio/x-iec958, payload=<val>", using the values defined by the IEC or CEA standards? Or do I need a new cap per format such as "audio/x-iec958-eac3"? Or are the capabilities listed somewhere in some central location to ensure consistency? Thanks for your time, -Pierre ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
Hi Pierre,
Maybe we could consider that it's the application's role to check with HDMI EDID what's supported and decide which streams will be passed through using SPDIF and which others need to be decoded completely with software decoding ?
At least that's what I m planning to do with Moovida in the near future. Best regards, Julien Moutte, FLUENDO S.A. On Tue, Oct 12, 2010 at 5:11 AM, pl bossart <[hidden email]> wrote: Hi, ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
> Maybe we could consider that it's the application's role to check with HDMI
> EDID what's supported and decide which streams will be passed through using > SPDIF and which others need to be decoded completely with software decoding > ? > At least that's what I m planning to do with Moovida in the near future. Lucky you, you have control on your own application. For others, where there are several layers and gstreamer is used as a back-end and isn't even known to the application, you will have to dynamically configure the pipeline using the autoconvert element (Credits to Stefam Kost for the idea). You would first try and connect with S/PDIF, and if the sink declines then you modify the caps of the sink to take PCM only. Autoconvert would then instantiate a sw decoder instead of an iec958 formatter. Still we are lacking a means to pass the payload type for the sink to make an educated decision. We also miss a good way to get the EDID information, there's no real ALSA API to get what formats are supported. -Pierre ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by pl bossart
On Mon, 2010-10-11 at 22:11 -0500, pl bossart wrote:
[...] > So the question is: how does one go about extending capabilities? Can > I just go ahead and define new fields, eg "audio/x-iec958, > payload=<val>", using the values defined by the IEC or CEA standards? > Or do I need a new cap per format such as "audio/x-iec958-eac3"? Or > are the capabilities listed somewhere in some central location to > ensure consistency? Extending the caps by adding a field for the payload type seems to make the most sense to me. Then when the API becomes available, alsasink can do a probe and update its sinkpad caps, presumably much in the way that v4l2sink does now. Just my 2p. :) -- Arun ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by pl bossart
Are you going to add a pre-emphasis property?
An HDCD property would also be interesting. It can be auto-detected, but perhaps there might be cases where it's already known to be present, or where you want to detect it w/o decoding it. Matt -----Original Message----- From: pl bossart [mailto:[hidden email]] Sent: Monday, October 11, 2010 23:11 To: Discussion of the development of GStreamer Subject: [gst-devel] IEC958 caps Hi, some HDMI implementations can use the EDID information to find out what is supported by the audio receiver. The idea is that a sanity check is run before actually playing, to make sure a given stream is supported downstream. One issue with gstreamer is that such a check isn't really possible: even though some existing elements support IEC958 formats, such as ac3iec958 and alsasink, they all rely on the same "audio/x-iec958" capability. Nice, but limited, since the actual payload format is lost. There's no way to signal that the data is actually an AC3, E-AC3, DTS or MPEG format, and as a consequence no means for the sink to check it can actually handle the data. So the question is: how does one go about extending capabilities? Can I just go ahead and define new fields, eg "audio/x-iec958, payload=<val>", using the values defined by the IEC or CEA standards? Or do I need a new cap per format such as "audio/x-iec958-eac3"? Or are the capabilities listed somewhere in some central location to ensure consistency? Thanks for your time, -Pierre ------------------------------------------------------------------------ ------ 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/beautyoftheweb _______________________________________________ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
> Are you going to add a pre-emphasis property?
No, I was not planning to fill the channel status or user bits. My experience is that most receivers ignore channel status bits since they are vastly unreliable. Most solutions actually check the data stream and do not trust the information in those control bits. > An HDCD property would also be interesting. It can be auto-detected, > but perhaps there might be cases where it's already known to be present, > or where you want to detect it w/o decoding it. I am looking at passing data that's already compressed through alsasink/pulsesink. I don't really see how this could be of any interested for HDCD, i.e. PCM only? -Pierre ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
I guess IEC 958 has the pre-emphasis info in-band. I think HDCD is not, however.
In my experience, it's neither true that the pre-emphasis bit is wrong nor that it's ignored. I don't know what you mean about it being in the data stream - I'm talking about PCM, here. Pre-emphasis should be a property of audio/x-raw-int, since it would otherwise get lost, at that point. HDCD could be a property of both audio/x-iec958 and audio/x-raw-int, but there's probably a better case for adding it to audio/x-raw-int than audio/x-iec958. Matt -----Original Message----- From: pl bossart [mailto:[hidden email]] Sent: Tuesday, October 12, 2010 16:51 To: Discussion of the development of GStreamer Subject: Re: [gst-devel] IEC958 caps > Are you going to add a pre-emphasis property? No, I was not planning to fill the channel status or user bits. My experience is that most receivers ignore channel status bits since they are vastly unreliable. Most solutions actually check the data stream and do not trust the information in those control bits. > An HDCD property would also be interesting. It can be auto-detected, > but perhaps there might be cases where it's already known to be present, > or where you want to detect it w/o decoding it. I am looking at passing data that's already compressed through alsasink/pulsesink. I don't really see how this could be of any interested for HDCD, i.e. PCM only? -Pierre ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
> I guess IEC 958 has the pre-emphasis info in-band. I think HDCD is not, however.
> > In my experience, it's neither true that the pre-emphasis bit is wrong nor that it's ignored. I don't know what you mean about it being in the data stream - I'm talking about PCM, here. Pre-emphasis should be a property of audio/x-raw-int, since it would otherwise get lost, at that point. > > HDCD could be a property of both audio/x-iec958 and audio/x-raw-int, but there's probably a better case for adding it to audio/x-raw-int than audio/x-iec958. the x-iec958 cap is used really for iec 61937, i.e for compressed data. I don't think anyone is talking about PCM support. If this generates confusion, we should add an x-iec61937 cap and close this thread. ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
-----Original Message----- ------------------------------------------------------------------------------ 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/beautyoftheweb _______________________________________________ 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 |