Hello, On Thu, 30 Oct 2003, Alex Beregszaszi wrote:

...

- for(qscale=1; qscale<32; qscale++){ + for(qscale=qmin; qscale<qmax; qscale++){

[cut]

...

j->s->q_intra_matrix16, - j->s->q_intra_matrix16_bias, - j->s->intra_matrix, j->s->intra_quant_bias); + j->s->intra_matrix, j->s->intra_quant_bias, 1, 31); return j; Why not 1-32 as it was in the original version? I looked into it, and your suggestion to call convert_matrix(..., 8, 8) (just as in libavcodec/mpegvideo.c) was correct. I got blocks on the screen because of an off-by-one error in the convert_matrix() function in jpeg_enc.c. (and my quick fix was to mess with the last two parameters of convert_matrix to get the image to appear right on the TV)

A CVS commit will follow shortly. Greetings, Rik. -- Nothing is ever a total loss; it can always serve as a bad example.

Hello, Some ramblings... On Fri, 31 Oct 2003, Alex Beregszaszi wrote:

...

A CVS commit will follow shortly. Btw, I'm really interested in moving away jpeg_enc to libmpcodecs. Some months ago I hacked vf_lavc to output mjpeg, but vo_zr was built around jpeg_enc. Are you interested in making vo_zr independent from jpeg_enc and moving jpeg_enc to filter layer aswell? 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) 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). I think it will be best to do this change in four steps. 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...)) 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) 3. Add vf_zrmjpeg.c, at first it will be jpeg_enc.c including a vf_wrapper. 4. Remove vo_zr.c if vo_zr2.c is better in every way. 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)

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. -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. -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) -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. So, the process of switching to libavcodec while keeping the performance, features and possibe future optimalisations of jpeg_enc.c seems very daunting to me. I like the simplicity of jpeg_enc.c, but I don't like the fact that some functions of libavcodec are duplicated because they are declared static in libavcodec... 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? Greetings, Rik. -- Nothing is ever a total loss; it can always serve as a bad example.

Hello,

On Sat, 1 Nov 2003, Alex Beregszaszi wrote:
> > 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.
There are two problems: 
- it must be known at config() time whether the incoming MJPEG
stream is interlaced.
- vo_zr2 must decide at query_format time if it can handle the MJPEG
stream, so it must be able to see if it is a zoran-compliant MJPEG stream
from the format parameter.

The MJPEG passthrough filter should perform some sanity-checks on the
first MJPEG frame and decide if it can be decoded by the zoran hardware
decoder, and if it is interlaced or not. (the first frame is available to
the passthrough filter during init, right?) If the first frame is
zoran-compliant it should set IMGFMT_MJPEG and IMGFMT_ZRMJPEG(_INTERLACED)
as supported output formats, otherwise just IMGFMT_MJPEG.
 
> > 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
Yes.

> > [multiple output/cinerama..]
> Maybe we should start the whole work in G2? G2 has plans for this
> multiple output support.
Well, I will write vo_zr2 in such a way that it is re-entrant. The
whole state of the driver is saved in a private data structure, so
that the same driver can be used for multiple cards. (the pointer to the
private data structure would need to be passed to vo_zr2.c, this is 
the case in G2 (vo->priv)). It will be easy to port it to G2.

Greetings,

Rik.

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

On Mon, Nov 03, 2003 at 12:24:11AM +0100, Diego Biurrun wrote:

rsnel@cube.dyndns.org writes:

...

(which is broken at this time though, but can be fixed by moving the -zr* options to the subdevice)

This btw has been in the wishlist for quite some time so you will earn some good karma if you do it.

vo_zr2 will have options in the subdevice, vo_zr should be obsolete (and removed) 'soon'. -- Nothing is ever a total loss; it can always serve as a bad example.