[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.117,1.118

Michael Niedermayer michaelni at gmx.at
Fri Mar 3 17:59:15 CET 2006


Hi

On Fri, Mar 03, 2006 at 10:28:50AM -0500, Rich Felker wrote:
[...]
> > current lavc will segfault with almost all codecs an some cpus if you feed 
> > unaligned buffers into it, this can be fixed in lavc for most relatvely easily
> > but it nicely shows how many people do such weird things, IMHO the whole
> > zerocopy thing is idiotic, its like the singlethread player is always
> > supperior rule, thers no question that fewer copies, fewer threads and
> > less synchronization between threads is better, but its not like that
> > could be changed in isolation, other things depend on it and the 1%
> > you gain here might cause a 50% loss somewhre else
> 
> Perhaps you'd like to demonstrate that mplayer is only 1% faster than
> the competition? Last I checked it was more like 10-200%, depending on
> which other player you're comparing to. Naturally this is not a result
> of being non-threaded by itself. It involves many factors, which
> include a reduction in the number of wasteful copies, lack of need for
> thread synchronization, and many other things I have no idea about.
> But you know as well as anyone else in ffmpeg development that many
> small things add up to huge performance advantage over the
> competition.

mplayer might beat xine, ffplay and others by 1-200% in raw performance, but
guess which player did i use yesterday to watch the 4th episode or AIR?
ffplay, why? because mplayers video output was not fluid/smooth and no messing
with its options helped, yes xine was almost as good as ffplay, mplayer was
far behind
and yes the file was not local on my hd (no space) but on another computer and
i viewed it over shfs which isnt the most bugfree thing so you can argue thats
the reason why but still in practice the 1-200% where not what mattered ...


[...]
> 
> > then there are non interleaved files and seeking in which cases
> > a pure mmap variant on 32bit seems problematic
> 
> No, non-interleaved case is easy. You simply treat it the same as
> -audiofile, i.e. open the file twice and treat the audio and video
> parts separately. This is needed anyway to make -cache work. The
> special-casing for non-interleaved AVI in MPlayer is a stupid hack.

there might be more then 2 streams in a non interleaved file ...
and theres some wasted memory in case of double opens (index for example)

and theres the issue with seeking independant of interleaving
how do you do a binary search with that single buffer thing

[...]

-- 
Michael




More information about the NUT-devel mailing list