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

LoRd_MuldeR
21st November 2008, 02:19
uploaded a 95mb remuxed video sample here: http://www.sendspace.com/file/bipcaq

Sorry, the free service is at full capacity.
...upgrade to sendspace Max™ to enable guaranteed slots and instant, fast downloads.

:rolleyes:


[EDIT]

Got the file now. I can confirm the artifacts when using four decoder threads. No problem with one thread though.

We can only hope the ffmpeg-mt developers will fix the remaining issues soon...

STaRGaZeR
21st November 2008, 02:29
I already have the sample Lord... try again.

BatKnight
21st November 2008, 02:50
Hi,

I've read that the ffdshow-mt is faster on Quad Core CPUs due to the multithreading capabilities. Fine.

But what about a Dual Core CPU? Is ffdshow-mt faster than the ffdshow SVN on 2 threads?

I think that H264 decoding on ffdshow SVN already uses 2 cores. Am I right? If so, then for the owners of Dual Core CPUs, the ffdshow-mt has no benefits over the SVN builds?

Thanks

Bat

jos99
21st November 2008, 02:59
Hi,

I've read that the ffdshow-mt is faster on Quad Core CPUs due to the multithreading capabilities. Fine.

But what about a Dual Core CPU? Is ffdshow-mt faster than the ffdshow SVN on 2 threads?

I think that H264 decoding on ffdshow SVN already uses 2 cores. Am I right? If so, then for the owners of Dual Core CPUs, the ffdshow-mt has no benefits over the SVN builds?

Thanks

Bat

Already answered on previous page (http://forum.doom9.org/showthread.php?p=1214860#post1214860) (thanks Mulder BTW:helpful:) - apparently the multi-threading in mt builds is more efficient than in normal ffdshow.

LoRd_MuldeR
21st November 2008, 03:07
Already answered on previous page (http://forum.doom9.org/showthread.php?p=1214860#post1214860) (thanks Mulder BTW:helpful:) - apparently the multi-threading in mt builds is more efficient than in normal ffdshow.

Yes, the multi-threading method used in ffdshow-mt is more efficient than the "old" one, even on two cores.
The old method, as currently used in ffdshow, was pretty inefficient and hence never made it into the official ffmpeg repository.
But ffdshow-mt only uses the multi-threaded H.264 decoder from ffmpge-mt. Other decoders are not multi-threaded yet.
And there are still display errors in some videos with ffdshow-mt (see post above).

LoRd_MuldeR
21st November 2008, 03:22
Here is another test, some numbers for "ffdshow vs. ffdshow-mt vs. CoreAVC" with different thread counts:

E:\HD\palvik-Clip003 - Copy_001.mp4

[Core AVC v1.8.5]
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 468.2, dfps: 66.2
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 741.3, dfps: 66.5 <-- 435%
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 741.3, dfps: 66.7

[ffdshow-mt r2333, 4 threads]
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 278.0, dfps: 56.3
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 280.9, dfps: 56.4 <-- 369%
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 242.6, dfps: 56.7

[ffdshow-mt r2333, 2 threads]
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 244.8, dfps: 28.8
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 254.2, dfps: 29.0 <-- 190%
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 218.8, dfps: 29.0

[ffdshow r2335 ICL, 4 threads]
User: 1s, kernel: 0s, total: 2s, real: 18s, fps: 196.2, dfps: 23.0
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 177.9, dfps: 23.6 <-- 154%
User: 1s, kernel: 0s, total: 2s, real: 17s, fps: 202.2, dfps: 23.7

[ffdshow-mt r2333, 1 thread]
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 15.4, dfps: 15.2
User: 26s, kernel: 0s, total: 26s, real: 27s, fps: 15.5, dfps: 15.3 <-- 100%
User: 26s, kernel: 0s, total: 26s, real: 27s, fps: 15.5, dfps: 15.3

Conclusion: ffdshow-mt is significant faster than ffdshow, even on two cores/threads ;)

BatKnight
21st November 2008, 13:07
Conclusion: ffdshow-mt is significant faster than ffdshow, even on two cores/threads ;)

Great. Thank you for your explanation. Sorry for bringing the question up again.
I'm going to give ffdshow-mt a try from now on. I'll report any problems I encounter.

Bat

clsid
21st November 2008, 14:53
I assume your [ffdshow r2335 ICL] test was done with 2 threads. Otherwise the result is a bit odd. Could you add a result with 1 thread as well?

With 4 threads it is just ~15% slower than CoreAVC :)

ikarad
21st November 2008, 15:35
Since these filters are not part of ffmpeg/libavcodec, they won't become multi-threaded just by going ffmpeg-mt.
It depends on the implementation of the individual filter in ffdshow! However the "Yadif" deinterlace filter in ffdshow-mt is multi-threaded already...

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2333

what is Yadif?
is it inverse telecine filter like telecide or just a simple bob/wave deinterlaced filter because there is an big difference between the two methods?

LoRd_MuldeR
21st November 2008, 16:06
what is Yadif?
is it inverse telecine filter like telecide or just a simple bob/wave deinterlaced filter because there is an big difference between the two methods?

It's not an inverse telecine (IVTC) filter! It's a "smart" deinterlacer and bobber (depending on the mode selected).

IMHO it's currently one of the best (if not the best) real-time bobber. Some super-slow bobbers interpolate nicer, but they can't work at real-time on an affordable machine ;)

http://guru.multimedia.cx/deinterlacing-filters/

I assume your [ffdshow r2335 ICL] test was done with 2 threads. Otherwise the result is a bit odd. Could you add a result with 1 thread as well?

Nope, I allowed four threads for the "ffdshow r2335 ICL" build, just to be sure. Does that setting apply to the H.264 decoder at all in "current" ffdshow?

Still the overall CPU load was around 30-40%. Using ffdshow-mt and allowing four threads results in ~100% CPU usage, all cores at full load.

That once again proves the ineffectiveness of the "old" multi-threading method. Well, it was better than nothing, back at the time when it was added.

bebo
21st November 2008, 16:09
Thanks CLSID!! Sounds like the last piece of the puzzle. Will load it in tonight and report results.:thanks:



clsid:

Thanks for the tip on MpegSplitter.ax. I found MpegSplitter.ax in the standalone filters per your direction. Next I went into GSpot to change the merit of same. Odd thing though...could not see MpegSplitter.ax in GSpot's list of codecs and filters. Tried dropping file in other directories...nothing worked - still couldn't see it. So I couldn't change the merit to prioritize MpegSplitter.ax.

Next I tried some other desperate stuff like deleting ffdshow.ax from ffdshow's directory and renaming MpegSplitter.ax as the "new" ffdshow.ax. All that did was render ffdshow useless and VMC defaulted back to the old default a/v codecs.

So, honestly I feel like a noob here, but how best can I acheive the objective I am going for...BD/HD-Dvd playback in VMC with full HD-audio decoding using ffdshow?

Much appreciated,

Bebo




clsid - got you PM - thanks will try.

littleD
21st November 2008, 16:33
To register u should paste this file into system32 directory (but not necessary), and register it, which means drag and drop over regsvr32.exe or choose start>> run>> regsvr32 mpegsplitter.ax :) U will see it in gspot as MPC - Mpeg Splitter (Gabest)

But... the only player which use this splitter (as standalone) issss.... MPC HC.. suuprise :). Windows Media Player and others players refuse to play m2ts tested file (can't connect with mpegsplitter). So we deal with bug here. (?)

bebo
21st November 2008, 16:40
To register u should paste this file into system32 directory (but not necessary), and register it, which means drag and drop over regsvr32.exe or choose start>> run>> regsvr32 mpegsplitter.ax :) U will see it in gspot as MPC - Mpeg Splitter (Gabest)

But... the only player which use this splitter (as standalone) issss.... MPC HC.. suuprise :). Windows Media Player and others players refuse to play m2ts tested file (can't connect with mpegsplitter). So we deal with bug here. (?)
Wow - huge downer litteD, but I its better to know I'm beating my head against a wall than to continue trying to make something happen that just ain't gonna...

I guess this means that for TrueHD streams I will have to drop out of my VMC integration project and fire up 'ol Arcsoft TMT using the file structure. A bit clunky when demo-ing the rig but seems like that's it for now.

So, I am out here on the fringe? Has nobody taken VMC player all the way to bright (full SD/HD A/V)? Hmmm...


....well I guess I must continue to bug Mike@haali to update the splitter to support MLP from .mt2s

clsid
21st November 2008, 16:45
You can use this registry tweak to force usage of the splitter.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.m2ts]
"Source Filter"="{1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}"

bebo
21st November 2008, 16:48
You can use this registry tweak to force usage of the splitter.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.m2ts]
"Source Filter"="{1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}"
...now you're talking! Let's use some reghack power!!

Thunderbolt8
21st November 2008, 19:58
It's not an inverse telecine (IVTC) filter! It's a "smart" deinterlacer and bobber (depending on the mode selected).

IMHO it's currently one of the best (if not the best) real-time bobber. Some super-slow bobbers interpolate nicer, but they can't work at real-time on an affordable machine ;)

http://guru.multimedia.cx/deinterlacing-filters/



Nope, I allowed four threads for the "ffdshow r2335 ICL" build, just to be sure. Does that setting apply to the H.264 decoder at all in "current" ffdshow?

Still the overall CPU load was around 30-40%. Using ffdshow-mt and allowing four threads results in ~100% CPU usage, all cores at full load.

That once again proves the ineffectiveness of the "old" multi-threading method. Well, it was better than nothing, back at the time when it was added.
im not familiar with the terms of deinterlacing like bob or real time interlace, interpolace etc.
im just concerned with the quality. ive so far used the ffmpeg deinterlacer, because I felt it has provided the best quality so far. what about yadif is that respect, does he provide a comparable quality as well, or is it primarily only a fast deinterlacer?

STaRGaZeR
21st November 2008, 20:19
im not familiar with the terms of deinterlacing like bob or real time interlace, interpolace etc.
im just concerned with the quality. ive so far used the ffmpeg deinterlacer, because I felt it has provided the best quality so far. what about yadif is that respect, does he provide a comparable quality as well, or is it primarily only a fast deinterlacer?

Do you want the best quality? Use hardware deinterlacing if you can. It also has near 0% (if not 0%) CPU usage increment. Yadif is nice, but is a resource hog and in certain scenarios like anime for example the results are far from good.

tal.aloni
21st November 2008, 21:06
But... the only player which use this splitter (as standalone) issss.... MPC HC.. suuprise :).

Wrong, I use MPC mpeg splitter with TCMP successfully.
(you have to disable haali mpeg splitter, uninstall and reinstall if needed), also, restart was also required in my case after I registered MpegSplitter.ax. (I can't explain this)
I can also use it with graph edit.

Thunderbolt8
21st November 2008, 22:14
Do you want the best quality? Use hardware deinterlacing if you can. It also has near 0% (if not 0%) CPU usage increment. Yadif is nice, but is a resource hog and in certain scenarios like anime for example the results are far from good.
I only have a gefore 7600gt, can I use it? if so, how to enable hardware deinterlacing in ffdshow? I only know about this deinterlacing box, but apparently all those deinterlacing options are for software/cpu deinterlacing

ikarad
21st November 2008, 23:14
im not familiar with the terms of deinterlacing like bob or real time interlace, interpolace etc.
im just concerned with the quality. ive so far used the ffmpeg deinterlacer, because I felt it has provided the best quality so far. what about yadif is that respect, does he provide a comparable quality as well, or is it primarily only a fast deinterlacer?

if you want the quality, use Inverse telecine filter like telecide.

jos99
21st November 2008, 23:40
Yes, the multi-threading method used in ffdshow-mt is more efficient than the "old" one, even on two cores.
The old method, as currently used in ffdshow, was pretty inefficient and hence never made it into the official ffmpeg repository.
But ffdshow-mt only uses the multi-threaded H.264 decoder from ffmpge-mt. Other decoders are not multi-threaded yet.
And there are still display errors in some videos with ffdshow-mt (see post above).
OK, I just updated from 2307 to 2333 mt as I saw the resource leak was fixed and ffdshow h.264 decoder wouldn't load for h.264 TV on DVBviewer.:scared: ....on the plus side I have been able to test out the latest version of standard ffshow 2338 and, guess what it is giving me slightly lower usage on 1080i h.264 channels - about 3-4% less with VMR9, even less usage with EVR (using 64x2 5000+ XPSP3).

STaRGaZeR
22nd November 2008, 00:51
I only have a gefore 7600gt, can I use it? if so, how to enable hardware deinterlacing in ffdshow? I only know about this deinterlacing box, but apparently all those deinterlacing options are for software/cpu deinterlacing

It has been a long time since I used a NV card, so I'll tell you the basics, it may work or not in that card. Or maybe not work as desired. In the output section of ffdshow check the "Set interlace flag in output media type", the two options to "Auto". "Force bob" means force deinterlacing always, "Force weave" is the same as no deinterlacing. Try with your current config, and if it doesn't work uncheck everything except NV12 as output colorspaces. Look for interlacing options in the NV control panel and enable them. VMR9 is not recommended as it's famous for displaying the field order incorrectly, however it may work. If nothing works, play with the different options :p

HW deinterlacing is like DXVA, very susceptible, but it produces wonderful quality.

haruhiko_yamagata
22nd November 2008, 03:39
ps. with the new yadif deinterlacer, seems i found a problem with interlaced mp4/avc files it crashes mpc when enabledPlease recompile libmplayer.dll using GCC 4.2.x. Yadif uses SSE2/SSSE3, which produced surprising performance boost (195% on Core 2). GCC 4.0.x cannot align stack properly.

roozhou
22nd November 2008, 04:43
Please recompile libmplayer.dll using GCC 4.2.x. Yadif uses SSE2/SSSE3, which produced surprising performance boost (195% on Core 2). GCC 4.0.x cannot align stack properly.

It is not true. In my test SSSE3 is at most 30% faster than original MMX2 on Core 2.

_xxl
22nd November 2008, 07:00
GCC 4.0.x cannot align stack properly.Version below MINGW GCC 4.2.x should be banned from ffdshow.

haruhiko_yamagata
22nd November 2008, 07:34
It is not true. In my test SSSE3 is at most 30% faster than original MMX2 on Core 2.
Then I calculated badly. But it's at least 160% faster.
Please remember to subtract decoding time.

rev2303:MMX-EXT
rev2307:SSSE3
rev2333:SSSE3 + 4 threads

On Core2 Quad,

MPEG-2 1080i, libmpeg2 yadif disabled
ffdshow_rev2333_20081117-mt.exe:User: 7s, kernel: 0s, total: 7s, real: 8s, fps: 158.8, dfps: 153.2 6.53ms/frame 0.00ms/yadif

Same file, yadif double frame rate
ffdshow_rev2303_20081106-mt.exe:User: 41s, kernel: 0s, total: 41s, real: 42s, fps: 29.2, dfps: 29.2 34.25ms/frame 27.72ms/yadif -> 100%
ffdshow_rev2307_20081107-mt.exe:User: 28s, kernel: 0s, total: 29s, real: 29s, fps: 42.3, dfps: 42.3 23.64ms/frame 17.11ms/yadif -> 162%
ffdshow_rev2333_20081117-mt.exe:User: 11s, kernel: 0s, total: 11s, real: 18s, fps: 109.3, dfps: 65.6 15.24ms/frame 8.71ms/yadif -> 318%

_xxl
22nd November 2008, 08:25
@ all ffdshow-tryout developers
I would like to remove from ffdshow's code MSVC7.1, MSVC8 project files, because there are to many and some buggy.

haruhiko_yamagata
22nd November 2008, 10:33
strcpy_s and some other secure string manipulation functions were added to the CRT at MSVC8.

http://msdn.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx
(http://msdn.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx)
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/coding/317-BSI.html

My next patch will use those functions. I also wrote an alternative functions so that we can do without completely dropping MSVC7.1. However MSVC7.1 is not the recommended compiler. Of course the official CRT is better than my code.
ICL9 and MinGW 4.0.x may be dropped at the same time. Supporting 6 compilers is a mess.
If some of the developers have only MSVC8, it is possible to continue supporting.

haruhiko_yamagata
22nd November 2008, 11:30
Screenshots from the Freedom series Blu-ray (AVC), EP1, using ffdshow-mt svn 2333:

noticed the other rainbows I had with 'Babel' are gone already with svn2333, but these here are still there, while gone with normal ffdshow

uploaded a 95mb remuxed video sample here: http://www.sendspace.com/file/bipcaq
Thank you. I have sent a mail to the developer.

Leak
22nd November 2008, 11:36
ICL9 and MinGW 4.0.x may be dropped at the same time. Supporting 6 compilers is a mess.
If some of the developers have only MSVC8, it is possible to continue supporting.
Well, I'm using MSVC8 but I guess I could give VS2008 a try.

But honestly I'd keep the MinGW only build, if only to be able to build ffdshow with 100% free tools...

fastplayer
22nd November 2008, 11:41
But honestly I'd keep the MinGW only build, if only to be able to build ffdshow with 100% free tools...
So it's not possible to build with the free Visual C++ Express Edition (http://www.microsoft.com/express/vc/)?

haruhiko_yamagata
22nd November 2008, 11:47
Do you want the best quality? Use hardware deinterlacing if you can. It also has near 0% (if not 0%) CPU usage increment. Yadif is nice, but is a resource hog and in certain scenarios like anime for example the results are far from good.I don't know anime, but are there many interlaced anime?
Yadif does better job than my nvidia 7900GS, if double frame rate is enabled. It's much better for sports.
You just need a better CPU. Buy quad core to play H.264 1080i @ 50fps :sly:.

haruhiko_yamagata
22nd November 2008, 11:48
So it's not possible to build with the free Visual C++ Express Edition (http://www.microsoft.com/express/vc/)?I don't know. Anyone succeeded?

haruhiko_yamagata
22nd November 2008, 11:52
if you want the quality, use Inverse telecine filter like telecide.IVTC cannot be used for deinterlacing.
This filter acts on telecined progressive source and attempts to recreate progressive frames. (http://neuron2.net/telecide.html)

Leak
22nd November 2008, 12:01
So it's not possible to build with the free Visual C++ Express Edition (http://www.microsoft.com/express/vc/)?
Errr... last I checked the Express Editions were free as in beer, not free as in speech...

And you really need MinGW anyway to build a version of ffdshow that doesn't crawl, speedwise.

np: B. Fleischmann - Phones And Machines (The Humbucking Coil)

haruhiko_yamagata
22nd November 2008, 12:10
And you really need MinGW anyway to build a version of ffdshow that doesn't crawl, speedwise.
Do you mean MinGW creates a fast build?
MinGW 4.0.x cannot compile properly for SSE2. ICL10 does better job in that regard, though it's expensive.

Leak
22nd November 2008, 13:14
Do you mean MinGW creates a fast build?
MinGW 4.0.x cannot compile properly for SSE2. ICL10 does better job in that regard, though it's expensive.
I was under the impression that several parts of ffdshow needed to be compiled with GCC to use any hand-optimized assembler code in them - did something change in that regard?

np: B. Fleischmann - Part Two (Tmp)

haruhiko_yamagata
22nd November 2008, 13:24
I was under the impression that several parts of ffdshow needed to be compiled with GCC to use any hand-optimized assembler code in them - did something change in that regard?

np: B. Fleischmann - Part Two (Tmp)I'm talking about ffdshow.ax. I should have explained this earliear.
libavcodec, libmplayer, x264 and xvidcore have to be compiled by GCC 4.2.x or newer.

Leak
22nd November 2008, 14:43
I'm talking about ffdshow.ax. I should have explained this earliear.
libavcodec, libmplayer, x264 and xvidcore have to be compiled by GCC 4.2.x or newer.
That's what I meant - you need GCC anyway, so why suddenly stop supporting it for compiling the main part?

np: B. Fleischmann - Waiting For You To Come (Welcome Tourist (Disc 1))

STaRGaZeR
22nd November 2008, 14:56
I don't know anime, but are there many interlaced anime?
Yadif does better job than my nvidia 7900GS, if double frame rate is enabled. It's much better for sports.
You just need a better CPU. Buy quad core to play H.264 1080i @ 50fps :sly:.

Oh yes, lots of DVDs. And the recent Blu-ray releases have commercials that are interlaced.
I don't know about nvidia, but you should try ATI's vector adaptive deinterlacer. Then you will understand my fixation with it. The only situation where it has failed to produce perfect quality is in some F1 races, and in very very small areas unoticeable if you are 1 meter away from your screen. Yadif has too many artifacts (white and black dots) and some combing here and there in anime.
I don't need a faster CPU for now, mine can play H.264 1080i @ 60fps (35Mbps) with yadif enabled in double framerate mode :D

BTW the last ffdshow-mt changes don't solve the sample I sent to you.

clsid
22nd November 2008, 17:43
There is no specific ICL9 project. All the ICL project files work with both ICL9/10. So no need to remove those.

I am using MSVC7.1 with the Windows Platform SDK 5.1. Shouldn't that support the safe string functions as well?

I prefer MSVC7.1 because it creates binaries that do not depend on those crappy MS runtimes. Perhaps we can statically link in that stuff? Then we could completely switch to VS2008.

LoRd_MuldeR
22nd November 2008, 18:33
if you want the quality, use Inverse telecine filter like telecide.

Which is completely useless if your source isn't telecined but "true" interlaced :rolleyes:


I only have a gefore 7600gt, can I use it? if so, how to enable hardware deinterlacing in ffdshow? I only know about this deinterlacing box, but apparently all those deinterlacing options are for software/cpu deinterlacing

To enable Hardware Deinterlacing, check "Set interlaced flag in output media type". I also learned that it may be necessary to limit the output colorspace to NV12.
Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though...

I personally am not really satisfied with Hardware Deinterlacing. But you should give it a try and see if it works well for you or not.
Anyway, the "FFmpeg deinterlacer" is a very simple one. And it's a deinterlacer (25i -> 25p). For smooth motion I'd highly recommend to use a bobber (25i -> 50p).
My favorites quality-wise are: Yadif ("Double Framerate" mode), "Greedy 2 Frame" (available through DScaler plugin) and KernelBob (Threshold < 5).

jos99
22nd November 2008, 19:19
To enable Hardware Deinterlacing, check "Set interlaced flag in output media type". I also learned that it may be necessary to limit the output colorspace to NV12.
Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though...

I personally am not really satisfied with Hardware Deinterlacing. But you should give it a try and see if it works well for you or not.

Thanks- setting to NV12 seems to allow hardware deinterlacing with my HD 3200 (780G) using Overlay, VMR7 and VMR9. This allows me to disable deinterlace and resize options in ffdshow and reduce usage from about 59% on 1080i 16.2Mbp/s h.264 TV (BBC HD) to 43-48% using 64x2 5000+ 2GB. I don't know if you saw my previous post but I am actually getting a reduction in CPU usage using normal ffdshow (2338) over ffdshow mt (2307-2333 didn't work for me)- can you explain this? Does it suggest my system is not using the dual cores correctly?

Thunderbolt8
22nd November 2008, 19:31
Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though..
and here it goes already :S not getting rid of haali, it gives me the best PQ, more than any switch of deinterlacer. all other renderers cannot keep up with it.

LoRd_MuldeR
22nd November 2008, 19:32
I don't know if you saw my previous post but I am actually getting a reduction in CPU usage using normal ffdshow (2338) over ffdshow mt (2307-2333 didn't work for me)- can you explain this?

Sure. In contrast to ffdshow-mt, the "normal" ffdshow uses an inefficient multi-threading method and hence won't be able to fully utilize your multi-core CPU.
Hence the reduced CPU usage along with reduced throughput (that is: worse performance).

Also I say it again: CPU usage alone doesn't say anything about performance. It's the actual throughput that matters!
So if you want to benchmark ffdshow vs. ffdhshow-mt on your local machine, download and use the timeCodec.exe (http://haali.cs.msu.ru/mkv/timeCodec.exe) tool and compare the "dfps" values.
Looking at the CPU load in taskman/procexp doesn't tell you much...


and here it goes already :S not getting rid of haali, it gives me the best PQ, more than any switch of deinterlacer. all other renderers cannot keep up with it.

As said before: I personally don't use Hardware Deinterlacing either. But for many people it's the way to go...

bebo
22nd November 2008, 19:36
clsid:

Thanks for the tip on MpegSplitter.ax. I found MpegSplitter.ax in the standalone filters per your direction. Next I went into GSpot to change the merit of same. Odd thing though...could not see MpegSplitter.ax in GSpot's list of codecs and filters. Tried dropping file in other directories...nothing worked - still couldn't see it. So I couldn't change the merit to prioritize MpegSplitter.ax.




clsid - got you PM - thanks will try.
Clsid and littleD:

Success! Thanks to you both for helping me get out of the woods on the last part of this project. Dragged and dropped MpegSplitter.ax over regsvr32 and then changed the ID value for the .mt2s extension per clsid's tweak and voila! MLP track playing in bit perfect resolution. Thanks for staying with the problem to its solution.

Only problem I have now is for some reason I now cannot ffwd, rew, or change chapters. I get a black screen and everything stops with no recoevery. Not complaining though because I've really wanted to get to this point for so long that watching a movie without controls is a small consolation to deal with. Will work on that later, right now I just want to watch some movies...

Thanks again guys.

bebo

Snowknight26
22nd November 2008, 20:53
Would I be correct in assuming that DTS Express can't be decoded by ffdshow because libavcodec cant (libdts too). If yes, any plans to add DTS Express decoding, even if it means bugging the ffmpeg team?

BatKnight
22nd November 2008, 20:59
I've been thinking about one thing, and I would like to know your opinion.

Imagine the following scenario:
One owns an external DTS-ES/DD-EX decoder and every DTS or AC3 that plays on the HTPC is SPDIFed to this decoder and played correctly.
But when it comes to a TrueHD MLP file, ffdshow decodes the MLP and doesn't SPDIF it, so the audio must be AC3 encoded for the surround channels to be properly played. Otherwise it would have to be the external decoder to apply something like a DTS Neo:6 to have surround sound.

My question is: sound quality wise, which is better?
- ffdshow to be able to strip the AC3 stream from a TrueHD track and then directly SPDIF it to the external decoder to properly play surround?
- ffdshow to decode the TrueHD track and then ffdshow AC3 encodes (640kbps) the audio and SPDIFs it to the decoder?

My main doubt is whether the decoding of the MLP and the following AC3 encoding (even at 640) is more lossy than the direct strip of an AC3 stream inside the MLP track.

What are your opinions and expertise on this?

Thanks

Bat

haruhiko_yamagata
22nd November 2008, 21:35
I am using MSVC7.1 with the Windows Platform SDK 5.1. Shouldn't that support the safe string functions as well?
I'm talking about this because MSVC7.1 doesn't support that safe functions.

tal.aloni
22nd November 2008, 23:40
My question is: sound quality wise, which is better?


the best is getting an 6/8 ch PCM over HDMI cabable receiver.
If we must stay in the s/pdif realm, it would be wiser not to re-encode, but that's not always preferred. for example, my room demand some equalization, so I would prefer re-encoding, that way I could apply the necessary post-processing, most receivers are much more limited in that area.