ffdshow tryouts project: Discussion & Development

[egur]

Strangely, code compiled on my home system didn't compile in other systems. A function refused to inline causing a warning that turned into an error.
Fixed at 4222. No ffdshow code change.

[betaking]

Strangely, code compiled on my home system didn't compile in other systems. A function refused to inline causing a warning that turned into an error.
Fixed at 4222. No ffdshow code change.

Thanks!

[egur]

Has anyone benchmarked Quick Sync vs LAV CUVID?

Yes, look here:
http://forum.doom9.org/showthread.php?t=163110

I also ran the 10 clips on my own PC (i7-2600) with a newer version of ffdhsow-quicksync:
http://forum.doom9.org/showthread.php?p=1548192#post1548192

[ryrynz]

Very nice, thanks!

[Dstruct]

Should be fixed at 4217. Added check for SSE4.1 as well as existance of either driver or Media SDK SW DLL (beta4) for devs.

Confirmed. Thanks!

[Dstruct]

Should be fixed at 4217. Added check for SSE4.1 as well as existance of either driver or Media SDK SW DLL (beta4) for devs.

Still a bit weird on AMD CPU (rev.4218):

AMD CPU (without SSE2):
QuickSync DLL: not found (ffdshow -> About page -> Version details)


Intel CPU (without Intel GPU):
QuickSync DLL: Version properly shown (ffdshow -> About page -> Version details)



Why is the DLL not "found" on AMD system? I know it doesn't work on AMD but the DLL itself should be listed under About page -> Version details!

[LigH]

Maybe the loading of the DLL already fails due to CPU instruction restrictions, so executing the version request function fails too?

[egur]

Still a bit weird on AMD CPU (rev.4218):

AMD CPU (without SSE2):
QuickSync DLL: not found (ffdshow -> About page -> Version details)


Intel CPU (without Intel GPU):
QuickSync DLL: Version properly shown (ffdshow -> About page -> Version details)



Why is the DLL not "found" on AMD system? I know it doesn't work on AMD but the DLL itself should be listed under About page -> Version details!

Don't know. I don't have AMD HW to check. Well, it's not relevant anyway.

[Midzuki]

Why is the DLL not "found" on AMD system? I know it doesn't work on AMD


but the DLL itself should be listed under About page -> Version details!

I second that. On my very-old Pentium 4, ffdshow r4210 still is "unable to find" xvidcore.dll (even though this seems to be loaded anyway whenever requested) :confused:

[Dstruct]

Don't know. I don't have AMD HW to check. Well, it's not relevant anyway.

Ok, no big problem!

[fano]

My system is this:
http://www.asrock.com/nettop/overview.asp?Model=Core%20100HT#Specifications

and I'm having big problems to use my new AVR Sony STR-DN1020:
http://www.sony.co.uk/product/hcs-home-cinema-receiver/str-dn1020/tab/technicalspecs


EAC3, Dolby True HD and DTS-MA don't bitstreaming... ffdshow seems to think my AVR is SPDIF connected? Sometime it decodes a multichannel LPCM track! But if it0s set to unmolest the audio?
Intel QuickSync should work, right? It's a system based on the Intel HM55 platform, it MUST support it! I can select QuickSync but ffdshow likes to use libavacod instead... it's unmodificable :mad:


In particular see this MediaInfo report file:


General
ID : 0 (0x0)
Complete name : D:\Torrenti\Fantasia.1940.BD.RU\BDMV\STREAM\00125.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 35.1 GiB
Duration : 2h 4mn
Overall bit rate mode : Variable
Overall bit rate : 40.3 Mbps
Maximum Overall bit rate : 48.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=12
Codec ID : 27
Duration : 2h 4mn
Bit rate mode : Variable
Bit rate : 27.2 Mbps
Maximum bit rate : 27.5 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.546
Stream size : 23.6 GiB (67%)
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Muxing mode : Stream extension
Codec ID : 134
Duration : 2h 4mn
Bit rate mode : Variable
Bit rate : 4 759 Kbps / 1 510 Kbps
Channel(s) : 8 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Muxing mode : Stream extension
Codec ID : 134
Duration : 2h 4mn
Bit rate mode : Variable
Bit rate : 2 722 Kbps / 1 510 Kbps
Channel(s) : 8 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy

Audio #3
ID : 4354 (0x1102)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : 130
Duration : 2h 4mn
Bit rate mode : Constant
Bit rate : 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 1.31 GiB (4%)

There are 6 more AUDIO tracks

Text #1
ID : 4609 (0x1201)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 2h 4mn
Delay relative to video : 7s 674ms

Text #2
ID : 4610 (0x1202)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144

Text #3
ID : 4615 (0x1207)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144

There are 14 more AUDIO tracks :scared:


The DTS-MA tracks are NOT present in the ffdshow Stream Switcher so it's clear NOW why they are not played :mad:

[Snowknight26]

Is there any way for ffdshow to honor the full range flag in H.264 videos if it's specifically set? I encoded a few videos and specifically set the full range flag but regardless of whether I choose Auto or Standard for the output range, it's still outputting limited range. I'm hoping there's an alternative to selecting Full Range each time those videos are played.

The more I think about it, the more certain I am that the tooltip for Auto is unclear whether the H.264 full range flag is honored or not.

[haruhiko_yamagata]

Is there any way for ffdshow to honor the full range flag in H.264 videos if it's specifically set? I encoded a few videos and specifically set the full range flag but regardless of whether I choose Auto or Standard for the output range, it's still outputting limited range. I'm hoping there's an alternative to selecting Full Range each time those videos are played.

The more I think about it, the more certain I am that the tooltip for Auto is unclear whether the H.264 full range flag is honored or not.
ffdshow is supposed to honor the flag if "Auto" is selected as "Input levels". If it is not working, it's a bug. I'll take a look.

[dukey]

I have a FFDshow feature request
Can ffdshow render subtitles to a secondary pin ?

Like this
http://i.imgur.com/f1U4I.png

If it acted as a pass through filter for the video we could support DXVA this way, which is a big plus. The secondary pin can just output RGBA no need to worry about all the hundreds of different colour spaces. Can be more efficient too since only need to update the subtitle image when the text needs to change, rather than composite it every frame.

[haruhiko_yamagata]

I have a FFDshow feature request
Can ffdshow render subtitles to a secondary pin ?

If it acted as a pass through filter for the video we could support DXVA this way, which is a big plus. The secondary pin can just output RGBA no need to worry about all the hundreds of different colour spaces. Can be more efficient too since only need to update the subtitle image when the text needs to change, rather than composite it every frame.I have been thinking about it. At least it is a lot of work. It's a long term TODO, which I can't promise implementation.

[dukey]

I can't see it being a huge amount of work, although I've not really studied the FFDShow source.

I might be able to assist. I am actually a c++ programmer. Specialise in opengl, but I know directshow. Written an opengl renderer in dshow ;p Im guessing you would need a new pin type for pass through, since it would be reading the sample type, for video size but not altering it.

[haruhiko_yamagata]

I can't see it being a huge amount of work, although I've not really studied the FFDShow source.

I might be able to assist. I am actually a c++ programmer. Specialise in opengl, but I know directshow. Written an opengl renderer in dshow ;p Im guessing you would need a new pin type for pass through, since it would be reading the sample type, for video size but not altering it.
Welcome to ffdshow development. Of course it's a good idea to have that feature.
Subtitles rendering is not pass through nor just alpha blending bitmaps. The input pin accepts text or coded bitmap and rasterize/decode them. And finally blend to the video. The output stage may be issued to a video renderer. It is not easy. None the less, you can do it ;).
I hope you have patience huge enough to deal with the messy existing code.

[haruhiko_yamagata]

Is there any way for ffdshow to honor the full range flag in H.264 videos if it's specifically set? I encoded a few videos and specifically set the full range flag but regardless of whether I choose Auto or Standard for the output range, it's still outputting limited range. I'm hoping there's an alternative to selecting Full Range each time those videos are played.

The more I think about it, the more certain I am that the tooltip for Auto is unclear whether the H.264 full range flag is honored or not.
fixed at rev 4230-4231. :thanks:

[betaking]

rev.4231 compile failed
http://i42.tinypic.com/2dvt06c.jpg
:helpful:

[obieobieobie]

In rev4225, post processing with automatic quality control enabled is broken at least for XVID content. Works in rev3984.

[hoborg]

BUG?
Hi.
I noticet if there is a "hi quality yv12 to RBG conversion" enabled in RGB convesion, 10-bit encoded videos make Graphstudio (FFDshow) to crash.
Just tested by "ffdshow tryouts project, svn 4236 (x86) - MSVC2010" on "i444compressed.mkv" sample.

[Snowknight26]

fixed at rev 4230-4231. :thanks:

Works beautifully, thanks.

[haruhiko_yamagata]

BUG?
Hi.
I noticet if there is a "hi quality yv12 to RBG conversion" enabled in RGB convesion, 10-bit encoded videos make Graphstudio (FFDshow) to crash.
Just tested by "ffdshow tryouts project, svn 4236 (x86) - MSVC2010" on "i444compressed.mkv" sample.
It works for me. What is the video renderer and the video card (Radeon HD 6750?)?

[hoborg]

It works for me. What is the video renderer and the video card (Radeon HD 6750?)?

Yes, 6750 + EVR

Edit:
The same problem on my HTPC with Radeon 6450 + VMR9 FSE.

Edit2:
I reset FFDshow setting and it is working now. Must be some registry entry in "HKEY_CURRENT_USER\Software\GNU\ffdshow\default" causing the crash.

[haruhiko_yamagata]

Yes, 6750 + EVR

Edit:
The same problem on my HTPC with Radeon 6450 + VMR9 FSE.

Edit2:
I reset FFDshow setting and it is working now. Must be some registry entry in "HKEY_CURRENT_USER\Software\GNU\ffdshow\default" causing the crash.
You found out very important thing.
Do you have any back up of the crashing settings? If you have one, please send it to me.

[hoborg]

You found out very important thing.
Do you have any back up of the crashing settings? If you have one, please send it to me.
Yes, here it is (http://hobring.esero.net/saf/ffdshow/10-bit_crash.zip).

[haruhiko_yamagata]

Yes, here it is (http://hobring.esero.net/saf/ffdshow/10-bit_crash.zip).
Thank you. It was crashing because dithering was unchecked.
I have fixed at rev 4240.

[haruhiko_yamagata]

What should be the default output color space to EVR for 10-bit 4:2:0 video?
For most (all?) PC, EVR does not accept P010/P016. Currently ffdshow use YV12 to connect with EVR.
It's lossy. I think RGB32 is less lossy. It's a bit slower though.
A small patch can change this.

Index: src/imgFilters/ffImgfmt.cpp
===================================================================
--- src/imgFilters/ffImgfmt.cpp (revision 4238)
+++ src/imgFilters/ffImgfmt.cpp (working copy)
@@ -1154,6 +1154,10 @@
FF_CSP_P216 ,
FF_CSP_444P10,
FF_CSP_Y416 ,
+ FF_CSP_BGR32,
+ FF_CSP_RGB32,
+ FF_CSP_BGR24,
+ FF_CSP_RGB24,
FF_CSP_420P ,
FF_CSP_NV12 ,
FF_CSP_YUY2 ,
@@ -1167,10 +1171,6 @@
FF_CSP_410P ,
FF_CSP_ABGR ,
FF_CSP_RGBA ,
- FF_CSP_BGR32,
- FF_CSP_RGB32,
- FF_CSP_BGR24,
- FF_CSP_RGB24,
FF_CSP_BGR16,
FF_CSP_RGB16,
FF_CSP_BGR15,

[nevcairiel]

IMHO the default should be to output a format as close to the original as possible, and upsampling chroma is not close at all. If 10-bit doesn't work, provide properly dithered 8-bit.

[clsid]

If P010/P016 can't be used, then best order of preference would probably be RGB > NV12 > YV12.

[madshi]

I definitely agree with nevcairiel here.

[haruhiko_yamagata]

IMHO the default should be to output a format as close to the original as possible, and upsampling chroma is not close at all. If 10-bit doesn't work, provide properly dithered 8-bit.
The video renderer has to up-sample chroma anyway unless the PC is connected to YCbCr analog TV.
The up-sampling without extra 2 bits is lossy. If up-sampling is done in ffdshow, it can utilize the 2 bits.
The video renderer may be able to use better interpolation while ffdshow use bilinear.
Which will produce better result? Is interpolation method more important than native conversion?

[madshi]

haruhiko, there's one thing missing in your argument, namely that RGB output is only 8bit. So let's collect arguments:

RGB output:
+ chroma upsampling and color conversion can make use of the original 10bit data
- after color conversion everything must be converted down to 8bit
- chroma upsampling algorithm is lower quality than what good renderers do
- user has to configure ffdshow's RGB output to match the display's level requirements (TV vs. PC levels)

NV12/YV12 output:
- video must be downconverted to 8bit right away
+ video renderer doesn't have to downconvert to 8bit after color conversion
+ chroma upsampling algorithm is higher quality
+ ffdshow doesn't have to care about PC vs. video levels

Please note that YCbCr -> RGB color conversion results in floating point data. So basically ffdshow has to dither the floating point RGB data down to 8bit integer. When using YV12/NV12, the video renderer doesn't have to do that, it can perform the color conversion in floating point and then maintain a much higher bitdepth in its internal processing chain.

[haruhiko_yamagata]

Thank you for your opinion.

- after color conversion everything must be converted down to 8bit

Currently most people do not have 10-bit enabled display. If they want to make use of full 10-bit, they must use madVR anyway. If EVR is used, I think we should target 8-bit display. In that case, the RGB32 output of ffdshow is the final output to display. Usually no further processing is required.

For now, it's a rare setting to have 10-bit monitor. It may change in the future, but until then, EVR would have supported P016/P010.

- chroma upsampling algorithm is lower quality than what good renderers do

Is the difference of upsampling algorithm more important than native conversion? I think you know how much is lost if 10-bit YCbCr is converted to 8-bit YCbCr and then to RGB32.

- user has to configure ffdshow's RGB output to match the display's level requirements (TV vs. PC levels)

This may be the weak point. People who use projectors have to configure the option.


+ video renderer doesn't have to downconvert to 8bit after color conversion
This is true only if it has high bit monitor.

Please note that YCbCr -> RGB color conversion results in floating point data. So basically ffdshow has to dither the floating point RGB data down to 8bit integer. When using YV12/NV12, the video renderer doesn't have to do that, it can perform the color conversion in floating point and then maintain a much higher bitdepth in its internal processing chain.
Well, 10-bit to 8-bit YCbCr conversion is very lossy and NV12 to RGB32 conversion is lossy again. The video renderer has to dither the output to 8-bit RGB unless the PC has high bit monitor.

What are expected in video renderer's processing chain? Resize is done in 8-bit anyway either in RGB32 or NV12. Deinterlacing is the biggest problem, but I have never encountered an interlaced high bit material.

After all, EVR must support P010/P016!

[nevcairiel]

A 10-bit -> 8-bit conversion may be lossy, but with proper dithering its "visually lossless", you don't see it. A forced RGB conversion may be visible, depending on what the renderer would do better with the raw YUV data.

[madshi]

@haruhiko_yamagata:

I agree that it would be ideal if EVR supported P010/P016. I'm not sure if that is something Microsoft would have to implement, or maybe the media player devs could do that with a custom mixer? Don't really know...

I don't think that 10bit to 8bit YCbCr is "very" lossy. If you apply proper dithering the loss should be small.

You're saying that the ffdshow RGB output will be the final output with no further processing. This may be true in many cases, but not in all. E.g. users may use the video renderer to scale the image. In my projection setup (CIH, Cinemascope) I always have to scale 16:9 and 4:3 movies. So even with 1080p content and 1080p displays scaling may still be necessary sometimes. Then there are color changes, brightness/contrast changes, level changes, calibration, gamma adjustments. These are all things that the video renderer may perform. If you take all that into account, you can't be sure that the ffdshow RGB output will see no further processing.

You do have a valid point, though: *If* ffdshow's RGB output is the final output without any further processing being done by the video renderer, then having ffdshow output RGB would minimize bitdepth losses.

At the end of the day I don't really care much, because all of this applies to EVR/VMR, only. So if you prefer RGB output in this situation, that's just fine with me.

[haruhiko_yamagata]

OK, I understand 10-bit YCbCr to 8-bit YCbCr conversion isn't too lossy. I'll keep it as it is.

[haruhiko_yamagata]

In rev4225, post processing with automatic quality control enabled is broken at least for XVID content. Works in rev3984.
I can't reproduce. I don't have many XVID samples that post processing is effective. Could you send us a sample?
Please pack exported settings with it.

[ikarad]

1)Problem with rgb32 output and ffdshow

With this video ffdshow doesn't work if I select rgb32 in output. If I check nv12 or p010 video works with mpc-hc and ffdshow.
video here: http://www.nyaa.eu/?page=torrentinfo&tid=270934

I tried with ffdshow 4238 and ffdshow 4079 there is the same problem.

edit: it's the same problem with all 10bit video and rgb24 output

edit2: If I use lav video and select only rgb32 output in lav video, video works well.

2) other problem.
a) If I turn on subtitles in ffdshow. If I open 10 bit video, ffdshow switch to rgb32 output and video do'esnt work (mpc and ffdshow open and close immediately like said in 1))
b) If I turn off subtitles in ffdshow. If I open 10 bit video, ffdshow swith to po10 output and video works. during the video, I can turn on subs and it works and subs are displayed.

There is a problem with turn on or turn off subs to select output color space when video start

3) question: When can I expect implementation of \t subs ? you have told 1 or 2 months in november.

[obieobieobie]

I can't reproduce. I don't have many XVID samples that post processing is effective. Could you send us a sample?
Please pack exported settings with it.

For me, it happened in every XVID file. The symptom was for the quality slider to go to the lowest value at once when automatic quality control was enabled no matter what quality the XVID file had. Usually the quality slider fluctuates.

I will try and get you a sample, though.

Edit: Hm, I can't reproduce either. I will get back to you if I encounter it again. Just put this out of mind. Sorry. :)

[haruhiko_yamagata]

Just one other thing, I've never managed to ever import my Avisynth code from the ffdshow exported settings without going viewing the exported file and manually copying the code for each preset, I documented that here.

http://sourceforge.net/tracker/index.php?func=detail&aid=3149428&group_id=53761&atid=471489
Fixed at rev 4243.
I cannot close the tracker because you posted the report to the original project.

[haruhiko_yamagata]

1)Problem with rgb32 output and ffdshow

With this video ffdshow doesn't work if I select rgb32 in output. If I check nv12 or p010 video works with mpc-hc and ffdshow.
video here: http://www.nyaa.eu/?page=torrentinfo&tid=270934

I tried with ffdshow 4238 and ffdshow 4079 there is the same problem.

edit: it's the same problem with all 10bit video and rgb24 output

edit2: If I use lav video and select only rgb32 output in lav video, video works well.

2) other problem.
a) If I turn on subtitles in ffdshow. If I open 10 bit video, ffdshow switch to rgb32 output and video do'esnt work (mpc and ffdshow open and close immediately like said in 1))
b) If I turn off subtitles in ffdshow. If I open 10 bit video, ffdshow swith to po10 output and video works. during the video, I can turn on subs and it works and subs are displayed.

There is a problem with turn on or turn off subs to select output color space when video start
Please try rev 4240 or newer.
3) question: When can I expect implementation of \t subs ? you have told 1 or 2 months in november.Sorry, maybe after the next release. It will take another two months at least.

[Midzuki]

Where can I download 4240 or newer because on official ffdshow website or xvidvideo.ru 4238 is the last version?

Try Xhmikosr's (http://xhmikosr.1f0.de/index.php) web site

[ikarad]

Try Xhmikosr's (http://xhmikosr.1f0.de/index.php) web site

Thanks


Sorry, maybe after the next release. It will take another two months at least.

I hope that you haven't give up the idea to improve sub renderer.

Please try rev 4240 or newer.

I just try (thanks to midzuki to find ffdshow 4242) and it doesn't work.

With 4238 if dithering box is checked, it works but with 4242 even with dithering box checked, it doesn't work

[haruhiko_yamagata]

With 4238 if dithering box is checked, it works but with 4242 even with dithering box checked, it doesn't workWhat does "doesn't work" mean?

[Stephen R. Savage]

Can anyone comment on whether it is possible to configure Avisynth processing in ffdshow to perform IVTC with, e.g. TIVTC? I have tried the following fragment:


TFM()
TDecimate()


I remember this working in some version long ago, but when I try this, I just end up with combed frames and incorrect decimation.

[asasadad_1]

how about add support for some dv files（avdv dv5p dvh5 dvpp）?
sample here : http://www.mediafire.com/?beorfvgaz02m9gn, ffplay ok.

[mandarinka]

It seems that ffdshow doesn't expect mkv chapters with the leading chapter entry set as hidden. If you open such file and right-click ffdshow's tray icon, ffdshow will crash.

This sample should be able to reproduce the crash: http://www.mediafire.com/?2053dzjwvis9j21
(Open file and right-click on ffdshow's try icon.)
This probably "works" with any video if muxed with chapters like these: http://pastebin.com/

[ryrynz]

Fixed at rev 4243.
I cannot close the tracker because you posted the report to the original project.

Cheers for that, it's very much appreciated.

[LigH]

@ Stephen: Just an uneducated guess ... precede with AssumeTFF() or AssumeBFF(), does that change the result?