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

[Arpi]

Hi,

> Hmm, what are you saying? Are there any formats right now that don't
no

> totally suck? Perhaps .mov/.mp4 is ok; I don't know anything about it.
NO!

> But all the rest (avi, asf, ogm, ...) are quite bad.
no...

mov/mp4 sucks even more than avi...
you cannot play a mov without the index.
and you have to seek inside the file...
the word 'qt streaming' is a joke, it means 'wget with very big buffer'...
(try to play any streamed qt with qt player and watch your temp dir - it
just downloads teh file and plays the already downloaded part).

i've found asf the best until now... it still have problems, but at
least seekable without index, low overhead, error correction, etc.
but anyway inserting/removing bytes damage asf too.

> > i guess the primary goals should be:
> > * low overhead (ppl seem to care alot about 0.5% ... )
> > * optional index (undamaged files should allways have one)
> 
> Should index be at the beginning or the end? IMHO, from a player's
> perspective, it makes a lot more sense to have it at the beginning, so
> you don't have to seek to the end of the media. Also this is nice for

and from encoder's perspective it's better at the end...

> > * simple 
> 
> Oh well, guess we can't use MCF... :)))

sure. a c++ library to parse a crappy fileformat is silly anyway

> > * 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.

> Also, another idea... Perhaps there should be a "reset pts timer"
> packet or something similar at the beginning of files, so that when
> you cat two files together, the player knows that all timestamps in
> the second file are starting from a new base. Or perhaps there's a
> different way to handle this...

i like the relative pts better

> > 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.

> 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)

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


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
    "However, many people beg for its inclusion in Debian. Why?" - Gabucino
  "Because having new software in Debian is good." - Josselin Mouette
"Because having good software in Debian is new." - Gabucino