[MPlayer-cvslog] r31359 - in trunk: configure libmpcodecs/vd_libmpeg2.c libmpeg2/header.c libmpeg2/libmpeg2_changes.diff libmpeg2/slice.c

[Ivan Kalvachev]

On 6/10/10, Luca Barbato <lu_zero at gentoo.org> wrote:
> On 6/10/10 12:39 PM, Ivan Kalvachev wrote:
>> It's good to discuss this kind of changes on the maillist not with one
>> single developer, to avoid confusing situations like this.
>>
>> I am surprised that you fail to understand basic concepts like how
>> postprocessing works and that you can't even test it properly.
>
> That code from what I could see is DEAD CODE, if isn't then it will
> rewritten as an opaque pointer + callback.

What is your definition of "DEAD CODE"?

Look at the very commit message, MPEG12_POSTPROC is/was
unconditionally defined in the configure, and the undefine in libmpeg2
is/was commented out//.
That code was very much working.
If I am wrong I would like to hear exact arguments, not just shout at me.

But even if it have been disabled by some obscure reason, it should be
treated as regression.


So please, start working on solution. And if you think that it would
take you more than 2 days, you'd better revert to the original code
until you are done.

Also, I don't see what use would be the callback. The quant store code
is in macro because it is tapping speed critical section, callback
there would be speed killer.

>> You need to insert postprocessing filter, like  pp, spp, fspp. The
>> quant info is used by these filters. Also you for best results you
>> need sample with less than perfect quality (aka with visible
>> blocking).
>
> I'll check now and see how much it does change. We might take this as an
> opportunity to document this requirement for vd (still I miss how this
> "quant info" would work with non-mpegish codecs that might have
> different parameters to describe it)

There are other parameters, some of them define the type of the quant,
aka h263 vs mpeg. I'm not sure if h264 is supported, but its
loopfilter makes postprocessing waste of time.


>> Without way to export quantization, libmpeg2 is pretty much crippled.
>>
>> This functionality should be pushed upstream, so it could be
>> implemented in cleaner standard way. Then it can be replaced.
>
> Let's ask upstream IF is that compelling.

IMHO, internal libmpeg2 have been kept mainly because they didn't
implement the quant export functionality.