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

[Michael Niedermayer]

On Tue, Dec 30, 2008 at 11:51:12AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Dec 30, 2008 at 9:52 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > What we need is as i said support for non interleaved rm files.
> > see avidec.c as an example on how to demux non interleaved data.
> 
> Is attached OK (for the interleaving, I didn't do seeking, yet, working on it)?
> 
> Output example, for a file where the first (default) chunk contains
> stream 4 and the multirate chunks contain (in that order) chunk 0, 1,
> 2, 3 and 5, with the stdout giving (for each RM packet) the offset,
> packet length, stream ID of packet and its PTS:
> 
> 0x     b68: packet len=0480 id=4 pts=000000
> 0x     d54: packet len=0480 id=4 pts=000191
> 0x   5db03: packet len=0580 id=0 pts=000000
> 0x   5dd54: packet len=0580 id=0 pts=000232
> 0x   ba595: packet len=0564 id=1 pts=000000
> 0x   ba7d6: packet len=0564 id=1 pts=000278
> 0x  105dbf: packet len=0352 id=2 pts=000000
> 0x  105f2c: packet len=0352 id=2 pts=000255
> 0x  139e79: packet len=0564 id=3 pts=000000
> 0x  13a0ba: packet len=0564 id=3 pts=000139
> 0x  1d1c41: packet len=0480 id=5 pts=000000
> 0x  1d1e2e: packet len=0480 id=5 pts=000191
> 0x  13a2fb: packet len=0564 id=3 pts=000278
> 0x     f40: packet len=0480 id=4 pts=000382
> 0x  1d201b: packet len=0480 id=5 pts=000382
> 0x   5dfa5: packet len=0580 id=0 pts=000464
> 0x  106099: packet len=0352 id=2 pts=000510
> 0x   baa17: packet len=0564 id=1 pts=000557
> 0x  13a53c: packet len=0564 id=3 pts=000417
> 0x    112c: packet len=0480 id=4 pts=000574
> 0x  1d2208: packet len=0480 id=5 pts=000574
> 0x  13a77d: packet len=0564 id=3 pts=000556
> 0x   5e1f6: packet len=0580 id=0 pts=000696
> 0x  106206: packet len=0352 id=2 pts=000766
> 0x  13a9be: packet len=0564 id=3 pts=000696
> 0x   bac58: packet len=0564 id=1 pts=000835
> 
> 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 ...


[...]
> @@ -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.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081230/fe2b2264/attachment.pgp>