[MPlayer-dev-eng] Re: [MPlayer-users] Re: lavc-Options for *BEST*

Michael Niedermayer michaelni at gmx.at
Wed Feb 5 10:44:59 CET 2003


Hi

On Wednesday 05 February 2003 10:00, Arpi wrote:
[...]
> > > * cutable (just chop it up and still be able to decode the fragments)
> >
> > How does cutting work with codec/stream/global headers? Perhaps the
> > spec should require the player to keep seeking forward until it finds
> > these headers if they're not right at the beginning. That way we could
>
> sure.
> or they should be stored at every keyframes.
> i don't think that 50-100 bytes can hurt compared to 50-100kByte of
> keyframe.
agree, if the overhead per keyframe is <0.5% in reallity (that would need some 
tests though ...)

[...]
> > > index
> > >   compressed (with bzip2 at least if noone has a better idea)
> > >
> > :))
>
> don't laugh
> that 4-8mb index at avi files could be stored in a few 100kbytes.
> just left out file positions, and mix flags into chunk sizes, and
> you already reduced 16 bytes/frame to 4 byte/frame.
> do some vlc and you have 2 bytes/frame.
and if we store just approximate positions (actually chunk sizes) (with 256 
byte precission) then we should be able the store it in 1 byte/frame, the 
exact position can be found trivially by searching the 256 bytes for the 
64bit startcode

>
> > Yes, see above. Overall, excellent! I'd like to see what Arpi has to
> > say.
>
> i think the only problem is that it's nonsense.
> why?
> these formats are coming from the windows world.
> just look at teh codecs: are they using libavcodec to encode dvdrips?
> no. they're using crappy divx4 and nowdays sometimes buggy xvid...
> why? because they are available under windows...

> (unfortunatelly the ffvfw project has died or sth)
seems so :(

>
> so unless you code a dshow filter and support to nandub/vdub for this
> fileformat it won't spread and being used.
i know :(

but perhaps we could cooperate with the ogg ppl to improve ogg, an official 
ogg2 should spread much better then an unknown container format

[...]

Michael


More information about the MPlayer-dev-eng mailing list