ffdshow tryouts project: Discussion & Development

[STaRGaZeR]

Seeking using libavcodec on H.264 videos (r2583) sometimes gives horrible desync and crazily fluctuating frames per second till about 5-10 seconds in.. when it levels out and goes back to being synchronized.

But it no longer displays corrupted frames! No garbled frames with all renderers Haruhiko. The changes made in rev2579 and rev2580 have affected at all formats decoded by libavcodec. Xvid and DivX seeking is strange now, with a momentary freeze. This revision is both good and bad, so maybe this will give you some new ideas.

[cyberbeing]

Could someone add an option to FFDshow to override the output colorspace (on launch) to whatever the built-in Avisynth is outputting and just pass it through to the renderer unmolested? Is there already some global option for this that I am missing?

Currently FFDshow seems to ignore the Avisynth output colorspace and does color conversions and level fixes (for RGB), seemingly based on the input colorspace, to the lowest common denominator colorspace selected in the output panel.

As a separate, somewhat related question, does FFDshow currently take the built-in Avisynth output colorspace into account when it does its own output colorspace conversions?

[albain]

Are you really sure about that? MPCs Direct3D renderer doesn't really care which screen is the primary one - it'll go fullscreen without problems on any monitor...

np: Other People's Children - Suicide Common (A Number Of Small Things (Disc 2))

This is what MSDN says about this API. When you have multiple displays with extended desktop (so not in clone mode), you will be able to see the video only on one desktop right ?
At one time this is what happened. Maybe it has changed with new gpu drivers & chips.

Well, I want to use ffdshow to correct the primaries of my display.
See this (http://forum.doom9.org/showpost.php?p=1227911&postcount=5868) post a few pages back.

Currently, I have to use an Avisynth filter for it, but I already suggested the addition of the 3D LUT to ffdshow.
And each display have different primaries, so, for each display, I have to use a different 3D LUT. That's why I need the preset selection by the screen resolution... or I have to change it manually each time I switch between my monitor and my projector...:(

OK, but you would need to base your preset selection on both the resolution and the "current monitor" ?
Can you tell if the resize filter when set to "resize to screen resolution" changes automatically when you move the video window from one desktop to another (assuming that you have a different resolution between desktops) ?

[leeperry]

OK, but you would need to base your preset selection on both the resolution and the "current monitor" ?
Can you tell if the resize filter when set to "resize to screen resolution" changes automatically when you move the video window from one desktop to another (assuming that you have a different resolution between desktops) ?
he never uses two displays simultaneously, only one at a time.
having a screen resolution condition would indeed be very handy, like for SD upscaling to native res. depending on the display :)

[yesgrey]

OK, but you would need to base your preset selection on both the resolution and the "current monitor" ?
No. I just need the preset selection to be based on the resolution, I only use one display at a time, so, it's always the main display.
Can you tell if the resize filter when set to "resize to screen resolution" changes automatically when you move the video window from one desktop to another (assuming that you have a different resolution between desktops) ?
No. It keeps the opening resolution.

like for SD upscaling to native res. depending on the display :)
You already could do this with the resize to screen resolution option.;)

[leeperry]

You already could do this with the resize to screen resolution option.;)
ah great! I overlooked that one :rolleyes:
quite frankly, I don't think your feature req would help for proper gamut conversion.......as ffdshow won't know whether you're watching HDTV/EBU/SMPTE-C content.

what I've done is shortcuts in the start menu, and they unpack the right LUT to a ramdisk :

start /b /high Z:\Rar.exe e -y Z:\pj_SMPTE-C.rar Z:\

and then in ffdshow :

rgb3dlut(lutfile="z:\lut.txt",threads=4)

[haruhiko_yamagata]

But it no longer displays corrupted frames! No garbled frames with all renderers Haruhiko. The changes made in rev2579 and rev2580 have affected at all formats decoded by libavcodec. Xvid and DivX seeking is strange now, with a momentary freeze. This revision is both good and bad, so maybe this will give you some new ideas.
Good news that it fixed H.264 seeking for you. The mt branch may have difficulty though.
Sorry for insufficient testing, the regression bug was easy to fix.

[Leak]

This is what MSDN says about this API. When you have multiple displays with extended desktop (so not in clone mode), you will be able to see the video only on one desktop right ?
I always have a 1280x1024 and a 1680x1050 display connected to my first ATI Radeon 4850 (with my 800x600 (don't laugh) projector and the DVI->HDMI adapter for our TV on the second card) and whenever I check "Direct3D fullscreen" it'll go fullscreen on the screen the MPC-HC window is on - so the screen resolution could either be 1280x1024 or 1680x1050.

The "trick" with the D3D renderers is that MPC simply slaps the video as a texture on a fullscreen 3D surface in D3D exclusive mode, just like your vanilla 3D first-person shooter does with it's graphics... i.e. it's not using any overlay capabilities, but just uploads the video images as textures to video ram then draws them on whatever screen Direct3D fullscreen is running on, which can be any of the connected screens.

You can choose the monitor to go fullscreen on in MPC's settings, but somehow for me it always uses the screen it's window is on...

(NB: Despite all this, Reclock has no problems finding out which monitor the video is playing on, so it's definitely doable, probably by querying the filters in the graph - throw my projector and the TV into the mix and there's 4 devices the video could be playing on...)

np: The Orb - Turn It Down (Long Version) (Cydonia Versions)

[haruhiko_yamagata]

At rev 2587, I've cleaned all known issues of libavcodec MPEG-1/2.
Is there anything left?
Now libavcodec may surpass libmpeg2.

And I'm going to change libmpeg2 to flag interlacing like libavcodec.
Any objections?

Anyway, there is no reliable flag in most cases. It's just "how the stream was encoded", not "how it should be treated after decoding".

[mark0077]

Thanks for those updates haruhiko, I will update the dvd quality test results once the new version is up on xvidvideo.ru. Maybe analysis of the video stream can be done in a future release to detect interlaced / progressive. Some expensive hardware players seem to have great success using various techniques. I am sure it could be done in software given enough time. It looks like most of my PAL dvds are badly flagged so this detailed analysis may be the only way to get acceptible detection.

Also, as I havn't had a chance to try the new version, have you had a chance to check libavcodec's issues I mentioned with highlighted items in dvd menu's appearing a few pixels to the right, and few pixels too far down.

Last issue I have is with rgb32hq, in my testing on my nvidia card, nvidias own yv12 output seems to be of higher quality than ffdshows rgb32hq mode. Maybe some analysis could go into how ffdshows rgb32hq could be improved. This would be fantastic. Also I wonder could the conversion speed be increased by using a lookup table rather than millions of multiplications?

I LOVE ffdshow!

Thanks,

[MatMaul]

what about remove the RGB32HQ option in the output tab ?
it is a duplicate of the one in the RGB conversion tab.

EDIT : little bug in the install script : when I install over my previous ffdshow whith a new one the "MPEG in AVI" is reset to libmpeg2

[haruhiko_yamagata]

Thanks for those updates haruhiko, I will update the dvd quality test results once the new version is up on xvidvideo.ru. Maybe analysis of the video stream can be done in a future release to detect interlaced / progressive. Some expensive hardware players seem to have great success using various techniques. I am sure it could be done in software given enough time. It looks like most of my PAL dvds are badly flagged so this detailed analysis may be the only way to get acceptible detection.It is ideal, and I believe my CPU (Core2 Quad 6600) can do that. What matters is my skill :scared:.

Also, as I havn't had a chance to try the new version, have you had a chance to check libavcodec's issues I mentioned with highlighted items in dvd menu's appearing a few pixels to the right, and few pixels too far down.I'll try some reproduce test later.

Last issue I have is with rgb32hq, in my testing on my nvidia card, nvidias own yv12 output seems to be of higher quality than ffdshows rgb32hq mode. Maybe some analysis could go into how ffdshows rgb32hq could be improved. This would be fantastic. Also I wonder could the conversion speed be increased by using a lookup table rather than millions of multiplications?
Chroma has to be upscaled 2x for either horizontally and vertically. The difference of quality is the algorithm of upscaling. It is interesting to try swscale.

[mark0077]

I am sure your coding skills will be enough ;)

I will upload some screenshots of the misaligned menu highlights. Its hard to notice with some DVD's, more noticable with some. I have one dvd that shows it very clearly, its a simple red rectangle highlight over a grey rectangle background. If they are misaligned, the grey is visible. If they are aligned, only red is visible.

Regarding rgb32hq, are there any plans to update it in the near future?

Thanks!

[Inventive Software]

You can try xvidvideo.ru builds one by one to find where the problem is, thus localizing the problem if there is any.

ff_kernelDeint.dll is a separate Visual Studio project and is usually only recompiled once in a blue moon with Intel's compiler when anything in the Kernel Deint sources itself changes - which it hasn't for some time now.

So either something else in some other part of ffdshow changed recently that makes it run slow, or you're using a build/an installer where a ff_kernelDeint.dll compiled with debug settings was included instead of the ICL compiled one... :confused:

I'll try a recent build when I get home tonight - where did you get yours? xvidvideo.ru?

SF also has a few hundred old builds:
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=436746

Thank you for the suggestions, I will switch the older ff_kerneldeint.dll with the newer ffdshow install and see whether that cures the problem. If so, something's a bit broken since a revision. Haven't found it yet, but it was a couple hundred revisions ago. Got a way to go as yet!

[_xxl]

Thank you for the suggestions, I will switch the older ff_kerneldeint.dll with the newer ffdshow install and see whether that cures the problem. If so, something's a bit broken since a revision. Haven't found it yet, but it was a couple hundred revisions ago. Got a way to go as yet!
xvidvideo.ru builds use MinGW GCC compiled ff_kerneldeint.dll. I use Icl11 to compile it.

[Inventive Software]

xvidvideo.ru builds use MinGW GCC compiled ff_kerneldeint.dll. I use Icl11 to compile it.

I don't use xvidvideo.ru builds, I use clsid's builds. Something changed with ff_kerneldeint.dll, but I haven't yet figured it out. I'll be back later with dates!! The older one was from the end of March, I have no clue about the newer one yet.

[madshi]

A little request:

I've just spent an hour digging through this thread to understand what is meant exactly with the "contrast" adjustments in the "RGB conversion" tab. I find the names not very intuitive.

Let's think about what happens with a normal DVD or Blu-Ray source: As far as I understand it, using "Standard" stretches the YUV signal in such a way that black gets the RGB value 0, 0, 0. Right? While "Full range" doesn't stretch, instead black gets the value 16 and white the value 235. Right? Do you see where my confusion is coming from? "Standard" stretches black to "0", but the numbers in the dialog for "Standard" read "16-235". And "Full range" sets black to "16" and white to "235", but still the dialog mentions "0-255" for "Full range". Huh?

Or am I misunderstanding what these controls do?

Thanks!

P.S: I'd suggest the following controls to make things more intuitive:

Input/Source levels:
(1) Video levels. (alternatively: "TV-range YUV" or "16-235 YUV")
(2) PC levels. (alternatively: "full range YUV" or "0-255 YUV")

Output levels:
(1) Video levels.
(2) PC levels.
(3) Same as input.

This way everybody (who understands what "video levels" and "pc levels" are) knows what the controls mean and do. Defaults should be "video levels" for input and probably "Same as input" for output levels.

Also the name "contrast" doesn't really fit. It suggests some automatic intelligent image contrast enhancement algorithm. I'd suggest "Levels" instead of "Contrast".

[leeperry]

As far as I understand it, using "Standard" stretches the YUV signal in such a way that black gets the RGB value 0, 0, 0. Right? While "Full range" doesn't stretch, instead black gets the value 16 and white the value 235. Right? Do you see where my confusion is coming from? "Standard" stretches black to "0", but the numbers in the dialog for "Standard" read "16-235". And "Full range" sets black to "16" and white to "235", but still the dialog mentions "0-255" for "Full range". Huh?
if you select "full range" ffdshow keeps the levels untouched(useful to output 16-235 RGB32), if you set it to "standard" it will do a TV>PC levels conversion.

just like in HR, where "PC" doesn't do any conversion and "TV" does TV>PC conversion.

it's quite confusing, I agree :D

[yesgrey]

Also I wonder could the conversion speed be increased by using a lookup table rather than millions of multiplications?

Well, a few posts back I have suggested the addition of 3D LUTs to ffdshow. I only suggested RGB input, but i believe it could be a good idea to also support 3D LUTs with YUY2 input...
let's hope any of the developers find the time to do it. haruhiko already told he would do it if he finds the time... I also will try to learn how to do it, maybe it's not too hard...;)

[leeperry]

i believe it could be a good idea to also support 3D LUTs with YUY2 input
humm...3D RGB LUT's in YUY2 ? I'd like to see that working :D

[alexins]

xvidvideo.ru builds use MinGW GCC compiled ff_kerneldeint.dll. I use Icl11 to compile it.
I recently used ff_kerneldeint.dll and TomsMoComp_ff.dll, built in icl 10.1.029 (with a patch for AMD).

[STaRGaZeR]

Good news that it fixed H.264 seeking for you. The mt branch may have difficulty though.
Sorry for insufficient testing, the regression bug was easy to fix.

After rev2586 everything is back to normal plus no more garbled frames. Great work once again :)

At rev 2587, I've cleaned all known issues of libavcodec MPEG-1/2.
Is there anything left?
Now libavcodec may surpass libmpeg2.

And I'm going to change libmpeg2 to flag interlacing like libavcodec.
Any objections?

All seems good. libmpeg2 is a bit faster seeking with MPEG-2 Blu-ray's, but with SD resolution there is no difference between them.

I wouldn't touch libmpeg2 flagging, remember the issue with DVB streams.

[jos99]

There is a problem with ffdshow mt builds and BBC HD- there is a small line of distortion on the lower edge as shown here that does not occur with normal ffdshow.

http://i535.photobucket.com/albums/ee357/jacz3/bbchddistortionffdshowmt.jpg

[turbojet]

Is there a chance of a 64 bit ffdshow-mt build?

[_xxl]

I can't link pthread with MinGW GCC 4.4.0. Win64, waiting for this issue to be fixed...

[Inventive Software]

I don't use xvidvideo.ru builds, I use clsid's builds. Something changed with ff_kerneldeint.dll, but I haven't yet figured it out. I'll be back later with dates!! The older one was from the end of March, I have no clue about the newer one yet.

FOUND IT! The ff_kerneldeint.dll file sizes between 2 builds are completely different, the working one is about 200-odd KB, the other's 668KB, suggesting it's made as a debug-build. Dated end of November, around 2390-ish.

[Leak]

FOUND IT! The ff_kerneldeint.dll file sizes between 2 builds are completely different, the working one is about 200-odd KB, the other's 668KB, suggesting it's made as a debug-build. Dated end of November, around 2390-ish.
Well, the ff_kerneldeint.dll shipped with beta6 is 668kB, but looking at it in biew doesn't show any debug info, just lots and lots of unrolled loops...

[_xxl]

lots and lots of unrolled loopsMaybe some forced optimizations from Icl compiler?

[Leak]

Maybe some forced optimizations from Icl compiler?
Aren't optimizations the whole point of compiling with ICL? Unrolling loops is, after all, one of the basic optimization techniques, and unless the code gets big enough to not fit into the L1 or L2 cache it should speed things up, not cause a slowdown...

(Of course it would help knowing what Inventive Software's CPU is. But I still doubt it's the unrolling that's causing the slowdown here, unless it was an older AMD chip or a P4...)

[clsid]

I made a fresh build with ICL10 yesterday an it turned out as 600kb-ish. Does that one have the same problem?

[Inventive Software]

Aren't optimizations the whole point of compiling with ICL? Unrolling loops is, after all, one of the basic optimization techniques, and unless the code gets big enough to not fit into the L1 or L2 cache it should speed things up, not cause a slowdown...

(Of course it would help knowing what Inventive Software's CPU is. But I still doubt it's the unrolling that's causing the slowdown here, unless it was an older AMD chip or a P4...)

AMD Turion X2 TL-50 for the record. No problems (I repeat 0 [zero] problems) with earlier (2-3 months ago) builds of ff_kerneldeint.dll.

[clsid]

@xxl

1) Could you please rename the icl10 projects in ffmpeg-mt branch to icl11 and create new icl10 projects?
2) I noticed you updated the baseclasses. The copyright dates however seem to suggest that you replaced them with an older version.
3) Is it worthwhile to continue including x264 with ffdshow? For VFW there already is x264VFW and for DS encoding there now is a filter from RadScorpion: http://blog.monogram.sk/janos/
4) Shouldn't xvidcore also be updated in trunk?

[_xxl]

Could you please rename the icl10 projects in ffmpeg-mt branch to icl11 and create new icl10 projects?
Yes, I'll rename them.
I noticed you updated the baseclasses. The copyright dates however seem to suggest that you replaced them with an older version.
No, ffdshow's baseclasses were based on dxsdk_sum2004. All updates are from microsoft sdks v6.1. True date is 2001 for sdk v6.1.
Is it worthwhile to continue including x264 with ffdshow? Yes, there are people that are against to remove it.
Shouldn't xvidcore also be updated in trunk
I'll update soon, x264, xvidcore, libmpeg2, cpu detection code and some other updates could be merged to trunk.

[leeperry]

Yes, I'll rename them.
didn't you tell me yesterday that you had no plan for ICL10 ffdshow-MT versions ?
anyway that's great news :)

[clsid]

Yes, there are people that are against to remove it.The main reason for that was because there was no other way to encode using DirectShow. Now there is an alternative for that.

[_xxl]

The main reason for that was because there was no other way to encode using DirectShow. Now there is an alternative for that.I think that having an alternative for ffdshow's x264 encoding is ok.

[clsid]

I get this error during linking of libavcodec in ffmpeg-mt branch:
C:\MinGW32\bin/ld.exe: cannot find -lpthreadGC2

I have the standard pthreads API for MinGW32 installed. Do I need something else?

[_xxl]

Change to -lpthread. It should work now.

[jos99]

There is a problem with ffdshow mt builds and BBC HD- there is a small line of distortion on the lower edge as shown here that does not occur with normal ffdshow.

http://i535.photobucket.com/albums/ee357/jacz3/bbchddistortionffdshowmt.jpg
Any comment on this? This has been a problem since at least mt 2333, and is still there on mt 2576. It occurs on BBC HD and Luxe HD which are 1080i h.264. It doesn't exist on normal ffdshow.

AMD 64x2 5000+ 780G Catalyst 8.10 XP SP3

[clsid]

The last line is repeated to create a mod16 resolution. The MT builds are experimental and unfinished, so bugs like this are to be expected.

[Mercury_22]

It's just me or LPCM it's NOT working in FF ? :confused:

[haruhiko_yamagata]

Any comment on this? This has been a problem since at least mt 2333, and is still there on mt 2576. It occurs on BBC HD and Luxe HD which are 1080i h.264. It doesn't exist on normal ffdshow.

AMD 64x2 5000+ 780G Catalyst 8.10 XP SP3
Could you upload the sample video?

[STaRGaZeR]

It's just me or LPCM it's NOT working in FF ? :confused:

Not working for me neither.

[jos99]

The last line is repeated to create a mod16 resolution. The MT builds are experimental and unfinished, so bugs like this are to be expected.
Thanks, I guess I will stick with normal ffdshow for the moment.
Could you upload the sample video?
Sure, here is a 10MB sample of BBC HD (http://rapidshare.com/files/180886722/01-08_00-18-38_BBC_HD__NAR__BBC_HD_Preview.ts), a 5MB sample of Luxe HD (http://rapidshare.com/files/180886723/01-08_00-33-37_Luxe_TV_HD_Shopping.ts). The line of distortion is slightly wider in BBC HD than Luxe.

[Mercury_22]

Not working for me neither.

Can someone look at the LPCM ? PLEASE !
I'm thinking since MPC-HC's internal LPCM it's working maybe it's easy to fix ?! :helpful:

[haruhiko_yamagata]

Thanks, I guess I will stick with normal ffdshow for the moment.

Sure, here is a 10MB sample of BBC HD (http://rapidshare.com/files/180886722/01-08_00-18-38_BBC_HD__NAR__BBC_HD_Preview.ts), a 5MB sample of Luxe HD (http://rapidshare.com/files/180886723/01-08_00-33-37_Luxe_TV_HD_Shopping.ts). The line of distortion is slightly wider in BBC HD than Luxe.
Thanks. Haali's media splitter is OK, but MPC's splitter is not.
Anyway ffdshow (or ffmpeg-mt) is to be blamed.

[Inventive Software]

Aren't optimizations the whole point of compiling with ICL? Unrolling loops is, after all, one of the basic optimization techniques, and unless the code gets big enough to not fit into the L1 or L2 cache it should speed things up, not cause a slowdown...

(Of course it would help knowing what Inventive Software's CPU is. But I still doubt it's the unrolling that's causing the slowdown here, unless it was an older AMD chip or a P4...)

There appears to be something that's making the code about 3x bigger than it ought to be. The last working build of clsid's I have with the working DLL is 2364, dated 20081125. From 2373 (the next build) onwards it seems not to be working. I've yet to try a very recent build, but it might be the switch to ICL11 from ICL10 is breaking something...

[haruhiko_yamagata]

Change to -lpthread. It should work now.
And it also fixes compilation/link x64 version for me.
Did you get the latest binary of pthread by MinGW 64 project?
The touble is that it doesn't work properly.

[clsid]

There appears to be something that's making the code about 3x bigger than it ought to be. The last working build of clsid's I have with the working DLL is 2364, dated 20081125. From 2373 (the next build) onwards it seems not to be working. I've yet to try a very recent build, but it might be the switch to ICL11 from ICL10 is breaking something...I have never used ICL11, always ICL10 or GCC. Please try my latest build. If that doesn't work, then I will try GCC next time.

[Leak]

There appears to be something that's making the code about 3x bigger than it ought to be.
What makes you so sure it's "bigger than it ought to be"?

Loop unrolling as an optimization technique does exactly that - it duplicates code so the CPU needs to do fewer conditional jumps (which cost performance) at the expense of, well, more generated code. Maybe the old DLL just wasn't optimized that much?

Also, what happens if you copy the old DLL into ffdshow's installation directory after installing a recent build?

(By the way - is it possible the bigger DLL was compiled with ICL, but not patched to fix Intel's CPU ID check? That would explain why it would run like molasses on AMD hardware...)