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@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)