[FFmpeg-devel] [PATCH] rmdec.c: support for multirate files

[Ronald S. Bultje]

Hi,

On Tue, Dec 30, 2008 at 5:10 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Dec 30, 2008 at 11:51:12AM -0500, Ronald S. Bultje wrote:
>> Are these small variations in PTS acceptable or do you want me to
>> read-ahead to see which PTS (in future) will be smallest?
>
> the question is, if theres any chance a decoder could end up starved
> that is having packets sufficiently out of sync so that its buffers
> are too small ...

It's 2 RM packets (1 + 1 in case of equal timestamps) away from "real"
sync. How much duration&datasize is in 1 RM packet? Datasize appears
to be small, in general, a few 100bytes for audio (I've seen it
increase to just above 1kB for audio in video files). For video, it's
smaller since frames are split over multiple packets, so generally a
few 10s to a few 100s of bytes per packet, with 1/10th of a
time-per-video-frame in duration.

If the decoding application doesn't expect exact synchronization of
its input packets, it should be OK.

>> @@ -449,20 +489,28 @@
>>                  if(len<0)
>>                      continue;
>>                  goto skip;
>> -            }
>> +            } else if (state == MKBETAG('D','A','T','A'))
>> +                return -1; // multirate next DATA chunk, shouldn't happen
>
> this definitly is not a reasonably choice, i mean you fail hard because the
> string "DATA" occured somewhere while the demuxer tried to resync.

You're right, it's not necessary. I've changed it into a warning to be
able to spot bugs slightly easier, but I can remove it completely if
preferred, it should never be reached unless files are broken or my
patch is buggy.

New patch attached. I've tested, just to be sure, that the demuxer
outputs all packets in the file exactly once (although in a different
order than my first patch, which didn't do packet interleaving), and
that is indeed the case (with same pts, same size, same data, etc.),
showing that the code is (theoretically speaking: "most likely")
correct.

Ronald
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix-multirate-rm.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081231/c89a0dc3/attachment.txt>