[MPlayer-users] Re: divx 6

[Mathieu Monnier]

> So is MPEG4-ES. Frames have timestamps and startcodes, thus they're
> seekable. 

Ok, then why is there an index in NUT, MP4, AVI, MKV... ?

> 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".

Fair enough

> It just means doom9 is an idiot.

*sigh*. Repeating it won't make it true. He's as stubborn as you are, I 
can grant you that. His container choice & argumentation were a little 
odd. He didn't take care of the possible IDCT drift issue, but it wasn't 
technically possible for him to do so, under his constraints. At least 
he did the test. He invested a lot of time in it. It wasn't perfect, ok, 
but who could be able to make a perfect test anyway ?

> >>  - 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!!!!!!!!!!!!!!!

Ok, you don't trust ffdshow. Ok, it has been broken in the past. So has 
mplayer, hasn't it ? Yet you forgave mplayer, but not ffdshow. Of 
course, you can't forgive ffdshow since you don't use it. Well, a 
windows program - you'll be amazed to learn - can be fixed. Even if 
there's dshow in its name.

Anyway, since dshow is the only way ( or rather, the only way i can 
think of ) to get all the participating codecs to use the same video 
renderer on windows, you have to bear with it. Acknowledging that, you 
should admit that ffdshow is the best candidate to decode lavc, in the 
dshow framework.

>> 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.

I'm well aware of these. But then, the bug was XviD's fault, and the 
file could be played back ""correctly"" only with XviD. So, actually, 
XviD, because of this bug, was even more disadvantaged. But lets not 
talk about that anymore, since

>>  - 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.

Ok, i reread your first contribution to that thread, and, indeed :

 > During the test bugs were discovered both in lavc and xvid. The lavc 
  > bugs were quality issues

Alas, I'm afraid that was lost in all the swearing that ensued.

So indeed, you acknowledge that at the time of the test, XviD, though 
uncompliant, was producing a better quality than lavc at more than twice 
its speed. You say things have changed since then. Well, I'll eagerly 
wait for next Doom9's test to confirm that :p

Regards,

Mathieu