[FFmpeg-devel] [PATCH] RV30/40 decoder

[Rich Felker]

On Wed, Sep 19, 2007 at 09:06:42PM +0300, Kostya wrote:
> On Wed, Sep 19, 2007 at 07:53:01PM +0200, Michael Niedermayer wrote:
> > Hi
> >
> [...] 
> > > I understand that it is hacky and not good but when proper RM demuxer will be introduced
> > > I will gladly drop this code. And decoding per slice is quite fragile and may
> > > result in consequent frame corruptions due to parsing errors.
> > 
> > maybe its not your job to fix the demuxer, but you worked around the bug
> > in the demuxer by joining split slices in the decoder this is unacceptable
> > and the rv30/40 decoder is rejected as long as this code is in it
> 
> I think it's container design bug. If you see any way how demuxer can join slice end
> by using only container data then I will write a patch (like I did for multiple
> slices in packet case).
> 
> But I could not find the way to determine if it's a loose end or another slice
> without parsing its header.
> 
> Well, I'm awaiting your suggestions on how to resolve this situation and remove that
> workaround.

I have a principle I?m always pushing in MPlayer and FFmpeg circles,
that when something is broken, the workaround should always be
isolated as close as possible to the code for handling the broken data
type. Even if this requires doing things that are in principle very
bad, the badness does not pollute the rest of the codebase ? or worse
yet, other containers when someone decides to use streamcopy.

In this case here, if the Real container stores frames in a broken
way and you need to parse a bit of the packet header to determine
whether you have more slices to get, then by all means do it. It?s
?wrong? but less wrong than forcing unrelated code elsewhere to have
to special-case the badness to prevent writing bad files.

BTW, isn?t there a way you can use pts to determine if slices belong
to a common frame? Or is the pts missing? If pts is missing and must
be computed by # of frames, then you?re already in a bit of trouble
since you won?t be able to assign pts to any subsequent data without
knowing where the frame boundaries are....

Rich