[FFmpeg-cvslog] r10892 - trunk/libavformat/rmdec.c

[Kostya]

On Thu, Nov 01, 2007 at 04:41:07PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Thu, Nov 01, 2007 at 10:02:29AM +0100, kostya wrote:
> > Author: kostya
> > Date: Thu Nov  1 10:02:29 2007
> > New Revision: 10892
> > 
> > Log:
> > Revert get_num() to old behaviour in order to handle
> > incorrect RMs generated by lavf muxer.
> > 
> > 
> > Modified:
> >    trunk/libavformat/rmdec.c
> > 
> > Modified: trunk/libavformat/rmdec.c
> > ==============================================================================
> > --- trunk/libavformat/rmdec.c	(original)
> > +++ trunk/libavformat/rmdec.c	Thu Nov  1 10:02:29 2007
> > @@ -366,7 +366,7 @@ static int get_num(ByteIOContext *pb, in
> >  
> >      n = get_be16(pb);
> >      (*len)-=2;
> > -    n &= 0x7FFF;
> > +//    n &= 0x7FFF;
> 
> it seems the seek regression tests still fail also
> this cannot _fix_ the crash, as simply storing the & 0x7FFF
> should still crash, its just a workaround

from the known info (librmff docs, rmdec.c):
when frame data is stored as slices there are two parameters stored here -
length of the full frame and offset of the current piece of data in it.
Both of them are stored in this way:
XCAAAAAA AAAAAAAA [AAAAAAAA AAAAAAAA]
if C=0 then value if 30-bit (includes 16 bits in square brackets)
otherwise it is 14-bit
flag X meaning is unknown but it is not the part of value at all.

lavf RM muxer wrongly writes size as put_be16(pb, 0x4000 + (size))
which may lead to parse errors in case of size>=0x4000.

I reverted demuxer to accept this broken format and submitted two
alternative patches to fix muxer. After that I may add a stricter check
for input values (so incorrect length/pos values will be caught and
reported).

As for the seeking I will address this tomorrow.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB