ffdshow tryouts project: Discussion & Development

[Mr VacBob]

Originally Posted by cyberbeing

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]

Originally Posted by 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?

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 . Feedback is needed, I think these are the best solutions but others might have better ones. Propose them!

[nevcairiel]

Originally Posted by STaRGaZeR

- 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.

Originally Posted by STaRGaZeR

- 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]

Originally Posted by STaRGaZeR

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.

Originally Posted by STaRGaZeR

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/libr...=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.ph...42#post1478742

[andrixnet]

Regarding removal of most encoders in ffdshow in fall 2010

Originally Posted by clsid

@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.ph...66#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




With ffdshow subs work well (but japan subs are not displayed vertically) but there isn't any animation




bugtracker
https://sourceforge.net/tracker/?fun...41&atid=867360

[fastplayer]

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

[ikarad]

Originally Posted by fastplayer

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]

Originally Posted by nevcairiel

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 . What's the consensus on this? Any official document to base the decision on?

Thanks for the feedback!

Originally Posted by Ger

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.

Originally Posted by 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.

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.

Originally Posted by 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.

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

Originally Posted by 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/libr...=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?

Originally Posted by 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.ph...42#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.

Originally Posted by 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.

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

[nevcairiel]

Originally Posted by STaRGaZeR

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]

Originally Posted by STaRGaZeR

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]

Originally Posted by STaRGaZeR

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

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

Originally Posted by STaRGaZeR

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 regarding our forum?

[STaRGaZeR]

Originally Posted by nevcairiel

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?

Originally Posted by fastplayer

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