ffdshow tryouts project: Discussion & Development

[leeperry]

well resizing only x to 1280 still outputs 1.78

I know I'm resizing to 1.67, yet I've never ever had this kind of problem before.

I would guess that the WMV splitter does the job right, considering ffdshow show the AR as 2.35

I've just tried with mpc2kxp6490, and it's............the same :D

so what's better then ?

YV12 resize and sharpening because there's no colorspace conversion

OR

YUY2 resize and sharpening because it's 16 bit instead of 12 ?

We usually process audio in 32/64 bit to get better overall results :D

[Inventive Software]

Right, I'm downloading this WMV-HD video, to try and figure out what the hell's going on. :D

Regarding YV12 vs YUY2, YV12 is YUV 4:2:0, YUY2 is 4:2:2. There's no difference between the output, unless your filters only work in YUY2.

Can you use MPC 6.4.9.1 from now on in this scenario, as that's what I'm running, and that fixes a few bugs and that's it. MPC-HC is too bleeding-edge to be considered reliable, because most new features in that end up breaking something, and I do read that thread occasionally, so I know what I'm staying away from.

One last thing. In the "Output" section of ffdshow's config, can you confirm the following settings...

- Planar YUV (mine's all enabled);
- Packed YUV (mine's all enabled);
- RGB (mine's all enabled, except YV12 to RGB) (if enabled, please disable YV12 to RGB conversion);
- Select Closest matching colorspace (mine's enabled);
- Set pixel aspect ratio in output media type (mine's enabled);
- Allow output format changes during playback - half-filled, not ticked.

Last thing, what's your ffdshow revision? I use 1856, and haven't updated it since.

[leeperry]

well, even if the source is 4:2:0, it's better to process in 4:2:2......ain't it ?
12 Vs 16 bit :eek:

and the "high quality YV12 to RGB conversion" does exactly that........YV12 > YUY2 > RGB32(haruhiko confirmed it) :D

I think I'll stick to YUY2 output to get upsampled chroma :D

but I'm not sure if resize and sharpening are processed depending on the input or the output colorspace ? :eek:

if it's done in YV12 like the source, then converted to YUY2 in the end.........it's pointless :(

if so, then I should use CoreAVC in YUY2........to make sure that ffdshow works in YUY2 as well :D


I use the latest build from XXL, everything's unchecked in the output section......except for YUY2

I've tried to enable the other options, didn't change a damn thing :D

[Inventive Software]

Well the easy way to determine whether your sharpen and resize work in YV12 or not is to do exactly that.... make it output YV12 ONLY! ;)

And the 4:2:0 to 4:2:2 then filtering, then converting back to 4:2:0 is a waste of CPU time because there's 2 (4?) bits not being used. Keep everything in the chain YV12 to be sure it's doing its job.

It's not actually up-sampling, because it's creating new data based on nothing! ;)

And I tried downloading that source that you have problems with, but my internet's so slow at my halls that I'll wait until uni tomorrow. So I can't do anything until then. Sorry.

[leeperry]

ohhhhhhhhhhh, so even with YUY2 output from CoreAVC, the extra chroma bits are not used at all ? :eek:

well video processing such as resize/sharpening would put those bits to use, or am I missing something ?

and I don't even know if they are processed in the colorspace of the input or of the output ?!

like sampling a vynil audio source in 24/96 and doing 64/192 post-processing on top of it ?!

[Inventive Software]

The only way CoreAVC would output usable YUY2 video is if the H.264 video was encoded as YUY2. Most of the time it's YV12. YUY2 is useful for connecting to a couple of renderers and filters that can't accept YV12 video, hence that option.

If you're recording at 24/96 and doing 64/192 post-processing, I'd ask why you're not recording at 64/192 in the first place. The extra precision may help if there's interpolation in the post-processing, but it's the same deal when encoding from that. Unless you're doing the final encode at 64/192 you lose what was calculated, which in audio is sometimes actually useable. So do the whole chain in 24/192, and don't convert inbetween.

If you have some time on your hands, do a test with ffdshow's video filters, and enable JUST YV12, YUY2 and RGB output, conversion enabled. If the filters work in all 3, you're fine and dandy. If you can see that it's better, great, all the better for you. If they don't work in YUY2 or RGB or YV12, please state which ones so that others don't make that mistake.

:)

[leeperry]

well the whole point of doing 64/192 post processing on 24/96 material is to get more precise roundings.

even if in the end you downsample to 24/96 again with noise shaping, you still end up with better roundings.......and the more filters you use, the better it gets :D

doing YUY2 resize/sharpening on YV12 input follows the same idea.........more usable bits....which then are converted to RGB32 by the videocard mixer, and then to RGB24 to the DVI output.

I just dunno if the ffdshow filters are processed in the input or the output colorspace ?!

I'm colorblind so I can't "see" changes.........but the smoother the roundings, the smoother the color fades.....and the reward would be less banding in the end :D

[SeeMoreDigital]

Lee,

Please try the "non HD" version of MPC and report your findings?


Cheers

[leeperry]

I did :D

I've just tried with mpc2kxp6490, and it's............the same :D

[SeeMoreDigital]

I did :DIn that case...

I think some of your MPC/FFdshow settings must be in-conflict with each other :eek:

The WMV sample is displayed at the correct aspect ratio for me.... ie: MAR=2.352941176:1 (or 40:17), ARS=4:3

[leeperry]

well, If I disable ffdshow I get correct AR.

what do u have enabled in ffd ?

[haruhiko_yamagata]

Is "Allow output format changes during playback" checked?

[haruhiko_yamagata]

ok Vincent Burel got back to me with some debug infos :

with his FFX4 plugin, available here :
http://vincent.burel.free.fr/download/ffx4WinAmp_FullDemo.zip

when you skip to a new song in MPC HC, his DLL is released before the destruction function was over.
the closing procedure of the plugin keeps on doing its work, BUT the DLL is not available on the system anymore.

so the FreeLibrary call is done too early, you need to wait for the QUIT call to be finished before closing the library.

sometimes it works(eg when you click on CONFIGURE in the ffdshow winamp plugin options), because the library is overwritten before the QUIT call was made, and that seems to work fine....but after 3 files in a row it's using 70% of CPU time.

any chance for a fix please ? :thanks:The dll is unloaded after QUIT call.
But finally I found that QUIT had to be called before the Window class was destroyed.
Rev 1928 should improve stability of Winamp plug-in feature, yet there are some other problems.

[leeperry]

OMG OMG OMG, finally a fix for Ozone ?! :D

can you play several files in a row w/o ffdshow audio crashing ? :eek:

thank you haruhiko!

can someone PLEASE compile rev1928 ? :D

Is "Allow output format changes during playback" checked?

just tried, doesn't change anything.

I'll try to reset ffdshow to defaults :devil:

[Inventive Software]

(Changed a few things)
One last thing. In the "Output" section of ffdshow's config, can you enable the following settings...

- All Planar YUV;
- All Packed YUV;
- All RGB except YV12 to RGB;
- Enable "Select Closest matching colorspace";
- Enable "Set pixel aspect ratio in output media type";
- Enable "Allow output format changes during playback", but make it not ticked, just filled.


Please either make a profile in ffdshow like that or make your settings like that currently, and then play it again.

And methinks you might have to wait a while (hours, possibly) to get your 1928 build. ;)

[leeperry]

well Seb.26(an occasional ffdshow coder) will build it for me in a few hours if noone else does in the meantime:D

ok you nailed it!

I need to have "Set pixel aspect ratio in output media type" and "Allow output format changes during playback" filled(not ticked)........then it's OAR :)

only one of the two options and it's 1.78.

should I fill these 2 options for all my profiles(SD,720p,1080p) ?

Thanks!

and BTW concerning my YV12 upsampled to YUY2, Seb.26 has told me that the sharpen filter of ffdshow works in YV12 :eek:

[Inventive Software]

If that ends up not working, and you're ready and willing to sort this, get GraphEdit and I'll give you my MSN addy via PMs. I got things to sort in the mean time, so gimme a couple hours. ;)

[leeperry]

I've edited my post actually :D

[haruhiko_yamagata]

OMG OMG OMG, finally a fix for Ozone ?! :D

can you play several files in a row w/o ffdshow audio crashing ? :eek:Yes, but not hundred. It doesn't crash anymore, but there are occasional freezes.

[SeeMoreDigital]

well, If I disable ffdshow I get correct AR.

what do u have enabled in ffd ?I have "libavcodec" selected.

[Inventive Software]

well Seb.26(an occasional ffdshow coder) will build it for me in a few hours if noone else does in the meantime:D

ok you nailed it!

I need to have "Set pixel aspect ratio in output media type" and "Allow output format changes during playback" filled(not ticked)........then it's OAR :)

only one of the two options and it's 1.78.

should I fill these 2 options for all my profiles(SD,720p,1080p) ?

Thanks!

and BTW concerning my YV12 upsampled to YUY2, Seb.26 has told me that the sharpen filter of ffdshow works in YV12 :eek:

About bloody time! Keep it that way! :D

[leeperry]

ok great, Seb.26 just gave me that new rev http://forum-images.hardware.fr/images/perso/mamy_furax.gif :
http://membres.lycos.fr/sebfr26/PCHC/.public/ffdshow.ax

so good news, now you can open two files in a row w/ Ozone.......but it start freezing at the third, and the more you open the more it freezes and the fifth refuses to open :(

like there was a deadlock ?! :eek:

it seems that the DX wrapper works fine as you said :)

but more importantly, you can take off the dsp wrapper from the blacklist coz it works perfectly fine now.......it even hides its GUI :)

at this point it's my best bet to find some similar plugin to Ozone in VST : http://www.savioursofsoul.de/Christian/Programs/WinAmp_VST_Bridge.exe

perfect VST support in ffdshow, AWESOME :eek:

thanks for all!

[leeperry]

to get back on the colorspace output differences with yv12 x264 input(with resize+sharpen)

the test video is available here :
http://www.megaupload.com/fr/?d=UE3O6G2J

yuy2:
http://www.freepicshost.net/pview.php?fid=9012&fname=yuy2.png

yv12:
http://www.freepicshost.net/pview.php?fid=9013&fname=yv12.png

rgb32:
http://www.freepicshost.net/pview.php?fid=9010&fname=rgb32.png

rgb32hq:
http://www.freepicshost.net/pview.php?fid=9011&fname=rgb32hq.png

YUY2 looks smoother(extra chroma bits?) than YV12, and same goes for RGB32 over RGB32HQ :eek:

[Px]

Thumbs images unavailable
http://www.freepicshost.net/public/thumb_47fd4dc8542c9353503495.png
Forbidden
You don't have permission to access /public/thumb_47fd4dc8542c9353503495.png on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

[leeperry]

fixed, click the links :D

ok this VST plugin seems to sound better than Ozone :

http://static.kvraudio.com/i/b/spectralive2.jpg

it works fine with ffdshow and the VST wrapper, but I've just opened like I dunno.........200 files in 3/4H and now it's freezing for each new file even if MPC HC was closed ?

I don't plan on rebooting my PC everyday :(

[foxyshadis]

Check that mpc is gone and not just closed. Sometimes something refuses to unload even though the GUI is gone, and it turns out there's a few copies of MPC still open in task manager.

[Shinigami-Sama]

I agree with foxy; I've had that problem a few times - also my enter key is no longer functioning here on doom9...

[leeperry]

Check that mpc is gone and not just closed. Sometimes something refuses to unload even though the GUI is gone, and it turns out there's a few copies of MPC still open in task manager.

yes I did, thanks for the tip!

I've removed the dsp stacker plugin, even though it wasn't in use, it was freezing to death ?! :eek:

ok nothing sounds as good as OZone :(

any chance to add a delay when you QUIT to avoid deadlock ?! :(

BTW, look at Amelie Poulain in EVR + unsharp mask 33 :

http://pix.nofrag.com/4/2/3/2ce84a7dbbfc9bab48e19a16b91d7tt.jpg (http://pix.nofrag.com/4/2/3/2ce84a7dbbfc9bab48e19a16b91d7.html) http://pix.nofrag.com/7/9/2/3fd6ab8948752efeb2a8e5d1b46aatt.jpg (http://pix.nofrag.com/7/9/2/3fd6ab8948752efeb2a8e5d1b46aa.html)

[jmartinr]

I would like the crop filter to respect PAR.

I always use "resize and aspect" to get video perfect on my TV.

I use "specify horizontal and vertical size", "keep original aspect ratio", "resize always" and "process pixel aspect ratio internally". Works great. But if I crop before, ratio isn't correct.

Cropping via the Avisynth filter does work. But I have an old computer attached to my TV, so if I could use the crop filter straightaway, speed would be helped and it would be more handy too.

Only thing needed I think/hope is that crop doesn't change PAR.

[clsid]

You could move crop below resize.

[cyberbeing]

I don't know if this is a ffdshow bug or a flv splitter bug but I'm suspecting there is a similar bug in both.

Sample1: http://www.mediafire.com/?cd2tyy2w9ew 640x360 30.000fps (reported by MediaInfo)
Sample2: http://www.mediafire.com/?bvgsdywr5gh 720x405 29.970fps (reported by MediaInfo)

FFDShow (latest clsid build) reports 25.000fps (renderer uses 30.000/29.970fps anyways) and outputs 640x368/720x416 even when using the Nero splitter (which reports 640x360/720x405) which results in seeing a 8/11 pixel blurry bar on the bottom of the video.

MPC-HC FLV decoder outputs 640x368/720x416 25.000fps (renderer uses 30.000/29.970fps anyways) even when using Nero Splitter.

FLVsplitter 1.0.0.4 reports 640x368/720x416

Nero FLV Splitter reports 640x360/720x405

Mplayer reports and outputs 640x360/720x405 30.000/29.970fps

Adobe Media Player outputs 640x360/720x405

Streaming players output 640x360/720x405

Any ideas? (16:9 MOD16 bug?)

[Placio74]

I don't know if this is a ffdshow bug or a flv splitter bug but I'm suspecting there is a similar bug in both.
...
Hmm...

But GSpot, VirtualDub with FLV input plugin (and ffdshow VfW as decoder) and Avidemux show 640x368/720x416.

After used FLV Extract - AVI files have 640x368/720x416 (MediaInfo show too).
With blurry bar on the bottom of the video when play or edit.
Same when change container used Avidemux.

After change container to AVI (used FLV Extract or Avidemux) and FourCC to VP62 - when play or edit with original VP6 codec - still blurry bar on the bottom of the video (exactly not bottom, but top - because image video is flip) and of course 640x368/720x416.

Used FLVMDI i'm see 640x360/720x405 in metadata info.

When change container to AVI used FFmpeg... most tools show 640x360/720x405.
VirtualDub with FLV input plugin and ffdshow VfW as decoder show 640x360/720x405.
When play (system AVI splitter and ffdshow) i'm see 640x368/720x416 and GSpot show too - but when change FourCC and use VP6 codec it's... 640x360/720x405. Except... when use ffdshow instead VP6 codec... it's again 640x368/720x416.

Odd...:confused:

[jmartinr]

You could move crop below resize.
Yes I could, but I want to end at a fixed size. Using Nvidia tv out that's wanted (if you want to know why see: http://www.jillesvangurp.com/2006/11/06/nvidia-tv-out-aspect-ratio-trouble-workaround/).

[clsid]

The FLV problem has nothing to do with ffdshow. The video decoder must crop off the blurry part, however afaik there is no way that the FLV splitter can signal the correct resolution to the video decoder.

[Mercury_22]

It's possible to add E-AC3 support, sice there is already a FFmpeg patch ? Look here http://forum.doom9.org/showthread.php?t=129050
Please ! :thanks::helpful:

(Even just experimental :stupid:)

[Inventive Software]

:search: It's not happening any time soon. Until it makes it into ffmpeg's SVN trunk, it won't make it into our trunk. ;)

[cyberbeing]

The FLV problem has nothing to do with ffdshow. The video decoder must crop off the blurry part, however afaik there is no way that the FLV splitter can signal the correct resolution to the video decoder.
That confuses me a little. So why are the extra blurry pixels (which I'm assuming don't even exist) being created on the bottom when FFDshow is used? What about the wrong reported framerate of 25fps? FFDshow is being passed 640x360 by the Nero FLV Splitter, FFDshow's video decoder info & cpu shows 640x360, yet it outputs 640x368 to the renderer. I was assuming there was some (GPL?) code being shared between multiple decoders/splitters that was wrongly forcing mod16 on flash video content.

FFDShow output pin (RGB & YV12 looks almost identical to YUY2 below)
- Connection media type:

Video: YUY2 640x368 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 471040
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(640,368)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 40
dwPictAspectRatioY: 23
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 640
biHeight: -368
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 471040
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 80 02 00 00 70 01 00 00 ........€...p...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 28 00 00 00 17 00 00 00 ........(.......
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 02 00 00 ........(...€...
0050: 90 fe ff ff 01 00 10 00 59 55 59 32 00 30 07 00 �þÿÿ....YUY2.0..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

- Enumerated media type 0:

Video: YUY2 640x360 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 460800
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(640,360)
rcTarget: (0,0)-(640,360)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 640
biHeight: 360
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 460800
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0010: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 10 00 00 00 09 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 02 00 00 ........(...€...
0050: 68 01 00 00 01 00 10 00 59 55 59 32 00 08 07 00 h.......YUY2....
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

- Enumerated media type 1:

Video: YUY2 640x360 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 460800
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(640,360)
rcTarget: (0,0)-(640,360)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

BITMAPINFOHEADER:
biSize: 40
biWidth: 640
biHeight: 360
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 460800
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0010: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 28 00 00 00 80 02 00 00 68 01 00 00 01 00 10 00 (...€...h.......
0040: 59 55 59 32 00 08 07 00 00 00 00 00 00 00 00 00 YUY2............
0050: 00 00 00 00 00 00 00 00 ........

- Enumerated media type 2:

Video: 640x360 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB32 {E436EB7E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 921600
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(640,360)
rcTarget: (0,0)-(640,360)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 640
biHeight: 360
biPlanes: 1
biBitCount: 32
biCompression: 0
biSizeImage: 921600
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0010: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 10 00 00 00 09 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 02 00 00 ........(...€...
0050: 68 01 00 00 01 00 20 00 00 00 00 00 00 10 0e 00 h..... .........
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

- Enumerated media type 3:

Video: 640x360 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB32 {E436EB7E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 921600
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(640,360)
rcTarget: (0,0)-(640,360)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

BITMAPINFOHEADER:
biSize: 40
biWidth: 640
biHeight: 360
biPlanes: 1
biBitCount: 32
biCompression: 0
biSizeImage: 921600
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0010: 00 00 00 00 00 00 00 00 80 02 00 00 68 01 00 00 ........€...h...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 28 00 00 00 80 02 00 00 68 01 00 00 01 00 20 00 (...€...h..... .
0040: 00 00 00 00 00 10 0e 00 00 00 00 00 00 00 00 00 ................
0050: 00 00 00 00 00 00 00 00 ........

[akupenguin]

After change container to AVI (used FLV Extract or Avidemux) and FourCC to VP62 - when play or edit with original VP6 codec - still blurry bar on the bottom of the video (exactly not bottom, but top - because image video is flip) and of course 640x368/720x416.
It just so happens that I have written a VP6 encoder and had to deal with exactly that issue.
VP62 is not identical to VP6F. One of the differences is that VP6F has an extra header field specifying the exact video resolution for the decoder to crop it to, while VP62 doesn't and can only derive resolution from number of macroblocks. Either your extractor removed that header, or the decoder ignored it since it's not supposed to exist in the new format.
FFDshow is being passed 640x360 by the Nero FLV Splitter, FFDshow's video decoder info & cpu shows 640x360, yet it outputs 640x368 to the renderer.Stuff like that can happen if the container disagrees with the video stream itself about the resolution.
Some players might also choose to crop the decoded video to the container's resolution (and might or might not crop the correct edge).

[jmartinr]

You could move crop below resize.
Though not my preferred solution I tried it.

I put Crop after Resize & Aspect and that doesn't do anything. :-(

[still using: "specify horizontal and vertical size", "keep original aspect ratio", "resize always" and "process pixel aspect ratio internally"]

[clsid]

I have uploaded two different builds of libavcodec (compiled with different GCC settings) here:
http://www.zshare.net/download/105865011265b406/

Everyone feel free to run some benchmarks and let me know if there is any noticeable performance difference between the two builds.

[wyrd]

I've tried with TheGreatestGame(H.264) (http://tirnanog.fate.jp/tmp/mp4_test/TheGreatestGame_HD_AVC.mp4).
(on C2D(E6600),filter not use,skip deblocking always)
result(timecodec)
(http://tirnanog.fate.jp/tmp/comparison/ffdshow_comparison_clsid_20080415_test.txt)Regards

[Px]

C2D 6300@2.8 GHz, renderer - null

H264_24Mbps_final.mkv, H.264, 1920x1080, 24 Mbps
dll_1
User: 2s, kernel: 0s, total: 2s, real: 32s, fps: 459.3, dfps: 35.7
User: 1s, kernel: 0s, total: 2s, real: 32s, fps: 534.2, dfps: 35.8
dll_2
User: 2s, kernel: 0s, total: 2s, real: 31s, fps: 465.0, dfps: 37.2
User: 1s, kernel: 0s, total: 2s, real: 31s, fps: 570.7, dfps: 36.9

Doom.720p.avi, DivX, 1280x720, ~4 Mbps
dll_1
User: 12s, kernel: 0s, total: 12s, real: 11s, fps: 145.1, dfps: 163.4
User: 12s, kernel: 0s, total: 12s, real: 11s, fps: 146.8, dfps: 164.3
dll_2
User: 11s, kernel: 0s, total: 11s, real: 10s, fps: 152.0, dfps: 164.7
User: 12s, kernel: 0s, total: 12s, real: 10s, fps: 146.0, dfps: 165.9

cornell_m1080p.mov, H.264, 1920x1080, ~10 Mbps
dll_1
User: 70s, kernel: 0s, total: 70s, real: 63s, fps: 50.8, dfps: 56.5
User: 68s, kernel: 0s, total: 69s, real: 63s, fps: 52.1, dfps: 56.5
dll_2
User: 60s, kernel: 0s, total: 60s, real: 62s, fps: 59.0, dfps: 57.3
User: 66s, kernel: 0s, total: 66s, real: 61s, fps: 54.4, dfps: 58.1

[cyberbeing]

AMD X2 4800+ 2.4Ghz
1440x1080 x264 16:9 anamorphic ~6Mbps

rev1925
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 634.7, dfps: 52.6
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 617.5, dfps: 52.0
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 519.3, dfps: 52.5
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 557.3, dfps: 53.0

libavcodec_1
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 531.3, dfps: 52.4
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 431.1, dfps: 52.6
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 439.4, dfps: 53.0
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 714.0, dfps: 52.8

libavcodec_2
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 439.4, dfps: 51.9
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 496.7, dfps: 52.9
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 634.7, dfps: 52.6
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 519.3, dfps: 51.8

[wyrd]

with rev1943 (http://tirnanog.fate.jp/tmp/comparison/ffdshow_comparison_clsid_rev1943_test.txt)

[Yong]

Vista x86, amd athlon 6000+, yv12 output colorspace, null renderer.

mpeg1 video, 800x600, 24fps, 8mbps
libmpeg2, msvc 2008 express
User: 10s, kernel: 0s, total: 10s, real: 10s, fps: 315.1, dfps: 306.2
User: 10s, kernel: 0s, total: 10s, real: 10s, fps: 316.0, dfps: 307.6
User: 10s, kernel: 0s, total: 10s, real: 10s, fps: 314.6, dfps: 305.3
libavcodec, gcc4.2.1 r1938
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 2278.1, dfps: 292.0
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 2410.5, dfps: 284.8
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 2094.0, dfps: 292.0
libavcodec_1.dll
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 2094.0, dfps: 289.1
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 1974.3, dfps: 287.9
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 2205.4, dfps: 290.4
libavcodec_2.dll
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 2528.1, dfps: 289.5
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 1901.9, dfps: 286.7
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 2229.1, dfps: 287.1

XviD, 704x396 29.97fps 3mbps
xvidcore.dll, gcc4.2.1
User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 498.8, dfps: 486.7
User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 495.7, dfps: 486.7
User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 495.7, dfps: 486.8
xvidcore.dll, msvc2008 express
User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 451.4, dfps: 445.2
User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 459.1, dfps: 452.7
User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 453.9, dfps: 445.2
libavcodec, gcc4.2.1 r1938
User: 3s, kernel: 0s, total: 3s, real: 4s, fps: 638.7, dfps: 624.0
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 651.6, dfps: 633.7
User: 3s, kernel: 0s, total: 3s, real: 4s, fps: 646.4, dfps: 626.3
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 646.4, dfps: 633.7
libavcodec_1.dll
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 651.6, dfps: 638.7
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 656.9, dfps: 636.3
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 665.0, dfps: 641.3
libavcodec_2.dll
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 659.6, dfps: 633.7
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 654.3, dfps: 641.3
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 670.5, dfps: 651.6

h264(x264-680m, high profile), 1920x1088, 29.97fps 10mbps
libavcodec, gcc4.2.1 r1938
User: 3s, kernel: 0s, total: 4s, real: 13s, fps: 124.0, dfps: 37.6
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 125.9, dfps: 37.5
User: 3s, kernel: 0s, total: 4s, real: 13s, fps: 123.5, dfps: 37.2
libavocdec_1.dll
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 128.5, dfps: 36.6
User: 3s, kernel: 0s, total: 4s, real: 13s, fps: 121.6, dfps: 36.6
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 134.4, dfps: 36.3
libavcodec_2.dll
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 129.5, dfps: 36.6
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 132.2, dfps: 36.4
User: 3s, kernel: 0s, total: 4s, real: 13s, fps: 118.1, dfps: 36.6
libavcodec, gcc4.2.1 r1945
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 377.8, dfps: 47.2
User: 0s, kernel: 0s, total: 1s, real: 10s, fps: 479.3, dfps: 47.0
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 396.5, dfps: 46.6

[clsid]

H.264 decoding should be a bit faster since rev1941.

[fastplayer]

H.264 decoding should be a bit faster since rev1941.
Xvid's IDCT uses now SSE2 instead of MMX. Maybe it's faster too...

[EpheMeroN]

Has anyone had issues decoding DivX5 video files with ffdshow tryouts? I have a DivX5 file that when opened up in Media Player Classic only the audio plays. Tested video in VLC and plays back fine.

I'm using ffdshow tryouts rev1897 nightly build from Mar 9 2008.

[leeperry]

strangest things happen sometimes :)

I've updated to the latest MPC HC/ffdshow from clsid/EVR

if I enable the luma sharpen to 0.10 in my spline/spline resize, then MPC HC will stay in memory when I close it if I open 2 WMV files in a row.

if I disable the luma sharpen, then MPC HC never hangs at shutdown.

also happens with 1080p MKV files randomly :eek:

[clsid]

@EpheMeroN

ffdshow can decode divx5 just fine. So there is probably something wrong with your file. Try another AVI splitter. Or remux your file with VirtualDub/Avidemux.