Bit depth in the container format vs. in the output

[Jonathan Miles]

Hi

I recently came across the same problem and got round it by adding a meta-data tag 'bits-per-sample' and setting it in the wav, flac, alac and aiff parsers.

The patches are attached. bits-per-sample applies to gstreamer1.0, aiff-bits-per-sample-tag applies to gstreamer1.0-plugins-bad, alac-flac-wav-bits-per-sample-tag applies to gstreamer1.0-plugins-good.

Hope that helps,

Jonathan
________________________________
From: gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org> on behalf of Arun Raghavan <arun at arunraghavan.net>
Sent: 14 July 2016 07:49
To: Discussion of the development of and with GStreamer
Subject: Re: Bit depth in the container format vs. in the output

On Wed, 13 Jul 2016, at 07:08 PM, Carlos Rafael Giani wrote:
> Hello,
>
> there is a problem with displaying file type information. Suppose I want
> to show a file's bit depth on screen. The intuitive solution is to use
> the caps that come out of a uridecodebin for example, and look at its
> format value. But this can be misleading.
>
> For example, if in a system, avdec_flac is used instead of flacdec, then
> the format value will be S32LE even if the actual internal FLAC data
> format is S24_32LE. So now all of a sudden the display shows "32 bit",
> even though "24 bit" is more correct.
>
> This is even visible with gst-discoverer. If you have a 24-bit FLAC
> file, and run gst-discoverer-1.0 -v <flacfile> , the output with flacdec
> present is:
>
>      Channels: 2
>      Sample rate: 192000
>      Depth: 24
>      Bitrate: 0
>      Max bitrate: 0
>
> but with flacdec missing (so only avdec_flac is available) it is:
>
>      Channels: 2
>      Sample rate: 192000
>      Depth: 32
>      Bitrate: 0
>      Max bitrate: 0
>
> So, the correct way to do this is to get the caps that *flacparse*
> outputs, and not the decoder's. However, I have no clue how to do that,
> or even how to communicate such information to the application properly.
> There is no tag that can hold a GstCaps instance.
>
> Any ideas?

At one point we had toyed with the idea of having a "shallow" mode in
GstDiscoverer -- basically get it to stop at the point of plugging a
parser. Perhaps this is worth resurrecting?

-- Arun
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Audio Partnership PLC, Gallery Court, Hankey Place, London SE1 4BB, UK 
Reg No. 2953313
This e-mail is confidential and for the addressee only. 
Please refer to <a href="http://www.audiopartnership.com/AP-disclaimer.php">Disclaimer</a>  for important notices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160714/bed6875e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aiff-bits-per-sample-tag.patch
Type: text/x-patch
Size: 667 bytes
Desc: aiff-bits-per-sample-tag.patch
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160714/bed6875e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alac-flac-wav-bits-per-sample-tag.patch
Type: text/x-patch
Size: 1807 bytes
Desc: alac-flac-wav-bits-per-sample-tag.patch
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160714/bed6875e/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bits-per-sample-tag.patch
Type: text/x-patch
Size: 1225 bytes
Desc: bits-per-sample-tag.patch
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160714/bed6875e/attachment-0002.bin>