Log in

View Full Version : ffdshow tryouts project: Discussion & Development


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 [138] 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308

STaRGaZeR
15th March 2009, 05:11
That flag is probably the one that tells the renderer the luma range of the source when feeding it with YUV data so it can convert it to RGB knowing the correct levels. The only sure thing is that if you're already feeding the renderer with RGB data that flag is useless as no conversion is done there.

albain
15th March 2009, 11:11
There is bug (my fault) since revision 2735 : with uncompressed streams + in Vista WMP or Media Center + and when alternate decoder is used (FFDShow acts as raw decoder), then no more crash but picture size in input is wrong so the picture is cropped.

I will work on it

Damien

halsboss
15th March 2009, 11:55
Hi, after a REALLY serious PC infection (causing good programs to try to connect to websites where my firewall says - "source port 1596 dest IP 205.234.175.175 dest port 80 which resolves to vip1.anycast.cachefly.com") I reformatted and locked it down more with Trend 2009 with "prevent unauthorized changes" turned on.

It blocks some programs with an error message "Program Library Injection" which it says is trying to "configure windows so that a DLL is automatically loaded by some or all of your applications". If I hadn't had settings change detection turned on in TREND I would never have known.

It appears that not installing ffdshow (from the ffdshow tryouts in sourceforge) in the first place gets rid of the "library injection" error in MPC and HCenc etc... Went back to using the plain (new) xvid and other individual reliable codecs.

Not at all saying it's the cause of the infection issue I had, however it does at least do away with the "library injection" matter. eg when I just try to run MPC.

Can someone please clarify what dll it's trying to "inject" ?

PS XP-sp3 fully updated

Leak
15th March 2009, 12:54
Can someone please clarify what dll it's trying to "inject" ?
Well, to figure this out I just built debug versions of MPC-HC and ffdshow-tryouts.

The only thing that happens on startup of MPC-HC is that it's capture dialog enumerates all VfW audio codecs on initialization, where it finds ff_acm.acm, which is a vfw audio decoder needed for files created with MakeAVIS to return sound.

That in turn loads ffdshow.ax since ff_acm.acm is only a tiny stub, and all ffdshow.ax does is to check if the process that's loading it is on the blacklist.

ff_acm.acm is a decoder only, so MPC-HC's capture dialog shouldn't even load it, but VfW has no mechanism to flag a codec as decoding only, so it gets loaded anyway and simply returns that it can't encode anything.

That's the only cause I can think of, but if your version of Trend Micro's crap stinks as much as the version I have to endure at work I wouldn't be surprised if that's really it.

So I think installing ffdshow without MakeAVIS support should fix the "problem", or if you do need MakeAVIS maybe you should just go ahead and tell your, errr, "watchdog" to shut up - after all, there's legitimate uses for "Program Library Injection" (is that what we call loading a DLL nowadays?) besides scaring it's users.

Also, I want the hour of my life that I've just spent on analyzing this back... :mad: (And no, I'm not going to infect my machine with a test version of "Trend soandso anything 2009" to figure out if that was really it, thankyouverymuch.)

np: The Fireman - Light From Your Lighthouse (Electric Arguments)

halsboss
15th March 2009, 13:11
Leak, THANKYOU for your work. I can't give you back your hour, but think of all the good karma due to you :) I think you just convinced me it's "OK".

I still have visions of credit card pins being used (given that coincidentally programs were starting connect to odd places on the web).

Thankyou once again.:thanks:

Mirabel
15th March 2009, 21:22
I've read somewhere that ATI Radeon owners benefit from NV12 over the other colorspaces.
I ticked NV12 only and it displays (NV21,VU). I've noticed that only NV12 enforces the Edge Enhancements and De-noise settings at the AVIVO tab inside Catalyst Center. All other colorspaces ignore those settings.

Bat

I also heard something like that, but to my eyes it looks as I'd get the AVIVO stuff in YUY2 too. Maybe I should do more testing.

Hi guys, especially those of you interested in colorspace conversion. Now that Beliyaal has discovered how to set the levels flag in the output type of mpc-hc, I had an idea.

Sorry for noob question, but how do you do it?

And I use EVR custom, since I'm on Vista.

BatKnight
16th March 2009, 01:12
I also heard something like that, but to my eyes it looks as I'd get the AVIVO stuff in YUY2 too. Maybe I should do more testing.
In fact, I've noticed that when I upgraded from Catalyst 8.12 to 9.2 those Advanced Quality settings of AVIVO no longer come effective no matter what colorspace you choose; not even NV12 :scared:
It's pretty anoying that you developers spend time fixing and adding new features and then ATI just break things on their drivers.

Bat

mark0077
16th March 2009, 01:39
I might be wrong, but the flag Beliyaal was talking about is not usable by ffdshow afaik. It is a flag that is set by MPC when initializing its custom version of EVR.

Yeah what I meant was not using the flag by ffdshow, but instead using the flag as a way to stop the graphics card doing any conversions when being sent non RGB.

So if we could do levels conversions in ffdshow without having to go to output in RGB, aswell as setting the flag in mpc-hc we can achieve two things

1) The graphic card won't do any conversion of levels as the flag is set.
2) We are still sending non RGB to the renderer so things like hardware de-interlacing are now possible :D

I think this is very reasonable.

albain
16th March 2009, 10:32
Some (minor) updates about Direct Media Object implementation within FFDShow :

from the following url (http://alax.info/blog/402) you can see that this is possible (and better) to implement a DirectShow+DMO filter, meaning that the filter handles both DirectShow and Direct Media Foundation interfaces.

This is what I am trying to do, it does not seem too difficult and there are much fewer modifications than developing a new filter from scratch.

clsid
16th March 2009, 12:20
What would be the benefit of having a DMO filter? I don't know of a player that supports DMO but not DirectShow. And WMP will most likely favor its own DMO instead of third party ones (even if those have higher merit). Would processing raw video become easier (without special workarounds) in WMP?

Leak
16th March 2009, 13:03
What would be the benefit of having a DMO filter? I don't know of a player that supports DMO but not DirectShow. And WMP will most likely favor its own DMO instead of third party ones (even if those have higher merit). Would processing raw video become easier (without special workarounds) in WMP?
Well, unless I misunderstood something MS is going to drop DirectShow somewhere down the line, so why not support DMO it early on?

And I'd hazard a guess that WMP simply tries DMO first, finds a suitable (built-in) decoder and simply doesn't try DirectShow at all...

albain
16th March 2009, 14:20
What would be the benefit of having a DMO filter? I don't know of a player that supports DMO but not DirectShow. And WMP will most likely favor its own DMO instead of third party ones (even if those have higher merit). Would processing raw video become easier (without special workarounds) in WMP?

Well, in Windows 7 as you can (or will) see, divx support is now integrated into DMO, as well as some other formats (wmv of course but also H264, and MP3 WMA for audio formats). I am not sure about MPEG1 & 2.

As a result, FFDShow cannot be used to decode divx/h264 within Windows Media Player and Windows Media Center, which is a big loss.

The only way to reverse this behaviour is a (heavy) hack : unregister MS DMO filters which breaks media center TV module.


So if everything works as I expect, FFDShow could support DMO interfaces and it should be possible to override (with higher merit) the standard DMO filters. Of course all of this is conditional and now I am facing some technical difficulties with the new SDK (v7 beta).

But you're right : if this is not possible to override the merit to use FFDShow instead of MS DMO filters or add FFDShow as raw decoder in output all of this is not worth it (it will just be useful for future versions of Windows with no directshow support).

leeperry
16th March 2009, 17:36
when the ffdshow installer detects my language, where does it get the info please ?
\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Nls\Language\ ?

I'd like to fake it so all programs believe I've got a US XP, but setting these keys to 0409 doesn't help :o

Leak
16th March 2009, 17:44
I'd like to fake it so all programs believe I've got a US XP, but setting these keys to 0409 doesn't help :o
I think the only way to really get that effect is to install an English version of Windows. At least that's what works for me at home.

Changing the regional settings of the German Windows XP I have at work doesn't work in that regard - I guess there's some OS function that returns which language version of Windows was installed.

np: Apollo 440 - Christiane (Dude Descending A Staircase (Disc 2))

leeperry
16th March 2009, 18:04
I think the only way to really get that effect is to install an English version of Windows. At least that's what works for me at home.

Changing the regional settings of the German Windows XP I have at work doesn't work in that regard - I guess there's some OS function that returns which language version of Windows was installed.
ok thanks for the confirmation, I've done some googling for like 1H before giving up and asking here :o
but where does the ffdshow installer get the info from?!

clsid
16th March 2009, 18:49
Well, unless I misunderstood something MS is going to drop DirectShow somewhere down the line, so why not support DMO it early on?Windows 7 still supports DirectShow, so we have got nothing to worry about for the coming years.

I am not against adding a DMO interface. But if it brings no benefits, then it would be a waste of time.

e-t172
17th March 2009, 11:55
I'm experiencing some strange performance problems with the Avisynth filter in ffdshow. Details are in this topic. (http://forum.doom9.org/showthread.php?t=145704) Is there an explanation? Should I file a bug report in the SF tracker?

By the way, what is the preferred way to get in touch with ffdshow-tryouts developers? I didn't find any mailing list, so...

Leak
17th March 2009, 15:36
By the way, what is the preferred way to get in touch with ffdshow-tryouts developers? I didn't find any mailing list, so...
*waves*

Last time I checked I do read these forums regularly...

Also, you didn't find a mailing list because there is no mailing list. But if you take a closer look at the homepage (http://ffdshow-tryout.sourceforge.net/) you'll notice the "Forum" link...

As for AviSynth speed - I'll look into it (most probably not before the weekend), but if I were you I wouldn't hold my breath for speed improvements - after all, this is just a wrapper around AviSynth, so it'll always be slower than using AviSynth alone or an equivalent built-in filter of ffdshow, and AviSynth itself probably creates a duplicate of each frame somewhere due to caching since it's designed to minimize the re-fetching of frames.

Also, pardon my french, but testing how it performs on an empty script seems rather useless to me.

e-t172
17th March 2009, 18:26
Also, pardon my french, but testing how it performs on an empty script seems rather useless to me.

I don't know of any better way to measure the overhead of the Avisynth filter in ffdshow. With the current situation, even a simple script which is supposed to be fast turns out to be slow when used in ffdshow.

rt87
18th March 2009, 12:29
/me still waits for COOK decoder be appeared in ffdshow.

tetsuo55
18th March 2009, 12:54
/me still waits for COOK decoder be appeared in ffdshow.

Is it added/stable in ffmpeg??

clsid
18th March 2009, 16:20
It has been in FFmpeg for a long time already. But supporting it in ffdshow needs some work. There already is some (old) code for it, but that doesn't work. We need a volunteer to fix that.

Mirabel
18th March 2009, 16:29
/me still waits for COOK decoder be appeared in ffdshow.

I'd prefer Snow.

clsid
18th March 2009, 17:05
Then wait for Christmas ;)

rt87
19th March 2009, 02:39
Is it added/stable in ffmpeg??

It was added into ffmpeg 0.5 release.

clsid
19th March 2009, 14:33
Wrong. It was added long before the 0.5 release. It is just mentioned in the changelog because the previous "official" FFmpeg release was several years ago.

roozhou
19th March 2009, 16:03
*waves*

Last time I checked I do read these forums regularly...

Also, you didn't find a mailing list because there is no mailing list. But if you take a closer look at the homepage (http://ffdshow-tryout.sourceforge.net/) you'll notice the "Forum" link...

As for AviSynth speed - I'll look into it (most probably not before the weekend), but if I were you I wouldn't hold my breath for speed improvements - after all, this is just a wrapper around AviSynth, so it'll always be slower than using AviSynth alone or an equivalent built-in filter of ffdshow, and AviSynth itself probably creates a duplicate of each frame somewhere due to caching since it's designed to minimize the re-fetching of frames.

Also, pardon my french, but testing how it performs on an empty script seems rather useless to me.

Will there be a built-in avisynth loader, which works w/o avisynth.dll? In that way avisynth plugins will work in ffdshow like Winamp and DScaler plugins.

albain
19th March 2009, 18:56
Windows 7 still supports DirectShow, so we have got nothing to worry about for the coming years.

I am not against adding a DMO interface. But if it brings no benefits, then it would be a waste of time.

With Windows 7 you can't use FFDShow with Media Player and Media Center on MPEG4 streams for example, even with the hack on uncompressed streams.

Some information :

Media Foundation separates decode to transform : this means that the decoding part should be separated from the postprocessing part, which makes sense
This is a good news because this is possible to get FFDShow work even if it does not decode by declaring it as a decoder and a transformer. At first in DMO world it will be only usefull as a transform filter and let the directshow part handle the decoding (when possible)

Leak
19th March 2009, 21:10
Will there be a built-in avisynth loader, which works w/o avisynth.dll? In that way avisynth plugins will work in ffdshow like Winamp and DScaler plugins.
I don't think so - it's really unfeasible as AviSynth plugins can use any built-in or external AviSynth filter, and many do. Without the AviSynth.dll (and the surrounding script environment) all you'd get would be a crash at best.

np: Broker/Dealer - Midnight (100)

Snowknight26
19th March 2009, 22:14
I couldn't think of an appropriate place to post this but here, so don't hate me! :P

What I'm trying to do is to compare the output (lets say YV12 or YUV2) between libavcodec and ffmpeg-mt for H.264 decoding. What I was thinking is that I could use something like OSD's MD5 feature. For every frame that gets played, the MD5 hash of the current frame is appended to the corresponding line number (new line of course) in a text file. That way, its as simple as play a file using timecodec, switch between libavcodec and ffmpeg-mt, then MD5 the resulting text file to see if all the MD5s are identical. That way I can see whether they produce exact results, and if they don't, find the frames that don't match, and possibly report a bug.

However, I haven't found an easier way to do this. Heck, the method I'd do can't be done at the moment either... which is why I'm looking for suggestions to help me with my little dilemma.

leeperry
20th March 2009, 01:18
you can CRC check them w/ cdcheck...it'll run a binary compare.

not sure that's what you're asking for, though

Snowknight26
20th March 2009, 01:20
Basically trying to ensure that two decoders' outputs are exactly the same without having to actually write the raw output to a file.

Edit: Hmm, I think I found the perfect thing, assuming the MD5 sum is of the decoded frame, not encoded frame.
I turned on the OSD, chose only current frame and MD5 sum, saved the file and played the video from start to finish. Then I simply switched decoders from libavcodec to ffmpeg, repeated (renaming the output file of course), then compared the MD5 of the saved files.

Edit 2: Aww, enabling MD5 significantly drops the decoding speed.. almost to that of 1 thread.

leeperry
20th March 2009, 13:48
@Haruhiko : I'm in contact w/ Christian Budde, the author of the VST winamp bridge/Electri-Q and many more audio plugins.

he will drop you an email on your "nifty" account, can you please have a look at it?

here's what he told me, and he will try to fix the ffdshow audio code :

It's hard to believe, but there's some very big mistakes in ffdshow audio code(calling "Init" twice and never "Quit", also checking only for the export as name rather than the index, etc).

http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=434 : they "blame" me for being the bad guy, while the mistakes they have in their code are at least at the same level(if not worse). So the best thing would simply be to fix the mistakes once and for all in their source (I hate workarounds or maintaining more than one version).

Also they could remove the name from the blacklist.

:thanks:

haruhiko_yamagata
20th March 2009, 14:13
@Haruhiko : I'm in contact w/ Christian Budde, the author of the VST winamp bridge/Electri-Q and many more audio plugins.

he will drop you an email on your "nifty" account, can you please have a look at it?

here's what he told me, and he will try to fix the ffdshow audio code :



:thanks:Good news. Please excuse me for blaming that filter.

leeperry
20th March 2009, 14:24
Good news.
sure is! I'm so looking forward perfect winamp/VST plugins support in ffdshow :cool:

BTW, sorry to repeat myself, but don't you think it's a bug :confused:

http://forum.doom9.org/showpost.php?p=1261217&postcount=6836

I want 1024, I get 1022 :(

yesgrey
20th March 2009, 17:08
so here's a real world example : a 672x384 AVI file w 7/4 DAR
resized to 1024*768 yet Info() in the Avisynth filter shows : 1022*584, which is not mod4....and none of my scripts work because of that
IMHO ffdshow is working correctly. You are specifying both horizontal and vertical sizes, but those values are just outer limits. To keep the AR, ffdshow has to calculate the target resolution, which could result in a slightly lower size to give you an accurate AR.
If the horizontal resolution is more important to you, specify only the horizontal size, then the vertical will be calculated using the AR and the horizontal res you specify.
is there a way to force ffdshow to actually resize to 1024*585 or 586 :confused:
Yes, just select "specify horizontal and vertical size", put 1024x586 in the size fields, and select "no aspect ratio correction".

leeperry
20th March 2009, 18:04
IMHO ffdshow is working correctly.
ok thanks for your help, but resizing to 1024* doesn't help, still 1022...but if I select "outside" in the borders option of the resize, then it's 1024*584 as I wanted in the first place..I've always thought that this setting was only active if you manually added black bars :rolleyes:

even Seb.26 missed that one....alright problem solved :cool:

OTOH I've got a 362*272 divx file that crashes Avisynth no matter what I do :D

whatever I set the borders to inside/outside, it resizes to 1024*766 if I keep the AR and crashes the ffdshow Avisynth filter instantly(whatever 2.57 or 2.58)...I'll make a profile that enforces 1.3333333 :cool:

yesgrey
20th March 2009, 18:48
but if I select "outside" in the borders option of the resize, then it's 1024*584 as I wanted in the first place
I have the "outside" selected, that's why it worked with me when I tested it...
I've always thought that this setting was only active if you actually added black bars :rolleyes:
When you resize to a size with a different AR and want to keep the source AR, you have to add black bars.;)

mark0077
20th March 2009, 20:09
haruhiko I see your recent work on dvd menu quality and positioning.

Maybe while you are looking into it I could do some tests for you? With the new version on xvidvideo 2792, my menu highlights are still off by a few pixels when ffdshow is in the chain.

As I said before, it doesn't matter if ffdshow or mpc-hc does the decoding, the menu's getting broken only happens when ffdshow is in the chain, even if it is doing nothing but passing data straight through to the renderer. Maybe this might give a clue to you as to where the "bug" might lie.

therealjoeblow
20th March 2009, 20:18
I'd like to report what I believe to be a bug with the FFDshow Official Beta6_rev2527_20081219 version.

If I toggle resize (either on or off, depending on what it started with, it doesn't really make a difference), video playback of XviD material freezes. FFDshow is set as the sole video decoder in this instance.

It does NOT do this for DVD material in either case where where (1) PowerDVD 8 or PowerDVD 9 decoders are the primary video filter and FFDshow is a supplementary filter post-processing the video; or (2) where FFDshow is set as the primary MPEG2 filter.

Nor does it do this for x264 material. In both the DVD and x264 examples, it happily toggles resize on and off as many times as I want without ever a hitch, unlike XviD.

For XviD I've tried on two different machines, with three different players and several different renderers:

-One machine is a custom built HTPC with a GA-MA78GM-S2HP motherboard using the onboard Radeon HD 3200 video chip out to HDMI

-The other is a Dell Vostro 1510 laptop using an Intel Mobile 965 IGP to its own display.

I tried Zoom Player v6.00, MPC v6.4.9.0 and MPC-Home Cinema v1.2.908.0, with Overlay Mixer, VMR9 (Windowed, Windowless and Renderless) and EVR (from .NET SP3.5), and in all cases the result is exactly the same. XviD freezes when resize is toggled, and DVD/MPEG2/x264 plays fine.

I should point out that resize actually works fine on XviD if it is enabled before playback starts, but it's the *process* of turning it off that freezes the video. Likewise if it was off, the video plays fine, but turning it on freezes the video as well.

Would be great if this could be fixed, since this is probably the most frequently used instance where one would want to be able to toggle it on and off. Resize performance with DVD and x264 is pretty predictable since they are higher quality formats to start with, but in many cases with XviD, resizing it just introduces too many artifacts and I find myself wanting to turn it on and off much more frequently there than in the other cases.

clsid
20th March 2009, 22:01
@mark0077
Those fixed are in a separate branch. They are a work in progress. There are not public builds that include those changes.

@therealjoeblow
Please test with a recent SVN build.

jmartinr
20th March 2009, 22:38
OTOH I've got a 362*272 divx file that crashes Avisynth no matter what I do :D

whatever I set the borders to inside/outside, it resizes to 1024*766 if I keep the AR and crashes the ffdshow Avisynth filter instantly(whatever 2.57 or 2.58).

Specify horizontal and vertical size, keep original aspect ratio and process pixel aspect ratio internally.

You can also do your avisynth stuff before resizing, or you could do the resize in avisynth. A bit of scripting will give you the same possibilities as the ffdshow resizer.

therealjoeblow
20th March 2009, 22:59
@therealjoeblow
Please test with a recent SVN build.

Tested ffdshow_rev2792_20090320_clsid.exe just now.

Exactly the same (XviD freezes when toggling resize on and/or off, DVD and x264 are fine).

I believe I forgot to point out earlier that both machines are running WinXP-SP3 (32bit) if that makes any difference. The Gigabyte HTPC is a brand new fresh install with very little else on it; the Dell laptop is only about 3 months old and has a pretty clean OS too.

haruhiko_yamagata
21st March 2009, 06:52
I'd like to report what I believe to be a bug with the FFDshow Official Beta6_rev2527_20081219 version.

If I toggle resize (either on or off, depending on what it started with, it doesn't really make a difference), video playback of XviD material freezes. FFDshow is set as the sole video decoder in this instance.

I can't reproduce. Toggling resize during playback is a basic feature of ffdshow, fully tested and shouldn't be a common bug to everyone. Please try to find something in your filter graph that prevents reconnecting. ffdshow may be connected to some filter other than video renderer.
You could check the status of "Allow output format changes during playback" in "Output" page.

haruhiko_yamagata
21st March 2009, 07:21
haruhiko I see your recent work on dvd menu quality and positioning.

Maybe while you are looking into it I could do some tests for you? With the new version on xvidvideo 2792, my menu highlights are still off by a few pixels when ffdshow is in the chain.

As I said before, it doesn't matter if ffdshow or mpc-hc does the decoding, the menu's getting broken only happens when ffdshow is in the chain, even if it is doing nothing but passing data straight through to the renderer. Maybe this might give a clue to you as to where the "bug" might lie.
That branch is finally ready for open test.
Improved and fixed:

Background rendering of glyph in thread. The thread has priority below normal. Better performance and quality with higher CPU usage.
Better gradation
Collision and layer handling
Karaoke bug fix
UTF-8 in 'Charset' combo box.
Better opaque box
Stereoscopic bug fix
Partial rewrite: cleaner code. It's still a big mess though.
Improved rendering of DVD menu/subtitles (especially in RGB output).
Fixed positioning of DVD menu/subtitles.
Fixed missing initial highlight of static DVD menu.
Improved vobsub handling: try to use non empty stream. This fixes the bug "nothing is displayed" in most cases.

TODO:

Improve text subtitles rendering in YV12 mode. Convert to RGB32, process, convert to YV12 and write back with mask.
Improve the gradation of borders (use the code from MPC).
Implement rotation (code for rotating glyph is already there but still much work to use it)
ASS:Implement \h, \clip(), \t(), etc.

Build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2797_20090321_Q.exe)

CiNcH
21st March 2009, 16:59
Is anybody in charge of the VC-1 decoder? An Access Unit parser like it has been done for H.264 would be cool. Here (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/mpcvideodec/MPCVideoDecFilter.cpp?revision=1009&view=markup) is Casimir's code concerning this issue (>= line 1285) but he did not yet release the code for the H.264 and VC-1 Access Unit parsers as you can see (code is commented out).

mark0077
21st March 2009, 18:59
That branch is finally ready for open test.


WOW very impressed now. Probably of the big 6 problems I had with dvd quality on my machine in relation to ffdshow listed in my dvd quality thread, I would say 5 have all been fixed now. Thanks alot for that.

The last problem that still remains is obv advanced interlaced vs progressive frame detection and I am assuming my other problem of some dvd menu freezes or delays are related to mpc-hc beliyaal's build for the moment as recent builds have exhibited this behaviour.

Thanks again!
EDIT: Here are my findings after testing on Queen Greatest Video Hits 1 which has some rectangular menus, aswell as some menus containing one frame. I have never seen this dvd menu look perfect recently.

======================================

-- ffdshow libmpeg2 --
DVD Menu Quality: Excellent
DVD Menu Speed: Extremely slow. This slowness means a minute or two wait for simple text animations to finish, like fade in fade out animations before a song plays. One of my core i7 @4ghz cores gets maxed out while these animations attempt to complete. These animations LOOK correct but perform very slow.
DVD Quality: Excellent

-- ffdshow libavcodec --
DVD Menu Quality: Excellent (But when text fade begins before dvd playback, the image below happens). Bad quality of dvd quality might be triggered by the text fade that was also extremely slow above.
DVD Menu Speed: Excellent
DVD Quality: Very Bad, screenshot attached
http://img16.imageshack.us/img16/9473/newlibavcodec.th.jpg (http://img16.imageshack.us/my.php?image=newlibavcodec.jpg)

-- mpc-hc libmpeg2 decoder --
DVD Menu Quality: Excellent
DVD Quality: Excellent
DVD Menu Speed: Excellent
Other Problems: Freezing when highlighting menus as always has been a problem (Image where freeze happens below), items seem to be still clickable even though highlights don't appear, no highlight shown when hovering over items (except first item), no frame drops reported in mpc-hc. I guess this is something mpc-hc developers and ffdshow developers need to discuss between eachother. Its like the hover event isn't being passed from mpc-hc to ffdshow when mpc-hc is doing the decoding, and ffdshow the highlights. Like as if communication isn't working.
http://img7.imageshack.us/img7/8038/queenproblem.th.jpg (http://img7.imageshack.us/my.php?image=queenproblem.jpg)

======================================

Interlaced Text?
I assume from the ffdshow libmpeg2 slowness on these text fades I talk about above, that these are treated as subtitles. If this is the case for this DVD I can also say that there is a problem (and always has been) with these text fades as the text looks like its interlaced. Our standard dvd player actually shows these text fades beautifully, but on PC they have always look interlaced, or with horizontal lines through them (except the first one strangely, with de-interlacing enabled OR disabled). Image shown below to illustrate this.

First one that always looks perfect
http://img3.imageshack.us/img3/646/firstu.th.jpg (http://img3.imageshack.us/my.php?image=firstu.jpg)
Second one that shows that any apart from the first always look like this.
http://img3.imageshack.us/img3/4092/secondhaa.th.jpg (http://img3.imageshack.us/my.php?image=secondhaa.jpg)

Leak
21st March 2009, 19:48
Can't say that I can duplicate your results - both libavcodec and libmpeg2 work for me without speed problems, though libavcodec seems to get the aspect ratio wrong when I close and reopen MPC-HC and resume playback. And the BSG DVD I've tested it with also showed the menu highlights without problems (except for the mouse areas being off, but I guess that's what you get when you set ffdshow to add all added borders to the bottom - MPC can't know that... ;))

(OT - while I get more than 25% CPU usage on my Core 2 Quad it's nicely distributed over many (10+) threads according to Process Explorer, none of them using more then 5% in total so I'm a happy camper... :D)

np: Jesse Somfay - The Days Of Our Youth Ended With Broken Bottles (Dominik Eulberg & Riley Reinhold Remix) (100)

mark0077
21st March 2009, 20:27
Can't say that I can duplicate your results - both libavcodec and libmpeg2 work for me without speed problems, though libavcodec seems to get the aspect ratio wrong when I close and reopen MPC-HC and resume playback. And the BSG DVD I've tested it with also showed the menu highlights without problems (except for the mouse areas being off, but I guess that's what you get when you set ffdshow to add all added borders to the bottom - MPC can't know that... ;))

(OT - while I get more than 25% CPU usage on my Core 2 Quad it's nicely distributed over many (10+) threads according to Process Explorer, none of them using more then 5% in total so I'm a happy camper... :D)

np: Jesse Somfay - The Days Of Our Youth Ended With Broken Bottles (Dominik Eulberg & Riley Reinhold Remix) (100)

Maybe these speed problems are only on the fading text. This Queen DVD contains alot of strange DVD menus I guess with single frame menu's. It has been a good test DVD for this type of thing in the past and is still finding problems. I am sure haruhiko will sort them out ;)

Below is the single frame menu that now looks PERFECT, but when mpc-hc does the decoding, moving the mouse over any of the other options in the menu shows no highlights. As I say, when I click on them the correct audio channels are used, but menu highlight never appears when I move mouse over different options in this scenario. I just confirm that the menu highlights don't appear in this scenario even when using keyboard navigation so definitely some communication problem between mpc-hc and ffdshow which causes these freezes.
http://img7.imageshack.us/img7/8038/queenproblem.th.jpg (http://img7.imageshack.us/my.php?image=queenproblem.jpg)

clsid
21st March 2009, 21:18
Perhaps you could create a modified copy of that DVD for Haruhiko (and Leak) for testing purposes? With for example DVDShrink it is possible to replace all videos with a still image and keep the original menus. That should result in a very small ISO.