ffdshow tryouts project: Discussion & Development

[Porsche_fan]

I have noticed that postprocessing doesn’t work when using ffdshow to decode a Windows Media Advanced Profile (VC-1) file. However, if I use MPC’s built in codec VC1 (FFmpeg) codec to decode and then use ffdshow set to Raw Support, I can utilize ffdshow’s postprocessing.


I’ve tried other players and had the same experience where postprocessing doesn’t work if ffdshow decodes. Also tried several of the recent builds too.


Is there a reason for ffdshow’s codec to disable ffdshow’s postprocessing for this file format?

[LoRd_MuldeR]

Not sure, but AFAIK the WMV9/VC-1 format has a "built-in" deblock filter that is always enabled, because it's an inherent part of the encoding/decoding process.

That's similar (but not identical) to H.264's Inloop-Deblocking. Therefore it would make sense to disable additional Post-processing for those formats...

[Px]

BatKnight
Mercury_22
Use Process Monitor utility to see registry and file activity on your system while hang, maybe that helps to track down the problem

[BatKnight]

Originally Posted by Px

BatKnight
Mercury_22
Use Process Monitor utility to see registry and file activity on your system while hang, maybe that helps to track down the problem

OK, I've done it.
I used Process Monitor to isolate the REGSVR32.EXE process during ffdshow installation and found out that it hangs with full CPU when registering ffdshow.ax
Here is a file with 2 logs in PML format (Process Monitor) showing everything. One is during the ffdshow installation and the other one is just a "regsvr32 /s ffdshow.ax"
http://stashbox.org/629584/logfiles.rar
Both give the same problem: the process hangs forever eating all CPU.

I have other information: I've tested the ICL 11.1.038 ffdshow on my notebook which is a C2D T4200 with Intel chipset and Windows 7 x64 and it gave the same exact problem. So I can reproduce this problem on both Win 7 x64 and Win 7 32bits.
On x64 I've noticed that it uses the 32bit regsvr32.exe, if this is of any importance.

If any ffdshow developer needs further testing, just let me know.

Bat

[Snowknight26]

Originally Posted by BatKnight

On x64 I've noticed that it uses the 32bit regsvr32.exe, if this is of any importance.

That's normal when you're using the 32-bit version of ffdshow.

[GrofLuigi]

BatKnight,

From a quick glance on your procmon log I can guess what could have interfered:

Eset
PunkBuster
DEP
Prefetch (if corrupt?)

For more, I think you'd need to disable "drop filtered events" if used, and not restrict logging to regsvr32 only...

GL

[Porsche_fan]

@ LoRd_MuldeR.

That makes sense. However, it was exactly that built in deblocking feature of wmv9 that I was hoping to take advantage of and couple it with ffdshow’s postprocessing deblocker.


Additionally, it would be helpful to use the postprocessing deblocking when decoding wmv videos with libavcodec. Within ffdshow it appears that for wmv decoding, deblocking occurs with wmv9 selected as the codec. However, the internal deblocking function doesn’t appear to occur, or is extremely minimal, with libavcodec. MPC’s FFmpeg decoding for wmv also appears to be missing the internal deblocking function too.


If it is possible, I think it would be beneficial to enable within ffdshow postprocessing with wmv decoding, allowing the flexibility to mix and match deblocking methods with different wmv decoders. As sometimes some deblocking is required but the wmv9 codec is a little too aggressive, resulting in significant loss of detail. In those instances it would be nice to be able to use libavcodec combined with ffdshow's postprocessing deblockers.

[FoLLgoTT]

Originally Posted by Mercury_22

Test 5.1 AC3 (Dolby Digital)
Test 7.1 E-AC3 (Dolby Digital Plus)
Test 7.1 Dolby TrueHD
Test 7.1 DTS-HD HR
Test 7.1 LPCM

Very helpful links. Do you have similar streams for 5.1 or 6.1?

[nm]

Originally Posted by Porsche_fan

Additionally, it would be helpful to use the postprocessing deblocking when decoding wmv videos with libavcodec. Within ffdshow it appears that for wmv decoding, deblocking occurs with wmv9 selected as the codec. However, the internal deblocking function doesn’t appear to occur, or is extremely minimal, with libavcodec. MPC’s FFmpeg decoding for wmv also appears to be missing the internal deblocking function too.

What do you mean by "internal deblocking"? Libavcodec does in-loop deblocking, but it doesn't do postprocess (out-loop) deblocking that Microsoft's wmv decoder does by default. For postprocess deblocking you are supposed to use ffdshow's filters, which should satisfy all your requirements. So are you suggesting that one of those filters should be enabled automatically for wmv decoding?

[Px]

Originally Posted by BatKnight

OK, I've done it.
I used Process Monitor to isolate the REGSVR32.EXE process during ffdshow installation and found out that it hangs with full CPU when registering ffdshow.ax

In addition to GrofLuigi answer:
Last event with regsvr32 in your logs is querying HKCU\Software\GNU\ffdshow\allowDPRINTF key, I've installed same version on my system to see, what regsvr32 doing next. In my case, it was querying keys HKCU\Software\GNU\ffdshow\isBlacklist and HKCU\Software\GNU\ffdshow\blacklist. Try to delete this keys and reinstall ffdshow again

[LoRd_MuldeR]

Originally Posted by Porsche_fan

That makes sense. However, it was exactly that built in deblocking feature of wmv9 that I was hoping to take advantage of and couple it with ffdshow’s postprocessing deblocker.

VC-1/WMV9's deblocking is an inherent part of the encoding and decoding process. It's technically impossible to use that for anything other than WMV9/VC-1!

And VC-1/WMV9 cannot be decoded (properly) without its "built-in" deblocking.

Originally Posted by Porsche_fan

If it is possible, I think it would be beneficial to enable within ffdshow postprocessing with wmv decoding, allowing the flexibility to mix and match deblocking methods with different wmv decoders.

You miss the point: We are NOT talking about "different deblocking methods" here! The buit-in deblocking is part of the WMV9/VC-1 specifications. Any WMV9 decoder does apply it and all WMV9 decoders must do it in the exactly same way! At the same time the "post-processing" filter in ffdshow is 100% format-independent and it's optional. It is applied after the video is returned from the decoder. Since the video returned from the VC-1/WMV9 decoder already has been deblocked (same goes for H.264 video!), there is no need for additional post-processing. Applying additional post-processing to WMV9 or H.264 wouldn't be beneficial in 99% of all cases. Therefore it is a good idea to skip the "post-processing" for VC-1 and H.264, in order to protect the user from deblocking the video twice and thus getting bad quality...

(I remember that back at the time when I experimented with H.264 for the very first stime, I wasn't satisfied at all. Until I turned of the additional post-processing and got great results ^^)

[Mercury_22]

Originally Posted by FoLLgoTT

Very helpful links. Do you have similar streams for 5.1 or 6.1?

Sorry NO

[Porsche_fan]

Originally Posted by nm

What do you mean by "internal deblocking"? Libavcodec does in-loop deblocking, but it doesn't do postprocess (out-loop) deblocking that Microsoft's wmv decoder does by default. For postprocess deblocking you are supposed to use ffdshow's filters, which should satisfy all your requirements. So are you suggesting that one of those filters should be enabled automatically for wmv decoding?

No I wasn’t suggesting anything should be automatic. What I have observed is that ffdshow’s postprocessing filter is nonfunctional when ffdshow decodes wmv video using either the wmv9 codec or the libavcodec. It appears that ffdshow deactivates the postprocessing filters for wmv files.


My suggestion is that ffdshow users be given the ability to engage ffdshow’s postprocessing filters, if they so chose, when using either wmv9 or libavcodec to decode a wmv file.

Originally Posted by LoRd_MuldeR

VC-1/WMV9's deblocking is an inherent part of the encoding and decoding process. It's technically impossible to use that for anything other than WMV9/VC-1!

And VC-1/WMV9 cannot be decoded (properly) without its "built-in" deblocking.



You miss the point: We are NOT talking about "different deblocking methods" here! The buit-in deblocking is part of the WMV9/VC-1 specifications. Any WMV9 decoder does apply it and all WMV9 decoders must do it in the exactly same way!

LoRd_MuldeR I apologize if I misunderstand what you are saying, however, there is a deblocking difference between decoding using ffdshow’s wmv9 filter alone verses ffdshow’s libavcodec filter alone. Maybe not the best example but here are two scene shots demonstrating this point with ffdshow decoding both...no other filters applied.


Libavcodec



wmv9

Originally Posted by LoRd_MuldeR

At the same time the "post-processing" filter in ffdshow is 100% format-independent and it's optional.

As I mentioned within ffdshow the wmv format prevents access to ffdshow's postprocessing. I can understand your point that many times it may be detrimental to allow the user to deblock twice unknowingly. However, especially in the case of using libavcodec, I believe allowing the user to select from customizable deblocking methods available within ffdshow’s postprocessing would be beneficial.

[LoRd_MuldeR]

Originally Posted by Porsche_fan

there is a deblocking difference between decoding using ffdshow’s wmv9 filter alone verses ffdshow’s libavcodec filter alone.

That definitely shouldn't be the case. Two standard-compliant decoders should always give identical output for identical input.

Given that libavcodec isn't broken, I suspect that M$'s WMV9 decoder has some additional filtering that goes beyond the standard VC-1 deblocking

(BTW: Cannot see your screenshots)

Originally Posted by Porsche_fan

As I mentioned within ffdshow the wmv format prevents access to ffdshow's postprocessing. I can understand your point that many times it may be detrimental to allow the user to deblock twice unknowingly. However, especially in the case of using libavcodec, I believe allowing the user to select from customizable deblocking methods available within ffdshow’s postprocessing would be beneficial.

Well, maybe a "Skip additional post-processing" option (enabled by default!) could be added to "WMV9" and "VC-1" on the "Codecs" page.

Let's wait for the ffdshow developers to comment on this...

[XhmikosR]

@devs: 64bit compilation is broken in rev3075.

EDIT: It seems the changes in makefile_c.inc break 64bit compilation.

[clsid]

Use this MinGW64 build:
http://sourceforge.net/projects/ming...1.zip/download

[BatKnight]

Originally Posted by Porsche_fan

LoRd_MuldeR I apologize if I misunderstand what you are saying, however, there is a deblocking difference between decoding using ffdshow’s wmv9 filter alone verses ffdshow’s libavcodec filter alone. Maybe not the best example but here are two scene shots demonstrating this point with ffdshow decoding both...no other filters applied.


Libavcodec



wmv9

Well, there is indeed a very noticeable difference between the two decoders. Could a ffdshow developer take a look on this?
If you can't see the screenshots let me know and I'll post a copy on different server if Porsche_fan allows me.

Bat

[Porsche_fan]

Originally Posted by LoRd_MuldeR

That definitely shouldn't be the case. Two standard-compliant decoders should always give identical output for identical input.

Given that libavcodec isn't broken, I suspect that M$'s WMV9 decoder has some additional filtering that goes beyond the standard VC-1 deblocking

I've always thought it was intentional as wmv9's deblocking is either too aggressive or nonselective. The result is decoding with wmv9 almost always produces a softer (slightly blurred) image compared to libavcodec.


So I hope that libavcodec will remain as it is...I'd just like the ability to apply postprocessing deblocking to both wmv9 and libavcodec for all types of wmv files.


Normally, I don't like to use deblocking or NR filters as I feel they tend to destroy too much detail. However, in the case of HD content, frequently they are created with low bits/pixel to keep the file size down. The end result however, is an increased tendency towards blocking.


I like your idea for a solution. Hopefully, it is easy to implement.



@BatKnight

I have no objection to anyone rehosting the pics. Thanks

[Dark Shikari]

Yes, libavcodec doesn't implement WMV9's optional postprocessing deblockers.

[alexins]

Originally Posted by XhmikosR

@devs: 64bit compilation is broken in rev3075.

EDIT: It seems the changes in makefile_c.inc break 64bit compilation.

In the file "makefile_c.inc" the error is made:

ifeq ($(64BIT),yes)
    TARGET_OS=x86_64-pc-mingw32
    CFLAGS+=-DWIN64 -D_WIN64 -D__MINGW64__
    OPTFLAGS+=-O2 -m64
else

Given the changes in revision 3075, should be so:

ifeq ($(64BIT),yes)
    TARGET_OS=x86_64-w64-mingw32
    CFLAGS+=-DWIN64 -D_WIN64 -D__MINGW64__
    OPTFLAGS+=-O2 -m64
else