ffdshow tryouts project: Discussion & Development

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

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.

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]

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

[Porsche_fan]

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.


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

http://thumbnails20.imagebam.com/4887/2eb04648867719.gif (http://www.imagebam.com/image/2eb04648867719)

wmv9

http://thumbnails20.imagebam.com/4887/7dc8a048867724.gif (http://www.imagebam.com/image/7dc8a048867724)


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]

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

(BTW: Cannot see your screenshots)

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/mingw-w64/files/Toolchains%20targetting%20Win64/Release%20for%20GCC%204.4.0/mingw-w64_x86-64_mingw32_4.4.0-1.zip/download

[BatKnight]

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

http://thumbnails20.imagebam.com/4887/2eb04648867719.gif (http://www.imagebam.com/image/2eb04648867719)

wmv9

http://thumbnails20.imagebam.com/4887/7dc8a048867724.gif (http://www.imagebam.com/image/7dc8a048867724)

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]

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


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]

@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

[XhmikosR]

@alexins: Yes, I know. I created a patch to revert this change because I'm using komisar's MinGW for the 64bit version. Everything is fine now.:)

PS. If you read some posts before, you'll see that Mercury_22 is not the only one who's having issues with ICL 11.1.038 builds while 11.0.072 works as expected. Maybe you should change your ICL version to 11.0.072. (If you don't have it, send me a PM).

[_xxl]

I use this version:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Release%20for%20GCC%204.4.0/mingw-w64_x86-64_mingw32_4.4.0-1.zip/download
Using latest builds I can't compile pthreads for win64.

[yesgrey]

I'd just like the ability to apply postprocessing deblocking to both wmv9 and libavcodec for all types of wmv files.
I don't know if this could help, but have you tryed using the "WMV PowerToy"?
It's a little program that lets you set some parameters in Microsoft's WMV encoder and decoder.
You can get it here (http://www.citizeninsomniac.com/WMV/).

[alexins]

Using latest builds I can't compile pthreads for win64.

Pthreads-w32 (CVS code (http://sourceware.org/pthreads-win32/)) + w64sup.patch (http://sourceware.org/ml/pthreads-win32/2009/msg00030.html) = Successful build!

[_xxl]

I have updated pthreads to latest 2.9.0 + all patches for win64 and other bugs. I can't compile pthreads with latest MinGw64. They are broken.

[alexins]

I have updated pthreads to latest 2.9.0 + all patches for win64 and other bugs. I can't compile pthreads with latest MinGw64. They are broken.
… strange… in me build is passed without the problems,...
make CROSS=x86_64-w64-mingw32- clean GC-static
make CROSS=x86_64-w64-mingw32- clean GC-inlined
... truth I do not use assemblies of mingw-w64 (http://sourceforge.net/projects/mingw-w64/). I use my constructions of mingw gcc x86/x64, for these constructions I took scripts written Komisar (http://komisar.gin.by/mingw/add/) and introduced in them my changes.

[tetsuo55]

Pthreads-w32 (CVS code (http://sourceware.org/pthreads-win32/)) + w64sup.patch (http://sourceware.org/ml/pthreads-win32/2009/msg00030.html) = Successful build!Does this apply to MPC-HC too? the 64bit build has many bugs that are not in the 32bit build, mostly related to libavcodec.
… strange… in me build is passed without the problems,...
make CROSS=x86_64-w64-mingw32- clean GC-static
make CROSS=x86_64-w64-mingw32- clean GC-inlined
... truth I do not use assemblies of mingw-w64 (http://sourceforge.net/projects/mingw-w64/). I use my constructions of mingw gcc x86/x64, for these constructions I took scripts written Komisar (http://komisar.gin.by/mingw/add/) and introduced in them my changes.


Maybe you could share exactly how you made your build environment, i think many will want to install it like you do (i know i do)

[_xxl]

… strange… in me build is passed without the problems,...
http://i32.tinypic.com/2r6mo03.jpg
That is my problem with latest MinGW64.

[alexins]

That is my problem with latest MinGW64.
Try like this:
make CROSS=i686-w64-mingw32- clean GC-static
http://i021.radikal.ru/0909/b4/ceb102290e5bt.jpg (http://radikal.ru/F/i021.radikal.ru/0909/b4/ceb102290e5b.png.html)
Does this apply to MPC-HC too? the 64bit build has many bugs that are not in the 32bit build, mostly related to libavcodec.
No, this does not affect the mpc-hc …
Maybe you could share exactly how you made your build environment, i think many will want to install it like you do (i know i do)
In the next few days, I will try to post for download scripts (build components mingw), and issue the finished building based on gcc 4.4.2 (prerelease) and GCC 4.5.0 (experimental).
@alexins: Yes, I know. I created a patch to revert this change because I'm using komisar's MinGW for the 64bit version. Everything is fine now.:)
PS. If you read some posts before, you'll see that Mercury_22 is not the only one who's having issues with ICL 11.1.038 builds while 11.0.072 works as expected. Maybe you should change your ICL version to 11.0.072. (If you don't have it, send me a PM).
I have all versions of ICL 11.*.*. I'm still going to monitor the situation, it is necessary to gather more information for decision.

[petran79]

There is a problem with the new version of DFX audio plugin for Winamp and ffdshow audio.It does not appear on the ffdshow Winamp plugin panel. Up to version 9.100 there was no problem. Other plugins appear and work normally.

Players like KMplayer and GOMplayer accept the new version

[leeperry]

is there ANY way to get sharper subs in ffdshow? :(

http://img87.imageshack.us/img87/2254/subsj.th.png (http://img87.imageshack.us/i/subsj.png/)

I understand blurry subs prolly look great on LCD screens, but on CRT/DLP all these font smoothing algorithms look terribly ugly(curse you Windows Vista/7! :devil:)...is there a chance someone could add a "blurriness" slider please? or am I missing something? everyone's watching blurry subs in here?

this is terrible w/ a projector, it's blurry-land..

[clsid]

First of all, I don't think that there is a developer available at this moment that is able/willing to implement this kind of suggestions.

Secondly, you are asking for something that is the exact opposite of what you want to accomplish.

Thirdly, use DirectVobSub (or MPC internal) and increase the texture resolution setting. That will give sharper subs.

[leeperry]

well, I meant a blurriness slider....so I could set it to 0 :)

I guess it's great to have blurry fonts on LCD...but luckily, many ppl don't use this technology. yeah, I guess I'll have to wait for madshi to add a subs pin in mVR...KMP is able to give very sharp subs, but it can't be used at this point :(

DirectVobSub is terrible...most of the times you can't even change the vertical alignment, you can't even override the look of .ass subs.

ah well, time to brush up my Japanese I guess http://forum-images.hardware.fr/images/perso/axellay.gif

[Astrophizz]

You could try having the subs render after upscaling. Also so far as I know Vista/7 use the same font smoothing as XP and this font smoothing has no effect on subtitle rendering.

[leeperry]

I don't upscale...this is downscaled from 1080p in ffdshow then subs are added on the native res, and the subs are always blurry ...and I've tried every possible setting, the anti-aliasing seems rather high...and I'm not the only one finding them blurry :o

well, Vista/7 seem to enforce that Cleartype stuff, w/ a bit of a hassle you can disable it in explorer...but not in other apps? ah well, if mVR finally delivers I'll stay in XP until the end of days...I don't need blurry fonts in all my apps, nor 40 mandatory background services or an OS that decides what I'm allowed to do: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

anyway, case closed...I understand blurry fonts will take over the world someday, I'll just wait for mVR to support subs.

[Astrophizz]

Yeah I find the fonts blurry from VSFilter compared to the KMP or MPC-HC internal sub renderers. I wish something was done about it but I put up with it and I guess I've gotten used to it. I'm almost certain that it's totally unrelated to Cleartype though.

[roozhou]

Yeah I find the fonts blurry from VSFilter compared to the KMP or MPC-HC internal sub renderers. I wish something was done about it but I put up with it and I guess I've gotten used to it. I'm almost certain that it's totally unrelated to Cleartype though.

VSFilter renders directly to the decoded frames so it's limited by video frame's resolution and YV12 colorspace.

[Astrophizz]

Doesn't the subtitle renderer in ffdshow have the same restrictions as VSFilter unless the scaling is done internally? Though I suppose since leeperry scales before adding the subtitles my issue isn't the same as his.

[leeperry]

I'm almost certain that it's totally unrelated to Cleartype though.
no it's not, these are two separate issues.
if you enable 2x/3x anti-aliasing for subs rendering in KMP, you also get blurry fonts. that's prolly what is happening in all these ffdshow/mpc/dvobsub..but they don't allow you to disable AA. anyway, this most likely will never be fixed...it's by design.

[thewebchat]

VSFilter process:

1) Get subtitles
2) Create subpicture that is 64x the resolution of the video frame
3) Scale subtitle sizes using some magic numbers
4) Multiply everything by 8
5) Get outlines and composite (note that there is no ClearType going on here)
6) Downscale to video resolution and paint

Note that the combination of 2 and 4 is the reason that VSFilter supports 8th-pel subpixel positioning and sizes.

[Snowknight26]

Why was the option to use libavcodec for H.264 decoding removed in the installer?

[Liisachan]

DirectVobSub is terrible...most of the times you can't even change the vertical alignment, you can't even override the look of .ass subs.[/IMG] For what it's worth, MPC lets you do that style by style. And MPC's internal renderer is superb when Max texture res is set high. MPC's clearness of subtitle texts on full-screen is unbeatable.
But I agree it's somewhat blurry even on Win XP if rendered @100%. I think it's intentional, it's supposed to be anti-aliasing I guess.
Then again, that you want to change the ASS styles manually usually suggests that your ASS is less-than-ideal, like font size is too small, border is too thin, face vs border/shadow is too un-contrastive, etc...in short not easy to read.
On the other hand ffdshow's sub renderer is still experimental, especially for ASS. There may be a lot of subtle, complicated problems there. Be patient, that is not because ffdshow sucks but simply because that part is still in development.

If the problem is really simple, though, it might be fixed very quickly once someone works on it by giving a simple option to change the lfQuality parameter of LOGFONT when creating a logical font. The default value will let Windows select whatever it wants to use by default, but you can explicitly request Antialiased instead of that, or even non-Antialiased.
Personally, I'm interested in this CLEARTYPE_COMPAT_QUALITY (CLEARTYPE_NATURAL_QUALITY?) thing: ClearType vs. non-ClearType may break absolute positioning of subs, which could cause typesetting problems—not commonly but in a few cases. Just a thought.

However whether it is really ClearType's problem or not is debatable. Do you like the results if you globally disable ClearType?

[leeperry]

Well, I mostly watch movies on a DLP pj, so I need yellow subs...white ones make too much RBE. Anyway, I hardly watch subbed movies, only some Japanese anime from time to time, I will survive until madshi hopefully implements a subs pin in mVR...so I can use totaly unaliased subs in KMP again(aliasing looks twice blurrier on a 2 meters wide projection screen w/ a 720p DLP pj):

http://img33.imageshack.us/img33/580/kb1.th.png (http://img33.imageshack.us/i/kb1.png/)

this prolly looks really ugly on LCD, that's why they invented ClearType I guess...plus in KMP I can keep the left side wheel button pushed and then the wheel is used to move the subs vertical placement, such a nice feature :D
PS: that's the sharpest I could get from ffdshow : http://img5.imageshack.us/img5/9728/leef.th.png (http://img5.imageshack.us/i/leef.png/)

[Liisachan]

OK, I can imagine your problem. Historically, anti-aliasing was considered a nice, advanced technology. Avery Lee said about the Subtitler (DirectVobSub, VSFilter, MPC's internal renderer are based on it):
Subtitler antialiases all fonts by default at an 8x8 setting, i.e. it renders
*all* glyphs at eight times normal size and reduces it down. The result is
crisp, high-quality text. But since the technology has changed, it may be about time to think again about it. Technically it should be VERY easy to optionally disable antialiasing, because it just means "do nothing". Actually, in the original Subtitler, you can turn off font antialiasing by disabling the advanced rasterizer. In other words, a player that happens to work better in your situation works that way because its subtitle text renderer is very simple, compared to Subtitler/VSFilter/ etc. Your problem is not even about ClearType, you want to disable ClearType AND the technology one generation older, Anti-aliasing. I bet ffdshow too can do that easily once a developer has motivation and time to do that (maybe when more people start experiencing the similar problem?).

[leeperry]

whatever AA/ClearType look very blurry on CRT/DLP...anyway, case closed...no biggy ;)

[travolter]

the current CPUs are not enough to do some video realtime processing.

-Try to apply strongdeblocking+deringing into a high def wmv video(set settings with wmv9 powertoy program) and the cpu is not enough to smooth 1080 playback
(libavcodec dont support postprocessing in WMV!!!.. plz developers... add it.. wmvs are very popular today)


-Apply a framerate doubling script over 1080 videos are its not enough..

some tricks like resize 1080 videos to 720 work for frameratedoubling.. but not for deblocking+reringing in wmv.. (that provides an amazing quality)

Anyone did a serious test.. and checked if a X64 machine.. with all video drivers/programs/dlls x64 provide extra boost performance?.. or we need to wait for better CPU´s yet?

[leeperry]

would there be a way to control the ffdshow volume filter w/ hotkeys? I think I read about this sort of things, still looking....I use 100% bit-perfect KS in Reclock, so I need a way to control the volume dynamically before it reaches Reclock :o

[Andy o]

As I've said above
Using the 5.1 test file your channels don't seem to be correct mapped ?
Again AFAIK 5.1 sound track has back channels not side Dolby recommendation it's referring to physical positioning

On 5.1 audio, there's no "side" surrounds, but the position that the "surrounds" take is equivalent to the position the "side surrounds" take on a 7.1 system. The extra 2 speakers you're adding on a 7.1 system should be the "back surrounds", the others are the same as a 5.1 system. This is standard in receivers, and in Dolby and DTS diagrams too. The problem is that Windows takes the 5.1 PCM stream coming from a player and, on a 7.1 system, maps the "surrounds" on the 5.1 stream to the "back surrounds" on the 7.1 output. It should map them to "side surrounds".

I don't have much of a problem because I use ReClock to set speaker configuration in Windows automatically, but that's a workaround, not a fix.

[mark0077]

This rear / side channel thing is becoming a bit of mess (well at least in my mind....)....

Other than that I have noticed a newish problem with ffdshow (wasn't there in older builds as it was fixed by haruhiko). After ripping another 15 or so DVD's to mkv, I notice ffdshow no longer "OUTPUTS" them in the correct aspect ratio.

haruhiko yamagata a few weeks ago, came up with a solution when the video input was found to be mpeg2 and was able to get dvd's outputting in the correct ratio with some trickery..... I wonder does anyone know if this fix was broken by something..... I can go back through builds, just it takes time and maybe someone knows something that could have caused the original problem to come back.

[LoRd_MuldeR]

Other than that I have noticed a newish problem with ffdshow (wasn't there in older builds as it was fixed by haruhiko). After ripping another 15 or so DVD's to mkv, I notice ffdshow no longer displays them in the correct aspect ratio.

ffdshow doesn't display anything. The player application (or more precisely: the video renderer) does.

So if you get wrong AR the question is: Is this because ffdshow forwards incorrect SAR/DAR values or because the application/renderer fails?

Blindly blaming ffdshow is no good...

[mark0077]

Blindly? Didn't I mention that I spoke with haruhiko yamagata about it and he came up with a temporary fix...... lol (In fact it involved probably 50 posts, and probably 50 pm's aswell so don't be so RUDE!)

You're post isn't helpful at all I'm afraid incase you think it was. ffdshow even with no decoders, resizing and with any combination of pixel aspect ratio output settings used to display dvd rips in mkv incorrectly, which was worked around by haruhiko, which now seems to have gone back to the old behaviour in newer builds.

What I asked was did anyone know off hand why this might be the case before I go about downloading build after build, if you don't want to or can't answer that then you don't have to reply to my post........ sheesh

[LoRd_MuldeR]

You said that ffdshow doesn't "display" MKV files with correct AR. That statement makes absolutely no sense, because ffdshow doesn't display anything! It's a decoder. It's NOT renderer. And NOT a playback application. ffdshow only passes the decoded video data to the next filter in the DirectShow graph, nothing else. So if you get wrong AR, there are many possible reasons! Wrong AR values could be stored in the MKV file -or- the application/renderer fails to set the correct AR. Yes, it's also possible that ffdshow forwards wrong DAR/PAR information to renderer and thus causes the renderer to choose a wrong AR. But that's only one possible reason out of many. If you already are 100% sure that ffdshow forwards wrong DAR/PAR information (and that the renderer/application does not fail), then you didn't express yourself clearly...

[mark0077]

hmm, well if you're going to come in and pick out particular words of a persons post, even when you know what they mean then you are never going to be of any help to anyone.....

Yes it has something to do with the PAR/DAR output from ffdshow which in turn has a conflict with mpc-hc's AR computations. ffdshow originally output everything perfectly as was defined within the mkv, but as everyone knows DVD's have badly marked AR and interlace/progressive flags and this is where haruhiko put in a workaround for those particular cases. I think it was basically IF the input is mpeg2 / PAL / certain resolutions, then the AR was forced to be either 16:9 or 4:3, something like that... but this workaround seems to have disappeared in some recent build.

Without starting a flame, in anycase, replying to ANY post with such replies as "Blindy" this or "blaming" that is not going to get anyone anywhere.... just brings the tone of the forum down to be honest and wastes peoples time :( If you dont have anything positive to say about a forum post, don't say it.... waste of your own time otherwise. Someone will always have something positive, even if the post isn't upto someone elses "clearness" standards.

[DarkZell666]

Without starting a flame, in anycase, replying to ANY post with such replies as "Blindy" this or "blaming" that is not going to get anyone anywhere.... just brings the tone of the forum down to be honest and wastes peoples time :( If you dont have anything positive to say about a forum post, don't say it.... waste of your own time otherwise. Someone will always have something positive, even if the post isn't upto someone elses "clearness" standards.

Hmm, I suppose when someone writes a post with a couple of badly chosen terms, it might not be clear, even after reading it several times, why the terms were badly chosen. Misunderstanding, simple mistake, tiredness ... whatever the reason, it's better (imho) to have the post corrected, not only for the OP but also for future readers. This is a necessary practice, and even more so on a technical forum like Doom9's.

MuldeR's clarification in itself wasn't superfluous, but I can understand that reading an emphasized and passionate post can make you feel uncomfortable ;)

Cheers !

[clsid]

Need to know the last know good and first bad revision.

[Inventive Software]

WMA Pro support made it into the ffmpeg trunk. :)

[travolter]

Deblocking 1080 videos problem
------------------------------

1.-The postprocessing ffdshow tab do not work with wmv.
2.-Libavcodec doesnot have any deblocking feature for wmv like h264 :(
3.-The only solution is use wmv codec to decode content and use "WMV power toy" program to select the deblocking level.. deringing etc.

4.- Cause 1080 videos are huge.. the deblocking is a cpu killer for current CPUs... so a trick like resize the video before apply deblocking would be nice (as someones do for frameratedoubling with 1080)

There is any way to apply a resize 1080->720 before the WMV decoder applies the deblocking filter?

[nm]

2.-Libavcodec doesnot have any deblocking feature for wmv like h264 :(
It does have in-loop deblocking and that's all it should have. The additional deblocking done by Microsoft's WMV decoder is post-process (similar to ffdshow's post-processing filters).

[G_M_C]

Mods: Sorry for cross-post. But the original post was in the wrong part of the forum. This discussion might be interesting here, and i think its best continued here :)

The new AMD Radeon 5xxx GPUs (5870/5850 launched today) allow for bit-streaming Dolby TrueHD/DTS-HD Master Audio over HDMI:

http://anandtech.com/video/showdoc.aspx?i=3643&p=10

So do we already have a working open-source toolkit (VC-1/AVC + THD/DTSMA -> MKV -> Matroska Splitter -> Video/Audio renderer) to support this feature?

Ffdshow has an experimental build that together with MPC-HC has full support for this.
We have never been able to actually get it to work, because none of the dev's and testers have a compatible hdmi card.

Where can i get that build ? I've got an ASUS Xonar HDAV, so i might be able to test ?

http://www.mediafire.com/?sharekey=05fb19b4b2e4495ee7c82ed4b8f0c380e04e75f6e8ebb871

Get BETA 5

K, installed and set up ffdshow B5. Set DTS-HD to bitstreaming in the output tab (also all other formats). Set uncompressed output to LPCM too.

Only have a DTS-MA video clip in m2ts format at hand. Used this to test.

Set MPC-HT (1.2.1044.0) to use its internal TS filter. It does recognise the DTS-HD audio track. But the track isnt bitstreamed, it does bitstream the core (to my Onkyo TX-SR875). Other problem is that the video stalls. The audio keeps playing, but the video freezes. Clicking on the video-window does show the frame that should have been shown, but also frozen.

Setting MPC-HT to not use its internal TS filter, using Haali media splitter in stead; The video works fine, but the audio-track is seen als DTS (core only). Thats bitstreamed also.

Cross-checked with ArcSoft total media; Both video and audio are recogized fine. Video plays as it should do, and DTS-MA is bitstreamed/passed through to my receiver.

What can i do to help to get DTS-MA bitstreaming working with MPC/ffdshow ?

[albain]

Thank you for your post, and yes I learned that yesterday about the new radeon cards, which is good news.
Which is sure is that I will buy one of those when they will be released.

The thing to to is to find how the stream is transmitted to the audio renderer, and if an alternate audio renderer is required.

With radeon 4xxx I fear that this is a driver issue that won't allow HD bistreaming.

However we know that TotalMedia theatre + Asus Xonar will output bitstream successfully, but to do that did they use hidden APIs or an alternate audio renderer ? also did they use special mediatypes between the decoder and the renderer ?

I know that TotalMedia relies on directshow, but I am not sure for the last versions.
Maybe this is possible to build a graph manually with graphedit with arcsoft decoder and grab the media type that is passed to the renderer.

Also one could ask AMD to get technical details about the future (directshow) implementation of HD bitstreaming.
I guess that there is an AMD development forum ?