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

Michael Niedermayer michaelni
Wed Sep 19 20:37:11 CEST 2007


Hi

On Wed, Sep 19, 2007 at 02:25:54PM -0400, Rich Felker wrote:
> 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....

there is a timestamp yes, and it likely could be used but i dont think this
is needed, as theres also a bit which marks the end of frames (h & 0x80) or
something similar. also theres pos which is 0 at the start of frames

so there really are MANY ways to detect the start and end of frames

there just isnt an obvious way to detect split slices but what i was
trying to say is that this is not needed as the demuxer should not
return slices but frames, mplayer does it that way and the binary
decoder as well expects frames not slices

the lavf demuxer does something silly that is return slices and that
causes the problem as far as i can see

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20070919/94d9c344/attachment.pgp>



More information about the ffmpeg-devel mailing list