Log in

View Full Version : New FFDShow versions can't render well


Delerue
12th December 2006, 03:39
After 'ffdshow-rev2529-SSE2' I can't find a version that can render some movies well. Below you can see the difference between any new version and the version above. Believe me, I tried more than 20 versions (with or without MMX or SSE or SSE2, doesn't matter) including the last one from today!

Any version:
http://img.photobucket.com/albums/v256/Delerue/ffdshow-any.jpg

rev2529-SSE2:
http://img.photobucket.com/albums/v256/Delerue/ffdshow-rev2529-SSE2.jpg

As you can see, there's a lot of strange artefacts (lines) in the first image, specially in the right side of the door entrance. I'm using all the options by default, except for 'postprocessing' that is disable in both cases. The player used: MPC (and doesn't matter the render...) on a Sempron 3000+@2.6 Ghz with a Radeon X800XL (last Catalyst version). The movie tested: Nackt (from Germany), encoded with DIV3.

Someone can explain to me what's happening?

Thanks a lot, guys.
;)

zambelli
12th December 2006, 04:07
Does it happen only in XviD/MPEG-4 encoded videos?

Delerue
12th December 2006, 04:28
Does it happen only in XviD/MPEG-4 encoded videos?

To be honest, I only tested this movie, because when I downloaded the version after 'rev2529-SSE2' I was making the portuguese subtitles for this movie, so, knowing each scene very well, it was easy to notice the difference. :)

BTW, I saw right now that VLC says that this movie file uses DIV3 codec.

foxyshadis
12th December 2006, 05:46
Try changing the IDCT, in decoder options. I think the current default is libmpeg2. Try auto, simple mmx, xvid mmx. If one of those doesn't work, I doubt any others would. If that still doesn't fix it, a sample of that one scene would be helpful, although it might have to be forwarded to the ffmpeg guys.

Delerue
12th December 2006, 06:25
Try changing the IDCT, in decoder options. I think the current default is libmpeg2. Try auto, simple mmx, xvid mmx. If one of those doesn't work, I doubt any others would. If that still doesn't fix it, a sample of that one scene would be helpful, although it might have to be forwarded to the ffmpeg guys.

Hmmm... Worked setting to 'auto'. Strange that DEVs choose a default option that doesn't work well, don't you think?

Thanks, man!

igor1st
12th December 2006, 07:03
Divx3 is real encoder for this file or maybe it has only fourcc=div3?

If you could give us a sample, it'll be very useful.

foxyshadis
12th December 2006, 07:11
libmpeg2 is more accurate for 'real' mpeg-4, along with mpeg-2 and 1 as you'd expect. But if it produces bad results for msmpeg4 and family, it's a bug.

I forget the exact reason why it was chosen, I'll have to look it up and see if something can be done.

Delerue
12th December 2006, 07:37
Divx3 is real encoder for this file or maybe it has only fourcc=div3?

If you could give us a sample, it'll be very useful.

I don't know how to answer your question and how can I extract a sample, but if it helps, I can show you another two SS of a different movie ('Playing By Heart'):

http://img.photobucket.com/albums/v256/Delerue/ffdshow-any-pbh.jpg

http://img.photobucket.com/albums/v256/Delerue/ffdshow-rev2529-SSE2-pbh.jpg

I think that any DIV3 video has this bug when IDCT is set to 'libmpeg2'.

sillKotscha
12th December 2006, 09:04
I don't know how to answer your question and how can I extract a sample

why would showing another two pictures would help identifying your file (used codec/ used fourcc) ??...

his question was/is...

do you know if Divx3 is really the used codec for the file or maybe only the fourcc is set to "div3" but another codec was/ is used...

if you don't know the answer(s) then it would be best to upload a small snippet of your file... say 10 seconds

extracting small fragments of a video file is BASIC video editing knowledge and before saying 'I don't know how?' you should search around - hint: loading your file into virtualdub -

and be careful with further answers... it very clearly seems that you didn't encode that file for yourself (else you would know the codec you used to encode the file)

clsid
12th December 2006, 13:39
If this problem can be reproduced for all divx3 and/or msmpeg4 videos, then we can implement a workaround for those formats to always use a particular iDCT.

KoD
12th December 2006, 15:02
As already mentioned in the ffdshow thread, iDCT algorithms used by various ASP codecs can cause different image results. The best option is auto, to let the decoder decide which idct algo to use based on the fourcc (I also think it does a bit of stream analysis as well, at least as far as I remember from the ffmpeg changelog notes regarding idct). Even Xvid changed its idct algo sometime around 2004, so files encoded before that with xvid will give artifacts when libmpeg2 is used.

Here's again the link to one page that speaks of this issue click me (http://guru.multimedia.cx/the-mpeg124-and-h26123-idct/).

All that's needed is to use "Auto" instead of forcing the use of libmpeg2 for iDCT.

Delerue
12th December 2006, 18:45
why would showing another two pictures would help identifying your file (used codec/ used fourcc) ??...

Just to prove that the problem isn't with a specific movie file, but with all DIV3 encoded files.

do you know if Divx3 is really the used codec for the file or maybe only the fourcc is set to "div3" but another codec was/ is used...

I undestood now. Well, 'Nackt' doesn't work with VirtualDub, but 'Playing by heart' does, so I extract a sample enconding to DIV3 and guess what... no problems. So, I think that the movie was encoded with real DivX3, not FOURCC.

extracting small fragments of a video file is BASIC video editing knowledge and before saying 'I don't know how?' you should search around - hint: loading your file into virtualdub -

Man, be more patience. I'm not an expert. I'm here to learn. :)

Delerue
12th December 2006, 18:53
If this problem can be reproduced for all divx3 and/or msmpeg4 videos, then we can implement a workaround for those formats to always use a particular iDCT.

Well, I tested right now with another movie ('The Vanishing') and the problem is the same when IDCT is set to 'libmpeg2'. Three of three movies tested have the same problem, so maybe is safe to say that's a general problem with DIV3 codec, ahn?

clsid
12th December 2006, 19:07
As already mentioned in the ffdshow thread, iDCT algorithms used by various ASP codecs can cause different image results. The best option is auto, to let the decoder decide which idct algo to use based on the fourcc (I also think it does a bit of stream analysis as well, at least as far as I remember from the ffmpeg changelog notes regarding idct). Even Xvid changed its idct algo sometime around 2004, so files encoded before that with xvid will give artifacts when libmpeg2 is used.

Here's again the link to one page that speaks of this issue click me (http://guru.multimedia.cx/the-mpeg124-and-h26123-idct/).

All that's needed is to use "Auto" instead of forcing the use of libmpeg2 for iDCT.
The only problem is that the "auto" method in ffdshow doesn't always select the best suitable iDCT method. So that needs some improvement. Currently there is not much code in ffdshow for iDCT selection.
The iDCT issue was discussed some time ago in the ffdshow thread and the conclusion was the using libmpeg2 by default was the best solution to get proper playback of the majority of files.

F_L_C
12th December 2006, 19:37
If this problem affects xvid/divx, I'd say do it clsid. It may not be optimal for mpeg1 or mpeg2, but I'd say the vast majority of ffdshow users use ffdshow specifically for xvid/divx and not mpeg1(2).

foxyshadis
13th December 2006, 08:35
If this problem affects xvid/divx, I'd say do it clsid. It may not be optimal for mpeg1 or mpeg2, but I'd say the vast majority of ffdshow users use ffdshow specifically for xvid/divx and not mpeg1(2).

These files are waaaaay pre-xvid. It should only affect the original divx ;-) codec, along with the msmpeg4/wmv7/wmv8 codecs that were closely related to it.

F_L_C
13th December 2006, 20:38
Oh, all right. While you and clsid are here, which setting should be used for those who only use ffdshow for modern xvid/divx and no other formats? Should it be left at default libmpeg2 or something else like xvid mmx? I have an Athlon XP cpu.

I'll probably be able to find info about this in the monstrous ffdshow thread, but I'm afraid my eyeballs will pop out of their sockets reading all the posts. TIA.

MacAddict
14th December 2006, 00:01
I use Skal's and strictly play XviD files. Never noticed any sort of artifacts especially like the pictures above.

clsid
14th December 2006, 18:13
libmpeg2 will work ok

caphook
18th December 2006, 15:24
After 'ffdshow-rev2529-SSE2' I can't find a version that can render some movies well. Below you can see the difference between any new version and the version above. Believe me, I tried more than 20 versions (with or without MMX or SSE or SSE2, doesn't matter) including the last one from today!

As you can see, there's a lot of strange artefacts (lines) in the first image, specially in the right side of the door entrance. I'm using all the options by default, except for 'postprocessing' that is disable in both cases. The player used: MPC (and doesn't matter the render...) on a Sempron 3000+@2.6 Ghz with a Radeon X800XL (last Catalyst version). The movie tested: Nackt (from Germany), encoded with DIV3.

Someone can explain to me what's happening?

Thanks a lot, guys.
;)

Try to delete [HKEY_CURRENT_USER\Software\GNU\ffdshow] and [HKEY_LOCAL_MACHINE\SOFTWARE\GNU\ffdshow] keys. Make backup before a delete.