ffdshow tryouts project: Discussion & Development

[haruhiko_yamagata]

More than just the PC vs rec levels, less than the custom matrix.
Black cutoff, white cutoff, chroma cutoff as well as ITUR-BT.601/701 are configurable.

[SBeaver]

the 64bit builds seem to be unable to decode flac audio, could someone look into this and see why it doesn't work?

[Shakey_Jake33]

Even with the 32-bit build, I've never been able to get ffdshow to decode standalone FLAC files.

[fastplayer]

Even with the 32-bit build, I've never been able to get ffdshow to decode standalone FLAC files.
Without a parser, it can't AFAIK.

[SBeaver]

Even with the 32-bit build, I've never been able to get ffdshow to decode standalone FLAC files.

Maybe not standalones, perhaps that is where the problem is.
I've played a lot of multichannel flacs in mkv containers and had ffdshow transcode them to ac3 and everything, all without issues. (32bit build).
I might digg one up and try it with 64bit and see what happens.

edit: ok I can confirm decoding works for flac in 64bit, as long as they are in a container.

[multiblitz]

One interesting observation: With Vista, 8600GT, 163.69driver, latest ffdshow from clsid and EVR-Renderer: I can sharpen with the sharpening of the drivers and can sharpen in parallel ffdshow. To my eyes it looks extremely good, potentially even better than limitedsharpening (I watch at 1920*1080 on a 4.2m wide and 2.2 high screen with a sony ruby)...less artifacts than anything else I tried...

...interesting: as soon as I enable lanzos resizing, the sharpening through the nvidia-drivers is broken...if I let the card do the resizing, sharpening works in ffdshow and in the card.

Before I started with limitedshaprening, I used to use lanzos resizing with some sharpening in ffdshow. I have tested this against the current resizing and sharpning of nvidia. In this case nvidia looks better than ffdshow...quite impressive.

[Valeron]

@haruhiko_yamagata:
The font size is not compatible with vsfilter, at least horizontal scale after rev1482.

I've got a NON-Square pixel AVC encode, when subtitle with ffdshow(after rev1482), the renderer automatic adjust the font size for the subtitle. but with vsfilter, it won't:devil:.

Great feature, though not compatible with vsfilter(opposite to the changelog), I like it.:thanks:

[LigH]

HuffVUV encoding seems to be broken in some current "tryout" builds. I used ffdshow with HuffYUV-YV12 and different settings to capture a desktop area with some screen recorder. Resolution: 1016x680 pixel, or similar dimensions.

The screen recorder used to crash after a while.

Watching a shorter video I completed before a crash, I saw that the bottom of the video contains some completely garbled lines with "fantastic colors", they grew upwards over the time the video played.

A thread in the german doom9/Gleitz board with a screenshot (http://forum.gleitz.info/showthread.php?p=347846#post347846)

[vlada]

Not before PAFF and h.264 multithreaded for all x264 encodes.
Maybe E-AC3 decoder should be added and dts issue fixed.

PAFF is already implemented in ffmpeg/libavcodec? Since when?

Also I'd like to repeat my very big feature request. It's letterboxing for DVD. Or at least it would be nice, if I could move the subtitles. Is someone willing to have a look at it? We've been already discussing this before, unfortunately this is still not implemented. I think with some work on VobSub, this might be implemented.

Also on the codecs tab under MPEG-2 it still says DVD Decoding (not working yet). Why? Are there any known problems? It works fine for me already for a long time (except for the letterboxing ;-) ). And I think MPEG-2/DVD support should be turned on by default.

[_xxl]

PAFF:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-September/035591.html
Multithreaded H.264 decoder for all x264 encodes:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-September/035877.html

[haruhiko_yamagata]

@haruhiko_yamagata:
The font size is not compatible with vsfilter, at least horizontal scale after rev1482.

I've got a NON-Square pixel AVC encode, when subtitle with ffdshow(after rev1482), the renderer automatic adjust the font size for the subtitle. but with vsfilter, it won't:devil:.

Great feature, though not compatible with vsfilter(opposite to the changelog), I like it.:thanks:Hmm... It's compatible with MPC's internal renderer, VMR9 renderless. VMR9 renderless is not compatible with vsfilter.
OK, you like it, I'll leave it as it is.

[fastplayer]

Not before PAFF and h.264 multithreaded for all x264 encodes.
Maybe E-AC3 decoder should be added and dts issue fixed.
Adding features especially experimental ones during a beta phase? Don't know if that's a good thing...

[Sharktooth]

i think it's a good idea instead. since those features are missing from long time. even if it breaks the conventional rule of thumb it's worth adding them

[Shakey_Jake33]

I think they are the features a lot of people are waiting for.

[_xxl]

encoder/cavlc.c: In function 'cavlc_mb8x8_mvd':
encoder/cavlc.c:262: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
I can't compile ff_x264 with MinGW GCC 4.2.1.

[foxyshadis]

Adding features especially experimental ones during a beta phase? Don't know if that's a good thing...

ffdshow does a few months of new features followed by a month or so of mostly testing & bugfixing, then a stablish 'beta' is released. (On a new svn branch, which is a bit pointless since I don't think any fixes have ever been backported to a stable branch, let alone recompiled and posted. It's there if someone wants to take the job, though.)

SBeaver, what splitter is being used? FlacSplitter from gabest?

[clsid]

No problems here building ff_x264 with MinGW GCC 4.2.1.

'FlacSplitter' doesn't exist :) SBeaver must be using either CoreFLAC or illiminable's filters.

[SBeaver]

I'm not sure I understand the question, but I understand enough to know that any answer I give will be irrelevant.

It seems clear though that there is a need for a dshow x64 flac parser.

[LigH]

Excuse my boldness...

Is this thread not the best place to report a bug?

[Inventive Software]

It is. Bug away. :)

[Leak]

Is this thread not the best place to report a bug?
Sure it is. It's just that I for example have exactly zero knowledge about the HuffYUV code which AFAIK comes from libavcodec, so I can't really say where the problem is...

Have you tried using ffmpeg to create your HuffYUV file? If that fails the same way it's a bug in libavcodec.

[madshi]

Are you ffdshow devs aware that 8 channel input (doesn't matter which format the source file has) is borked right now? Any hope for a fix? For my needs it would already suffice to just extract 5.1 and trash the remaining 2 channels. But right now 8 channel input plays terribly distorted through ffdshow.

[LigH]

Well - ffdshow has a VfW codec, so I can use it for screen capturing; using ffmpeg for it might be complicated...

I will try to create a few artifical videos, and reply later. Tomorrow is german national holiday, that means a little free time. ;)

[haruhiko_yamagata]

Preview version of YCbCr <-> RGB conversion options documentation (not executable, patches). Any suggestions, fixes are wellcome.
http://ffdshow-tryout.sourceforge.net/html/en/cspOptions.htm

[vlada]

What about dynamically adjusting the range? Start with 16-235 (Rec mode and if in the movie appear values lower/higher then 16/235, change the mode to PC to avoid discarding of information. Maybe it would be only useful to check first couple seconds a then decide which mode to use.

[SBeaver]

What about dynamically adjusting the range? Start with 16-235 (Rec mode and if in the movie appear values lower/higher then 16/235, change the mode to PC to avoid discarding of information. Maybe it would be only useful to check first couple seconds a then decide which mode to use.

Isn't that allready available in the levels tab?
Anyway I hope these new features come with some good presets for those who don't really know what numbers to set.
I have a hard time getting the levels right and if it isn't right I get a whole lot of blocking because of it.
Coreavc (and also haali renderer) has a lot simpler settings but they usually turn out better. This is regarding pc/tv levels only not the 709. 609. thing.

[foxyshadis]

Preview version of YCbCr <-> RGB conversion options documentation (not executable, patches). Any suggestions, fixes are wellcome.
http://ffdshow-tryout.sourceforge.net/html/en/cspOptions.htm

Don't forget to mention that if a video looks washed out, with a grey picture, it should be set on PC to compensate, even though it's the renderer's fault.

[haruhiko_yamagata]

What about dynamically adjusting the range? Start with 16-235 (Rec mode and if in the movie appear values lower/higher then 16/235, change the mode to PC to avoid discarding of information. Maybe it would be only useful to check first couple seconds a then decide which mode to use.Seb's BTB&WTW level filter is merged this time.
http://sourceforge.net/tracker/index.php?func=detail&aid=1753853&group_id=173941&atid=867362

[haruhiko_yamagata]

Don't forget to mention that if a video looks washed out, with a grey picture, it should be set on PC to compensate, even though it's the renderer's fault.Do you mean RGB -> YUV conversion?
In YUV-> RGB conversion, PC mode looks more washed out.

[foxyshadis]

Do you mean RGB -> YUV conversion?
In YUV-> RGB conversion, PC mode looks more washed out.

Ah, of course, my mind was elsewhere. Looking at the user interface, I was wondering if maybe it should be:

ITU-R BT.601 (DVD Default)
ITU-R BT.709 (HD Default)

Standard (Y 16-235, etc.)
Less contrast (or full range?) (Y 0-255, etc.)
Custom:

And since there's extra space, as long as you're making these matrices would it be hard to add SMPTE 240M and FCC as well? Their definitions can be found in the colormatrix (http://forum.doom9.org/showthread.php?s=&threadid=82217) source (colormatrix.h).

[yesgrey]

Preview version of YCbCr <-> RGB conversion options documentation (not executable, patches). Any suggestions, fixes are wellcome.

It looks very good.

I think it would be better saying:
BT.601: almost all SDTV and DVD
BT.709: almost all HDTV, HD-DVD and Blu-Ray

I know it's almost the same, but it's easier to who doesn't know.

Good work.

[yesgrey]

And since there's extra space, as long as you're making these matrices would it be hard to add SMPTE 240M and FCC as well? Their definitions can be found in the colormatrix (http://forum.doom9.org/showthread.php?s=&threadid=82217) source (colormatrix.h).

The values in colormatrix appear to be slightly off... the BT.709 were.

[zambelli]

Preview version of YCbCr <-> RGB conversion options documentation (not executable, patches). Any suggestions, fixes are wellcome.
http://ffdshow-tryout.sourceforge.net/html/en/cspOptions.htm
Somebody more knowledgable of the ITU specs can correct me, but I was under the impression the BT.601/709 specs define both chroma and luma mapping. If a video is being converted from YUV to RGB using BT.601 or BT.709, the luma conversion scale is already defined by that specification, so IMO it's incorrect to say a conversion is *both* BT.601/709 and PC because by definition PC (full range) mapping doesn't follow the BT.601/709 spec. No?

[zambelli]

And since there's extra space, as long as you're making these matrices would it be hard to add SMPTE 240M and FCC as well? Their definitions can be found in the colormatrix (http://forum.doom9.org/showthread.php?s=&threadid=82217) source (colormatrix.h).
I believe SMPTE 240M is being largely deprecated in favor of BT.709 because it preceded the ITU standard by just a few years and is similar enough that most people wouldn't care.

[haruhiko_yamagata]

Are you ffdshow devs aware that 8 channel input (doesn't matter which format the source file has) is borked right now? Any hope for a fix? For my needs it would already suffice to just extract 5.1 and trash the remaining 2 channels. But right now 8 channel input plays terribly distorted through ffdshow.I know. Just don't have time to fix it.

[haruhiko_yamagata]

And since there's extra space, as long as you're making these matrices would it be hard to add SMPTE 240M and FCC as well? Their definitions can be found in the colormatrix (http://forum.doom9.org/showthread.php?s=&threadid=82217) source (colormatrix.h).OK, it's not too hard.
Kr=0.2122 Kg=0.7013 Kb=0.0865 for SMPTE 240M. Is this correct?
What is FCC used for?

[haruhiko_yamagata]

It looks very good.

I think it would be better saying:
BT.601: almost all SDTV and DVD
BT.709: almost all HDTV, HD-DVD and Blu-Ray
Thank you. It looks better.

[fastplayer]

FWIW, "mostly" sounds a bit better than "almost all".

[foxyshadis]

What is FCC used for?

NTSC analog video. Zambelli's right, though, it and 240M are close enough to BT.601 and BT.709 respectively that it's kind of pointless to include them after all.

[LigH]

Back to ffdshow's HuffYUV:

According to my tests, used as converting video codec (without much pressure, "streamingly" called) it works fine.

What does not work reliably, is using the codec for capturing purposes (when timing matters). It might be too slow when there are more expensive tasks running, or there is a different calling technique. Probably the next frame already has to be encoded while the last frame is not yet finished.

I have no TV card here, I can only simulate it using a screen capturer (HyperCam or similar). More tests with matching equipment could be necessary.

[haruhiko_yamagata]

Somebody more knowledgable of the ITU specs can correct me, but I was under the impression the BT.601/709 specs define both chroma and luma mapping. If a video is being converted from YUV to RGB using BT.601 or BT.709, the luma conversion scale is already defined by that specification, so IMO it's incorrect to say a conversion is *both* BT.601/709 and PC because by definition PC (full range) mapping doesn't follow the BT.601/709 spec. No?I think you are right. But because some video clips have Y below 16 and/or over 235, someone wants to take it.
MJPEG and JPEG (used in grab filter) use so called PC601 in most cases. ffdshow had the code to automatically convert the color space using this information from stream. The code was buggy and did not work though. With my patch, MJPEG will use proper color space. The setting from dialog will be ignored in this case.

[haruhiko_yamagata]

Here is the patch that implements YCbCr <-> RGB conversion options. Seb.26's level filter is merged.
http://sourceforge.net/tracker/index.php?func=detail&aid=1753853&group_id=173941&atid=867362

[haruhiko_yamagata]

Standard (Y 16-235, etc.)
Less contrast (or full range?) (Y 0-255, etc.)
Custom:Thank you. It's better. I'll use Standard, Full range and Custom.

[madshi]

I know. Just don't have time to fix it.
Thanks for your reply. I'm glad that the bug is at least known... :)

[_xxl]

Here is the patch that implements YCbCr <-> RGB conversion options. Seb.26's level filter is merged.

Bin:
http://rapidshare.com/files/60036197/ffdshow_rev1500_20071003_xxl.exe.html

[zambelli]

I think you are right. But because some video clips have Y below 16 and/or over 235, someone wants to take it.
MJPEG and JPEG (used in grab filter) use so called PC601 in most cases. ffdshow had the code to automatically convert the color space using this information from stream. The code was buggy and did not work though. With my patch, MJPEG will use proper color space. The setting from dialog will be ignored in this case.
As a general rule of thumb, decoders should never be doing luma remapping but should instead pass untouched YUV video to the renderer along with correct metadata. Of course, Ffdshow is somewhat of an exception to the rule because it's also a video processor so in this case it's an acceptable practice - but one that should be used by caution, due to the number of "moving parts" in a video rendering pipeline.
In DirectShow the color matrices are specified using VideoInfoHeader2 (http://msdn2.microsoft.com/en-us/library/ms787914.aspx) and DXVA_ExtendedFormat (http://msdn2.microsoft.com/en-us/library/ms796493.aspx). I wish I could tell you for sure whether the latter can be used even when DXVA decoding isn't used, but if you're interested in implementing it, you could try emailing askdshow@microsoft.com for exact information.
Thank you. It's better. I'll use Standard, Full range and Custom.
"16-235" RGB is typically referred to as "Studio RGB", whereas the "0-235" RGB is referred to as "PC" or "Computer RGB". These are the names used in Charles Poynton's "Digital Video and HDTV Algorithms and Interfaces" book (ch.25).

[foxyshadis]

As a general rule of thumb, decoders should never be doing luma remapping but should instead pass untouched YUV video to the renderer along with correct metadata. Of course, Ffdshow is somewhat of an exception to the rule because it's also a video processor so in this case it's an acceptable practice - but one that should be used by caution, due to the number of "moving parts" in a video rendering pipeline.

In this case it's the RGB conversion that's meant, ie, it is actually being internally signalled and converted properly in the RGB converter, regardless of its setting, rather than remapped during decode. There is a FF_CSP_FLAGS_YUV_JPEG & PIX_FMT_YUVJ420P (plus 4:2:2, 4:4:4, and 4:4:0 variations). I'll grant that calling fullscale formats 'jpeg' probably isn't the greatest idea, but they are the 90% usage case.

It's not externally signaled though.

In DirectShow the color matrices are specified using VideoInfoHeader2 (http://msdn2.microsoft.com/en-us/library/ms787914.aspx) and DXVA_ExtendedFormat (http://msdn2.microsoft.com/en-us/library/ms796493.aspx). I wish I could tell you for sure whether the latter can be used even when DXVA decoding isn't used, but if you're interested in implementing it, you could try emailing askdshow@microsoft.com for exact information.

There was a patch to do this with VIH2, afaik, but renderers mostly ignored it, which is why it isn't presently used.

[Wilbert]

The values in colormatrix appear to be slightly off... the BT.709 were.
Could you post the values used in colormatrix and the ones i posted in this thread (a few posts back; quoted from avisynth.org)?

Somebody more knowledgable of the ITU specs can correct me, but I was under the impression the BT.601/709 specs define both chroma and luma mapping. If a video is being converted from YUV to RGB using BT.601 or BT.709, the luma conversion scale is already defined by that specification, so IMO it's incorrect to say a conversion is *both* BT.601/709 and PC because by definition PC (full range) mapping doesn't follow the BT.601/709 spec. No?
Yes, that's correct (at least in theory). There are dvds (jap. anime for example) which use the full YCbCr [0,255] range, and i thought most of them were BT.601?

[yesgrey]

Could you post the values used in colormatrix and the ones i posted in this thread (a few posts back; quoted from avisynth.org)?

In Colormatrix is GBR order (file Colormatrix.h):
+0.7152, +0.0722, +0.2126, // Rec.709 (0)
-0.3850, +0.5000, -0.1150,
-0.4540, -0.0460, +0.5000,


Charles Poynton's ColorFAQ (the same in the avisynth link):
RGB ITU.BT-709 HDTV -> YUV
kr = 0.2125; kg = 0.7154; kb = 0.0721;
Matrix should be:
0.2125 0.7154 0.0721
-0.114506 -0.385494 0.5000
0.5000 -0.454222 -0.045778

[Thunderbolt8]

since x/h264 multiple core acceleration is about to come soon, would it also be possible to do the same for ffdshow using VC-1 via libavcodec? I know that its already supported when using the WMVideo Decoder WMO, but ffdshow has a slight edge over that regarding quality and with ffdshow im also able to apply real time sharpening, which is useful when viewing native 1080p on a 720p screen/resolution. such an addition, in combination with that h264 speedup would make ffdshow even better suited for hddvd/blueray remuxes.