[Mplayer-cvslog] CVS: main/libvo jpeg_enc.c,1.17,1.18

[Alex Beregszaszi]

Hi,

> Moving jpeg_enc to the filter layer is doable. Two new IMGFMT's will
> be needed, like
> 
> IMGFMT_ZRMJPEG (YUV422, width%16==0, height%8==0)
> IMGFMT_ZRMJPEG_INTERLACED (two concatenated JPEG images of halve
> height)
Imho IMGFMT_MJPEG is ok for it (mpi can/should handle interlacing flag),
and the filter should handle different styles of mjpeg. So for example
-vf lavc=format=mjpeg:favor=zoran should do the job.

> The ZR is there to signify that the JPEG images need to have special 
> properties, ordinary MJPEG streams from webcams for example, won't
> work with zoran boards because the colorspace is wrong (YUV420). 
For that imgfmt=yuv422 should do the job.

> 1. Add new zr driver (vo_zr2.c, for example), which only accepts 
> IMGFMT_ZRMJPEG* (and complies with the 'multiple config calls are 
> alllowed'-rule (vo_zr still doesn't...))
Ok.
 
> 2. Add passthrough driver (analogous to vd_mpegpes) (for quick
> testing, passthrough will also be useful because mplayer will then be
> able to emulate the behavour of lavplay from the mjpegtools)
That already exists in my 'implementation'
 
> 3. Add vf_zrmjpeg.c, at first it will be jpeg_enc.c including a
> vf_wrapper. 
Better would be copying jpeg_enc.c to vf_zrmjpeg.c and later remove
jpeg_enc.c
 
> 4. Remove vo_zr.c if vo_zr2.c is better in every way.
Yes
 
> One major obstacle is cinerama support. (which is broken at this time 
> though, but can be fixed by moving the -zr* options to the subdevice)
> Ideally the -vf layer will allow multiple output devices, and multiple
> instances of the same output device (where possible).
> 
>                              crop=left_part:vo=x11,display=localhost:0
>                            /
> movie -> scale=bla:split -
>                            \
>                            crop=right_part:vo=x11,display=otherhost:0
> 
> The current cinerama functionality of the zr driver could then be
> replaced by doing vo=zr2,dev=/dev/video0 and vo=zr2,dev=/dev/video1 in
> the example.(also the crop filter could be enhanced to accept
> IMGFMT_ZRMJPEG* data; JPEG files can be easily cropped at macroblock
> boundaries)
Maybe we should start the whole work in G2? G2 has plans for this
multiple output support.
 
> > Or better, backport your improvements to ffmpeg.
> There are a few things which need to be added (in some way) to
> libavcodec:
> 
> -support for black and white encoding (is already implemented for
> other codecs), will probably be easy.
yes
 
> -support for the creation of YUV422 jpeg from YUV420 and YUV422 data.
> If agreement is reached about in which way this will fit in the
> current libavcodec, it will probably be doable.
i planned that since ages, as lot of windows mjpeg decoders only support
422
 
> -support for very generic buffer specification of the source image to
> facilitate horizontal decimation. (hard, the functionality could be 
> replaced by a filter in the -vf chain, but at a performance loss)
> (the workings of the 'very generic buffer specification' in
> jpeg_enc.c, are explained in the comment preceding jpeg_enc_init)
will have a look at it
  
> -support for creating interlaced ZRMJPEG from non-interlaced YUV420
> data with the following optimalisation (this optimalisation currently
> does not exist in jpeg_enc.c): the JPEGs of the odd and even frame
> will be created in parallel so that the U and V planes only need to be
> encoded once. This should give a 33% performance increase. (now, the
> first and second field also have the same UV data, but it is encoded
> twice because the fields are encoded seperately). The source needs to
> be non-interlaced to make sure that the color on the first U and V
> line matches with the first two lines of Y.
generic interlaced encoding support into lavc
 
> I am, however, interested starting to create a new, clean vo_zr2.c and
> corresponding filters. Alex, do you agree with the 'four step plan' 
> presented above?
yes with my changes :)

-- 
Alex Beregszaszi <alex at fsn.hu>
(MPlayer Core Developer -- http://www.mplayerhq.hu/)