ffdshow tryouts project: Discussion & Development

[_xxl]

Maybe it's time to drop MMX altogether... It's inferior to SSE2 and I would be very surprised if there are functional platforms that don't have SSE2 - anyway they couldn't play any 720p+ content. I had a P4 system that could barely play 720p (w/o any processing).
There are millions of old SSE only cpu's... this from my experience with some customers that still have old PC's. Only MMX I don't see to often...

[haruhiko_yamagata]

Is it possible to make ffdshow compatible with media foundation? I'm thinking especially at the subtitle part.
Of course it is possible. It's just very hard. As for me, I'm not sure if I'm going to do it.

[Px]

Then, for generic builds, Pentium II / Athlon are minimum requirement, aren't they?
Pentium III or Athlon XP, original Athlons doesn't have sse support

[fastplayer]

And yes, "Pentium III or newer" is a good candidate for the near future release.
Please don't bump CPU requirements unless there are significant benefits. Lots of SSE-only CPUs like Athlon XP are perfectly capable of playing 720p content.
I'm using VS2010 trial version. OK, I'll buy one.
You might wanna try C++ 2010 Express:
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express

[haruhiko_yamagata]

Pentium III or Athlon XP, original Athlons doesn't have sse support
We only need MMX. But Pentium MMX does not work, Pentium II should work. If I remember correctly, some instructions have been added between Pentium MMX and Pentium Pro. Unfortunately Pentium Pro does not have MMX, and so Pentium II is required.

[haruhiko_yamagata]

Please don't bump CPU requirements unless there are significant benefits. Lots of SSE-only CPUs like Athlon XP are perfectly capable of playing 720p content.
In my opinion, SSE-only CPUs should not be dropped for the time being. MMX only CPUs may be dropped in the near future.

You might wanna try C++ 2010 Express:
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express
Thank you. I have not tried it for ffdshow yet, but last time I tried it for MPC-HC, it didn't work. I have to compile and trace MPC-HC, so I need the professional version.

[fastplayer]

In my opinion, SSE-only CPUs should not be dropped for the time being. MMX only CPUs may be dropped in the near future.
Sounds good to me!
Thank you. I have not tried it for ffdshow yet, but last time I tried it for MPC-HC, it didn't work. I have to compile and trace MPC-HC, so I need the professional version.
I had successfully build ffdshow with the Express edition months ago (even though its functionality is quite limited). I'm not sure if it's still possible...
Here's a link which compares the Visual Studio editions:
http://msdn.microsoft.com/en-us/library/hs24szh9.aspx

[haruhiko_yamagata]

I had successfully build ffdshow with the Express edition months ago (even though its functionality is quite limited).
Good news for someone who don't want to buy MSVC.:)

[fastplayer]

Good news for someone who don't want to buy MSVC.:)
There's even better news if you're a student because then you get the latest Visual Studio Professional edition and lots of other MS software for free: https://www.dreamspark.com/

[fastplayer]

Haruhiko,
currently ffdshow uses the threadpool library which itself depends on Boost. nevcairiel found an alternative for his RGB converter in LAVFilters: Parallel Patterns Library (PPL) (http://msdn.microsoft.com/en-us/library/dd492418.aspx)
Maybe ffdshow can take advantage of this library too and get rid of the Boost dependency?

[Superb]

My guess is that 3765 caused the new crash regression (is has to do more w/ colorspace stuff), but I can't be sure unless someone provides me w/ 3764 compilation.Just popped by to verify that rev4043 doesn't have the crash issue anymore. Probably due to egur's patches, if I had to guess. Thx for all the work. I can finally use the latest ffdshow revision again.

[haruhiko_yamagata]

Haruhiko,
currently ffdshow uses the threadpool library which itself depends on Boost. nevcairiel found an alternative for his RGB converter in LAVFilters: Parallel Patterns Library (PPL) (http://msdn.microsoft.com/en-us/library/dd492418.aspx)
Maybe ffdshow can take advantage of this library too and get rid of the Boost dependency?Thanks for the info. PPL seems to be a similar library to threadpool.
I introduced boost to learn about it and the next version of C++ (C++11). Actually it has been too difficult for me to fully understand. I'm only using its thread and BOOST_FOREACH.
Still the dependency is deep and hard to remove.

[haruhiko_yamagata]

Just popped by to verify that rev4043 doesn't have the crash issue anymore. Probably due to egur's patches, if I had to guess. Thx for all the work. I can finally use the latest ffdshow revision again.
Good news.
Speaking of rev 3765, RGB24 has been removed from the output color spaces. But isn't it necessary to interact with VFW codecs?

[clsid]

You can re-add RGB24 if you think it is needed.

[haruhiko_yamagata]

OK, I'll re-add RGB24.

[haruhiko_yamagata]

NV12 input has been disabled at rev3985. It seems to work now. Maybe fixed at rev4029?
Index: src/settings/TglobalSettings.cpp
===================================================================
--- src/settings/TglobalSettings.cpp (revision 4054)
+++ src/settings/TglobalSettings.cpp (working copy)
@@ -808,8 +808,8 @@
FF_FOURCC1_OP(411P,(rawv==1 || rawv==2 || rawv==FOURCC_411P)& dxvamask,CODEC_ID_411P) \
FF_FOURCC1_OP(Y41B,(rawv==1 || rawv==2 || rawv==FOURCC_Y41B)& dxvamask,CODEC_ID_411P) \
FF_FOURCC1_OP(410P,(rawv==1 || rawv==2 || rawv==FOURCC_410P)& dxvamask,CODEC_ID_410P) \
- /*FF_FOURCC1_OP(NV12,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV12)*/ \
- /*FF_FOURCC1_OP(NV21,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV21)*/ \
+ FF_FOURCC1_OP(NV12,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV12) \
+ FF_FOURCC1_OP(NV21,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV21) \
/* exotic */ \
FF_FOURCC_OP (MP4S,mp4v & rawmask & dxvamask,c_mpeg4) \
FF_FOURCC_OP (SEDG,mp4v & rawmask & dxvamask,c_mpeg4) \

[clsid]

If that bug was fixed then of course it should be re-enabled. Please test in combination with LAV Video.

[mandarinka]

Edit: Just after posting the following, I realised that the video was encoded with 10bit build of x264, which means that the issue is caused by the swscale conversion from 10bit yuv in the build used. If that is the case then I think it can be disregarded, as long as the new 10bit to rgb code is used for grabbing and as long as it switches colormatrix properly. I won't get to testing newer builds for now myself I'm afraid.
Sorry for teh chaotic report.

Doing something with grab, (I think) I noticed another issue with the color conversion. I'm afraid I didn't have much time to poke it further,
so this will be just a brief report for all that is worth.

Taking screens of a 960x720 h.264 video ripped from a bluray source with ffdshow's grab while having LAV video decoding with forced rgb32 output
enabled, I was getting different results than from grabbing with ffdshow decoding itself.
I tried all three colormatrix options in the rgb conversion menu (bt709, bt601 and auto based on resolution), and all of them have the same
color balance (different from LAV video rgb result), meaning that the same colormatrix was used each time, despite me switching... If I use ffdshow
for decoding and force rg32 output teh situation is the same, switching bt709/bt601 has no effect.

I didn't know how to quickly figure which coeficients were actually used and if LAV video got it right. It seems to me though that LAV video used
the same as my gpu's rendering used (Radeon x700 with 10.2 driver, win xp sp3 32bit, Athlon 64 cpu). In any case, it seems that neither switching
based on resolution, nor manual switching of colormatrix does work ATM.

This was observed on revision 3996 (what is shipped with last version of CCCP).

Images (color converters used specified in filename, all taken with ffdshow's grab as described above):

http://img696.imageshack.us/img696/6605/yyhffdshowauto.png
http://img192.imageshack.us/img192/5426/yyhffdshowforcebt601.png
http://img706.imageshack.us/img706/7852/yyhffdshowforcebt709.png
http://img190.imageshack.us/img190/6389/yyhlavvideo.png

[haruhiko_yamagata]

Edit: Just after posting the following, I realised that the video was encoded with 10bit build of x264, which means that the issue is caused by the swscale conversion from 10bit yuv in the build used. If that is the case then I think it can be disregarded, as long as the new 10bit to rgb code is used for grabbing and as long as it switches colormatrix properly. I won't get to testing newer builds for now myself I'm afraid.
Sorry for teh chaotic report.
The latest version should work.
Thank you for giving me the opportunity to advertise the latest version.

[haruhiko_yamagata]

If that bug was fixed then of course it should be re-enabled. Please test in combination with LAV Video.It worked if no video filter was used. I found Cb and Cr were swapped for video filters. I had to remove NV21 to fix the bug without messing the source code too much. If anybody need NV21, please tell me, it's not too hard to restore.

[TheRyuu]

There are millions of old SSE only cpu's... this from my experience with some customers that still have old PC's. Only MMX I don't see to often...

It's 2011, anything remotely new has SSE2. x87 needs to go die.

[clsid]

Forcing the compiler to use a certain instruction set has little benefit in the case of ffdshow. We have already tested that in the past. Going from MMX to SSE has a very tiny performance gain, going from SSE to SSE2 has almost no gain. The move to SSE will be made.

Before any n00bs misunderstand the above: performance critical parts in ffdshow and its decoders are already hand optimized and use MMX/SSE/SSE2/SSSE3/SSE4/etc whenever possible. Those optimized code parts are used only when the CPU supports it and impose no additional requirements on the CPU.

[Chikuzen]

Is anyone using GCC 4.5.x? Can we migrate to GCC 4.6.2?
Is this patch OK?
The problem(name mangling behavior) is not based on the version of gcc and based on the difference in mingw and mingw-w64.
I think that you should not take such a way.

I sent a patch to xvid-devel ML about the same problem.
(This refers to the method which x264 took)
http://list.xvid.org/pipermail/xvid-devel/2011-September/006341.html

I think that this is better solution than yours.

[haruhiko_yamagata]

The problem(name mangling behavior) is not based on the version of gcc and based on the difference in mingw and mingw-w64.
I think that you should not take such a way.

I sent a patch to xvid-devel ML about the same problem.
(This refers to the method which x264 took)
http://list.xvid.org/pipermail/xvid-devel/2011-September/006341.html

I think that this is better solution than yours.
Thanks for the info.
I'm afraid we do not use autoconf. We have fixed makefiles. We simply do not want to use our time to support various versions of compilers.

[TheRyuu]

The move to SSE will be made.

Hasn't it used SSE since forever? Several parts won't even compile without sse enabled (kerneldeint, tomsmocomp, libmpeg2).

[clsid]

Those are non-essentials parts and the SSE requirement only applies when using GCC for compiling them. They compile fine with MSVC, which is the default.

[_xxl]

If I remember correctly almost critical parts are optimized by hand written code "asm". Why to force SSE ? There are some parts that won't compile without SSE... with MinGw GCC.

[ikarad]

I have a problem with ffdshow 4079 (same problem with 4072)

If I check nv 12 8bit and po10 output and see 8bit movie. I have no problem.
http://img15.hostingpics.net/thumbs/mini_1424168bit8bit.jpg (http://www.hostingpics.net/viewer.php?id=1424168bit8bit.jpg)

If I check only po10 and see 8bit movie.ffdshow select 10 bit
http://img15.hostingpics.net/thumbs/mini_6310698bit10bit.jpg (http://www.hostingpics.net/viewer.php?id=6310698bit10bit.jpg)

If I check only po10 and see 10bit movie. ffdshow select 10 bit
http://img15.hostingpics.net/thumbs/mini_91000310bit10bit.jpg (http://www.hostingpics.net/viewer.php?id=91000310bit10bit.jpg)

If I check 8bit and po10 output and see 10bit movie. I have the problem. ffdshow select 8 bit
http://img15.hostingpics.net/thumbs/mini_61706410bit8bit.jpg (http://www.hostingpics.net/viewer.php?id=61706410bit8bit.jpg)

Why ffdshow don't select the best output like with lav video?

[haruhiko_yamagata]

If I check 8bit and po10 output and see 10bit movie. I have the problem. ffdshow select 8 bit

Why ffdshow don't select the best output like with lav video?
If any image filters including subtitles are enabled ffdshow has to convert the image to 8 bit before processing. In that case, it is reasonable to output 8bit.
If only Resize is checked ffdshow outputs 10 bit, but it doesn't seem to be doing 10 bit native scaling.

[ikarad]

If any image filters including subtitles are enabled ffdshow has to convert the image to 8 bit before processing. In that case, it is reasonable to output 8bit.
If only Resize is checked ffdshow outputs 10 bit, but it doesn't seem to be doing 10 bit native scaling.

Is it not possible to enable sub renderer without stay at 10bit?

If I use mpc-hc sub renderer, video stay at 10 bit.

Can you make that filter can be used with 10 bit video without converting to 8bit? Is it possible or not?

[haruhiko_yamagata]

Is it not possible to enable sub renderer without stay at 10bit?

If I use mpc-hc sub renderer, video stay at 10 bit.

Can you make that filter can be used with 10 bit video without converting to 8bit? Is it possible or not?
I plan to implement RGB64 output and subtitles renderer for it.
Improving YV12 subtitles renderer is low priority for me. I have no plan to write subtitles renderer for P010/P016.

Unless you have 10-bit enabled video card and monitor, the recommended setting for 10-bit video stream with subtitles is RGB32 output (you may want a good CPU). ffdshow's subtitles in YV12 is not very good.

[haruhiko_yamagata]

In "Output" page in ffdshow decoder's dialog, there is "DV" check box.
It is meant to encode the output in DV like ffdshow audio can encode the output in AC3.
Has anybody ever seen it working?
I think it has been broken for years (maybe I broke it?).
I'm going to remove it. Anybody who want the feature back?

[ikarad]

I plan to implement RGB64 output and subtitles renderer for it.
Improving YV12 subtitles renderer is low priority for me. I have no plan to write subtitles renderer for P010/P016.

Unless you have 10-bit enabled video card and monitor, the recommended setting for 10-bit video stream with subtitles is RGB32 output (you may want a good CPU). ffdshow's subtitles in YV12 is not very good.
With rgb32, madvr doesn't work. With nv12 or YV12, mad vr works

RGB32
http://img15.hostingpics.net/thumbs/mini_482396Sanstitre.jpg (http://www.hostingpics.net/viewer.php?id=482396Sanstitre.jpg)

NV12 or YV12
http://img15.hostingpics.net/thumbs/mini_197490Sanstitre.jpg (http://www.hostingpics.net/viewer.php?id=197490Sanstitre.jpg)

It works with RGB24. The problem occurs with only RGB32

[haruhiko_yamagata]

@ikarad, it's not ffdshow's fault anyway. Sorry I can't target your hardware.

[ikarad]

@ikarad, it's not ffdshow's fault anyway. Sorry I can't target your hardware.

geforce gtx285 (same problem), vista 32 sp2.

Yes, I agree with you but I can't use rgb32 for this moment. What is the differences between rgb24 and rgb32? The quality is similar or not?

[haruhiko_yamagata]

If the output color space is RGB24, ffdshow's subtitles filter convert the image to RGB32, draw subtitles and after that, the output filter converts RGB24 to RGB32. So the quality is fine, just slower than RGB32 output.

[crl2007]

Hi, I have a problem that started a couple of hours ago. I use Stereoscopic Player for 3D movies and until today it worked ok with ffdshow subtitle filter. Now, all of a sudden, if I put ffdshow subtitle filter as video processor, the player just closes. No error, nothing. Also, I can't seem to make the subtitle display on the black borders. They always appear above the black bars. What's the setting for lowering subtitles on the black borders ? I ticked "Process whole image" but nothing. Thanks in advance.

[mandarinka]

Outputting rgb32 (with HQ conversion of course) is probably a good choice if one is going to use vsfilter for rendering, too.
With that though, I'm starting to feel more regret about that chroma position thing. Life's so complicated! :)

Edit: Oh, somewhat related question - do the software scalers in ffdshow work with rgb video (when for example, another decoder outputting rgb is used first), or do they also force a conversion to yv12, like (some of) the other filters?

[fastplayer]

Haruhiko, would a fix for the chroma shift require a lot of effort?

[clsid]

In "Output" page in ffdshow decoder's dialog, there is "DV" check box.
It is meant to encode the output in DV like ffdshow audio can encode the output in AC3.
Has anybody ever seen it working?
I think it has been broken for years (maybe I broke it?).
I'm going to remove it. Anybody who want the feature back?I don't mind if it gets removed.

[haruhiko_yamagata]

Hi, I have a problem that started a couple of hours ago. I use Stereoscopic Player for 3D movies and until today it worked ok with ffdshow subtitle filter. Now, all of a sudden, if I put ffdshow subtitle filter as video processor, the player just closes. No error, nothing.Did you update ffdshow recently? Did you try older version?
Also, I can't seem to make the subtitle display on the black borders. They always appear above the black bars. What's the setting for lowering subtitles on the black borders ? I ticked "Process whole image" but nothing. Thanks in advance.
If the black bar is added by ffdshow, it should work. Is "Letterbox" in Subtitle placement page checked?

[haruhiko_yamagata]

Haruhiko, would a fix for the chroma shift require a lot of effort?
No, it wouldn't. Just a few lines if I do not care about MPEG-1.:)

[haruhiko_yamagata]

I don't mind if it gets removed.
Thanks for reply. I'll wait until tomorrow and if nobody wants the feature, I'll remove it.

[crl2007]

Did you update ffdshow recently? Did you try older version?

If the black bar is added by ffdshow, it should work. Is "Letterbox" in Subtitle placement page checked?


I tried older versions too. I checked letterbox too. It's just a normal 2.35:1 HD movie.

[haruhiko_yamagata]

I tried older versions too. I checked letterbox too. It's just a normal 2.35:1 HD movie.
If the crash does not depend on version of ffdshow, and the crash started recently, it may be Windows update, video/audio driver update or malfunction of your hardware. Similar problem is reported here (https://sourceforge.net/projects/ffdshow-tryout/forums/forum/597594/topic/4838949).
To control the position of subtitles, use slider in Subtitles placement page. If the subtitles are SSA/ASS, "Override SSA/ASS positioning ..." may help, but not recommended.

[haruhiko_yamagata]

Edit: Oh, somewhat related question - do the software scalers in ffdshow work with rgb video (when for example, another decoder outputting rgb is used first), or do they also force a conversion to yv12, like (some of) the other filters?
Reading the code, it seems to convert to YUV 4:4:4 and scale. it's not ideal, but not too bad.

[haruhiko_yamagata]

@clsid,
Was High 4:2:2 Profile of H.264 added at rev 4089? Does it support 10-bit?
Do you have any samples?

[_xxl]

I'm going to remove it.
Please do it. I prefer less but safe.

[clsid]

@clsid,
Was High 4:2:2 Profile of H.264 added at rev 4089? Does it support 10-bit?
Do you have any samples?
Yes, libavcodec now supports 4:2:2 8/10bit. But it is disabled in ffdshow because it can not handle the relevant colorspaces yet. I don't have any samples.

[crl2007]

If the crash does not depend on version of ffdshow, and the crash started recently, it may be Windows update, video/audio driver update or malfunction of your hardware. Similar problem is reported here (https://sourceforge.net/projects/ffdshow-tryout/forums/forum/597594/topic/4838949).
To control the position of subtitles, use slider in Subtitles placement page. If the subtitles are SSA/ASS, "Override SSA/ASS positioning ..." may help, but not recommended.


No update in windows or drivers whatsoever. I just installed the latest ffdshow and the subtitle filter causes Stereoscopic Player to close without error or warning. It just closes.

As for the subtitles, I can't get them to display on the black border, like this:

http://thumbnails63.imagebam.com/16161/aadc1c161601550.jpg (http://www.imagebam.com/image/aadc1c161601550)

ffdshow displays them like this:

http://thumbnails24.imagebam.com/16161/802ecb161601552.jpg (http://www.imagebam.com/image/802ecb161601552)

The movie resolution is 1920x816, so the black borders are added by ffdshow.

LE: I solved the player close issue. It was because I had ffdshow installed in program files and I installed K-Lite because I needed some more codecs and K-Lite changed the ffdshow path to program files\k-lite\ffdshow and from here on every player didn't know what to do with subtitle filter. ffdshow itself was working fine tho. I installed ffdshow back and k-lite without ffdshow. Now it only remains the positioning.