[MPlayer-dev-eng] Wishlist round 2

rsnel at cube.dyndns.org rsnel at cube.dyndns.org
Thu Aug 29 17:27:38 CEST 2002


Hello,

On Thu, 29 Aug 2002, Alex Beregszaszi wrote:
> > Four points for the wishlist:
> >   * seeking in realmedia files
> it's working since years (you need to use -idx or -forceidx)
> also i havn't tested it with the new real codec interface, but with
> audio-only files and rv10 it's working right (expect the a-v sync, but
> it's bad anyway with rv10)
Ah yes, it is even in TFM... I should R it more... (sync seems to be fine
for non-rv10 files)

> >   * A 'cinerama' video filter that can be used to distribute the frames
> >     over different (instances of) vo devices. (as in: 'send the left part
> >     of the movie to THIS (+parameters) vo driver and send the right part
> >     to THAT vo driver) The zr driver can do this, but I feel that it is
> >     the job of the MPlayer core and not of the video output drivers.
> hm, use ggi? :) it can do that
Hypothetical example of how the -vop commandline may look in the above
case. Assume the movie is 640x288 and output is two tv's, one at
/dev/video0 (left) and the other at /dev/video1 (right).

mplayer -vop vo=zr:/dev/video0,crop=320:288:0:0,{vo=zr:/dev/video1,\
crop=320:288:320:0}=split movie.avi

(it looks a bit weird in right-to-left mode) It reproduces mpi's (without
memcopy of course) and sends the reproduced one through the chain between
the { }. The 'original' mpi's are sent through the part of the chain after
the {. (after as in 'right to left'). vo specific options should be in the
'subdevice', in this case, to make clear for which device they are meant.

> >   * Move the zoran jpeg encoder to the video filters. This can only
> or (better?) merge it back into lavc (i'm willing to help in that)
I have no incentive to put the jpeg encoder in libavcodec. I want to have
enough freedom to implement paralel encoding for interlaced output (do the
color planes once (25% gain), this means using 2 bitwriters and two
buffers) and I find this stuff too specific to try to fit it in the
libavcodec achitecture.

Greetings,

Rik.

-- 
Nothing is ever a total loss; it can always serve as a bad example.






More information about the MPlayer-dev-eng mailing list