[MPlayer-users] Re: divx 6

[Mathieu Monnier]

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 
forget that the only reason Doom9 chose to use Ateme's decoder was that 
FFDShow was seeking inaccurately. 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, 
all mpeg4 ASP codecs were treated equally container wise.
  - 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 
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 ).
  - the multithreaded encoding was discarded by Corey and Rich during 
the pretests, because the speed gain was not worth the quality loss. So 
you can't complain about that. XviD wasn't multithreaded at the time of 
the test ( "and recently there has been some SMP optimization, but the 
release of those optimizations was too close to the deadline to make the 
test." )
  - apart from Rich, which seems allergic to anything coming out of this 
test, others seem to have acknowledge the results : vb_strategy=2 is 
commited two day after the results, Corey is working on XviD's RC 
integration. Nobody seems to criticize lavc raw coding efficiency, which 
indeed seems a bit higher than XviD's.

Regards,

Mathieu