[MPlayer-users] Re: divx 6

[Rich Felker]

On Fri, May 05, 2006 at 07:07:35AM +0200, Mathieu Monnier wrote:
> Just a few random remarks :
> 
>  - GMC can improve the PSNR ( I've seen +0.1 dB at same file size, on 
> some rare files ), but visually, it'll be hard to see its usefulness. I 
> don't consider GMC to be that hackish - after all, it integrates itself 
> rather nicely in the macroblock bitstream.
>  - MP4 has a great advantage over raw video : it's seekable. Don't 

So is MPEG4-ES. Frames have timestamps and startcodes, thus they're
seekable. If your program sucks too much to seek, then fix it.

> forget that the only reason Doom9 chose to use Ateme's decoder was that 
> FFDShow was seeking inaccurately.

LOL.. This is just because the whole dshow framework is crap. It's not
the codec's responsibility to seek to non-key frames, this belongs in
the player. In a good design it's not even _possible_ for a codec to
do this.

> In that regards, MP4 is a consistent 
> choice. It has a normal overhead, it can contain the audio used in his 
> test, and it handles bframes properly. I'd have chosen MKV ( and I 
> wouldn't have bothered with audio ), but that's my own opinion. Anyway, 

Any sane person would have done the same as you.

> all mpeg4 ASP codecs were treated equally container wise.

Arrg RTFemail!! Of course the container is not "unfair treatment". It
just means doom9 is an idiot.

>  - DCT drifts may or may not have occurred, for XviD, lavc, or DivX. 
> Nobody ever cared to check what IDCT was used by default on windows, and 
> for which codecs the drifts happened. Anyway, Doom9 still compared, at 
> your request, the XviD and Lavc file with FFDShow ( but then comes the 

FFDSHOW IS NOT LIBAVCODEC!!!!!!!!!!!!!!!
It's a modified windows build of libavcodec with dshow wrapper around
it. The defaults have been KNOWN to be different in past versions and
may be now. I have no idea what IDCT it uses by default.

> MP4 container, without fourcc, and I don't know whether lavd can rely on 
> the userdata to make its IDCT autodetection. Anyway, there again, both 
> Xvid and Lavc can have DCT drifts ).

Drift is not the issue, it's errors at the individual frame level.
Read the original thread on ffmpeg list.

>  - apart from Rich, which seems allergic to anything coming out of this 
> test, others seem to have acknowledge the results : vb_strategy=2 is 

Again, selectively ignoring me. In one of the very first emails in
this thread, I noted that due to the tests, bugs were found both in
libavcodec and xvid. This does not make the test legitimate.

Rich