Re: [xine-devel] Header Buffers: thinking out loud...

[Petri H. <phi...@us...>]

Chris Rankin wrote:
> On 16/09/11 13:12, Petri Hintukainen wrote:
> >> So I was thinking - the FFmpeg decoder itself is the only code that knows what
> >> needs to happen with these particular header buffers... so what if the decoder
> >> removes BUF_FLAG_HEADER from decoder_flags and then processes these buffers
> >> normally?

HEADER buffers are not supposed to contain audio stream data. PREVIEW
buffers are. This would change the semantics of HEADER buffers.

> >> That would remove the need for "rewinding" the stream, and the audio
> >> decoder loop would then automatically not cache them.
> >
> > I believe it wouldn't work (except with current mpeg-ts demuxer).
> 
> That's what I mean - get the FFmpeg decoder *itself* to remove BUF_FLAG_HEADER 
> from the decoder flags, because it knows it doesn't contains "out of band" data. 
> The audio decoder loop would then never realise that the buffers had originally 
> been declared as headers by the demuxer, and so wouldn't cache them.

Demuxer would still need some knowledge about decoders. There are other
audio decoders that are used with mpeg-ts (a52, dts, faad, mad, LPCM).
Those would still behave differently (some would decode the header
buffers, some would ignore. Headers would still be stored in audio
decoder.)

It is also likely that some containers (matroska, ...) have
codec-specific header data that is actually used. In most cases such
HEADER buffers should not be decoded - those are not supposed to contain
audio stream data.

> > Current status:
> > ===============
> >
> > Audio decoders:
> 
> > combined/ffmpeg:
> >    PREVIEW:   opens codec, not decoded
> >    HEADER:    required for initialization (used with COOK, 14_4, 28_8)
> >    STDHEADER: used when available
> 
> Hmm, I think HEADER opens the codec in this case. Otherwise I wouldn't have 
> needed to send it. And I don't think PREVIEW frames are used at all.

HEADER buffer initializes the codec. It calls avcodec_find_decoder().
Then it allocates context and copies header data to the context. Codec
is opened (avcodec_open() called) when first data or preview buffer
arrives.
If audio parameters were not passed in header buffer, first data buffer
is decoded to get the parameters. When decoder gives the parameters,
audio output is opened. Finally all data is decoded again to produce the
output.

Preview buffers are not decoded (those could be decoded if output is not
passed to audio out). Decoding preview buffers would give audio
parameters required for opening the output (unless those were already
passed in HEADER buffer).

Content of HEADER buffers from mpeg-ts demuxer is currently not used for
anything. Only thing it could be used is to get audio parameters by
decoding the buffers - but that's what PREVIEW buffers are meant for.


ffmpef audio decoder wrapper is very easy to change to work without
HEADER buffers. Of course this applies only to the formats that do not
require codec-specific extra data. All other decoders used with mpeg-ts
already work without HEADER data. Well, LPCM decoder needs header data
but it excepts demuxer to add that data (PCM configuration bytes) to
every data buffer.

- split codec initialization from header data handling
- if codec hasn't been initialized when stream data arrives, initialize
it before codec is opened.

By splitting the existing code to smaller functions we can fix this
problem by adding only two lines of code - without changing the
semantics of header buffers and without the risk of breaking something
else.


- Petri