[FFmpeg-devel] [PATCH] dca: export profile information on decode

[Kostya]

On Mon, Dec 27, 2010 at 01:09:33PM +0200, Anssi Hannula wrote:
> On 27.12.2010 11:46, Kostya wrote:
> > On Mon, Dec 27, 2010 at 04:51:06AM +0200, Anssi Hannula wrote:
> >> ---
> >> This patch makes the dca decoder provide profile information of the
> >> stream, so that users can easily differentiate between the DTS types.
> >>
> >> Couple of things related to this I'm not sure of:
> >> - The values of the profile #defines. In this patch I put them into an
> >>   approximate order of quality, with space in between for future
> >>   profiles. Is this OK, or should I just make them sequential from 0?
> > 
> > I'd rather not do it this way - first, one should detect HD part in
> > frame ( which is easy) and divide profile into HRA or base, then if needed
> > scan core part for X96k/XCh/XXCh extensions and set profile according to
> > that. HD part has too complex structure - it may contain several
> > substreams (or ass-ets as they call it), each one with its own
> > capabilities. So unless you can parse it properly better not touch it at
> > all.
> 
> Well, my main motivation for this patch is to provide end applications
> some way of detecting core-only/HRA/MA cases, so that they can show the
> type to the user and decide whether to use full passthrough / pass core
> only / whatever, so I'd really like the HD type to be shown here (the
> ES/96_24 types were just a bonus).
> 
> I believe I could parse the HD header more thoroughly, separating the
> assets, and then only look at the first asset. Would that be OK for you?

Yes, though I'm just grumbling.
And mind you, that HD header contains all extensions information coded
as flags, though it may be still easier to search for synccodes ;)

> Also, what exactly do you mean by dividing profile?
> 
> Something like this?
> 
> #define FF_PROFILE_DTS_CORE    0x00ff
> #define FF_PROFILE_DTS_BASE    0x0001
> #define FF_PROFILE_DTS_ES      0x0002
> #define FF_PROFILE_DTS_96_24   0x0003
> 
> #define FF_PROFILE_DTS_HD      0xff00
> (#define FF_PROFILE_DTS_EXPRESS 0x0100)
> #define FF_PROFILE_DTS_HD_HRA  0x0200
> #define FF_PROFILE_DTS_HD_MA   0x0300
> 
> My idea was to have a generic profile value that would provide the user
> a basic idea of the quality / used encoding method, instead of exporting
> too much information about the used extension packets in the bitstream
> or their location. Or is that what you wanted? i.e. should we provide
> exact information about the used extension types (in a bitfield) instead
> of using the high-level profile names?
> IMHO that would complicate the simple use case too much for little
> benefit, but I'm ok with that if that is what you want.

I meant this flow:
1) determine HD frame position (from core frame length + size checks)
2) if HD is present -> set profile to DTS_HD
3) else do steps 4-5
4) set profile to DTS_CORE
5) search in core frame for XCh and X96 extensions, if found, upgrade
   profile to DTS_ES or DTS_96_24

Or, alternatively, you can reuse asset flags system just to signal what
extensions are present (0x1 -> core, 0x10 -> core in HD frame,
0x200 -> lossless, etc).

And let's wait for word from other DTS maintainer.

> Thanks for your quick reply.
> 
> -- 
> Anssi Hannula