ffdshow tryouts project: Discussion & Development

[tal.aloni]

@Haruhiku,
I've started working on correcting the RGB <> BGR mismatches in the source code, it's opposite over opposite,
and I'll try to make it right.

Tal

[MatMaul]

Yes, it will be OK.
thanks a lot !
here is an other bug I reported :
http://sourceforge.net/tracker/index.php?func=detail&aid=2298876&group_id=173941&atid=867360

[haruhiko_yamagata]

I think I mentioned it before, but the following deinterlacing filters don't deinterlace:
"Framerate doubler" and "Cubic blending"

If these can't be fixed easily, I think the code should be disabled/removed. There are enough alternatives.

BTW: What is "Bypass" good for? If the user doesn't want to deinterlace, (s)he can simply uncheck deinterlacing. Unless it's required for some special purpose, it could be removed too.
I will remove them. I didn't check the code, just because the drop down list is too messy.
544x576 MPEG-2, libmpeg2, Core2 Quad

None:User: 1s, kernel: 0s, total: 1s, real: 1s, fps: 485.4, dfps: 476.6
Linear interpolation:User: 1s, kernel: 0s, total: 1s, real: 1s, fps: 411.6, dfps: 405.0
Linear blending:User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 405.2, dfps: 399.0
Cubic interpolation:User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 405.2, dfps: 399.0
Median:User: 1s, kernel: 0s, total: 1s, real: 1s, fps: 408.4, dfps: 405.2
TomsMoComp:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 325.7, dfps: 323.7
DGBob(single):User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 158.8, dfps: 158.8
DGBob(double):User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 93.0, dfps: 92.9
ffmpeg deinterlacer:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 392.8, dfps: 392.8
5-tap lowpass:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 375.6, dfps: 372.9
Kernel deinterlacer:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 362.4, dfps: 359.9
Kernel bob:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 275.2, dfps: 275.2
yadif (single):User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 480.9, dfps: 381.2
yadif (double):User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 395.8, dfps: 304.4

This is a rough bench mark test.
Classic deinterlacers such as "Linear interpolation" is a bit faster than modern deinterlacers.
What is DGBob good for?

[Leak]

What is DGBob good for?
It's another deinterlacer made by Donald Graft, aka neuron2 (http://www.neuron2.net/dgbob/dgbob.html)...

(Can't tell you more as I haven't used it, mind you...)

np: Gas - Track 7 (Pop)

[LoRd_MuldeR]

It's another deinterlacer made by Donald Graft, aka neuron2 (http://www.neuron2.net/dgbob/dgbob.html)...

(Can't tell you more as I haven't used it, mind you...)

np: Gas - Track 7 (Pop)

It's another bobber. IMHO you get nicer results with Yadif or KernelBob, but thats subjective. Other users may prefer DGBob.

I vote for: Keep it. (And you really don't want to insult Neuron2 by removing his filter, right? ^^)

Classic deinterlacers such as "Linear interpolation" is a bit faster than modern deinterlacers.

Another point for "classic" deinterlacers besides speed is that they produce a 100% artifact-free results. Throw away half of the lines, interpolate to get a full frame.

All those fancy motion-compensated deinterlacers retain more information in "static" areas, but some artifacts slip through here and there.

People that can live with a rather smooth image and don't want to mess with threshold values may prefer one of the simple deinterlacers. Enabled and watch ;)

[haruhiko_yamagata]

Here are some bugs that have been reported in the past. Can anyone confirm if they are still present in revision 2391? If not, I will remove them from the bugtracker:

# Cubic blending deinterlacer doesn't work.
# Anamorphic MPEG-1 video displays with incorrect aspect ratio when using libavcodec as decoder.
# ttxt subtitles are always rendered in italic with small size and with times (new) roman font
# amr audio decoding doesn't work in 64-bit builds?

And here are a few more:
http://sourceforge.net/tracker/index.php?func=detail&aid=2333334&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1924063&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2215967&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1673817&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1952999&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2028210&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2056124&group_id=173941&atid=867360
I would like to release next beta as soon as possible, because the security hole fixed at rev 2349 is very serious.
Some bugs that has been added after beta5 should be fixed before beta6, other bugs before RC1.
@albain: Could you fix the regression bug of subtitle?

[haruhiko_yamagata]

When opening a video file with Visualizations unchecked and all options disabled nothing shows, as supposed.
If while watching the file you open the ffdshow dialog and then check the Visualizations, whitout any options being enabled, if then you start enabling the options nothing shows.

Summarizing: You only could see the Visualizations if any option is checked prior to checking the Visualizations check box.
Thank you. I understand. If you close the dialog, it will appear.

[DeathTheSheep]

Subtitles still bad. (See previous post).


http://img175.imageshack.us/img175/9320/subsny9.jpg

[haruhiko_yamagata]

Source: DVB Source, MPEG-2
Decoder: libavcodec mpeg2video
Oh, yes, it won't work. I've forgotten I've written it won't work.
The fix is impossible in the short term.

pict.srcSize = (size_t)frame->reordered_opaque3; // FIXME this is not correct for MPEG-1/2 that use SOURCE_TRUNCATED. (Just for OSD, not that important bug)

[haruhiko_yamagata]

I would like to remember a very useful proposition Leak did back in October:

http://forum.doom9.org/showthread.php?p=1208512#post1208512
I think I have fixed this. Is it not?

http://forum.doom9.org/showthread.php?p=1208726#post1208726

This would be a nice feature. I hope Leak will eventually implement the feature, but next beta is not bound to it.

[LoRd_MuldeR]

The configuration sliders for "Greedy 2 Frame" still do crazy things in r2392.

Also I'm happy to announce yet another DVBViewer problem:
Moving the window from one screen to another one with Yadif enabled causes "slow motion" playback now :(

[haruhiko_yamagata]

The configuration sliders for "Greedy 2 Frame" still do crazy things in r2392.I see, if I try to slide one slider, another one moves.

Also I'm happy to announce yet another DVBViewer problem:
Moving the window from one screen to another one with Yadif enabled causes "slow motion" playback now :(
Is this once fixed and added back?

[LoRd_MuldeR]

Is this once fixed and added back?

With Yadif enabled:
* Primary screen: Plays perfectly smooth.
* Move to second screen: Get "slow motion" effect
* Move back to primary screen: Plays smooth again
* Move to second screen again: The "slow motion" is back
* And so on...

[Leak]

With Yadif enabled:
* Primary screen: Plays perfectly smooth.
* Move to second screen: Get "slow motion" effect
* Move back to primary screen: Plays smooth again
* Move to second screen again: The "slow motion" is back
* And so on...
What's the CPU use on the second screen? If it goes through the roof it's probably the graphics driver being unable to handle this situation - which for instance also happens if you drag a 3D game window from the primary screen to the secondary; but if this is the case I couldn't think of a reason why yadif should cause it unless it's extra CPU use pushes DVBViewer over the edge...

np: Squarepusher - Duotone Moonbeam (Just A Souvenir)

[yesgrey]

If you close the dialog, it will appear.

Yes, that works. I also tried just clicking the "Apply" button, but had no effect.

[Djon]

Hi :)
Little question : I plan to install Vista 64, should I use ffdshow 64 ? I actually use ffdshow-mt due to my Quad core CPU.
Thanks for responses.

[LoRd_MuldeR]

What's the CPU use on the second screen? If it goes through the roof it's probably the graphics driver being unable to handle this situation - which for instance also happens if you drag a 3D game window from the primary screen to the secondary; but if this is the case I couldn't think of a reason why yadif should cause it unless it's extra CPU use pushes DVBViewer over the edge...

np: Squarepusher - Duotone Moonbeam (Just A Souvenir)

Can't be a graphics driver problem, because I didn't change/update the driver. But I did update ffdshow-MT ;)

But the CPU usage goes crazy indeed. On the primary screen (with Yadif working) it's in the ~10% range.
As soon as I move to the second screen it jumps to ~25%, maximum load for a single core.

[EDIT]

When limiting the output colorspace to RGB32 (let ffdshow do the YUV -> RGB conversion) the problem seems to be gone!

Shouldn't this be even slower? :confused:

[LoRd_MuldeR]

Hi :)
Little question : I plan to install Vista 64, should I use ffdshow 64 ? I actually use ffdshow-mt due to my Quad core CPU.
Thanks for responses.

There is no reason to use ffdshow x64 yet, because...
* Only 64-Bit players would be able to use it (e.g. MPC x64), none of the 32-Bit players
* Usually 64-Bit binaries are less optimized and slower than the 32-Bit binaries, at least for the time being
* ffdshow x64 is still experimental, the x86 version is much more stable
* 32-Bit players using 32-Bit filters (including ffdshow x86) will run on 64-Bit Windows just fine

[Djon]

* Usually 64-Bit binaries are less optimized and slower than the 32-Bit binaries

Okay, thanks for answer, but, what's the advantage of 64-Bit OS so ? Should I use MPC x86 even if I use Vista 64 ?

[LoRd_MuldeR]

Okay, thanks for answer, but, what's the advantage of 64-Bit OS so ?

Support for more than ~3 GB of total RAM. No 2 GB memory limitation per process (64-Bit processes only).

And support for 64-Bit binaries, which could be faster than 32-Bit binaries, if fully optimized for AMD64 processors (few are yet).

Should I use MPC x86 even if I use Vista 64 ?

Yes. If you used MPC x64, you would be limited to use 64-Bit filters!

There are very few 64-Bit filters at the moment and they usually are slower and/or less stable than their 32-Bit pendants.

I just don't see any advantage in going MPC x64 currently, except for testing...

[Djon]

Hmm, so ffdshow-mt + MPC HC x86 is the best combo, doesn't matter 32 or 64 OS ?

[LoRd_MuldeR]

Hmm, so ffdshow-mt + MPC HC x86 is the best combo, doesn't matter 32 or 64 OS ?

Speed-wise yes. Stability-wise no.

For best stability you shouldn't go with ffdshow-MT yet (ffmpeg-MT is work in progress, for example some H.264's still show artifacts).

[leeperry]

I already spoke about it w/ Seb.26(occasional ffdshow coder), and he kept telling me that ffdshow can't resize vertically.

is he right, or are we overlooking something ?

this is a 2.35 movie :

http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031t.jpg (http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031.html)

if I change the AR to 1.78 I get this :

http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aect.jpg (http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aec.html)

is there a way to expand the picture vertically, instead of horizontally ? I've tried every option I could think of :rolleyes:

thanks

[Djon]

I watch a lot of big-resolution movies (1080p +) and I see a little difference with -MT, but thank you for all the answers.
See you at avidemux's forum :)

[LoRd_MuldeR]

I watch a lot of big-resolution movies (1080p +) and I see a little difference with -MT, but thank you for all the answers.

You should see a HUGE speed-difference between ffdshow and ffdshow-MT, especially for HD media :cool:

If you don't see any visual differences then you are lucky and don't have any of the files that are broken with MT ;)

(I checked the sample that was posted a while ago and it still shows artifacts with latest ffdshow-MT build)

[STaRGaZeR]

I think I have fixed this. Is it not?

You introduced changes about how to deal with telecined content in rev2236, flagging it as progressive. Those changes broke Pulldown, so you changed it in rev2276 now sending field information and allowing Pulldown to work. But as Leak says:

So in most places the INT_TFF/INT_BFF bits should be just ignored when PROGRESSIVE_FRAME bit is set, but in the AviSynth filter "Apply Pulldown" would instead ignore PROGRESSIVE_FRAME in favour of the interlacing bits...

In most places, the field information is ignored. But ATI's deinterlacer does not ignore it, and the resulting image is blinking. So in order to allow Pulldown and at the same time don't send field information to the renderer, just frames flagged as progressive, what do you suggest?

[haruhiko_yamagata]

I already spoke about it w/ Seb.26(occasional ffdshow coder), and he kept telling me that ffdshow can't resize vertically.

is he right, or are we overlooking something ?

this is a 2.35 movie :

http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031t.jpg (http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031.html)

if I change the AR to 1.78 I get this :

http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aect.jpg (http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aec.html)

is there a way to expand the picture vertically, instead of horizontally ? I've tried every option I could think of :rolleyes:

thanksffdshow can.
If you stretch vertically too much that the height is bigger than screen height, it will be like that. Your application may shrinking the screen. It depends on application and video renderer.

[haruhiko_yamagata]

In most places, the field information is ignored. But ATI's deinterlacer does not ignore it, and the resulting image is blinking. So in order to allow Pulldown and at the same time don't send field information to the renderer, just frames flagged as progressive, what do you suggest?It is not flagged to downstream, if both FIELD_TYPE::PROGRESSIVE_FRAME and FIELD_TYPE::INT_?FF is set.
Could you send me the sample? I think libmpeg2 wrapper failed to detect telecine for that file.

[leeperry]

ffdshow can.
If you stretch vertically too much that the height is bigger than screen height, it will be like that. Your application may shrinking the screen. It depends on application and video renderer.
ok thanks for the fast reply.
so I've tried both KMP and MPC and set "adjust window from outside" in both players.
I've also set the PAR to 1:1 in ffdshow and the AR to DAR in my players.

yet it's doesn't output 1280 wide picture with 1:78 vertical ratio instead of 2.35

as HR says through its OSD, ffdshow is outputting 973x384 :

http://pix.nofrag.com/0/e/0/89263d60e7624a554b4db90db69c6t.jpg (http://pix.nofrag.com/0/e/0/89263d60e7624a554b4db90db69c6.html)

sure you can upscale 973x384 to 1.78, but I'd like to vertically resize........not horizontally, and I can't get ffdshow to do it :(

[haruhiko_yamagata]

Can't be a graphics driver problem, because I didn't change/update the driver. But I did update ffdshow-MT ;)

But the CPU usage goes crazy indeed. On the primary screen (with Yadif working) it's in the ~10% range.
As soon as I move to the second screen it jumps to ~25%, maximum load for a single core.

[EDIT]

When limiting the output colorspace to RGB32 (let ffdshow do the YUV -> RGB conversion) the problem seems to be gone!

Shouldn't this be even slower? :confused:Probably the video renderer switch to GDI or something slower.
By the way, in which revision does the problem start? Is it the same from the start?

[haruhiko_yamagata]

The configuration sliders for "Greedy 2 Frame" still do crazy things in r2392.
Thank you for finding this issue.
After fixing it at rev 2397, it looks like more general problem.

[fastplayer]

Yes, it will be OK.
Just tested it with the "Forbidden Kingdom" DVD and it works both in MPC and WMP.
:thanks:

[KoD]

When ffdshow is installed, choosing to reset settings during install, the following video decoders are enabled:
FVFW
QTRLE
QRZPA
FFV1

While FVFW and FFV1 are formats that are specific to ffdshow, so it's understandable to have them enabled by default, I don't know if QTRLE and QRZPA should get the honors of being enabled by default as well. After all, much more common formats like xvid, divx and h264 are not. What do you think ?

[fastplayer]

..., I don't know if QTRLE and QRZPA should get the honors of being enabled by default as well.
I agree. ffdshow's policy is to override as little as possible. Most people have QT installed anyway which should take care of the formats you mentioned.

[clsid]

I agree that they shouldn't be enabled. But they aren't interfering with QT, which isn't a DirectShow player.

Edit: they don't get enabled here after deleting ffdshow's registry keys. Theora does however, and I will fix that.

[tal.aloni]

@developers,
when I fixed the Grab filter related Color Space conversion issue, I noticed that there were some major inconsistencies regarding the RGB colorspace. the FF_CSP_ enum is referring to how the bytes are stored in memory, which is the opposite of the writing order under x86 architecture (little endians).
we work with many libraries, some use the write order(libmplayer), and some use the "byte order" (ffmpeg).

(also, when writing to files, the write order equals to the "byte order", which makes things even more confusing)
it's hard to decide what's right to do in this case, because in any way, our enum will appear to be erroneous,

I made a patch that I think will make the code more clear,
I guess future work should be done (comments etc.),
I would like to hear what you think, and if you have a better suggestion.

http://iknowu.net/files/public/ffdshow/2401-LittleEndian.patch

Tal

to summerize, I replaced the FF_CSP_RGB?? in the enum with FF_CSP_BGR?? and vice versa, and defined the following: (I also replaced the FF_CSP_????? in the rest of the code, to match the appropriate values)

#define FF_CSP_RGB15_LITTLE_ENDIAN FF_CSP_BGR15
#define FF_CSP_RGB16_LITTLE_ENDIAN FF_CSP_BGR16
#define FF_CSP_RGB24_LITTLE_ENDIAN FF_CSP_BGR24
#define FF_CSP_RGB32_LITTLE_ENDIAN FF_CSP_BGR32
#define FF_CSP_BGR15_LITTLE_ENDIAN FF_CSP_RGB15
#define FF_CSP_BGR16_LITTLE_ENDIAN FF_CSP_RGB16
#define FF_CSP_BGR24_LITTLE_ENDIAN FF_CSP_RGB24
#define FF_CSP_BGR32_LITTLE_ENDIAN FF_CSP_RGB32

[jmartinr]

@ leeperry

I'd like to vertically resize........not horizontally, and I can't get ffdshow to do it.

If you crop the sides in the avisynth filter section before resizing you can do what you want. At least that is when I understood your problem correctly.

I've automated the cropping like this:

# if DAR is bigger than 16:9 we crop something off
# maximum DAR x:y
mx=16
my=9
maxwidth=round(last.height*float(ffdshow_sar_y)*mx/ffdshow_sar_x/my)
maxwidth=maxwidth-(maxwidth%16)
maxwidth=min(last.width,maxwidth)
crop((last.width-maxwidth)/2,0,maxwidth,0)

[leeperry]

@ leeperry
If you crop the sides in the avisynth filter section before resizing you can do what you want. At least that is when I understood your problem correctly.
cool, thanks!

but after I asked him a while ago, haruhiko was kind enough to add AR presets in ffdshow.

this is very convenient, like for mod8/16 movies that don't have exactly the right AR(like 2.42 instead of 2.40, or 2.37 instead of 2.35)

but fixing the AR will add horizontal black borders at this point....and I can't find a way to get ffdshow to vertically resize :confused:

Seb.26 tells me that ffdshow can't vertically resize, haruhiko tells me the opposite....

apparently ffdshow resize works as if you checked "touch window from inside" in MPC, when what you want is "touch window from outside" :(

maybe a ffdshow/HR limitation, or some misconfigured option I overlooked :rolleyes:

[jmartinr]

@leeperry

Keep fiddling around. I have ticked "borders inside" and I can resize vertically. Any film I play is resized to 720x576 (my TV's resolution).

[leeperry]

@leeperry

Keep fiddling around. I have ticked "borders inside" and I can resize vertically. Any film I play is resized to 720x576 (my TV's resolution).
well I'm trying it on a 2.19:1 720p trailer

whatever inside or outside borders doesn't change much as I don't add borders.

I got resize enabled to 1280*768, if I check 1.78 or 2.35 the picture is nowhere near vertically large enough for this AR...

oh well, ffdshow is too l33t for me I guess :D

[jmartinr]

@ leeperry

It's still not very clear to me.

1. Do you want to keep the pixel aspect ratio?
2. Do you crop the sides?

You have to use one of two methods to change the screen aspect ratio. Which one is it?

[leeperry]

@ leeperry
It's still not very clear to me.

1. Do you want to keep the pixel aspect ratio?
2. Do you crop the sides?

You have to use one of two methods to change the screen aspect ratio. Which one is it?
well I wanna change the DAR.
like resizing a 1280*540 video to 1280*720 for instance, going from 2.37 to 1.78

exactly as if you checked "touch window from outside" in MPC/KMP...when right now ffdshow is working as if I had "touch window from inside" enabled.

maybe coz I set the PAR to 1:1? hah :p

[KoD]

I agree that they shouldn't be enabled. But they aren't interfering with QT, which isn't a DirectShow player.

Edit: they don't get enabled here after deleting ffdshow's registry keys. Theora does however, and I will fix that.

When installing ffdshow, there's this entry called "Reset all video/audio settings" or something like that, for both video and audio. I thought the purpose of checking that entry (not half-checked, but fully checked) was to remove any video codec entries. That's why I find it odd to see that when I check it, those two QTxx formats are enabled.

It's not like it's hard to disable them manually each time after installing ffdshow, but I really don't see the point in having them enabled. Let's see, when checking that entry during setup, divx, xvid, h264, and all of the audio formats are disabled, but these two are not. Which exactly are more likely to be used by people, these two oddballs or the really common formats ? It doesn't make sense.

Besides, those two don't help with Quicktime playback either, you'd need the audio formats for Quicktime enabled as well (and they are not when you reset the audio settings during setup), and not all audio formats Quicktime has used in the past can be decoded by ffdshow either, at least from what I remember. Once again, it doesn't make sense and it's not consistent.

I'm starting to feel this is more an issue of "this guy always criticizes us, so we'll always say No to whatever he says". If that's the case, you can do better than that.

[haruhiko_yamagata]

Finally, a few bugs that have been reported before but I don't know if they're accounted officially:
1. mpeg1 layer 3 in avi files causes "clicks" when libavcodec is used as a decoder (Microsoft's avi splitter is used); same files don't show this behavior when mp3lib for instance is used
2. mpeg1 layer 2 in mpg files also causes clicks when libacodec is used as a decoder (Microsoft's mpeg splitter is used); same files don't show this behavior when mp3lib for instance is used

I can't reproduce. Is it hard to hear? Does it depend on samples?
I think Microsoft's AVI splitter is used.

[rack04]

My latest test results:

ffdshow tryouts svn 2399
User: 60s, kernel: 0s, total: 60s, real: 70s, fps: 63.3, dfps: 54.6

ffdshow tryouts -mt 2392
User: 5s, kernel: 0s, total: 6s, real: 52s, fps: 638.5, dfps: 73.5

[clsid]

@KoD, I generally don't use ffdshow's installer, so that's why I didn't notice it. I have fixed the install script.

[LoRd_MuldeR]

My latest test results:

ffdshow tryouts svn 2399
User: 60s, kernel: 0s, total: 60s, real: 70s, fps: 63.3, dfps: 54.6

ffdshow tryouts -mt 2392
User: 5s, kernel: 0s, total: 6s, real: 52s, fps: 638.5, dfps: 73.5

What video format? And how many threads/cores? :confused:

[rack04]

What video format?

General
Complete name : C:\Personal\Videos\inkheart-tlr2a_h1080p.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 153 MiB
Duration : 2mn 8s
Overall bit rate : 9 998 Kbps
Encoded date : UTC 2008-11-30 16:02:09
Tagged date : UTC 2008-11-30 16:02:09
Writing application : Yamb 2.0.0.8 [http://yamb.unite-video.com]

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 8s
Bit rate mode : Variable
Bit rate : 9 896 Kbps
Maximum bit rate : 26.7 Mbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.400
Frame rate mode : Constant
Frame rate : 29.970 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.215
Stream size : 151 MiB (99%)
Encoded date : UTC 2008-10-20 18:09:37
Tagged date : UTC 2008-11-30 16:02:17

Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 2mn 8s
Bit rate mode : Variable
Bit rate : 98.1 Kbps
Maximum bit rate : 164 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 44.1 KHz
Resolution : 16 bits
Stream size : 1.50 MiB (1%)
Encoded date : UTC 2008-11-30 16:02:16
Tagged date : UTC 2008-11-30 16:02:17


And how many threads/cores? :confused:

I don't know how to change the threads/cores.

The test was run on my laptop. Intel Mobile Core 2 Duo T7250.

[LoRd_MuldeR]

I don't know how to change the threads/cores.

START -> Programs -> ffdshow -> Video decoder configuration -> Decoder options -> Libavcodec options -> Number of decoding threads

The test was run on my laptop. Intel Mobile Core 2 Duo T7250.

That explains the "small" speed-up between ffdshow and ffdshow-MT. On a Quadcore you'd see a bigger difference :cool:

[rack04]

START -> Programs -> ffdshow -> Video decoder configuration -> Decoder options -> Libavcodec options -> Number of decoding threads



That explains the "small" speed-up between ffdshow and ffdshow-MT. On a Quadcore you'd see a bigger difference :cool:

So the note that pops up when changing the number of decoding threads that says "mpeg1/2 decoder only" does not apply? I can test later with my Q6600.