[MPlayer-users] Re: divx 6

[Rich Felker]

On Fri, May 05, 2006 at 10:56:21PM +0200, Mathieu Monnier wrote:
> 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, 

"At least he did the test"?? A misleading, improper test is much worse
than no test at all!

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

Huh? The issue is, we know mplayer and how it works, and the lavc
developers test using mplayer, vlc, ffplay, etc. -- programs that use
libavcodec directly and use the official version. Due to historical
brokenness and lack of any interaction with ffdshow developers I have
no idea what to expect from ffdshow. I know in the past they've
changed the defaults on things like IDCT.

At this point it may or may not do the same thing as official
libavcodec. However if doom9 wants to use this software and claim it's
"libavcodec" then it's up to him to investigate and verify that it's
the same.

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

No, there is absolutely no reason that the same "video renderer" needs
to be used. Even if you do insist on that, using mplayer would have
worked perfectly well for all of the codecs being tested, and works
just fine on windows.

> Acknowledging that, you should admit that ffdshow is the best
> candidate to decode lavc, in the dshow framework.

No.

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

More disadvantaged? More disadvantaged in what? The XVID IDCT issue
was a completely separate thing a few weeks before the doom9 tests.
Using a proprietary decoder of course makes it impossible to tell
exactly what IDCT algo is being used, but I would assume that a
company that wants their software to look good is going to make sure
it matches XVID IDCT when decoding XVID... None of doom9's XVID
screenshots showed artifacts like the ones discussed on ffmpeg-devel
regarding the IDCT issue.

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

No. I acknowledge that XVID and lavc both had bugs at the time, and
that some of the lavc bugs affected quality. I have never seen a
legitimate comparison of xvid and lavc and in the absence of one I
have no position on which produced better quality at the time, or
which produces better quality now. If you want to make a legitimate
comparison, be my guest. But I'm sick of people putting words in my
mouth.

As for performance I will assume the numbers are correct, though this
is probably giving doom9 more credit than he deserves.

> You say things have changed since then.

Huh?!? Where did I ever say something to that effect??

Rich