[MPlayer-advusers] large files old-incoming review

Reimar Doeffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Fri Jan 26 16:09:23 CET 2007


Hello,
On Fri, Jan 26, 2007 at 03:34:50PM +0100, Diego Biurrun wrote:
> On Fri, Jan 26, 2007 at 10:30:50AM +0100, Reimar Doeffinger wrote:
> > On Fri, Jan 26, 2007 at 02:42:06AM -0500, compn wrote:
> > > /!under_checking/ra_problem.tar.bz2
> > > AUDIO: 16000 Hz, 1 ch, s16le, 16.1 kbit/6.29% (ratio: 2012->32000)
> > > Selected audio codec: [rasiprwin] afm: realaud (Win32 RealAudio Sipro)
> > > works
> > > delete unless you need for testing ffsipr in the future....
> > > 
> > > !unknown/e32k3-halflife2_pce32003_8dn_qt.mov
> > > seems to desync completely on last frame
> > > b-frame support missing in ffsvq3
> > > works with binary codec
> > > delete
> > 
> > IMO it is a good idea to keep such samples if we don't have any yet. If
> > they are big we could add a .txt with a request for smaller samples to
> > the directory...
> 
> I think we have examples of SVQ3 that ffsvq3 fails to decode.
> 
> > > !under_checking/703.wmv
> > > display is warped with wmv8 binary codec
> > > displays fine iwth ffwmv2 (but j-type picture errors)
> > > colorspace problem?
> > 
> > Maybe we should collect those J-type samples in case someone should want
> > to implement them...
> 
> I think we have plenty of those samples.  They're not really hard to
> come by.

Well, we have altogether "only" 6 wmv2 samples... None of these have a
name that would make it obvious if they contain J-Frames.
Finding samples is not difficult I admit (though it still is an effort),
but there is hardly a better reason to keep a sample than that it
illustrates a common problem...

Greetings,
Reimar Doeffinger



More information about the MPlayer-advusers mailing list