[MPlayer-dev-eng] [RFC] rc2 at the beginning of October

[Michael Niedermayer]

Hi

On Sat, Sep 29, 2007 at 12:03:18PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Sep 28, 2007 at 09:30:15PM -0400, Rich Felker wrote:
> > On Sat, Sep 29, 2007 at 12:38:55AM +0200, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Fri, Sep 28, 2007 at 06:41:47PM +0200, Diego Biurrun wrote:
> > > > On Mon, Sep 24, 2007 at 07:28:39PM +0300, Siarhei Siamashka wrote:
> > > > > 
> > > > > Are there any known regressions related to using lavf for avi files in 
> > > > > mplayer?
> > > > 
> > > > AFAIR the libavformat AVI demuxer does not support noninterleaved AVI
> > > > files.
> > > 
> > > who is spreading that lie?
> > > of course does the lavf demuxer support non interleved AVI
> > 
> > How does this work? Does it continually seek back and forth? 
> 
> yes
> 
> 
> > It sounds
> > like the dual demuxer instance idea I proposed would be a better way
> > to handle NI files..
> 
> maybe, this all depends on the OS and the AVProtocol implementation and
> other related things ...
> a well written os will detect the
> multiple chains of sequential reads and read ahead a lot more into a cache
> a not so well written OS would still always read ahead a little, and a OS
> which doesnt read ahead at all will be very slow for many more things
> than just this case here
> 
> so for lavf alone there really isnt much of a problem with the design
> the problem mainly appears with mplayers cache which AFAIK always reads
> ahead alot but then always flushes this during seeks?
> i think fixing the cache so it can keep 2+ instead of 1 block would be
> a better solution
> but i dont know the mplayer cache code at all so maybe iam wrong ...
> 
> also besides all this, opening things multiple times will cause problems
> with some ftp and http servers which have limits on the number of concurrent
> connections
> and 2 demuxers will consume more resources (memory mainly) than 1
> 
> and all that for files which are rare and which one could consider broken
> 
> but noone stops you from implementing support in demux_lavf.c to open
> a file n times for n streams

additionally, we shouldnt forget that AVIs arent always properly interleaved
or completely non interleaved, theres the intermediate of wrongly interleaved
ones for which 2 demuxers will read everything twice

and theres mov and mp4 which (like NI avi) just give you a table of offsets
and sizes with which you read the frames, that is its perfectly valid to
store them like
A5 A1 A2 B8 A4 B1 A3 ... :)

here 2 demuxers wont help either while a smarter cache would

also theres the possible solution of having 1 demuxer and 2 caches with a file
opened twice
and the cache routing the reads depending on pos to the proper (sub) cache
this seems like it could handle a failed second open much better

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/mplayer-dev-eng/attachments/20070929/63c963f8/attachment.pgp>