ffdshow tryouts project: Discussion & Development

[Mr VacBob]

ffdshow builds after r3734 (last working) are causing corruption with certain h.264 streams when using ffmpeg-mt. FFDshow r3744 shows corruption while playing normally, r3740 (last working for normal playback) shows corruption only while seeking.

libavcodec handles the stream fine in all builds. MPC-HC r2931 (MPC Video Decoder ffmpeg) also handles the stream fine.
CoreAVC 2.0 shows corruption similar to ffdshow ffmpeg-mt.

x264 r1867 sample of problem segment:
http://www.mediafire.com/?ambidqywri92f9q

Sample saved. ffmpeg-mt repository is currently quite outdated and I broke huffyuv in it, I'll update it soonish based on git.ffmpeg.org.

[ryrynz]

Does FFmpeg need to be updated in ffdshow as often as it is? It almost appears to be the bleeding edge judging from the broken features etc. If that's the case, is ffdshow used as a test platform for this code? Or is it just updated for the heck of it?

[JEEB]

Does FFmpeg need to be updated in ffdshow as often as it is? It almost appears to be the bleeding edge judging from the broken features etc. If that's the case, is ffdshow used as a test platform for this code? Or is it just updated for the heck of it?
It's for development and testing.

Keeping the development version's ffmpeg as close as possible to the original is a good thing as it means we get the latest fixes, new features etc. from the ffmpeg repository and less work needs to be done to modify ffmpeg to match ffdshow-tryouts (and the other way) compared to if it was done once in a full moon. Or at least less sudden bugs would happen during every update cycle.

The bugs reported in the last post were from the ffmpeg-mt repository (frame-based multithreaded ffmpeg), which isn't completely up-to-date regarding the original ffmpeg repository, and thus might just happen to have bugs that have slipped into it just before the last update, and then fixed a day or two later in the original repository. This happens, and you should understand the

Also, of course this helps people find bugs in ffmpeg itself, as more users use the decoders with various files.

If you have a problem with this, stick to "stable" versions or, if you need a specific feature/fix added after the last "stable", the last development version that works for you is good for you.

[STaRGaZeR]

@devs, I have some stuff in mind and I want your input/opinion about the following changes.

First, regarding the output section of ffdshow video, specially the bunch of colorspace output options ffdshow has.

The default options are just not good. With XP at least YV12 is accepted by its default renderer, in Vista/7 we're forcing a conversion to YUY2 with EVR, because it doesn't accept YV12, with the quality and speed issues this causes.

Right now we can output YUV 4:2:0, YUV 4:2:2 or RGB. The order of preference should be YUV 4:2:0 > RGB > YUV 4:2:2 for the following reasons:

- Almost everything is in 4:2:0 format. Output that by default: fast, no conversions and every renderer accepts it (more on this later).
- We have almost no 4:2:2 sources. Don't output it unless the source is already 4:2:2 or if it's absolutely necessary.
- If you don't want to output the original colorspace (4:2:0) or if the renderer doesn't support it (duh), and since we have to convert it in ffdshow anyway, do it to RGB, which is the best looking format plus it's accepted by almost all renderers.

With this in mind, the list of preferred outputs is:

For XP: YV12 > RGB32 > YUY2

For Vista/7: NV12 > RGB32 > YUY2

Since EVR doesn't accept YV12, output it as NV12 which is the exact same information, but differently arranged. The final list is:

YV12 > NV12 > RGB32 > YUY2

XP's default renderer will accept YV12, good. EVR will refuse YV12 but accept NV12, good. The rest, as they are in the list.

Second:

- Why do we keep I420 as an option? Exact same information as in YV12, differently arranged. Is there a single filter that accepts I420 but doesn't accept YV12? If not, my suggestion is to remove it. YV12 is the de-facto planar 4:2:0 colorspace.

- YUV 4:2:2 formats: currently we have YUY2, UYVY and YVYU. All the same information, differently arranged. Is there a single filter that accepts UYVY or YVYU but doesn't accept YUY2? If not, my suggestion is to remove them. YVYU is not even accepted by EVR.

- Do we consider NV12 as a planar or a packed format? Just to move it to the correct place if necessary.

- Any cases where RGB15 and RGB16 are useful? Sources in this format? Filters that want this as input?

Third, some new defaults:

- High quality YV12 to RGB32 + dithering enabled by default. If someone wants to convert to RGB32 in ffdshow, with the speed penalty it causes, at least do it right.

- Use libavcodec MP1/2/3 and AAC decoders by default. I've been using them for months without a single problem, but as always it should be tested by a large group of people. By doing this, we can get useful feedback.



Sorry for the wall of text :p. Feedback is needed, I think these are the best solutions but others might have better ones. Propose them!

[nevcairiel]

- Do we consider NV12 as a planar or a packed format? Just to move it to the correct place if necessary.

NV12 is Planar. Also, NV12 is really similar to YV12, the U/V values are just interlaved in NV12, and not so in YV12. They should be put next to each other, imho.


- Use libavcodec MP1/2/3 and AAC decoders by default. I've been using them for months without a single problem, but as always it should be tested by a large group of people. By doing this, we can get useful feedback.

I'm using those in my own DirectShow audio decoder, and they work just fine.

[Ger]

With this in mind, the list of preferred outputs is:

For XP: YV12 > RGB32 > YUY2

For Vista/7: NV12 > RGB32 > YUY2

Since EVR doesn't accept YV12, output it as NV12 which is the exact same information, but differently arranged. The final list is:

YV12 > NV12 > RGB32 > YUY2

XP's default renderer will accept YV12, good. EVR will refuse YV12 but accept NV12, good. The rest, as they are in the list.


As a Win7 user who wants the best hardware deinterlacing methods possible (most drivers require NV12 to to enable all methods as you know), this sounds like a good new default priority to me. The current solution, forcing NV12 by disabling everything else is not optimal.


Feedback is needed, I think these are the best solutions but others might have better ones. Propose them!

I know GUI changes in ffdshow aren't always straight forward because of space constraints etc., but when you have removed any redundant colorspace and have a final list of the remaining ones, why not organize them in a prioritized list in the GUI (similar to how it's done in CoreAVC or in the OSD page/tab in ffdshow), allowing the user to change the default priority/merit by moving them up/down in the list, rather than just having the option to disable/enable each one.

[clsid]

Removing UYVY, YVYU, RGB15, RGB16 is fine with me unless someone comes up with a good reason for keeping them.

Enabling HQ RGB32 by default is fine with me too.

Using libavcodec MP1/2/3 and AAC decoders is fine too. We can always revert if needed. Ultimately the goal is to remove the external libs.
Having LATM AAC support would be cool too. Any volunteers for that?

I also agree that YV12->NV12 should be preferred over YV12->YUY2.

[madshi]

I agree with setting YV12 and NV12 as priority. I also agree with removing superfluous options. The more the merrier. So let's talk about the following 2 options:

- "Set pixel aspect ratio in output media type"
- "Allow output format changes during playback"

Does anybody know any reason for *not* forcefully enabling these two options (and removing them from the GUI)? FWIW, I've received some bug reports from users who thought that there was a bug in madVR, while actually they just had these options disabled in ffdshow. IMHO these options should be renamed to:

- "keep aspect ratio secret, to make the renderer show the image wrong (hehe!!)"
- "keep output format changes secret, to catch the renderer on the wrong foot (hehe!!)"

But maybe I'm missing something and having these options unchecked actually serves a purpose? I can't think of any, though.

[cyberbeing]

UYVY should probably be kept, since capture cards seem to prefer it over YUY2.

Microsoft as of 2008 continues to list UYVY as a recommended FourCC along with YUY2 as well.
http://msdn.microsoft.com/en-us/library/dd206750%28v=VS.85%29.aspx

Adobe Premiere documentation also seems to claim that UYVY is the standard colorspace for SD-SDI output.

All those combined I think are reason enough to keep it. Disabling it by default would probably be acceptable though.

[jeremy33]

Is it a way to use the tab "rgb conversion" with YCbCr specification and Input/Output levels if I set output to NV12 to avoid the black screen bug of mpchc ?

http://forum.doom9.org/showthread.php?p=1478742#post1478742

[andrixnet]

Regarding removal of most encoders in ffdshow in fall 2010

@LigH
You must also understand things from out point of view. We are trying to remove all inferior and non-working stuff. For two main reasons: (1) because they are not maintained and thus we can't do any bugfixes, and (2) to direct users to better alternatives.

The one great thing about ffdshow is the fact that offered a great variaty of decoders and encoders all in one package, while not being a codec-pack, but a single entity.


Regarding the "alternatives", since xvid or H264 or theora or dirac or mpeg* are available as separate codec packages, isn't it self defeating ?
I mean have ffdshow for those so many decoders, but one wants to encode, install this and that and that? Which also includes by default a decoder for the same format.

I have to agree with wolfgangbeyer here : http://forum.doom9.org/showthread.php?p=1477266#post1477266

I don’t see any reason to install any ffdsow version above ffdshow_rev3572_20100913_clsid.exe, which seems to be the last available version with all encorders

Please bring back the encoders.

[Gleb Egorych]

Is there way to use NV12 with "Set interlace flag to output media" as preferred and automatically revert to YV12 if NV12 is not supported WITHOUT using profiles?

At the moment ffdshow disables YV12 option as soon as I enable "Set interlace flag to output media" option.

YV12 output is essential for madVR but for general output I prefer NV12.

[ikarad]

I find a problem with ffdshow sub renderer

file here
http://www.megaupload.com/?d=SB6Y47LD

With mpc-hc subs work very well and there is animation
http://img526.imageshack.us/img526/3982/mpchcsub.th.jpg (http://img526.imageshack.us/i/mpchcsub.jpg/)



With ffdshow subs work well (but japan subs are not displayed vertically) but there isn't any animation
http://img822.imageshack.us/img822/9428/ffdshowsub.th.jpg (http://img822.imageshack.us/i/ffdshowsub.jpg/)



bugtracker
https://sourceforge.net/tracker/?func=detail&aid=3186705&group_id=173941&atid=867360

[fastplayer]

ikarad, after 264 posts you should've figured out this forum's netiquette: Use thumbnails!

[ikarad]

ikarad, after 264 posts you should've figured out this forum's netiquette: Use thumbnails!

Sorry (I had forgotten), I change immediately by thumbnails.

[STaRGaZeR]

NV12 is Planar. Also, NV12 is really similar to YV12, the U/V values are just interlaved in NV12, and not so in YV12. They should be put next to each other, imho.


I'm using those in my own DirectShow audio decoder, and they work just fine.

I know NV12 is planar, but I don't know the exact meaning of the word packed in this context. In NV12, the chroma planes are "packed", if you know what I mean :p. What's the consensus on this? Any official document to base the decision on?

Thanks for the feedback!

As a Win7 user who wants the best hardware deinterlacing methods possible (most drivers require NV12 to to enable all methods as you know), this sounds like a good new default priority to me. The current solution, forcing NV12 by disabling everything else is not optimal.



I know GUI changes in ffdshow aren't always straight forward because of space constraints etc., but when you have removed any redundant colorspace and have a final list of the remaining ones, why not organize them in a prioritized list in the GUI (similar to how it's done in CoreAVC or in the OSD page/tab in ffdshow), allowing the user to change the default priority/merit by moving them up/down in the list, rather than just having the option to disable/enable each one.

Exactly. Wanna know something? NV12 is not even in the list of colorspaces to be considered for "best match" right now. The only way of using it is by disabling everything else. Duh.

I can see benefit in a list like that for people in the know. However, put something like that there and the average joe will mess everything up. The defaults are fine IMO. There's also the space constraint as you say.

Removing UYVY, YVYU, RGB15, RGB16 is fine with me unless someone comes up with a good reason for keeping them.

Enabling HQ RGB32 by default is fine with me too.

Using libavcodec MP1/2/3 and AAC decoders is fine too. We can always revert if needed. Ultimately the goal is to remove the external libs.
Having LATM AAC support would be cool too. Any volunteers for that?

I also agree that YV12->NV12 should be preferred over YV12->YUY2.

Noted. I'd remove libmad now, but I'd wait for libfaad until all the issues with ffmpeg are sorted out.

For LATM AAC we'd need to use ffmpeg's AAC parser, right? If that's the case we really need to find why the parser doesn't work. I didn't spend much time on it, but maybe it's a splitter issue? Does it work with LAVFSplitter?

The relevant stuff is in TaudioCodecLibavcodec.cpp . In fact, this file should be seriously cleaned up and formatted properly.

I agree with setting YV12 and NV12 as priority. I also agree with removing superfluous options. The more the merrier. So let's talk about the following 2 options:

- "Set pixel aspect ratio in output media type"
- "Allow output format changes during playback"

Does anybody know any reason for *not* forcefully enabling these two options (and removing them from the GUI)? FWIW, I've received some bug reports from users who thought that there was a bug in madVR, while actually they just had these options disabled in ffdshow. IMHO these options should be renamed to:

- "keep aspect ratio secret, to make the renderer show the image wrong (hehe!!)"
- "keep output format changes secret, to catch the renderer on the wrong foot (hehe!!)"

But maybe I'm missing something and having these options unchecked actually serves a purpose? I can't think of any, though.

There's a lot of options like that in ffdshow. I agree with you, and I can't think of any reasons either. Any feedback on these options?

BTW, you should update your ffdshow screenshot in the madVR thread to a recent version :devil:

UYVY should probably be kept, since capture cards seem to prefer it over YUY2.

Microsoft as of 2008 continues to list UYVY as a recommended FourCC along with YUY2 as well.
http://msdn.microsoft.com/en-us/library/dd206750%28v=VS.85%29.aspx

Adobe Premiere documentation also seems to claim that UYVY is the standard colorspace for SD-SDI output.

All those combined I think are reason enough to keep it. Disabling it by default would probably be acceptable though.

Fair enough. Then we could keep it, but as you say disabled by default. Devs, do you agree with this?

Is it a way to use the tab "rgb conversion" with YCbCr specification and Input/Output levels if I set output to NV12 to avoid the black screen bug of mpchc ?

http://forum.doom9.org/showthread.php?p=1478742#post1478742

The name "RGB conversion" should be self explanatory. You're not converting to RGB.

Also, you should tell the MPC-HC devs to fix the black screen bug in MPC-HC instead of finding workarounds elsewhere.

Is there way to use NV12 with "Set interlace flag to output media" as preferred and automatically revert to YV12 if NV12 is not supported WITHOUT using profiles?

At the moment ffdshow disables YV12 option as soon as I enable "Set interlace flag to output media" option.

YV12 output is essential for madVR but for general output I prefer NV12.

I can't think of any. BTW, why is YV12 grayed out when you enable the interlace flags?

[nevcairiel]

For LATM AAC we'd need to use ffmpeg's AAC parser, right? If that's the case we really need to find why the parser doesn't work. I didn't spend much time on it, but maybe it's a splitter issue? Does it work with LAVFSplitter?

I know that using LAV Splitter and LAV Audio Decoder together makes LATM AAC work, and i don't do anythign special in the audio decoder - not even apply the parser. Just hooked up the ffmpeg latm_aac decoder.
There is only like 2 splitters that can properly process LATM AAC anyway.

[jeremy33]

The name "RGB conversion" should be self explanatory. You're not converting to RGB.

Also, you should tell the MPC-HC devs to fix the black screen bug in MPC-HC instead of finding workarounds elsewhere.
Yeah I know but I try every possibilities because I tried to understand the bug with JanWillem32 but it's not possible to fix for now.

[fastplayer]

BTW, you should update your ffdshow screenshot in the madVR thread to a recent version :devil:

IIRC, that ffdshow version misses dithering and a couple of RGB32HQ tweaks.

Fair enough. Then we could keep it, but as you say disabled by default. Devs, do you agree with this?
Not a dev per se but I agree. Same goes for RGB32HQ! :)

@clsid:
Can you comment on this post (http://forum.doom9.org/showthread.php?p=1477149#post1477149) regarding our forum?

[STaRGaZeR]

I know that using LAV Splitter and LAV Audio Decoder together makes LATM AAC work, and i don't do anythign special in the audio decoder - not even apply the parser. Just hooked up the ffmpeg latm_aac decoder.
There is only like 2 splitters that can properly process LATM AAC anyway.

Good to know. Those splitters are LAV Splitter and? Do you have any samples?

IIRC, that ffdshow version misses dithering and a couple of RGB32HQ tweaks.

Not a dev per se but I agree. Same goes for RGB32HQ! :)

Couple tweaks? In that rev RGB32HQ wasn't HQ at all :D

[Ger]

For LATM AAC we'd need to use ffmpeg's AAC parser, right? If that's the case we really need to find why the parser doesn't work. I didn't spend much time on it, but maybe it's a splitter issue? Does it work with LAVFSplitter?

The relevant stuff is in TaudioCodecLibavcodec.cpp . In fact, this file should be seriously cleaned up and formatted properly.


I know that using LAV Splitter and LAV Audio Decoder together makes LATM AAC work, and i don't do anythign special in the audio decoder - not even apply the parser. Just hooked up the ffmpeg latm_aac decoder.
There is only like 2 splitters that can properly process LATM AAC anyway.

AFAIK, the current status for LATM AAC:

I'd say LAV Splitter + LAV Audio works with more or less all LATM samples I've tested.

LAV Splitter + Monogram AAC decoder (libfaad2 based) works partially. Some LATM samples work. Some don't.

LAV Splitter + ffdshow audio won't connect for LATM AAC.

The subtype used to connect LAV Splitter to Monogram AAC does not seem to be listed for ffdshow audio decoder in MPC-HC external filters:

// {000001FF-0000-0010-8000-00AA00389B71}
static const GUID MEDIASUBTYPE_LATM_AAC =
{ 0x000001ff, 0x0000, 0x0010, { 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 } };

EDIT: Sample (http://www.multiupload.com/O17QVRTW8N)
5.1 track is noise with Monogram. 2.0 tracks is fine. Both tracks are fine with LAV Audio.

[clsid]

clsid, what's the status on our forum? Should we close it completely and focus on SF's forum?
I've updated the wiki to the latest version and implemented required changes (http://sourceforge.net/blog/project-web-rebooted/) due to the SF's infrastructure updates.
Unless anyone has a better idea, I agree it is best to use SF's forum for now and dump the old spam infested phpbb forum.

Can you make the changes?

[fastplayer]

Unless anyone has a better idea, I agree it is best to use SF's forum for now and dump the old spam infested phpbb forum.
Can you PM me the admin login/password and tell me how you disabled the forum? I'll take a closer look at it.
If I can't figure it out, then we should consider moving to SF's forum. This way we can focus more on support and don't have to worry about managing it.
Can you make the changes?
I've already done that. I just wanted to let you know because the directory structure of our web space has changed quite a bit. Anyway, things are a lot "easier" now thanks to the SF update. :)

[ikarad]

@devs, I have some stuff in mind and I want your input/opinion about the following changes.

First, regarding the output section of ffdshow video, specially the bunch of colorspace output options ffdshow has.

The default options are just not good. With XP at least YV12 is accepted by its default renderer, in Vista/7 we're forcing a conversion to YUY2 with EVR, because it doesn't accept YV12, with the quality and speed issues this causes.

Right now we can output YUV 4:2:0, YUV 4:2:2 or RGB. The order of preference should be YUV 4:2:0 > RGB > YUV 4:2:2 for the following reasons:

- Almost everything is in 4:2:0 format. Output that by default: fast, no conversions and every renderer accepts it (more on this later).
- We have almost no 4:2:2 sources. Don't output it unless the source is already 4:2:2 or if it's absolutely necessary.
- If you don't want to output the original colorspace (4:2:0) or if the renderer doesn't support it (duh), and since we have to convert it in ffdshow anyway, do it to RGB, which is the best looking format plus it's accepted by almost all renderers.

With this in mind, the list of preferred outputs is:

For XP: YV12 > RGB32 > YUY2

For Vista/7: NV12 > RGB32 > YUY2

Since EVR doesn't accept YV12, output it as NV12 which is the exact same information, but differently arranged. The final list is:

YV12 > NV12 > RGB32 > YUY2

XP's default renderer will accept YV12, good. EVR will refuse YV12 but accept NV12, good. The rest, as they are in the list.

Second:

- Why do we keep I420 as an option? Exact same information as in YV12, differently arranged. Is there a single filter that accepts I420 but doesn't accept YV12? If not, my suggestion is to remove it. YV12 is the de-facto planar 4:2:0 colorspace.

- YUV 4:2:2 formats: currently we have YUY2, UYVY and YVYU. All the same information, differently arranged. Is there a single filter that accepts UYVY or YVYU but doesn't accept YUY2? If not, my suggestion is to remove them. YVYU is not even accepted by EVR.

- Do we consider NV12 as a planar or a packed format? Just to move it to the correct place if necessary.

- Any cases where RGB15 and RGB16 are useful? Sources in this format? Filters that want this as input?

Third, some new defaults:

- High quality YV12 to RGB32 + dithering enabled by default. If someone wants to convert to RGB32 in ffdshow, with the speed penalty it causes, at least do it right.

- Use libavcodec MP1/2/3 and AAC decoders by default. I've been using them for months without a single problem, but as always it should be tested by a large group of people. By doing this, we can get useful feedback.



Sorry for the wall of text :p. Feedback is needed, I think these are the best solutions but others might have better ones. Propose them!
You said that YV12 is not supported in vista/seven but if we use Madvr, only YV12 works with madvr in ffdshow.
What is the solution in vista and seven? Or I don't undertsand what you mean.

[clsid]

Can you PM me the admin login/password and tell me how you disabled the forum? I'll take a closer look at it.
If I can't figure it out, then we should consider moving to SF's forum. This way we can focus more on support and don't have to worry about managing it.
It was disabled using the phpbb admin control panel. I can make you an admin there if needed, but the forum is down atm due to database error.
I suggest to just remove the phpbb forum completely.

[fastplayer]

It was disabled using the phpbb admin control panel. I can make you an admin there if needed, but the forum is down atm due to database error.
I suggest to just remove the phpbb forum completely.
Oops, I thought you just "disabled" the forum by cutting the DB connection. As I said, I'll take a shot at it but things are definitely not looking good...

Edit: I fixed the connection error. Can you set me up an admin account?
Edit2: No need for an account. I made one in the DB.
Edit3: Forum is up and running again: http://ffdshow-tryout.sourceforge.net/forum/

[STaRGaZeR]

You said that YV12 is not supported in vista/seven but if we use Madvr, only YV12 works with madvr in ffdshow.
What is the solution in vista and seven? Or I don't undertsand what you mean.

Solution for what? What's the problem?

I said that EVR, the default Vista/7 renderer, doesn't accept YV12.

[ikarad]

Solution for what? What's the problem?

I said that EVR, the default Vista/7 renderer, doesn't accept YV12.

Sorry, I misunderstood.

[khagaroth]

Why do you want to prefer YV12 over NV12 on XP? With YV12 it's impossible to use HW deinterlacing, so NV12 should be default for both XP and Vista/7.

[ikarad]

Why do you want to prefer YV12 over NV12 on XP? With YV12 it's impossible to use HW deinterlacing, so NV12 should be default for both XP and Vista/7.
I don't use HW deinterlacing.

I don't prefer YV12 over NV12 but if I want to use madvr, I must use YV12 because madvr only functions with YV12.


For this moment, I use YUY2.

[Gleb Egorych]

BTW, why is YV12 grayed out when you enable the interlace flags?
I think it's by design. I'm using rev3760, the check greys out "Planar YUV" formats. Do you see different behaviour on your system?


- Use libavcodec MP1/2/3 and AAC decoders by default. I've been using them for months without a single problem, but as always it should be tested by a large group of people. By doing this, we can get useful feedback.

I see it's already done in 3762. Has the problem with improper downsampling been fixed? AFAIK ffmpeg downsamples output to 16bit integer without any dithering, this was discussed here several times. Ideally it should not change data format at all.

[clsid]

The libavcodec MP1/2/3 decoders give floating point output.

[Gleb Egorych]

clsid, so the situation changed since september 2010 (http://forum.doom9.org/showthread.php?p=1446541#post1446541)? Does libav give original FP output or FP->int->FP?

[STaRGaZeR]

Why do you want to prefer YV12 over NV12 on XP? With YV12 it's impossible to use HW deinterlacing, so NV12 should be default for both XP and Vista/7.

Default should be, in every case, no conversion at all. Colorspace conversions are for when the next filter doesn't support the original colorspace, or for when you intentionally don't want to output the original colorspace for some reason.

I think it's by design. I'm using rev3760, the check greys out "Planar YUV" formats. Do you see different behaviour on your system?

Yes, by ffdshow's design: if you enable the flags, it will gray out YV12, in all PCs. The question is why, that's what I'd like to know.


After testing the proposed changes, that work fine as far as I can test here, I've noticed that nothing except "Old renderer" in MPC-HC accepts RGB24. With the others I always see a filter called "Color Space Converter" inserted in the graph, and the output mediatype is set to MEDIASUBTYPE_RGB32 (¿?), so no support for RGB24. With VMR9 I get a black screen too. Can you guys try it? Any revision will do. Deselect everything except RGB24 and try to connect to something.
What would you use RGB24 for? RGB32 and 24 are again the same information and RGB32 it's the preferred (and it seems the only supported) RGB format.

Also, about the "Set pixel aspect ratio in output media type" option. What this does is use VIDEOINFOHEADER or VIDEOINFOHEADER2. Is there any filter today that doesn't use/accept VIH2?

EDIT: here's a build so you can test the stuff done so far. Try to ignore the bad looking GUI, it's not final. A fresh install is recommended, although not needed.

http://www.mediafire.com/?tb94xou67ahiatp

[nevcairiel]

clsid, so the situation changed since september 2010 (http://forum.doom9.org/showthread.php?p=1446541#post1446541)? Does libav give original FP output or FP->int->FP?

The MP1/2/3 decoders are one of the few that actually support native float output (assuming you use mp3float instead of mp3). The other decoders have to be patched to allow this - i'm unsure if this is being done currently. Following which custom patches are in ffdshows ffmpeg is kinda impossible.

[Gleb Egorych]

nevcairiel, thanks for the info. Do you know that thing about output of libav AAC decoder which is now default instead of libfaad2?

[Ger]

EDIT: here's a build so you can test the stuff done so far. Try to ignore the bad looking GUI, it's not final. A fresh install is recommended, although not needed.

http://www.mediafire.com/?tb94xou67ahiatp

Seems OK to me (using Win7/x64 and JanWillem32's MPC-HC r2941 test build).

With all 6 checked:
VMR9 and madVR uses YV12.
All EVR variants fall back to NV12.
Haali and VMR7 fall back to RGB32.


Yes, by ffdshow's design: if you enable the flags, it will gray out YV12, in all PCs. The question is why, that's what I'd like to know.

Well, I suggest you remove it regardless. I normally use EVR variants and keep the flags enabled, but if I want to test madVR quicky I have to remember to disable the flags as well to allow YV12, or the graph just falls back to "Video Renderer".


After testing the proposed changes, that work fine as far as I can test here, I've noticed that nothing except "Old renderer" in MPC-HC accepts RGB24. With the others I always see a filter called "Color Space Converter" inserted in the graph, and the output mediatype is set to MEDIASUBTYPE_RGB32 (¿?), so no support for RGB24. With VMR9 I get a black screen too. Can you guys try it? Any revision will do. Deselect everything except RGB24 and try to connect to something.
What would you use RGB24 for? RGB32 and 24 are again the same information and RGB32 it's the preferred (and it seems the only supported) RGB format.

Same results here.

I don't know a good reason to keep RGB24, but maybe someone else does?

Also, about the "Set pixel aspect ratio in output media type" option. What this does is use VIDEOINFOHEADER or VIDEOINFOHEADER2. Is there any filter today that doesn't use/accept VIH2?

Well, I didn't see VIH2 in the pin info during the RGB24 test above. So the "Old Renderer" and the "Color Space Converter" are probably two. I didn't double check this though.

According to the tooltip the indeterminate/grayed state tries VIH2 first and falls back to VIH on failure. If the goal is to reduce confusing and redundant options like madshi mentioned, why not remove the option and always use the indeterminate state.

[nevcairiel]

nevcairiel, thanks for the info. Do you know that thing about output of libav AAC decoder which is now default instead of libfaad2?

The avcodec AAC decoder rounds to 16-bit integer. Its easy to patch to output float though. I patched ffmpeg for float output on all major formats (AAC, AC3, DTS) which i use in my own audio decoder. If anyone wants the patches, feel free to contact me.

[madshi]

Also, about the "Set pixel aspect ratio in output media type" option. What this does is use VIDEOINFOHEADER or VIDEOINFOHEADER2. Is there any filter today that doesn't use/accept VIH2?
According to the tooltip the indeterminate/grayed state tries VIH2 first and falls back to VIH on failure. If the goal is to reduce confusing and redundant options like madshi mentioned, why not remove the option and always use the indeterminate state.
I agree with Ger. The "indeterminate" state should be the best solution. There may be some filters who don't support VIH2, but there's really no need to have a control in the ffdshow settings for this. Just try VIH2 first, and then VIH. Every good filter does it this way.

[Gleb Egorych]

I patched ffmpeg for float output on all major formats (AAC, AC3, DTS) which i use in my own audio decoder. If anyone wants the patches, feel free to contact me.
Having those patches in ffdshow would be great, the main question is how difficult is to maintain them is adapt to future versions. I suppose ffdshow developers won't apply them if the adaptation is quite tricky.

[STaRGaZeR]

Seems OK to me (using Win7/x64 and JanWillem32's MPC-HC r2941 test build).

With all 6 checked:
VMR9 and madVR uses YV12.
All EVR variants fall back to NV12.
Haali and VMR7 fall back to RGB32.

Cool. The results should be YV12 for everything except:

- NV12 for all EVR variants.
- RGB32 for Haali and VMR7 renderless. They don't accept YV12 or NV12, so ffdshow uses RGB32. VMR7 windowed should use YV12.
- RGB32 for old renderer. It only accepts RGB here.

Well, I suggest you remove it regardless. I normally use EVR variants and keep the flags enabled, but if I want to test madVR quicky I have to remember to disable the flags as well to allow YV12, or the graph just falls back to "Video Renderer".

Unless I have solid info on why it gets grayed out, I'm not going to touch it. It may break something.

Well, I didn't see VIH2 in the pin info during the RGB24 test above. So the "Old Renderer" and the "Color Space Converter" are probably two. I didn't double check this though.

According to the tooltip the indeterminate/grayed state tries VIH2 first and falls back to VIH on failure. If the goal is to reduce confusing and redundant options like madshi mentioned, why not remove the option and always use the indeterminate state.

It doesn't do that, but it doesn't matter anyway. The option is gone, the indeterminate state is the new forced value. Everything is working here.

Here's a new build. This one is what's going to be commited unless someone finds bugs in it. I don't like the "Output settings" name in one of the groupboxes, so if you guys have a better one, post it.

http://www.mediafire.com/?91bcr8akv38ql6s

[yesgrey]

I don't like the "Output settings" name in one of the groupboxes, so if you guys have a better one, post it.
I think it's a bit redundant to use the word output in some of the designations, since it's already the name of the tab, so here are my suggestions:
1st group: "Supported color spaces"
2nd group: "Stream settings"
2nd group - 1st check box: "Set interlaced flag"

Some more radical suggestions...
Why do we need to distinguish between planar/packed YUV? I don't think that would be important to the end user... I would simply remove it. However, if you still want to group the formats I think it would be preferable to do it considering the color resolution formats, like this:

---Supported color spaces---
| 4:2:0 - YV12 NV12 |
| 4:2:2 - YUY2 UYVY |
| 4:1:1 - DV |
| 4:4:4 - RGB32 |
----------------------------

[TheShadowRunner]

For the VP6F one, the AVI says the height is 416 pixels, however the correct value is maybe 408 or something like that. There is no "extradata" that would indicate the need for cropping either. Are you sure that this information didn't get lost at some point so what ffdshow decodes is simply the best it can do with the information in the file?

Ok, I found out this *IS* a FFmpeg FLV4/VP6F decoding bug after all.
I filed a report here: http://roundup.ffmpeg.org/issue2620
Later,

TSR

[Ger]

Cool. The results should be YV12 for everything except:

- NV12 for all EVR variants.
- RGB32 for Haali and VMR7 renderless. They don't accept YV12 or NV12, so ffdshow uses RGB32. VMR7 windowed should use YV12.
- RGB32 for old renderer. It only accepts RGB here.


Confirmed. I only tried the renderless versions of VMR 7/9 before, so yes, VMR7 windowed does use YV12 here as well.


Unless I have solid info on why it gets grayed out, I'm not going to touch it. It may break something.

Well, I think it happened here (http://ffdshow.svn.sourceforge.net/viewvc/ffdshow?view=revision&revision=1531) and maybe here (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=479)? No reason given from Milan or Haruhiko there at least.

I did try the MPC-HC MPEG-2 decoder connected to madVR (so YV12) with interlaced flags checked, and saw no problem other than (obviously) no deinterlacing.

I'd guess it was grayed out either simply because they knew hw deinterlacing wouldn't work with YV12 and I420, or because of some old renderer/driver bug.

IMHO, I think the current implementation is actually more likely to break something for the hw deint users out there, like madVR connection or other filters that may require YV12, if they are unaware of the issue.

You decide, of course. But if you would consider making a test build, maybe after committing the other changes, we can at least try it with Vista/7 and look for any obvious problems, and maybe there is a volunteer around to test it with XP + VMR7/9 as well.

[cca]

Just tested rev 3763, libavcodec as MP3 decoder gives me 32bit float but the libavcodec AAC gives 16bit still while libfaad2 gives 32bit float. Will keep libfaad2 selected for now.

[STaRGaZeR]

I think it's a bit redundant to use the word output in some of the designations, since it's already the name of the tab, so here are my suggestions:
1st group: "Supported color spaces"
2nd group: "Stream settings"
2nd group - 1st check box: "Set interlaced flag"

Some more radical suggestions...
Why do we need to distinguish between planar/packed YUV? I don't think that would be important to the end user... I would simply remove it. However, if you still want to group the formats I think it would be preferable to do it considering the color resolution formats, like this:

---Supported color spaces---
| 4:2:0 - YV12 NV12 |
| 4:2:2 - YUY2 UYVY |
| 4:1:1 - DV |
| 4:4:4 - RGB32 |
----------------------------


Sounds good. I'll leave the "in output media type" for aesthetics thou.

The same for the grouping. Not doing it or doing it with numbers looks bad, and it isn't important anyway. If you know what these options do, you don't need any extra info, and if you don't know, you shouldn't be in this tab anyway. Also the DV option does a lot of stuff, not only setting the output to 4:1:1, that's why the separator is there.

Well, I think it happened here (http://ffdshow.svn.sourceforge.net/viewvc/ffdshow?view=revision&revision=1531) and maybe here (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=479)? No reason given from Milan or Haruhiko there at least.

I did try the MPC-HC MPEG-2 decoder connected to madVR (so YV12) with interlaced flags checked, and saw no problem other than (obviously) no deinterlacing.

I'd guess it was grayed out either simply because they knew hw deinterlacing wouldn't work with YV12 and I420, or because of some old renderer/driver bug.

IMHO, I think the current implementation is actually more likely to break something for the hw deint users out there, like madVR connection or other filters that may require YV12, if they are unaware of the issue.

You decide, of course. But if you would consider making a test build, maybe after committing the other changes, we can at least try it with Vista/7 and look for any obvious problems, and maybe there is a volunteer around to test it with XP + VMR7/9 as well.

Good guess, but it's still a guess. The thing is that I don't like it either. If you want YV12+NV12 with HW deint you're screwed. I'll try to find a more elegant solution, like implementing the check not in the GUI, but inside ffdshow. This way you'll be able to select both YV12 and HW deint, and ffdshow will use it unless the output is YV12, without user intervention.

Ideally we'd have HW deint enabled by default, like Microsoft decoders do so users don't have to mess up with deinterlacing. This could cause problems with ffdshow's internal deinterlacer filter thou, like double deinterlacing (120fps output :p). I want to hear opinions about this.

In the meantime, do I commit the changes so far? Has anyone found any bugs?

EDIT: And this build does just that. You can enable YV12 and HW deint at the same time. The flags will always be used except when outputting YV12, which is the same as the old behaviour without the hassle of the grayed out YV12 checkbox. Also HW deint is enabled by default. Implications:

Stuff accepting YV12: no changes.
EVR and variants, accepting NV12: high quality HW deinterlacing by default.
Haali, accepting RGB32: surprisingly this renderer deinterlaces RGB, and not bad as far as I can see. Quality deinterlacing by default.
VMR7 renderless, accepting RGB32: no changes, no HW deinterlacing for RGB.
Old renderer (yikes), accepting RGB32: doesn't support VIH2, so no flags, no HW deinterlacing.

http://www.mediafire.com/?1q6u8axjxvp8qi0

[fastplayer]

- What about RGB32HQ? Shouldn't it be enabled by default?
- The grouping IMO is unnecessary. It made sense visually when there were a lot of more choices.
- The tooltip for "Set interlaced flag..." and "Method:" has redundant blank lines. Can you remove them or are they required for translation?

[Gleb Egorych]

STaRGaZeR, with your build I have YV12 used by default with EVR (according to info page), NV12 is used only when YV12 unchecked.

[STaRGaZeR]

- What about RGB32HQ? Shouldn't it be enabled by default?
- The grouping IMO is unnecessary. It made sense visually when there were a lot of more choices.
- The tooltip for "Set interlaced flag..." and "Method:" has redundant blank lines. Can you remove them or are they required for translation?

- It is enabled by default, and used when YV12 or NV12 fail.
- Looks like ass IMO, I can make a build if you want to see it first person :p
- Indeed. It's interesting, I see the \n's in the code, but I can't see the blank lines in the tooltip, that's why I forgot to remove them. Removed.

STaRGaZeR, with your build I have YV12 used by default with EVR (according to info page), NV12 is used only when YV12 unchecked.

The colorspaces EVR supports depends of the graphics card drivers. Since you have one that supports YV12, YV12 is used over NV12.

[fastplayer]

- It is enabled by default, and used when YV12 or NV12 fail.
I tested inside a WinXP VM and HQ was definitely disabled, while Dithering was greyed-out. Or does it get automagically enabled when YV12/NV12 fail?
- Looks like ass IMO, I can make a build if you want to see it first person :p
Nah, leave it as it is. We don't want a**-like looking things in ffdshow, do we? :D
- Indeed. It's interesting, I see the \n's in the code, but I can't see the blank lines in the tooltip, that's why I forgot to remove them. Removed.
Great, thanks!