[FFmpeg-devel] [PATCH] ALS decoder

Justin Ruggles justin.ruggles
Wed Aug 26 23:21:53 CEST 2009

Thilo Borgmann wrote:

>>>>> +    // increment the frame counter
>>>>> +    ctx->frame_id++;
>>>> that wont work with seeking
>>>> I think ive not missed some setting of frame_id to a value from the
>>>> bitstream
>>> No, it's selfmade. The decoder has to know, which frame it is in.
>>> How to determine it in a seeking compatible way?
>> the short awnser is certainly that, you cant
>> what is the spec saying about this? is the demuxer required to pass
>> some frame number to the decoder? (that makes ALS only possible in
>> some containers)
> I think the spec doesn't say anything about how to determine or retrieve
> this. Maybe Justin knows better.
> Also the reference encoder manually counts the frame number but that is
> of course of no value...

One of the reasons we have the frame count is to determine RA frames,
but we found out that the container will always separate packets by
random access units, not individual frames.  On top of that, the frames
are not able to be parsed (boo! hiss!).  We might be able to do
something to determine RA frames based on packet timestamp changes?

The other reason is to be able to determine if we are decoding the last
frame, which may have fewer samples.  Unfortunately the only mechanism
ALS has to determine this is by comparing the frame size and sample
count from the header, then you have to keep track of each frame to know
if you're decoding the last one.  If you don't know it, the decoding
will either fail or give garbage output.  We ran across that before
Thilo figured out the undocumented oddities in handling block switching
in the last frame.

We might be out of luck... This is just poor design.


More information about the ffmpeg-devel mailing list