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!

[Gleb Egorych]

The colorspaces EVR supports depends of the graphics card drivers. Since you have one that supports YV12, YV12 is used over NV12.
I use Geforce 8800GT with drivers 266.58. Maybe NV12 should be made a higher-priority output colorspace than YV12. At the moment behaviour is almost the same as it was before your changes.

*EDIT* Tab-order of this settings page and other pages is curious.

[Ger]

:thanks:


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.


I like the idea of having it working "out of the box" like MS decoders. Maybe add a big/fat/red warning in the software deinterlacing tab if both are enabled at the same time? Or would any user messing with that tab already know that? I don't know.

Regarding the DV option it doesn't have a tooltip explaining what it does, and it seems to disable just about "everything", but at least you can see many options getting grayed out as soon as you check it.

I use Geforce 8800GT with drivers 266.58. Maybe NV12 should be made a higher-priority output colorspace than YV12. At the moment behaviour is almost the same as it was before your changes.

I tend to agree with Gleb Egorych and khagaroth, moving NV12 to the top, above YV12 in priority.

That would solve the issues that apparently occur with Nvidia and EVR, not needing to uncheck YV12, and would also give XP/VMR9 user hw deint by default.

Given the lossless nature of YV12 -> NV12 conversion, the only downside would be a slightly higher CPU usage, right? My CPU is from 2006 and while it may be a few percent higher with YV12 uncheked, it really seems negligible with todays hardware.

If JanWillem32's changes are accepted in MPC-HC their decoders will use NV12 a lot more, and Microsoft already does use NV12, even with non-DXVA. Just tried "Mpeg4s Decoder DMO" for software XviD decoding connected to VMR9 and it used NV12. With madVR it falls back to YV12.

*EDIT* Tab-order of this settings page and other pages is curious.

I had to read that a few times before I understood you meant the Tab key and not a GUI tab, but yes you're right.

EDIT: One more thing. I know it was agreed to keep UYVY because of capture cards and disable it by default, but if it's bottom of the priority list anyway, why not just enable it by default, just in case something needs it.

[clsid]

If the internal deinterlacing is enabled, then the input interlacing flag should obviously not be propagated to the next filter in the chain.
So set output interlacing flag only if input had the flag enabled and internal deinterlacing is not enabled.

[mark0077]

Guys, discussion going on over at the avsforums regarding problems with ffdshow causing crashes when using avisynth. A couple of the chaps over there narrowed it down to right after build 3356

http://www.avsforum.com/avs-vb/showthread.php?t=1025800&page=33

I can only assume this change brought in the problems.

Revision 3358 - Directory Listing
Modified Thu Apr 15 08:27:07 2010 UTC (10 months, 1 week ago) by tal_aloni
AviSynth Frame accurate seeking. (patch by SEt and Jeremy Duncan)

Anyone know why these changes might be causing ffdshow to cause crashes from time to time, mostly when opening a second / third file without closing down the software player.

[fastplayer]

Forum status update

I've updated it to the latest phpBB version, cleaned out countless spam accounts, added hundreds of e-mail addresses, domains, and usernames to the ban list and they still keep coming. Unfortunately, we can't ban by IP because SourceForge is doing something funky with them (probably routing through their own proxies).
Unless someone knows how to effectively block spam and is willing to implement it, I see no other choice than killing off the forum... Any takers or should I pull the plug?

Edit:
I've pulled the plug today. Redirects point to ffdshow's SF.net forum.

[madshi]

I tend to agree with Gleb Egorych and khagaroth, moving NV12 to the top, above YV12 in priority.
I also agree. The MS documentation says this about NV12:

> NV12 is the preferred 4:2:0 pixel format for DirectX VA.
> It is expected to be an intermediate-term requirement
> for DirectX VA accelerators supporting 4:2:0 video.

BTW, the next madVR build will support NV12 and YV12.

[Px]

Unless someone knows how to effectively block spam
Replace default captcha with this - http://www.captcha.ru/en/

[Ger]

Just did a test with yadif with double framerate + output flags checked. Double double framerate (well, only an increase from 50 to 60, monitor refresh rate, in my case) only happens if Force bob is selected (output/method). With The default "Auto" mode it seems no hw deint is applied if already deinterlaced internally. This according to the CTRL-J stats in EVR Custom.

[nevcairiel]

BTW, the next madVR build will support NV12 and YV12.

Awesome, then my CUVID decoder doesn't have to implement conversion to YV12 :D

[SamuriHL]

I also agree. The MS documentation says this about NV12:

> NV12 is the preferred 4:2:0 pixel format for DirectX VA.
> It is expected to be an intermediate-term requirement
> for DirectX VA accelerators supporting 4:2:0 video.

BTW, the next madVR build will support NV12 and YV12.

Oh THIS will be fun! :D

[madshi]

Just so that there are no misunderstandings: madVR supporting NV12 does *not* mean that DXVA decoding or deinterlacing works... ;)

Hmmmm... Does anybody know a decoder or source filter which outputs P010 or P016 video data? That's 10bit or 16bit 4:2:0 (NV12 and YV12 are 8bit). I've just added support for P010 and P016 to madVR, but I have no way to test it.

[nevcairiel]

Just so that there are no misunderstandings: madVR supporting NV12 does *not* mean that DXVA decoding or deinterlacing works... ;)


I know that, but it still saves me time coding a conversion!

[madshi]

@nevcairiel, I knew that you knew. :) But not everyone knows as much as you do. Just wanted to make sure that nobody gets up his hopes.

[SamuriHL]

@nevcairiel, I knew that you knew. :) But not everyone knows as much as you do. Just wanted to make sure that nobody gets up his hopes.

I wasn't entirely sure if dxva was being utilized or not, so, good clarification. Still, this is a good thing IMO!

[madshi]

Ok, new version out now with support for YV12, NV12, P010, P016:

http://madshi.net/madVR.zip (v0.38)

Follow up please in the madVR thread, thanks.

[STaRGaZeR]

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?

Hah, good find. What's your CPU? It's only enabled by default if you have at least 2 cores AND SSSE3 support (Core2Duo and newer, dunno about AMD). I don't know why haruhiko used SSSE3 as requirement, since the HQ converter only needs SSE2, so let's do it this way. Internally the converter already has a SSE2 check, only the GUI has to be fixed. So disable both checkboxes if the CPU doesn't support SSE2. Try the build below to see if they're properly disabled for CPUs not supporting SSE2.

I use Geforce 8800GT with drivers 266.58. Maybe NV12 should be made a higher-priority output colorspace than YV12. At the moment behaviour is almost the same as it was before your changes.

*EDIT* Tab-order of this settings page and other pages is curious.

Interesting. So with nvidia cards EVR accepts YV12?

And what has changed? Better or worse now? Be specific! Remember that what I'm changing here is the order of the output colorspaces, but only if the original fails. That is, if you have YV12 video, the list is only consulted if you have YV12 disabled or if the renderer doesn't accept it. Doing YV12->NV12 by default will require changing code I'm not familiar with. So for now YV12 > NV12.

Indeed. At least the output tab should be better now.

:thanks:

I like the idea of having it working "out of the box" like MS decoders. Maybe add a big/fat/red warning in the software deinterlacing tab if both are enabled at the same time? Or would any user messing with that tab already know that? I don't know.

Regarding the DV option it doesn't have a tooltip explaining what it does, and it seems to disable just about "everything", but at least you can see many options getting grayed out as soon as you check it.

I tend to agree with Gleb Egorych and khagaroth, moving NV12 to the top, above YV12 in priority.

That would solve the issues that apparently occur with Nvidia and EVR, not needing to uncheck YV12, and would also give XP/VMR9 user hw deint by default.

Given the lossless nature of YV12 -> NV12 conversion, the only downside would be a slightly higher CPU usage, right? My CPU is from 2006 and while it may be a few percent higher with YV12 uncheked, it really seems negligible with todays hardware.

If JanWillem32's changes are accepted in MPC-HC their decoders will use NV12 a lot more, and Microsoft already does use NV12, even with non-DXVA. Just tried "Mpeg4s Decoder DMO" for software XviD decoding connected to VMR9 and it used NV12. With madVR it falls back to YV12.

I had to read that a few times before I understood you meant the Tab key and not a GUI tab, but yes you're right.

EDIT: One more thing. I know it was agreed to keep UYVY because of capture cards and disable it by default, but if it's bottom of the priority list anyway, why not just enable it by default, just in case something needs it.

See below for the double deinterlacing solution.

I'm not 100% sure, but here it goes: the DV option encodes (yes, encoding, it requires libavcodec) your video to DV and outputs it like that. That's why the option disables everything else.

See above. When I'm more familiar with the code I may change that. But not now. The truth is that if the price is HW deinterlacing by default everywhere without any downsides except very little CPU usage increase, NV12 may be a better option. However, at least with my HD5850, NV12+flags only works with EVR and Overlay mixer. With VMR7/9 they're simply ignored, so we'd be in the same situation as with YV12.

Good observation. Enabled by default now.

If the internal deinterlacing is enabled, then the input interlacing flag should obviously not be propagated to the next filter in the chain.
So set output interlacing flag only if input had the flag enabled and internal deinterlacing is not enabled.

Yep. In this build, if the deinterlacing filter is enabled the flags are set to weave, which is the same as "do nothing".

Just for the record, if somebody wants to see the difference between any of ffdshow's deinterlacers and HW deinterlacing in real time: output NV12+flags so HW deint is enabled, then check the deinterlacing filter configured as you want. This will result in HW deint stopping working and for example yadif being enabled almost instantly, so differences can clearly be seen between the two.

Test build: http://www.mediafire.com/?vny5xjraq0fjn9m

[ranpha]

Interesting. So with nvidia cards EVR accepts YV12?

And what has changed? Better or worse now? Be specific! Remember that what I'm changing here is the order of the output colorspaces, but only if the original fails. That is, if you have YV12 video, the list is only consulted if you have YV12 disabled or if the renderer doesn't accept it. Doing YV12->NV12 by default will require changing code I'm not familiar with. So for now YV12 > NV12.


It seems so in my case.

http://i.min.us/ijif0u.jpg

Oh BTW, the requirement that you must pass NV12 to EVR (vanilla/custom presenter) in order to have hardware deinterlacing only applies to ATI GPUs. This doesn't apply to nVidia GPUs, because hardware deinterlacing with EVR (vanilla/custom presenter) can be achieved even when you pass NV12 or YV12 or whatever colorspace the GPU supported (see picture below).

http://i.min.us/il3mZg.jpg

[Ger]

Remember that what I'm changing here is the order of the output colorspaces, but only if the original fails. That is, if you have YV12 video, the list is only consulted if you have YV12 disabled or if the renderer doesn't accept it. Doing YV12->NV12 by default will require changing code I'm not familiar with. So for now YV12 > NV12.

When I'm more familiar with the code I may change that. But not now.
OK. I think most of us wrongly assumed that it was as easy to change the YV12 order as the other ones, but clearly not. Hopefully you or someone else will be able to change it another time then.

In the meantime Nvidia users can disable YV12 and leave everything else enabled if they want hw deint in EVR. Now that madVR supports NV12 it shouldn't cause too many problems. I remember Stax had an issue with DirectShowSource, but (unless YV12 was forced with parameters) I'm pretty sure that was because only NV12 was enabled, and that won't be a problem after your changes.


The truth is that if the price is HW deinterlacing by default everywhere without any downsides except very little CPU usage increase, NV12 may be a better option. However, at least with my HD5850, NV12+flags only works with EVR and Overlay mixer. With VMR7/9 they're simply ignored, so we'd be in the same situation as with YV12.

Weird, I assumed it worked in VMR9 because I didn't see combing. Checking "Set interlaced flags in output media type" definitely triggers some kind of deinterlacing with NV12 + VMR9 renderless here (Win7 x64, ATI 5770, 11.2 drivers), but it looks way worse than with EVR. I see blocking in the channel logo that aren't there in EVR. On an Nvidia laptop I can't see that quality difference between EVR and VMR9, but the panel is horrible on that one so I don't trust my eyes 100%.

With EVR I can see the effect live/immediately if I change Method (Auto/Force bob/Weave) or Field order, but with VMR9 there is no difference even after a reconnect. Only the checkbox matters. I guess VMR9 (in Win7 at least) checks VIH2 and if "dwInterlaceFlags: 0x00000081", makes its own decisions regardless of bob/weave/field order flags in the stream. If dwInterlaceFlags: 0x00000000, no deinterlacing.

Oh, well. I really don't care what happens in VMR9 in Win7 anyway. I don't know why I bothered writing all that. I don't even care what happens in XP since I haven't used it since 2006. :p


Yep. In this build, if the deinterlacing filter is enabled the flags are set to weave, which is the same as "do nothing".

Test build: http://www.mediafire.com/?vny5xjraq0fjn9m


And with the same frame rate test I used with the last build, I now get around 50 fps as it should be, so no double deinterlacing occurs even when Force bob is selected. So that seems to work just fine. :cool:

Oh BTW, the requirement that you must pass NV12 to EVR (vanilla/custom presenter) in order to have hardware deinterlacing only applies to ATI GPUs. This doesn't apply to nVidia GPUs, because hardware deinterlacing with EVR (vanilla/custom presenter) can be achieved even when you pass NV12 or YV12 or whatever colorspace the GPU supported (see picture below).

I don't think so. I can't double check at the moment, but I'm pretty sure I tested with YV12 + EVR Custom with Nvidia drivers reporting like that and I saw combing, and no visible deinterlacing at all until i switched to NV12 or YUY2. I just think DXVAChecker gets incorrect info from the drivers. I pretty sure the old drivers (below 200.xx somewhere) didn't report it that way last time I checked, a year or so ago. Have you seen hw deint really happening with YV12?

The ATI drivers only show NV12, YUY2 and UYVY in that list, with only NV12 supporting VectorAdaptiveDevice and MotionAdaptiveDevice.

EDIT: Oh, that's right. No flags activated with ffdshow + YV12 anyway, so I guess I haven't tested at all then. Sorry. I guess you have to use another decoder to test then. Maybe DXVAChecker is right after all.

[fastplayer]

Hah, good find. What's your CPU? It's only enabled by default if you have at least 2 cores AND SSSE3 support (Core2Duo and newer, dunno about AMD).
It's an Athlon64 X2 and inside the VM it's just a single-core and SSE3 is as far as it goes SIMD-wise (SSSE3 is not supported).
I don't know why haruhiko used SSSE3 as requirement, since the HQ converter only needs SSE2, so let's do it this way. Internally the converter already has a SSE2 check, only the GUI has to be fixed. So disable both checkboxes if the CPU doesn't support SSE2. Try the build below to see if they're properly disabled for CPUs not supporting SSE2.
You mean NV12/YV12, right? If I disable both, RGB32 takes over and plays fine. RGB32HQ is now enabled by default on this setup.
If I disable SSE2 (and SSE3), then RGB32HQ+Dithering is grayed-out. The SSE2-check seems to work. :)
I'm not sure about the RGB32HQ multi-core requirement, though. It seems to work fine with one core in the VM...

[madshi]

Hmmmm... Does anybody know what NV24 is? NVidia DXVA seems to support it. Is it 16bit 4:2:0? Then it would be identical to P016?

[nevcairiel]

Hmmmm... Does anybody know what NV24 is? NVidia DXVA seems to support it. Is it 16bit 4:2:0? Then it would be identical to P016?

I found this reference on the MSDN

The FOURCC format of the surface defines whether the interlaced fields are interleaved or not. For example, NV12 is an interlaced format with interleaved fields whereas NV24 is an interlaced format with non-interleaved fields.

http://msdn.microsoft.com/en-us/library/ff563056%28v=vs.85%29.aspx

From what i can tell, commercial players seem to be using NV24 alot, especially PowerDVD. Other then that, not much references popped up.

[ranpha]

I don't think so. I can't double check at the moment, but I'm pretty sure I tested with YV12 + EVR Custom with Nvidia drivers reporting like that and I saw combing, and no visible deinterlacing at all until i switched to NV12 or YUY2. I just think DXVAChecker gets incorrect info from the drivers. I pretty sure the old drivers (below 200.xx somewhere) didn't report it that way last time I checked, a year or so ago. Have you seen hw deint really happening with YV12?

The ATI drivers only show NV12, YUY2 and UYVY in that list, with only NV12 supporting VectorAdaptiveDevice and MotionAdaptiveDevice.

EDIT: Oh, that's right. No flags activated with ffdshow + YV12 anyway, so I guess I haven't tested at all then. Sorry. I guess you have to use another decoder to test then. Maybe DXVAChecker is right after all.

I cannot test with YV12, because if the 'Set interlace flag in output media type' is checked, YV12 will be greyed out. Hardware deinterlacing works fine with YUY2 though.

[nevcairiel]

Hardware deinterlacing works fine with YUY2 though.

YUY2 is a 4:2:2 format though, and your chroma will be (badly) upsampled to get there.

[Gleb Egorych]

And what has changed? Better or worse now? Be specific!
I wrote *almost* because in fact you removed several checkboxes which *theoretically* could be checked or unchecked. *Practically* in my usage scenarios I didn't notice any changes in behaviour because enabling YV12 gave me no HW deinterlacing and I needed to disable YV12 to get HW deinterlacing with NV12.

[ranpha]

YUY2 is a 4:2:2 format though, and your chroma will be (badly) upsampled to get there.

Yes, the quality is a disaster (deinterlacing works, but other image quality problems surfaced). But the best way to test hardware deinterlacing with YV12 is to use CoreAVC (no need to turn on CUDA decoding), make it output YV12 only, set the deinterlacing method to 'Hardware' and connect it directly to EVR renderer. Works very well with YV12, NV12 et. al. but not if CoreAVC is forced to only output any of RGB* colorspaces (which the DXVA Checker says isn't supported).

[madshi]

I found this reference on the MSDN

http://msdn.microsoft.com/en-us/library/ff563056%28v=vs.85%29.aspx

From what i can tell, commercial players seem to be using NV24 alot, especially PowerDVD. Other then that, not much references popped up.
Ah thanks! Makes sense. Too bad, though, I was excited for a moment, hoping NV24 would be 16bit 4:2:0.

[Ger]

I cannot test with YV12, because if the 'Set interlace flag in output media type' is checked, YV12 will be greyed out. Hardware deinterlacing works fine with YUY2 though.

Yeah, I know. That's what I meant with the edit. In STaRGaZeR's latest test builds it won't be grayed out, but the flags will be automatically disabled when YV12 is used, so it still can't be used for testing that particular issue.

YUY2 works on ATI as well (but not with the two best algos), so that's less interesting than YV12.

Given the currently available ffdshow implementations another decoder that allows forced YV12 + hw deint flags would be the only way to test for sure.

EDIT:
Didn't see your last post regarding CoreAVC. I guess we know it works then. You learn something new every day.

[STaRGaZeR]

It seems so in my case.

Oh BTW, the requirement that you must pass NV12 to EVR (vanilla/custom presenter) in order to have hardware deinterlacing only applies to ATI GPUs. This doesn't apply to nVidia GPUs, because hardware deinterlacing with EVR (vanilla/custom presenter) can be achieved even when you pass NV12 or YV12 or whatever colorspace the GPU supported (see picture below).

I will enable the flags for YV12 then, so you guys can run some tests.

Oh, well. I really don't care what happens in VMR9 in Win7 anyway. I don't know why I bothered writing all that. I don't even care what happens in XP since I haven't used it since 2006. :p

You can't alienate XP users, even if you don't use XP :p

It's an Athlon64 X2 and inside the VM it's just a single-core and SSE3 is as far as it goes SIMD-wise (SSSE3 is not supported).

You mean NV12/YV12, right? If I disable both, RGB32 takes over and plays fine. RGB32HQ is now enabled by default on this setup.
If I disable SSE2 (and SSE3), then RGB32HQ+Dithering is grayed-out. The SSE2-check seems to work. :)
I'm not sure about the RGB32HQ multi-core requirement, though. It seems to work fine with one core in the VM...

ffdshow has several converters for different colorspaces (a mess, I must say). If you convert to RGB32 from YV12, one is used. If you convert to RGB32HQ from YV12, another is used. This is obviously controlled by the "High quality..." option. This HQ converter is only for YV12/NV12/YUY2 -> RGB32 conversion. The HQ converter requires SSE2 and nothing else. It's multithreaded. The dual core and SSSE3 check is only for determining the default value, you can still use it as long as your CPU supports SSE2. haruhiko probably used this particular combination just to make sure only fast modern CPUs have it enabled by default.

I wrote *almost* because in fact you removed several checkboxes which *theoretically* could be checked or unchecked. *Practically* in my usage scenarios I didn't notice any changes in behaviour because enabling YV12 gave me no HW deinterlacing and I needed to disable YV12 to get HW deinterlacing with NV12.

OK, then everything is right.


In this build, the flags are enabled for all colorspaces. The only real change compared to the previous one is that YV12 is flagged too. Report your findings in both ATI and NV, XP and Vista/7.

http://www.mediafire.com/?5g9jtd6yzjd2c0t

As expected, in my system (ATI + Vista) it makes no difference: YV12 is still not deinterlaced, the renderer doesn't matter. No downsides observed.

[fastplayer]

The dual core and SSSE3 check is only for determining the default value, you can still use it as long as your CPU supports SSE2. haruhiko probably used this particular combination just to make sure only fast modern CPUs have it enabled by default.
Thanks for summing it up! :)
Looks like Haruhiko played the "better safe than sorry"-card with this check.

[madshi]

Can anybody reproduce the following problem I'm seeing here?

- all output colorspaces active in the ffdshow output section
- external decoder delivers NV12 to ffdshow raw video processor
- ffdshow raw video processor connects to renderer with NV12

In this situation MPC-HC with EVR Custom crashes for me. And with madVR half the screen is black while the other half is empty. It seems to me that the ffdshow raw video processor doesn't handle NV12 input + NV12 output correctly. Any other combination seems to work fine, though. E.g. YV12 input + NV12 output works fine.

[ranpha]

Test video (http://www.filesonic.com/file/20150847/history_chan_hd_sample_interlaced.mkv)

No deinterlacing (ffdshow raw video filter outputing YV12 to EVR custom presenter without the interlace flag been set):-
http://i.min.us/ijqKyO.jpg

ffdshow raw video filter set to output YV12 with interlace flags being set:-
http://i.min.us/ijvjlu.jpg

ffdshow raw video filter set to output UYVY with interlace flags being set:-
http://i.min.us/ijvhdm.jpg

Haven't tested with NV12 or YUY2, I assume that they will just work in my nVidia GPU. In other words, this build works really well. Now hardware deinterlacing with YV12 in ffdshow is actually doable.


Can anybody reproduce the following problem I'm seeing here?

- all output colorspaces active in the ffdshow output section
- external decoder delivers NV12 to ffdshow raw video processor
- ffdshow raw video processor connects to renderer with NV12

In this situation MPC-HC with EVR Custom crashes for me. And with madVR half the screen is black while the other half is empty. It seems to me that the ffdshow raw video processor doesn't handle NV12 input + NV12 output correctly. Any other combination seems to work fine, though. E.g. YV12 input + NV12 output works fine.

With Stargazer build, there is no crash reported (CoreAVC output NV12, pass it to ffdshow raw video filter that will then output NV12 to EVR custom presenter). Haven't tried with the latest madVR though, I haven't got around installing it yet (still using 0.36) .

[Gleb Egorych]

In other words, this build works really well. Now hardware deinterlacing with YV12 in ffdshow is actually doable.
Same here. Tested on my samples, HW deinterlacing works with YV12 now.

[Ger]

I will enable the flags for YV12 then, so you guys can run some tests.

In this build, the flags are enabled for all colorspaces. The only real change compared to the previous one is that YV12 is flagged too. Report your findings in both ATI and NV, XP and Vista/7.

http://www.mediafire.com/?5g9jtd6yzjd2c0t

As expected, in my system (ATI + Vista) it makes no difference: YV12 is still not deinterlaced, the renderer doesn't matter. No downsides observed.

In other words, this build works really well. Now hardware deinterlacing with YV12 in ffdshow is actually doable.

Cool. I can also confirm that on a borrowed Nvidia laptop it also works with YV12 in both EVR and VMR9r (Win7). There is no ugly half-way solution in VMR9 like on ATI+NV12, and flag changes are also immediately visible in VMR9r with Nvidia. In short Nvidia drivers/deinterlacers seem far more flexible with regards to both colorspace and renderer.

The defaults in the last build should make everyone happy. Hw deint works out of the box (with properly flagged streams at least) for both Nvidia and ATI on Vista/7 + EVR. :thanks:

XP and Intel behavior is still untested, but I doubt these changes will make anything worse than before for them. It will most likely be better there as well. Would be nice if anyone could confirm this though.

I do have a long-standing issue with a particular spot in one of the auto flagging algos, but I'm not going to even bring that up until these changes are safely committed.

[STaRGaZeR]

Nice.

Devs, tell me when you want this commited (IF you want to :p).

[fastplayer]

How about... right now? I need my daily ffdshow fix! :D
I haven't noticed any anomalies today while "testing" the latest build you posted. It just works™! :)

[STaRGaZeR]

It's on now :D

[mark0077]

Anyone know how I can contact SEt, I doubt he has seen my PM regarding avisynth / ffdshow crashes problem since a commit he made a few months back...

[madrazel]

I found a problem with old Real Video file. Since FFdshow has appropriate codecs for RealVideo 1 to 4, I think this might be interesting to you. This issue is with RealVideo 3.
The video is a lecture from Berkeley on their webcast, for the file go to: http://webcast.berkeley.edu/course_details.php?seriesid=1906978254.
and the link to the file is: http://webcast.berkeley.edu/stream.php?type=real&webcastid=13952 -> rtsp://169.229.131.16:554//bibs/f2004/group6/psych1/20040830.rm , 87 MB - to download it I used Portable Offline Browser, 30 day full working trial here: http://www.metaproducts.com/mp/Portable_Offline_Browser.htm
I was trying to play it in latest GOM Player, but I think the player is irrelevant here, because other Real Media videos from that site go through ffdshow without issues.
Also this file is playing fine with VLC 1.1.7, and with Media Player Classics when Real Alternative 1.9.0 is installed , that is bypassing ffdshow. There is an error at the beginning of the file visible in players that can handle this file, but I don't know it is a recorded analog error from the camera or digital error in the file. However if it is a digital error I think there should be a way to seal the algorithm to not go stupid while encountering it.

Error is that the picture is gray about 1 second at the beginning of the file and then player hangs up and quits.

[ikarad]

I found a problem with ffdshow 3760 and the last versions.
The back right channel (speaker) and the LFE crossover channel are swapped. I found a workaround for this problem by using the swap channel options to swap the LFE and Back right channels.

I use ffdshow with mpc-HC

Edit: I try with ffdshow since 3361 and thre is the same problem. I have tried with different version of mpc-hc (1.2.2972 until the last 1.5.1.2931) and There is the same problem (I haven't tried with older version of ffdshow and mpc-hc)

edit2: I try under xp sp3 or vista and there is the same problem

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

[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
Up for this problem present in ffdshow 3765

[Gleb Egorych]

I found a problem with ffdshow 3760 and the last versions.
The back right channel (speaker) and the LFE crossover channel are swapped.
At sf.net you wrote "I use ffdshow with mpc-HC but this bug doesn't appeared with mpc-hc only". Sounds like it's rather mpc-hc's bug.

[STaRGaZeR]

Up for this problem present in ffdshow 3765

Upping your problems won't solve them.

[ikarad]

At sf.net you wrote "I use ffdshow with mpc-HC but this bug doesn't appeared with mpc-hc only". Sounds like it's rather mpc-hc's bug.

No it's a bug of ffdshow because without ffdshow it works. If it was a bug of mpc-hc, it wouldn't work with mpc-hc only.

[ikarad]

Upping your problems won't solve them.

Yes I know but It's for that developpers see this bug.
I don't know if bugtracker is still used by developpers.

[Gleb Egorych]

No it's a bug of ffdshow because without ffdshow it works. If it was a bug of mpc-hc, it wouldn't work with mpc-hc only.
Your logic is wrong. Imagine that MPC-HC has 2 bugs: wrong mapping in internal decoder and wrong mapping in internal mixer and these 2 bugs "neutralize" each other, ie the output is correct.
But when external decoder (ffdshow in your case) is connected to internal mixer then the output is wrong. Your description of the problem does not rule out this speculative situation.

BTW I tested ffdshow in 2 different players (not MPC-HC) and didn't noticed the problem.

[nevcairiel]

Its much more likely that there is one bug, and not two bugs correcting each other.
Besides, i have no issues with channel assignment using MPC-HC, and i know for a fact that the MPC-HC audio switcher does not do any channel mappings, unless you setup some mappings manually.

[ikarad]

Your logic is wrong. Imagine that MPC-HC has 2 bugs: wrong mapping in internal decoder and wrong mapping in internal mixer and these 2 bugs "neutralize" each other, ie the output is correct.
But when external decoder (ffdshow in your case) is connected to internal mixer then the output is wrong. Your description of the problem does not rule out this speculative situation.

BTW I tested ffdshow in 2 different players (not MPC-HC) and didn't noticed the problem.
Can uo utell me the 2 differents players that you tested to that I test.

Moreover, it's maybe a bug with comportment of ffdshow when mpc-hc use ffdshow and not a bug of mpc-hc.

After it's maybe a bug of mpc-hc.

For that I refer also this problem on the bug tracker of mpc-hc.

[ikarad]

Its much more likely that there is one bug, and not two bugs correcting each other.
Besides, i have no issues with channel assignment using MPC-HC, and i know for a fact that the MPC-HC audio switcher does not do any channel mappings, unless you setup some mappings manually.

Finally, it's a bug with mpc-hc or ffdshow?

[HeadlessCow]

Yes I know but It's for that developpers see this bug.
I don't know if bugtracker is still used by developpers.

The ffdshow ssa/ass subtitle renderer is not very complete and (from what I understand) there is no real plan to fix that given the large amount of work it would require. At some point ffdshow might integrate libass (or vsFilter) to give it better support, but it's also a lot of work and low priority for the developers.

[ikarad]

The ffdshow ssa/ass subtitle renderer is not very complete and (from what I understand) there is no real plan to fix that given the large amount of work it would require. At some point ffdshow might integrate libass (or vsFilter) to give it better support, but it's also a lot of work and low priority for the developers.

Thanks.
The problem is that the sub renderer of mpc-hc is still very buggued (and like for ffdshow, nobody works on the sub renderer) for example and even more buggued (ssa/ass renderer is buggued and pgs renderer is buggued) than sub renderer in ffdshow.
It's very difficult (I don't know the software) to find a software whose sub renderer is perfect and works all the time.

[Gleb Egorych]

Can uo utell me the 2 differents players that you tested to that I test.

Zoom Player and DVBViewer.

[nevcairiel]

You can turn off any audio processing by MPC-HC by simply turning off the "Use built-in Audio Switcher" Checkbox in the Audio options. If its still going out the wrong channels then, its ffdshows fault, no question.

Personally, i use the audio switcher to adjust for A/V delay, but without anything selected in the channel mapping table there. Never had any issues with any audio codec.

[HeadlessCow]

Thanks.
The problem is that the sub renderer of mpc-hc is still very buggued (and like for ffdshow, nobody works on the sub renderer) for example and even more buggued (ssa/ass renderer is buggued and pgs renderer is buggued) than sub renderer in ffdshow.
It's very difficult (I don't know the software) to find a software whose sub renderer is perfect and works all the time.

The "perfect" solution is to install vsFilter since that's the software that everyone making the subtitles uses. It's buggy too, but as long as you're using the same version as the maker of the subs, it's what they're using to create it anyways. MPC-HC should be nearly exactly the same since it's just an internal version of the same code.

[ikarad]

The "perfect" solution is to install vsFilter since that's the software that everyone making the subtitles uses. It's buggy too, but as long as you're using the same version as the maker of the subs, it's what they're using to create it anyways. MPC-HC should be nearly exactly the same since it's just an internal version of the same code.

The problem is that with mpc-hc there are many bugs with sub renderer and it's not the perfect solution. FFdshow sub renderer is better even if not perfect.

[ikarad]

You can turn off any audio processing by MPC-HC by simply turning off the "Use built-in Audio Switcher" Checkbox in the Audio options. If its still going out the wrong channels then, its ffdshows fault, no question.

Personally, i use the audio switcher to adjust for A/V delay, but without anything selected in the channel mapping table there. Never had any issues with any audio codec.

I have tried by simply turning off the "Use built-in Audio Switcher" Checkbox in the Audio options and there is the same problem.

[pirlouy]

I'm using ffdshow_rev3765_20110225_xhmikosr_icl12 build, but with an older build, I also have this problem:

I can't manage to read old MPEG1 videos with ffdshow. Player crashes quite quickly, with libmpeg2 or libavcodec. I did not have this problem some weeks ago... I don't have problem when using MPC-HC decoder though (huh ?).

I know it's not a splitter problem or a an audio decoder. It's really something to do with ffdshow video part.

[p0w3rh0u5e]

I have some problems with the mixer, but only with the x86-build.

If i set it up to 5.1 (3/0/2) it simply doesn't work, no sound at all and the filter only connects if i choose ReClock as renderer. MPC falls back to another decoder, if i don't use ReClock. Same thing happens when i disable the mixer, no sound...

I can set up the mixer to some other presets, with some working and some not (but nothing really fits, because i have a 5.1 setup). For example, 3/2/1 works without LFE, but not with LFE enabled... 3/0/1 works with both LFE enabled and disabled. 3/0/2 doesn't work at all. Changing the splitter doesn't help too (tried haali, lavf and mpc's internal)

Everything is working with the x64-build of the same version and identical configuration.

Any ideas?

[STaRGaZeR]

I've fixed the last issue I had with libavcodec and DTS streams. So here's a test build, so you guys can torture it. What to do:

- Test everything, DTS, all variants of DTS-HD (only the DTS core will be decoded obviously), switching, retarded splitters, etc.
- Test only software decoding. No bitstreaming.
- If you're going to report anything, try libdts and confirm you don't have the issue with it before reporting.
- Since someone is going to say it, 16-bit output is not an issue. Decoding failures are.

And if possible, do the same with AC3, AAC, MP1/2/3.

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

[fastplayer]

What exactly was wrong with DTS in the first place? If it's libavcodec's fault, shouldn't it be fixed upstream instead?
Off to testing...

[hoborg]

@hoborg
We need a volunteer to fix the twos/sowt decoding code and also port some QT PCM additions from MPC-HC.
Preferably also separate these formats from "uncompressed" into new format options.

Thanks for info.
How much work it will need to separate them from RAW audio?
Right now i didn't found a way how to prevent FFDshow load to decode twos/sowt so MPA MPA decoder can be used instead. If i disable RAW audio, it will broke playback of videos with mixed PCM and compresed audio, so this is not good way.

Of course best will be if somebody fix twos/sowt playback, but i understand there is tasks with highter priorities :)

[fastplayer]

@STaRGaZeR:
Since you've had some fun with the RGB32HQ code, does this explanation on our wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:rgb_conversion#high_quality_yv12_to_rgb_conversion) make any sense?
High quality YV12 to RGB conversion

This checkbox will instruct ffdshow to use a high quality conversion method. If you have a dual core CPU, you can do so without performance penalty. If you have quad core CPU, check this, it's faster with higher quality.
This sounds like a quad-core will produce a better image than a dual-core. Is there something in the code that suggests this or is this just bad wording?

[STaRGaZeR]

What exactly was wrong with DTS in the first place? If it's libavcodec's fault, shouldn't it be fixed upstream instead?
Off to testing...

DTS-HD (MA at least, dunno about HR) failed with libavcodec. This was caused by ffdshow's internal parser, doing something wrong stripping the HD blocks. So I just disabled it, letting ffmpeg's parser do its magic, and here it works just fine. In this test build DTS decoding is 100% ffmpeg unless there's something hidden in ffdshow I'm not aware of.

If nobody finds any bugs I'll make ffdshow audio default to libavcodec for everything, and eventually remove libmad, libfaad, liba52 and libdts.

@STaRGaZeR:
Since you've had some fun with the RGB32HQ code, does this explanation on our wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:rgb_conversion#high_quality_yv12_to_rgb_conversion) make any sense?

This sounds like a quad-core will produce a better image than a dual-core. Is there something in the code that suggests this or is this just bad wording?

Not at all, more or less cores will only be faster or slower. Remember the previous dual core requirement for the checkbox to be enabled? That's probably why it says "if you have a dual core CPU". You wouldn't have been able to enable it otherwise :p

[fastplayer]

If nobody finds any bugs I'll make ffdshow audio default to libavcodec for everything, and eventually remove libmad, libfaad, liba52 and libdts.
Haven't noticed any issues so far with your build throughout the entire day and I've thrown AC3, DTS, AAC, and MP3 at it. :)
I've been using libavcodec as an audio decoder for months by now and I haven't encountered any anomalies. Keep in mind that I'm not doing any bitstreaming, post-processing or other fancy stuff. Just good ol' analog stereo output! :)
Not at all, more or less cores will only be faster or slower. Remember the previous dual core requirement for the checkbox to be enabled? That's probably why it says "if you have a dual core CPU". You wouldn't have been able to enable it otherwise :p
Understood. I'll update that entry accordingly. Thanks!

[STaRGaZeR]

Haven't noticed any issues so far with your build throughout the entire day and I've thrown AC3, DTS, AAC, and MP3 at it. :)
I've been using libavcodec as an audio decoder for months by now and I haven't encountered any anomalies. Keep in mind that I'm not doing any bitstreaming, post-processing or other fancy stuff. Just good ol' analog stereo output! :)

Post-processing, bitstreaming and stuff have nothing to do with the software decoding itself, so we're good :)

[yesgrey]

If nobody finds any bugs I'll make ffdshow audio default to libavcodec for everything, and eventually remove libmad, libfaad, liba52 and libdts.
The only problem I can see is that libavcodec outputs 16 bit integer for some formats. If you plan to patch ffdshow to allow 32 FP for those formats (like madshi did to use with eac3to) I agree with removing the others, otherwise don't.

[STaRGaZeR]

The only problem I can see is that libavcodec outputs 16 bit integer for some formats. If you plan to patch ffdshow to allow 32 FP for those formats (like madshi did to use with eac3to) I agree with removing the others, otherwise don't.

Since someone is going to say it, 16-bit output is not an issue. Decoding failures are.

See? I knew it :D

[yesgrey]

See? I knew it :D
Sorry, I've missed it, but even though it might not be an issue, it would make ffdshow worse, and I think that should be avoided.;)

[STaRGaZeR]

Let's end this flame before it even starts, shall we? I don't want to argue with the same guys that always bring these kind of debates, and that think they can hear stuff with equipment that produces more noise and distortion than the conversion does by itself. My arguments:

Yes, the 16-bit conversion is not optimal from a signal processing point of view.
Yes, ffmpeg is like that.
Yes, for me to modify ffmpeg there should be a showstopper situation. This one isn't.
Yes, if ffmpeg devs decide to remove the conversion and output 32-bit float, ffdshow will do it too.
Yes, basing your perception of quality in a number is just wrong. Proof: you don't know how they work internally, but you assume 32-bit float from libdts is better (not that it sounds better, hah!) than rounded 16-bit integer from libavcodec for example, without even listening to them. And what's worse, you and others will spread this nonsense like you always do. Then users without a clue come, with the same BS, and we have to endure it.
No, you can't hear the difference. Face it.
No, I don't want to (and won't) patch every ffdshow decoder, since that's what would be needed if you want to do it the right way.

I hope this will be my last post on the subject. No need to start a tl;dr useless post war. These are my arguments, I already know yours.

That said, I won't oppose at all if someone does it, even if I think it's a waste of time ;)

Now back to business, any bugs with the libavcodec decoders?

[Qaq]

If there is no chance to get libavcodec as perfect decoder I prefer to stay with 32fp decoders. At least I don't see they do that nonsense 32fp > 16int rounding. And thanks for 32fp for mp3 btw.

[fastplayer]

What has happened to visual styles in recent builds? In Win7 no themes are applied to controls at all. Manifest missing/broken?

[madshi]

The only problem I can see is that libavcodec outputs 16 bit integer for some formats. If you plan to patch ffdshow to allow 32 FP for those formats (like madshi did to use with eac3to) I agree with removing the others, otherwise don't.
If there is no chance to get libavcodec as perfect decoder I prefer to stay with 32fp decoders. At least I don't see they do that nonsense 32fp > 16int rounding. And thanks for 32fp for mp3 btw.
I fully agree with yesgrey and Qaq.

Rounding 32fp -> 16int is not just "not optimal", it's a straight forward violation of digital processing laws. Yes, ffmpeg is like that. And that is reason enough to not remove possibly better alternatives from ffdshow.

My opinion: Make libav default, if you want, but don't remove libdts/liba52, until the libav devs get their act together. Just to balance my (negatively sounding) comment, let me say here that IMHO libav is a *wonderful* open source project.

[yesgrey]

Let's end this flame before it even starts, shall we?
Agreed, but remember that was you who started it... ;)
Just keep the other decoders, it's as simple as that. Or is there any problem of having them inside ffdshow?

No, I don't want to (and won't) patch every ffdshow decoder, since that's what would be needed if you want to do it the right way.
Agreed. I also think that the problem should be handled by libavcodec authors, and not patched in ffdshow.

[Gleb Egorych]

I think that only libmad may be removed. liba52/libdts/libfaad2/libsamplerate in quality aspect are better than libav's ones.

About libav bugs: AAC decoder shows wrong bitrate, libfaad2 shows proper bitrate.

[STaRGaZeR]

What has happened to visual styles in recent builds? In Win7 no themes are applied to controls at all. Manifest missing/broken?

Can you narrow it to a specific rev?

And that is reason enough to not remove possibly better alternatives from ffdshow.

My opinion: Make libav default, if you want, but don't remove libdts/liba52, until the libav devs get their act together.

I don't base my decisions on possibility. You know that argument holds no water.

Just keep the other decoders, it's as simple as that. Or is there any problem of having them inside ffdshow?

Agreed. I also think that the problem should be handled by libavcodec authors, and not patched in ffdshow.

I don't see them as problems, I see them as redundant, since we have fully functional libavcodec decoders. And since they are redundant, there's no need to keep them. That's why I started this: to confirm the robustness of libavcodec in ffdshow, and act in consequence. Or do we remove the libavcodec decoders, since we have liba52, libdts, etc.? I don't think so ;)

And that's exactly the point. "Fix" it in ffmpeg, and all projects using ffmpeg will benefit for it.

About libav bugs: AAC decoder shows wrong bitrate, libfaad2 shows proper bitrate.

Unfixable, for the nth time. ffmpeg's AAC parser is needed for that, and it doesn't work even in LAV Audio. Also it doesn't affect decoding at all.

EDIT: I'll make it output "N/A" instead of 0 though.

[fastplayer]

Can you narrow it to a specific rev?
Oops, I'll take that back. It's just your build that's missing the MANIFEST file. IIRC, your previous test builds missed it, too.

[TheShadowRunner]

Regarding the "FLV4 decoding bug", reimar says it's a ffplay bug, not ffmpeg.. and now I wonder: ffplay = ffdshow?
http://roundup.ffmpeg.org/issue2620

[yesgrey]

I don't see them as problems, I see them as redundant, since we have fully functional libavcodec decoders.
You see them as redundant, but they aren't.

And that's exactly the point. "Fix" it in ffmpeg, and all projects using ffmpeg will benefit for it.
Unfortunately, if I remember correctly, its authors see it like you do, that there is no need to output as 32FP, even though all internal processing is performed using it. They simply round to 16 int.

I will not continue this discussion too. Besides, I'm not one of the devs, so my opinion doesn't really counts. Do what you want, and then I will decide what to use.

[madshi]

I don't base my decisions on possibility. You know that argument holds no water.
Well, I don't know for sure whether liba52 and libdts are true floating point decoders, but I think it's likely, since libav ac3/dts decoders are internally floating point, too. Anyway, you don't seem to have informed yourself properly whether liba52/libdts are better quality or not. So you are not in a good position to decide whether they can be removed.

From what I can see, up until now 4 people have voted against your suggestion to remove liba52/libdts, at least 2 of them being devs, and only 1 person (non-dev) so far seems to support your suggestion. So you should accept that you've been outvoted, at least so far.

That said, I very much appreciate you working on ffdshow. Thank you.

[STaRGaZeR]

Unfortunately, if I remember correctly, its authors see it like you do, that there is no need to output as 32FP, even though all internal processing is performed using it. They simply round to 16 int.

I never said there's no need for 32-bit output. In fact I said that when libavcodec outputs that, ffdshow will too, just like the MP1/2/3 decoder. Just in case you don't remember, it was me who changed it. You're just making things up. And I wonder why.

Well, I don't know for sure whether liba52 and libdts are true floating point decoders, but I think it's likely, since libav ac3/dts decoders are internally floating point, too. Anyway, you don't seem to have informed yourself properly whether liba52/libdts are better quality or not. So you are not in a good position to decide whether they can be removed.

From what I can see, up until now 4 people have voted against your suggestion to remove liba52/libdts, at least 2 of them being devs, and only 1 person (non-dev) so far seems to support your suggestion. So you should accept that you've been outvoted, at least so far.

That said, I very much appreciate you working on ffdshow. Thank you.

So let me get this straight. You, who uses liba52&co. only because it outputs 32-bit float, come here to tell me that I'm not in a good position to decide? You're just confirming what I said. No one here (including you and me) knows how they work internally. Also working in float or integer means nothing by itself to the final audio quality, and that's what matters. You shouldn't give a f*** about what it outputs, just how it sounds. And since the whole debate was started months ago by you and others I still haven't seen a single argument/opinion based on audio quality and not in output resolution, which is lame at best. Here's a hint: talk about audio quality instead of numbers, and then your suggestions will be taken into account. Your (and the others) whole argument comes down to "32 is better than 16", and that won't get you anywhere. EDIT: I just remembered something. Our beloved audio/video freak leeperry talked about it here (http://forum.doom9.org/showthread.php?p=1446603#post1446603). libdts sounds "metallic" compared to libavcodec according to him. Out of curiosity, what are your thoughts on this?

I'm having trouble with that sentence. 4 people: Qak, yesgrey, madshi, Gleb Egorych. You say 2 are devs. I see no devs in there. I see 2 placebo guys I know very well, and 2 guys that don't give any reason for anything, just like with the recent encoder removal. This is not a public poll, just in case you missed it. Also it doesn't matter where an opinion comes from, a dev or an idiot, the content is what matters.

And after I said I didn't want tl;dr posts, I'm finishing one of them for the exact same reason as always. Sigh. I see no reason to continue this conversation unless you provide something to backup your desire of not removing liba52/dts/faad/mad. Output resolution isn't one of them. Put up or shut up, as they say.

[STaRGaZeR]

Please — no need to overrate the troll ^_^

http://img687.imageshack.us/img687/2017/lookslikeanothercoolsto.jpg

Sorry for the OT guys, this is the continuation of a Doom10 thread :D

[JEEB]

Overall agreeing with STaRGaZeR here.

People should care if a decoder follows spec or not decoding-wise, instead of looking at some random int/float output setting. In case of at least AC3 and AAC my opinion is that the libav decoders would be at the very least on the level of the current outside decoder libraries if not better, as both have been worked on during the last year+ (The AAC one at the very least should be better, looking at its added and fixed features, which lead to the removal of libfaad from the ffmpeg supported outside libraries).

The DTS decoder has also been under at least some kind of development, although I haven't taken as deep look at it as with f.ex. AAC.

And if there are bugs, ffmpeg is actually an active project, and looking at how Jumpyshoes as well as elenril got their patches in I'd say it's no longer as impossible as it used to be to get your patches in if they make sense.

Of course, just taking a look at the spec, making sure that the decoder actually fails at it, and taking contact with the current maintainer of the given part of libavcodec is never a bad idea and isn't exactly impossible either, given the fact that even I have posted something on the ffmpeg mailing lists -- and gotten a response.

[madshi]

So let me get this straight. You, who uses liba52&co
Actually no. I do not use liba52. I use libavcodec, patched to floating point output.

come here to tell me that I'm not in a good position to decide?
Exactly. You plan to remove a codec without knowing anything about how it compares quality wise. That's blind behaviour.

No one here (including you and me) knows how they work internally.
Actually I just checked out the liba52 source code and it *DOES* decode to full floating point. So it is definitely better quality than (unpatched) ffmpeg/libavcodec. QED.

Output resolution isn't one of them.
Output resolution was never the problem. The problem is raping the audio data by skipping the required dithering and thus introducing measurable and (with good equipment) audible quantization noise. Which is exactly what (unpatched) libavcodec is doing.

Put up or shut up, as they say.
I just did. Which would have been your job, btw, before making decisions on which decoders you remove.

People should care if a decoder follows spec or not decoding-wise
libavcodec violates fundamental audio processing laws, liba52 does not.

[Qaq]

Personally, I don't really care, I already have what I want. I use bitstream under Win7 and under XP I build a chain like this: ffdshow decoder (32fp) > ffdshow output (32fp) > ReClock processing: resampling (32fp AFAIR), volume attenuation (53fp), final stage rounding (24 padded to 32int) > Kernel Streaming. Do I see any sense in 32fp > 16int > 32fp? No. It's stupid and should be fixed by someone who is in right mind. Too bad we lost albain. He is never used to play a *boss* or something.

[Reimar]

Do I see any sense in 32fp > 16int > 32fp? No. It's stupid and should be fixed by someone who is in right mind.

Yes it is. Which is why there is unlikely to be resistance to it on principle in FFmpeg. However if someone just rips out the conversion it's likely to be not very welcome. The 32fp -> 16int conversion is very often needed (most sound cards do not support anything else) and on older or at least some ARM systems it can be _very_ slow, doing it in the decoder allows some tricks to make it faster.
As long as any advanced processing is still in 32fp, this conversion costs rather little in quality, and in performance only on systems that can easily afford it. If it's an either-or decision the performance advantage on systems that need it is what makes the current solution win.
That said, I do not think it would be that had to make libavcodec support both, it just needs someone who considers it worth the effort to do it.

[madshi]

A couple of years ago I tried getting patches in to allow floating point output via #define. But my patches were declined with the argument that the audio pipeline would "soon" be rewritten, anyway. Well, maybe I should try again now... :)

What did happen to albain, btw?

[Qaq]

The 32fp -> 16int conversion is very often needed (most sound cards do not support anything else)
Yes, but at final stage, right? That's the point.
.. and on older or at least some ARM systems it can be _very_ slow, doing it in the decoder allows some tricks to make it faster.
Yes, but user can use some old software for older systems, right? User should has a choice - that's the point. And now situation comes to that users with older systems will be using new (16int) software and users with newer systems will be using old (32fp) software. Good choice, yeah. I can't call it progress.
As long as any advanced processing is still in 32fp, this conversion costs rather little in quality, and in performance only on systems that can easily afford it.
Imagine how many parts of whole audio chain have their *little compromises*. Isn't it the reason of that crap at final stage?

[clsid]

liba52/libdts/libfaad will only be removed once libavcodec becomes superior. That includes having 32fp support.

@madshi,
Can you send me your ffmpeg patches for 32fp ac3/dts (and possibly other formats)?

[madshi]

Thanks, clsid.

You can find the patches I'm using in the "eac3to\legal stuff\ffmpeg\compiling" folder. You should probably ignore the mlp patches. Important are mainly the dca and ac3dec patches.

[yesgrey]

I never said there's no need for 32-bit output. In fact I said that when libavcodec outputs that, ffdshow will too, just like the MP1/2/3 decoder. Just in case you don't remember, it was me who changed it. You're just making things up. And I wonder why.
If you also agree that it might be useful outputting with the same bit depth used on internal processing, why insisting in removing the other decoders? It was you, not me, who said they were redundant, and I only consider something to be redundant when there is another one which does exactly the same, and that's not what's happening.
Sorry if put words on you that weren't exact. I have no hidden agenda, just gave my opinion.

Well, maybe I should try again now...
Please do. Maybe you have better luck now. ;)

[JEEB]

A couple of years ago I tried getting patches in to allow floating point output via #define. But my patches were declined with the argument that the audio pipeline would "soon" be rewritten, anyway. Well, maybe I should try again now... :)
Please do, the ffmpeg process was streamlined and I'd bet they'd be more realistic about their current progress on many accounts.

Also, personally I would feel that run-time code path selection would be the better alternative than #defining stuff in the source files before building... Although I guess that would add some "unneeded" fluff into the whole thing.

Also, ever since I saw this audiophile herp derp on these threads I've been thinking, don't the specifications for audio decoders specify what is right and what is wrong to do with an encoded audio stream? Or am I one of those happy fellows who has gotten used to standards like H.264 that standardize the decoder to be bit-exact? All this "You should have X instead of Y to have better output" stuff just doesn't make muchos sense, coming from such a background.

And if it's something like dithering post-decoding, I don't really get why it can't be decoded with int to get the exact output that was meant to be gotten (given if the specification specifies this -- and I would guess it actually might specify it given the fact that float math's results depend highly on the system/architecture etc.), and then converted to float with dithering for output/filtering/whatever your cat wants to do to it.

But maybe lossy audio codecs just make less sense than I thought.

[SamuriHL]

What did happen to albain, btw?

That's a damn good question. :(

[madshi]

Please do, the ffmpeg process was streamlined and I'd bet they'd be more realistic about their current progress on many accounts.
Ok, will put that on my to do list.

Also, ever since I saw this audiophile herp derp on these threads I've been thinking, don't the specifications for audio decoders specify what is right and what is wrong to do with an encoded audio stream? Or am I one of those happy fellows who has gotten used to standards like H.264 that standardize the decoder to be bit-exact? All this "You should have X instead of Y to have better output" stuff just doesn't make muchos sense, coming from such a background.
Video codecs work *very* differently compared to lossy audio codecs. Video codecs use motion estimation to try to minimize the difference between video frames and then store the motion vectors together with changed pixels (well, very much simplified). Lossy audio compression is worlds away from that in technical implementation. There's no such thing as "motion estimation" for audio compression.

Audio decoders are standardized in a way, too. However, what you need to be aware of is that standards only tell us how to decode video and audio. They don't tell us how to do post processing. E.g. does the h264 standard tell you how to upsample chroma from 4:2:0 to 4:4:4? No, it doesn't, that's outside of the decoder, it's a post process. Does the h264 standard tell you how to downconvert 8bit per component video to 7bit per component video? Nope, it doesn't, because that's got nothing to do with encoding/decoding. The same thing applies to audio: How you post process the audio got nothing to do with decoding. So it's not specified in the codec specs. You can downconvert 24bit audio to 4bit, if you like. You shouldn't do that, but you can. So do you expect the decoder specs to contain information on how to downconvert 24bit audio to 4bit?

And if it's something like dithering post-decoding, I don't really get why it can't be decoded with int to get the exact output that was meant to be gotten (given if the specification specifies this -- and I would guess it actually might specify it given the fact that float math's results depend highly on the system/architecture etc.), and then converted to float with dithering for output/filtering/whatever your cat wants to do to it.

But maybe lossy audio codecs just make less sense than I thought.
AC3 and DTS do not compress in time domain. They do not compress PCM audio. They convert PCM to frequency domain, IIRC, and then compress the data in the frequency domain. When decompressing, the frequency data needs to be converted back to PCM, which usually results in floating point data. If you look at the AC3 and DTS decoder source code, you'll notice that it natively decodes to floating point data.

So the final question is: *After* the decoders have completed their task, what further processing is done to the decoded audio data? libavcodec and liba52/libdts do not differ so much in how they decode. They differ on how they post process. libavcodec violates processing laws by forcedly rounding down to 16bit integer. liba52 doesn't do that, it outputs the decoding result untouched. So the problem with libavcodec is not the decoding itself, it's the post processing, which can't be turned off. Not even via compiler switches or #defines.

[JEEB]

...So the problem with libavcodec is not the decoding itself, it's the post processing, which can't be turned off. Not even via compiler switches or #defines.
Finally, the first person to actually make sense for me in this. So the problem really isn't in the decoding itself, but, as I was already kind of thinking, the output a post processor gives. Thank you for making this clear for me, as the multiple levels of audio hipsters have made this problem look like an actual decoder problem, which of course makes me go wee on the "How much does this make sense" scale.

+1 reason for ffmpeg not to reject a patch that lets it handle more than one type of output. Or something that would just let the calling application get the decoded output and do whatever it wants to the output, so the next generation of audio hipsters can get their float64 or float128 instead without concerning the ffmpeg project itself (*grin*).

[Kovensky]

A couple of years ago I tried getting patches in to allow floating point output via #define.
From AVCodecContext's definition:

/**
* audio sample format
* - encoding: Set by user.
* - decoding: Set by libavcodec.
*/
enum AVSampleFormat sample_fmt; ///< sample format
A better approach for a patch would be to allow the user to set sample_fmt for decoding too. There are several audio functions in the API that deal with int16_t* btw, but that does *not* mean they only return int16_t.

The audio decoding API will soon be changed anyway to return AVFrames instead of the user having to manage buffers.

[madshi]

A better approach for a patch would be to allow the user to set sample_fmt for decoding too.
Yes, that would be nice.

The audio decoding API will soon be changed anyway
Deja vu. I've been told that 3 years ago... :p

[Kovensky]

Deja vu. I've been told that 3 years ago... :p
This time there are actual patches :)

EDIT: and this wouldn't affect or block any possible patches you make for sample format; it's just an user interface change not internal ffmpeg stuff

[madshi]

Well, that sounds good... :)

[ranpha]

libdts at least should not be removed, until libavcodec can decode DTS core in DTS-HD MA track properly. My test MKVs files with DTS-HD MA tracks will not start playing, if I were to use libavcodec to play the core audio track, but with libdts playback works perfectly.

[STaRGaZeR]

If you also agree that it might be useful outputting with the same bit depth used on internal processing, why insisting in removing the other decoders? It was you, not me, who said they were redundant, and I only consider something to be redundant when there is another one which does exactly the same, and that's not what's happening.
Sorry if put words on you that weren't exact. I have no hidden agenda, just gave my opinion.

Because a decoder is a lot more than what it outputs. Accepting this, the decoders are redundant. But it seems that this fact is not acknowledged here. As you can see there's still not a single argument against the removal based on audio quality or features supported, the ultimate goals of an audio decoder.

Since clsid is with the placebo guys, I'm outta this debate. At least I hope that the guy in charge of the patching does it right: by patching AAC, AC3, DTS, Vorbis, WMA and Nellymoser. That's another thing I've noticed, the guys complaining only complain because it affects themselves directly. ffdshow is a lot more than an AC3/DTS decoder for playing your DVDs. I don't remember anyone complaining when tremor (32-bit int output) was removed, leaving only libavcodec (16-bit int). A word exist for this: hipocrisy.

Actually I just checked out the liba52 source code and it *DOES* decode to full floating point. So it is definitely better quality than (unpatched) ffmpeg/libavcodec. QED.

As I said, working in float or integer, by itself, means *NOTHING* to the final audio quality. QED.

And as always, you don't answer the key questions, only what's best for your interests. I will do the same with you from now on.

AC3 and DTS do not compress in time domain. They do not compress PCM audio. They convert PCM to frequency domain, IIRC, and then compress the data in the frequency domain. When decompressing, the frequency data needs to be converted back to PCM, which usually results in floating point data. If you look at the AC3 and DTS decoder source code, you'll notice that it natively decodes to floating point data.

You're wrong. DTS doesn't work in frequency domain. DTS compress in time domain, filtered PCM audio as ADPCM or APCM. For details, see here: http://www.mp3-tech.org/programmer/docs/dts_whitepaper.pdf, pages 5 and 7. You don't seem to have informed yourself properly, and at the same time you like to judge others. I won't comment on that, it's pretty self explanatory.

libdts at least should not be removed, until libavcodec can decode DTS core in DTS-HD MA track properly. My test MKVs files with DTS-HD MA tracks will not start playing, if I were to use libavcodec to play the core audio track, but with libdts playback works perfectly.

I've fixed that in my last build. Search a few pages back for it. And report if it works for you too!

[yesgrey]

At least I hope that the guy in charge of the patching does it right: by patching AAC, AC3, DTS, Vorbis, WMA and Nellymoser.
Agreed.

I don't remember anyone complaining when tremor (32-bit int output) was removed, leaving only libavcodec (16-bit int). A word exist for this: hipocrisy.
There is another word for that (3 words to be exact): "lack of knowledge"

I don't know every single feature of ffdshow. It contains a lot more decoders than I will ever need, so it's natural for me to complain only about the parts that I know.

[madshi]

As you can see there's still not a single argument against the removal based on audio quality
Oh yes, there is, you're just choosing to ignore it.

That's another thing I've noticed, the guys complaining only complain because it affects themselves directly. ffdshow is a lot more than an AC3/DTS decoder for playing your DVDs. I don't remember anyone complaining when tremor (32-bit int output) was removed, leaving only libavcodec (16-bit int). A word exist for this: hipocrisy.
Huh? I can only comment on things I know anything about. I've no clue what "tremor" is, never heard of it.

As I said, working in float or integer, by itself, means *NOTHING* to the final audio quality. QED.
Violating audio processing laws, resulting in measurable addition of quantization noise, does very much mean something to the final audio quality.

You're wrong. DTS doesn't work in frequency domain. DTS compress in time domain, filtered PCM audio as ADPCM or APCM.
Ok, didn't know that. But it doesn't change the fact that the libavcodec DTS decoder natively produces floating point samples. Rounding them to 16bit integer samples introduces quantization noise.

[STaRGaZeR]

Oh yes, there is, you're just choosing to ignore it.

Maybe I'm missing something, but I don't remember you saying anywhere that liba52, libdts, libfaad or libmad sound better than unpatched libavcodec? Can you point me to it? All I read is "32 to 16 sucks, adds shit to the decoded PCM". While this is 100% true, you're comparing patched libavcodec with unpatched libavcodec. And the debate is not there.

Huh? I can only comment on things I know anything about. I've no clue what "tremor" is, never heard of it.

That's the problem, there's a lot of things you don't know about ffdshow and stuff in general, yet you're here pretending to be some kind of I-know-it-all guy. Just to put you in perspective: it was the same situation, nobody objected. tremor sounded like crap compared to libavcodec, despite outputting 32-bit int samples.

Violating audio processing laws, resulting in measurable addition of quantization noise, does very much mean something to the final audio quality.

Aha. Since I'm sure you're not talking out of your a** when you say it does very much mean something to the final audio quality, where's that audio quality comparison between liba52/dts/faad/mad and unpatched libavcodec? Where are the blind tests?

Ok, didn't know that. But it doesn't change the fact that the libavcodec DTS decoder natively produces floating point samples. Rounding them to 16bit integer samples introduces quantization noise.

Read the first quote: the debate is not here.

[madshi]

All I read is "32 to 16 sucks, adds shit to the decoded PCM".
Not really. If libavcodec *dithered* down to 16bit, I would agree with removing liba52 and libdts. The problem is not doing a conversion from 32bit float to 16bit integer. That's fine with me. The problem is that libav is doing the conversion in a bad way.

That's the problem, there's a lot of things you don't know about ffdshow and stuff in general, yet you're here pretending to be some kind of I-know-it-all guy.
I don't "know it all". But I do know some things, one of them is how audio and video data processing should be done. And I know that libav's conversion from 32fp to 16int is done in a bad way, which adds quantization noise.

Aha. Since I'm sure you're not talking out of your a** when you say it does very much mean something to the final audio quality, where's that audio quality comparison between liba52/dts/faad/mad and unpatched libavcodec? Where are the blind tests?
I don't trust in blind tests I haven't faked myself.

I think you're misunderstanding me a bit: I do not explicitly claim that liba52 sounds noticeably better than libavcodec. I don't know that for a fact. *However*, there's a known problem with libavcodec decoding quality, while there is no known problem with liba52 decoding quality. This alone is IMHO a key argument to not remove liba52 until the libavcodec problem is fixed. I don't see any sense in removing a decoder which has no known audio quality problems in favor of another decoder which does have known audio quality problems. And that's basically what I was trying to say from the start.

[fastplayer]

I've fixed the last issue I had with libavcodec and DTS streams. So here's a test build, so you guys can torture it. What to do:

- Test everything, DTS, all variants of DTS-HD (only the DTS core will be decoded obviously), switching, retarded splitters, etc.
- Test only software decoding. No bitstreaming.
- If you're going to report anything, try libdts and confirm you don't have the issue with it before reporting.
- Since someone is going to say it, 16-bit output is not an issue. Decoding failures are.

And if possible, do the same with AC3, AAC, MP1/2/3.

http://www.mediafire.com/?ac6bc5s3wb1st9u
Just a bump in case people missed it. Please test! :)

[clsid]

Here is a test build with fp32 output for libavcodec AC3 and DTS:
http://www.sendspace.com/file/lrjn02

[STaRGaZeR]

Not really. If libavcodec *dithered* down to 16bit, I would agree with removing liba52 and libdts. The problem is not doing a conversion from 32bit float to 16bit integer. That's fine with me. The problem is that libav is doing the conversion in a bad way.

I know that. But we're not talking about ifs. I'll paste you here the question you didn't selectively answer, since you accused me of something I didn't do, and it's also very relevant to this debate:

Maybe I'm missing something, but I don't remember you saying anywhere that liba52, libdts, libfaad or libmad sound better than unpatched libavcodec? Can you point me to it?

Thanks.

I don't "know it all". But I do know some things, one of them is how audio and video data processing should be done. And I know that libav's conversion from 32fp to 16int is done in a bad way, which adds quantization noise.

I know that too. There's no need to repeat it in every post. However, thanks.

I don't trust in blind tests I haven't faked myself.

I think you're misunderstanding me a bit: I do not explicitly claim that liba52 sounds noticeably better than libavcodec. I don't know that for a fact. *However*, there's a known problem with libavcodec decoding quality, while there is no known problem with liba52 decoding quality. This alone is IMHO a key argument to not remove liba52 until the libavcodec problem is fixed. I don't see any sense in removing a decoder which has no known audio quality problems in favor of another decoder which does have known audio quality problems. And that's basically what I was trying to say from the start.

Just in case it wasn't clear enough already, I'll tell you again what I think it's THE flaw in your argument: the bolded part. Nobody here should be thinking about what happens internally in ffdshow, you should only care about the final result. You base your claim in problems you can't hear, in numbers you can't hear. Well, let's rephrase that a bit: in stuff I can't hear. I'm human, I have limitations. A lot of them. I'm asking you to prove me wrong since the very beginning. You're constantly ignoring that simple request, for example when I ask you for blind tests, you talk about faking and all that. Do we trust the numbers, or do we trust our ears? This is not an academic signal processing exercise. Prove me wrong on the field. I know what should be done from the academic point of view, and I'll apply it once it's done in the proper place to do it: the ffmpeg repository. Until then, I'll trust my ears unless someone comes with an audio quality objection (based on his or someone's ears, of course).

And just for the record: the libs removal was in no way inmediate. Time is needed to fix any possible bugs in ffdshow's implementation of libavcodec. You, in the meantime, should try to get the ffmpeg stuff done. That's where you excell, and with the new ffmpeg's direction I see it doable. Go for it.

[STaRGaZeR]

Here is a test build with fp32 output for libavcodec AC3 and DTS:
http://www.sendspace.com/file/lrjn02

Works just fine here.

[pirlouy]

You base your claim in problems you can't hear, in numbers you can't hear. Well, let's rephrase that a bit: in stuff I can't hear. I'm human, I have limitations.

I'm a noob, so you can ignore this, but on Hydrogenaudio forum (that I dislike because too much harsh), they ban you if you base things on what you hear, and not on numbers, graph,etc.

In my case, I don't hear any difference between sources in 16 bits, 24 bits, 44100Hz, 96000Hz etc.

But even if it's boring for you, it's a good thing that there is a discussion. Better now than later.

[Astrophizz]

I'm a noob, so you can ignore this, but on Hydrogenaudio forum (that I dislike because too much harsh), they ban you if you base things on what you hear, and not on numbers, graph,etc.

AFAIK on Hydrogenaudio they actually prefer if you can provide ABX results for your comparisons. That's based on what you hear and not on numbers. But that's for more minute differences than 32 bit downconverted with and without dithering, for which they have an agreed upon stance (the same as madshi's) based on past ABX tests. That's also why they don't like certain people who post here on Doom9 that use company press releases as evidence for superior audio quality and don't provide ABX comparisons for their claims that (eg.) upsampling 44.1 kHz to 96 kHz makes audio sound better.

[Gleb Egorych]

AAC, AC3, DTS, Vorbis, WMA and Nellymoser
E-AC3 as well.
hipocrisy
I guess very few people need Vorbis in ffdshow. In fact only AAC, (E-)AC3 and DTS decoders need to be patched. Everything else either work as it should or simply not used. BTW I don't know who needs 12 (twelve) software deinterlacers (and +1 HW) in ffdshow.

DTS doesn't work in frequency domain. DTS compress in time domain, filtered PCM audio as ADPCM or APCM. For details, see here: http://www.mp3-tech.org/programmer/docs/dts_whitepaper.pdf, pages 5 and 7.
I've read that paper. DTS encoder clearly works in frequency domain. To be exact, it operates in joint time-frequency domain, for every given time-window it decomposes input signal into frequency sub-bands and then works with that decomposition.

Here is a test build with fp32 output for libavcodec AC3 and DTS
Thanks, clsid

[madshi]

Here is a test build with fp32 output for libavcodec AC3 and DTS:
http://www.sendspace.com/file/lrjn02
Wonderful, thanks a bunch!!

I'm asking you to prove me wrong since the very beginning. You're constantly ignoring that simple request, for example when I ask you for blind tests, you talk about faking and all that. Do we trust the numbers, or do we trust our ears? This is not an academic signal processing exercise. Prove me wrong on the field.
I've tried to prove you wrong, you just don't like my way of doing that. You don't seem to like technical/scientific eplxanations. You don't seem to like quotes of well known processing laws and mentioning of measurements. I'm not sure how you expect me to prove you wrong instead. If I did a blind test myself and reported the results here, would you believe my subjective test results? Probably not, why would you. I wouldn't trust your subjective blind test results, either. There is no "prove" by using our ears, unless we do a large scale study by letting hundreds of people vote in a blind test. Do you want to organize such an event? I don't, I have so many more important things to do. Furthermore, even if we did organize such an event, there might still be discussions like "oh, with different audio clips the results might have been different", or "most users probably have too low quality hardware to hear a difference", or "most users don't really know what to listen for" etc etc...

Anyway, this is all moot, if clsid's patch makes it into SVN. Then we can truely get rid of liba52 and libdts!

[yesgrey]

Here is a test build with fp32 output for libavcodec AC3 and DTS
Both AC3 and DTS are working perfectly.

Thanks for adding the patches, and specially for bringing some reasonability and help ending this sterile discussion. :)

[clsid]

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.

[ranpha]

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

Just tested it, the core DTS in DTS-HD MA tracks now works fine.

[fastplayer]

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.
Confirmed. LAVSplitter handles it fine, though.

[Reimar]

+1 reason for ffmpeg not to reject a patch that lets it handle more than one type of output.

They won't. But they will most likely reject a patch that just removes the current method, because only outputting float is worse in some ways than only outputting float (unless you do some additional changes to make sure it is not).
They most likely will reject a lazy-way patch that uses a compile-time define, it will cause compatibility issues (e.g. for Linux systems where all programs use the same binary).
I do not really mean to discuss pro or contra (this has been done beyond the point where it is useful), I just want to make sure that everyone understands very clearly that just because some of you think this is incredibly important the FFmpeg developers will not accept a horribly crappy patch. And there and only there is where the problem lies.
And concerning audio API changes: It actually has changed 2 times already, and only since the second change is float output even supported.
I think a third change is pending that probably should make things work a bit better still, but I didn't really follow it.

[Gleb Egorych]

Changes (3769-3771):
* Updated FFmpeg. Libavcodec AC3/E-AC3/DTS decoders now output floating point data.;
* Float output for libavcodec AAC decoder;
* Float output for libavcodec Vorbis decoder.
Thanks, clsid!

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.
Have this too. Haali 1.11.96.14. libdts is OK.

[fastplayer]

@Devs:
Can you take a look at this and commit if it's OK?
Updated Japanese translation and iss (http://sourceforge.net/tracker/index.php?func=detail&aid=3199504&group_id=173941&atid=867362)

[Andy o]

Hi, I'm having this problem with PGS subs in mkvs. These are straight blu-ray rips. It usually shows with anime, because the characters on-screen are subbed, at the same time that the characters' voices are being subbed too.

http://photos.smugmug.com/photos/1208599178_inGYm-O.jpg

As you can see the subs are cut off. If I switch to MPC-HC's sub renderer, I can only see one or the other.

This is using 32-bit versions of MPC-HC 1.5.1.2959 with EVR-Sync (also happens with madVR), and ffdshow 3768. I have an ATI 5770 on Win 7 64-bit if that matters.

[Sarasa]

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.
Same bug here, no prob with libdts

[STaRGaZeR]

I'm a noob, so you can ignore this, but on Hydrogenaudio forum (that I dislike because too much harsh), they ban you if you base things on what you hear, and not on numbers, graph,etc.

In my case, I don't hear any difference between sources in 16 bits, 24 bits, 44100Hz, 96000Hz etc.

But even if it's boring for you, it's a good thing that there is a discussion. Better now than later.

Since you know how Hydrogenaudio is, you can clearly see that this forum has been progressively becoming like HA for a good number of months already: full of pedantic individuals that only care about themselves. Don't worry, nobody here can hear the difference. It's just placebo and stupidity. Plus, the debate wasn't there to begin with.

E-AC3 as well.

I guess very few people need Vorbis in ffdshow. In fact only AAC, (E-)AC3 and DTS decoders need to be patched. Everything else either work as it should or simply not used. BTW I don't know who needs 12 (twelve) software deinterlacers (and +1 HW) in ffdshow.


I've read that paper. DTS encoder clearly works in frequency domain. To be exact, it operates in joint time-frequency domain, for every given time-window it decomposes input signal into frequency sub-bands and then works with that decomposition.

AC3 and E-AC3 are the same decoder.

You guess wrong. And I already proposed a long time ago to remove some of those deinterlacers, since a lot of them have the same quality/speed ratio. The devs didn't want to do that, and I fully respect that decision.

If you came to that conclusion, you should read the paper again. There's not a single transform to frequency domain in the process. You divide your initial PCM stream in 32 sub-bands by filtering it, and each band is still PCM audio (time domain). Then you compress them differently based on psychoacoustic analyses.

Anyway, this is all moot, if clsid's patch makes it into SVN. Then we can truely get rid of liba52 and libdts!

Yes, it's all moot now that you've achieved what you wanted, kissing some asses here and there and ignoring key questions, as always. Good job doing a half-ass job in ffdshow. Now we have a half-patched ffdshow and nobody willing to do it the right way. It's a pity others can't see the damage you and your kind are doing. Enjoy your 32-bit float output, I guess.

Oh yes, go ahead and remove the libs right now! The bugs are not important, since we have 32-bit output! Banana republic.

[avih]

...
Yes, it's all moot now that you've achieved what you wanted, kissing some asses here and there and ignoring key questions, as always. Good job doing a half-ass job in ffdshow. Now we have a half-patched ffdshow and nobody willing to do it the right way. It's a pity others can't see the damage you and your kind are doing. Enjoy your 32-bit float output, I guess.

Oh yes, go ahead and remove the libs right now! The bugs are not important, since we have 32-bit output! Banana republic.
No need for sarcasm. Make your point, and stop there please.
Consider it a warning.
Thanks.

[TheShadowRunner]

They won't. But they will most likely reject a patch that just removes the current method, because only outputting float is worse in some ways than only outputting float (unless you do some additional changes to make sure it is not).
<snip>
I think a third change is pending that probably should make things work a bit better still, but I didn't really follow it.

Oh Reimar, unrelated but could you elaborate on this?
Regarding the "FLV4 decoding bug", you say it's a ffplay bug, not ffmpeg.. and now I wonder: ffplay = ffdshow?
http://roundup.ffmpeg.org/issue2620
Thanks,

TSR

[arestarh]

Updated Russian translation for ffdshow:
http://www.mediafire.com/?cjrr610n2z2a2r0

[clsid]

And I already proposed a long time ago to remove some of those deinterlacers, since a lot of them have the same quality/speed ratio. The devs didn't want to do that, and I fully respect that decision.I support any effort from anyone that wants to help make ffdshow better and/or cleaner. If there are deinterlacers that can be considered inferior or redundant, then they could be removed. I suggest starting a new topic to discuss the deinterlacers of ffdshow. Then users who play a lot of interlaced material can explain which algorithms they prefer and why. Given enough feedback we can decide if there are any candidates for removal.

Oh yes, go ahead and remove the libs right now! The bugs are not important, since we have 32-bit output! Banana republic.Calm down ;) Nothing will be removed anytime soon, certainly not if there are good reasons (bugs, performance, quality) to prefer any of the external libs over libavcodec.
Instead of getting lost in technical discussions, let just focus on bugs and the actual experiences when using the various decoders. In the end that is what matters to the users.

[BelowSky]

I hope I'm not interrupting something here. But FFDShow can't play (some) Real Cook Audio with a sample rate at 22KHz.
I can play them with FFplay and Real Player Alternative without any problem.

http://samples.mplayerhq.hu/real/AC-cook/Vetenskap_extramaterial_2005-10-31_142936.rm
http://samples.mplayerhq.hu/real/AC-cook/Vetenskap_mosbricka_2005-03-02_105820.rm

[STaRGaZeR]

I support any effort from anyone that wants to help make ffdshow better and/or cleaner.

These patches don't make ffdshow better nor cleaner. They contribute to the mess it already is.

Nothing will be removed anytime soon, certainly not if there are good reasons (bugs, performance, quality) to prefer any of the external libs over libavcodec.
Instead of getting lost in technical discussions, let just focus on bugs and the actual experiences when using the various decoders. In the end that is what matters to the users.

I was focusing on bugs and the actual experiences of users instead of papers and numbers without any kind of meaning since the very beginning. See my initial post. The usual whiners convinced you of something that doesn't benefit ffdshow in any way. If you, the leader of ffdshow, who has the final word on everything, didn't see this simple fact as your words and actions suggest, we're screwed.

[clsid]

The fact that most people won't hear any difference (including myself), doesn't mean the patch is wrong or useless. The FFmpeg developers even want to eventually make their decoders output in the native data format. But they first need to extend the rest of their audio pipeline with more functionality. API changes like that are very slow in FFmpeg. That extra functionality is not needed by ffdshow, so there is no need to wait for that. The used patch is sufficient.

[STaRGaZeR]

After all this BS it seems you got it wrong too, like everyone else. What the patch does is the right thing to do, we all agree on that. The way it does it isn't. Good luck waiting for anything related to ffmpeg now, you're going to need it.

[roytam1]

E-AC3 as well.

I guess very few people need Vorbis in ffdshow. In fact only AAC, (E-)AC3 and DTS decoders need to be patched. Everything else either work as it should or simply not used. BTW I don't know who needs 12 (twelve) software deinterlacers (and +1 HW) in ffdshow.


I've read that paper. DTS encoder clearly works in frequency domain. To be exact, it operates in joint time-frequency domain, for every given time-window it decomposes input signal into frequency sub-bands and then works with that decomposition.


Thanks, clsid

the audio part in Google WebM format uses Vorbis.

[madshi]

FWIW, I've tried yesterday to get a patch committed to ffmpeg to enable optional float output to the AC3 and E-AC3 decoders. So far I've not succeeded. However, as a reaction Michael Niedermayer actually suggested to change all native float decoders to always output float instead of int16 *right now*. Unfortunately he's not the leader, anymore, and some other guys seem to prefer to wait (for a sample conversion framework to be implemented/completed) before implementing such a change. Not sure yet how it will play out. But it looks like everyone agrees that ultimately ffmpeg native float decoders (ac3, e-ac3, dts, aac, vorbis, wma, ...) should output float. It's only a matter of time when this gets implemented. If we have good luck, it can happen today. If we have bad luck, the change can be delayed another few months (or years). Anyway, I've tried.

@STaRGaZeR, I don't really understand what problem you have now. The patch clsid implemented seems to work well, it has no theoretical or practical disavantages. It does improve audio quality. Maybe the improvement is not audible to your ears on your hardware but that doesn't mean nobody can hear a difference. Your ear/hardware alone can not be the judge for the rest of the world. Furthermore the patch does what ffmpeg will do in the (hopefully near) future, anyway. And implementing the patch in ffdshow has *ZERO* effect on ffmpeg/libav. Just because ffdshow implemented such a patch does not mean that the "real" fix in ffmpeg/libav will be delayed even one second. So there is no damage done by implementing the patch in ffdshow now.

(Thanks to Reimar for his constructive way of posting in the ffmpeg-devel mailing list.)

[STaRGaZeR]

If ffmpeg outputting float is so inmediate, there should have been no commits to ffdshow. If this is in no way inmediate as almost everything in ffmpeg, putting even more custom stuff/patches/workarounds (call it what you want) in ffdshow that it already has is the number one thing you should not do.

The quality argument wasn't to justify float vs integer, get it already ffs.

[fastplayer]

Instead of reducing the number of /* ffdshow custom code */ comments in the code, we have now added half a dozen of these "things"... IMO the goal should be to stay as close as possible to ffmpeg. If they think that 16-bit int is a reasonable trade-off (http://forum.doom9.org/showthread.php?p=1482627#post1482627) between quality and performance, then I don't see why we should deviate from that position. Most certainly not to please a vocal minority...

[madshi]

IMO the goal should be to stay as close as possible to ffmpeg. If they think that 16-bit int is a reasonable trade-off (http://forum.doom9.org/showthread.php?p=1482627#post1482627) between quality and performance, then I don't see why we should deviate from that position.
They do plan to change to float output as soon as possible. The only reason why they haven't done that yet is that they want to do some other things first, as usual. So the patch clsid added does not deviate from ffmpeg's position, it actually realizes ffmpeg's ultimate goal for how the decoders should behave.

Most certainly not to please a vocal minority...
If you browse through the last few pages you'll find that STaRGaZeR and you seem to be the vocal minority.

Ok, I'm out of this discussion now.

[Wilbert]

@STaRGaZeR, I don't really understand what problem you have now. The patch clsid implemented seems to work well, it has no theoretical or practical disavantages. It does improve audio quality. Maybe the improvement is not audible to your ears on your hardware but that doesn't mean nobody can hear a difference. Your ear/hardware alone can not be the judge for the rest of the world. Furthermore the patch does what ffmpeg will do in the (hopefully near) future, anyway. And implementing the patch in ffdshow has *ZERO* effect on ffmpeg/libav. Just because ffdshow implemented such a patch does not mean that the "real" fix in ffmpeg/libav will be delayed even one second. So there is no damage done by implementing the patch in ffdshow now.
I have been trying to follow the last few pages in this thread. Does that mean we can open our audio as float in AviSynth using ffdshow and process it from there? That would be great.

[yesgrey]

Does that mean we can open our audio as float in AviSynth using ffdshow and process it from there? That would be great.
Yes. Welcome to the "vocal minority". :D

[LigH]

:D

Do you remember why BeSweet was developed?

Besides joining decoder and encoder DLLs, processing the audio in floating-point format for optimal quality was one of those reasons.

This is all just a little bit of history repeating... (http://www.youtube.com/watch?v=a-a5HTLDMWc)

[Wilbert]

@Wilbert, I'm no AviSynth expert, but if you can generally use ffdshow output as AviSnyth input then yet, that should work just fine, and you should get full floating point quality directly from the libav decoders, passed through ffdshow. But I'm wondering: Is there no direct AviSynth audio decoder available based on libav?

Yes, ffmpegsource (http://forum.doom9.org/showthread.php?t=127037) (i forgot about that one). I will ask over there.

[clsid]

Instead of reducing the number of /* ffdshow custom code */ comments in the code, we have now added half a dozen of these "things"... IMO the goal should be to stay as close as possible to ffmpeg. If they think that 16-bit int is a reasonable trade-off (http://forum.doom9.org/showthread.php?p=1482627#post1482627) between quality and performance, then I don't see why we should deviate from that position. Most certainly not to please a vocal minority...I agree that it is the overall goal to reduce the amount of custom code. But in this case it is just a small amount, and mostly just a few extra lines, so its easy to maintain (by me).

[STaRGaZeR]

They do plan to change to float output as soon as possible. The only reason why they haven't done that yet is that they want to do some other things first, as usual. So the patch clsid added does not deviate from ffmpeg's position, it actually realizes ffmpeg's ultimate goal for how the decoders should behave.

Yes, that's why you have been waiting 3 years, and complained loads of times because of that. Like here (http://forum.doom9.org/showthread.php?p=1482634#post1482634) and here (http://forum.doom9.org/showthread.php?p=1482670#post1482670). :stupid:

I agree that it is the overall goal to reduce the amount of custom code. But in this case it is just a small amount, and mostly just a few extra lines, so its easy to maintain (by me).

Have fun managing that custom code. I'm outta this ffdshow comedy.

[mark0077]

Hi guys, when using ffdshow video decoder with mpc-hc, when I right click on the player and choose "Filters" -> "ffdshow Video Decoder" -> I see audio information rather than video information. ie i'm watching a h264 mkv file atm and ffdshow video decoder submenu is showing me ac3 audio information... Is it something thats known about or easy to fix?

[nevcairiel]

Hi guys, when using ffdshow video decoder with mpc-hc, when I right click on the player and choose "Filters" -> "ffdshow Video Decoder" -> I see audio information rather than video information. ie i'm watching a h264 mkv file atm and ffdshow video decoder submenu is showing me ac3 audio information... Is it something thats known about or easy to fix?

I think its intended. I forgot why, but i remember asking ended in me being flamed for some reason.

[avih]

...
The quality argument wasn't to justify float vs integer, get it already ffs.
Calm down, and keep it that way please.

[clsid]

Hi guys, when using ffdshow video decoder with mpc-hc, when I right click on the player and choose "Filters" -> "ffdshow Video Decoder" -> I see audio information rather than video information. ie i'm watching a h264 mkv file atm and ffdshow video decoder submenu is showing me ac3 audio information... Is it something thats known about or easy to fix?That is the stream selection (for the splitter).

It could be a bug in the code that determines what should be shown in that context menu. Its shared code between audio/video decoder.

If it was intentional, I don't remember what the exact rationale was for it. Maybe albain can explain if he is still around.

[fastplayer]

If it was intentional, I don't remember what the exact rationale was for it. Maybe albain can explain if he is still around.
According (http://forum.doom9.org/showthread.php?p=1404103#post1404103) to albain, the missing video track info is a limitation of ffdshow.

[clsid]

That is true. But I wasn't talking about showing video info there, but hiding the audio info (and show it only in the audio decoder).

[TheShadowRunner]

Thanks for build 3771, but I can confirm the FLV4 bug (http://roundup.ffmpeg.org/issue2620) is still there.

[clsid]

The FLV4 issue is not a decoding bug. The video was padded to make it mod16 and needs to be cropped. ffdshow will automatically crop based on info signaled by the splitter, but only if the video render is not Overlay Mixer, which does not support it properly.

[TheShadowRunner]

Thanks for checking it. I tested with VMR9 and EVR, the issue is there with both renderers, meaning ffdshow doesn't crop properly then?
Or is it a splitter bug?
The On2 flv4 directshow decoder is free of this bug but I'd really rather use ffdshow for everything. ^^;

[clsid]

It indeed doesn't work. If I remember correctly it used to work, so you could try some old builds to see where things got broken.

[TheShadowRunner]

I already did, tried up to the oldest ffdshow tryout build available on sourceforge, the bug is there.
It has never worked correctly for me.

[clsid]

It was fixed in 3031/3039. I tested old build 3040 and it is working. Will try newer ones now.

Edit: it was broken again in 3062.
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=3062

Edit: reason is discussed here:
http://forum.doom9.org/showthread.php?p=1312127#post1312127
http://forum.doom9.org/showthread.php?p=1319023#post1319023

A proper fix needs to be made that doesn't break resize/auto-crop.

[TheShadowRunner]

Are you sure? 3040 has the bug here.
Edit: a file (http://www.square-enix.co.jp/music/sem/page/xenogears_orchestra/swf/soundsbgm/pv.flv)showing the bug also on the bottom, maybe useful for testing in the future.

[tal.aloni]

Hi all,
I'm seeing that clsid modified ffmpeg's makefile in rev. 3733,
the following line was added:

$(shell test -d $(@) || mkdir -p $(@))


as a result, I'm getting errors when trying to build ffmpeg using cmd.exe and MinGW (TDM), any help would be appreciated.
('test' is not recognized as an internal or external command)

Thanks,
Tal Aloni

[mark0077]

Hi tal.aloni, clsid

A discussion over on the avs forums has found that ffdshow has been causing crashes when used with avisynth but only since the following ffdshow revision so I assume its this avisynth change that was made in ffdshow. As Set hasn't gotten back to us in a few weeks, I'm wondering what the procedure is for things like this. Should the patch be backed out as according to the guys on the avs forums, it does more harm than good.

Revision 3358 - Directory Listing
Modified Thu Apr 15 08:27:07 2010 UTC (10 months, 1 week ago) by tal_aloni
AviSynth Frame accurate seeking. (patch by SEt and Jeremy Duncan)

http://forum.doom9.org/showthread.php?p=1479990#post1479990

Thanks in advance,
Mark

[oddball]

Hey guys I am trying to use autoloading profiles to playback some problematic videos in episodic fashion. I am only able to create a profile for each episode right now which is not what I want. I need to have 2 profiles. One for episodes 1 and 15-18 and another for the episodes in between. Any ideas if.how I can do it? I can't seem to get it working with wildcards and there is a limits on the number of characters you can use on the filenames using the ; seperator method. Basically it only lets me enter 2 file names which is no good obviously. I don't want to rename the files to shorter names.

[clsid]

Hi all,
I'm seeing that clsid modified ffmpeg's makefile in rev. 3733,
the following line was added:

$(shell test -d $(@) || mkdir -p $(@))


as a result, I'm getting errors when trying to build ffmpeg using cmd.exe and MinGW (TDM), any help would be appreciated.
('test' is not recognized as an internal or external command)

Thanks,
Tal Aloni
I am not having any problems here during building. I also always use the Windows command prompt instead of MSYS.
Perhaps it depends on the version of make.exe? Can anybody else test it as well?

[clsid]

Hi tal.aloni, clsid

A discussion over on the avs forums has found that ffdshow has been causing crashes when used with avisynth but only since the following ffdshow revision so I assume its this avisynth change that was made in ffdshow. As Set hasn't gotten back to us in a few weeks, I'm wondering what the procedure is for things like this. Should the patch be backed out as according to the guys on the avs forums, it does more harm than good.

Revision 3358 - Directory Listing
Modified Thu Apr 15 08:27:07 2010 UTC (10 months, 1 week ago) by tal_aloni
AviSynth Frame accurate seeking. (patch by SEt and Jeremy Duncan)

http://forum.doom9.org/showthread.php?p=1479990#post1479990

Thanks in advance,
Mark
I don't mind if the patch is reverted if none of the Avisynth experts here can come up with a better fix.

[tal.aloni]

I don't mind if the patch is reverted if none of the Avisynth experts here can come up with a better fix.

same here,
I've notified the author of the patch a few days ago, he didn't reply yet. I'll revert it as soon as I'm able to build properly, I'll try updating mingw, I do have an older version.

Tal

[tal.aloni]

Updated to MinGW TDM 4.5.1 with Make 3.82.8,
Now I'm getting this error:

../makefile_c.inc:62: *** missing separator. Stop.


after replacing the spaces in line 62 with a TAB, I'm getting the previous error.
('test' is not recognized as an internal or external command)
any clue? which make version are you using that works?
clsid, are you sure there isn't any test.exe?

Thanks,
Tal

[mark0077]

same here,
I've notified the author of the patch a few days ago, he didn't reply yet. I'll revert it as soon as I'm able to build properly, I'll try updating mingw, I do have an older version.

Tal

Fantastic!! This will make alot of avisynth users HTPCs more stable until the patch can be readded without the crashes.

[nevcairiel]

I've been trying to figure out why ffdshow stops displaying subs after a while when used with LAV Splitter, but i have hit a wall. I was using a MKV with embedded VOB subs, and it did seem like every time there was a period of no subs being displayed (no talking), afterwards ffdshow would stop showing them, while the MPC-HC renderer happily continues. With the Gabest MKV Splitter, it works just fine.

What really puzzles me, however, is this: I used a Tee and a Dump filter and wrote the subtitle output of both the Gabest Splitter and of LAV Splitter into a file, including timestamps, flags and everything, and its perfectly identical. Unless ffdshow somehow has special handling when dealing with the Gabest MKV splitter, i don't know what the hell is going on.

I'll probably enhance the Dump filter somewhat to also write down commands like Flush and NewSegment, but i doubt that those are going over the stream mid-playback.

If anyone of you ffdshow guys has some more indeep knowledge of the subtitle code, i would appreciate any insight in the issue, as its really bugging me right now.

[mark0077]

Guys, I went to play an old space shuttle mpg file I downloaded last year to show someone and found with with ffdshow decoders, I get black / no output. I had to revert back to mpc-hc decoder. I tried with lav splitter and mpc-hc internal one, madVR renderer and evr-cp. If nobody can reproduce I'll try to make a sample if someone is interested in looking.

[ryrynz]

I don't mind if the patch is reverted if none of the Avisynth experts here can come up with a better fix.

Excellent, I posted this problem here 2 months ago.

http://sourceforge.net/tracker/?func=detail&atid=867360&aid=3158065&group_id=173941

It would have been nice to get an update on this sooner as it was easy to reproduce bug and an easy fix, I am looking forward to using new builds that don't crash.

I would like to question the bug submission process as it doesn't appear to be optimal, bugs get submitted, bugs get ignored.

[tal.aloni]

ryrynz, I apologize for that, I was responsible for the changes in rev. 3358, however, you have to realize we're all volunteers and we have other pressing matters in life, I became aware of this issue only last week (when mark0077 PMed me), next time, if possible, it would be best to narrow the bug down to a revision, and notify the developer who committed the changes as well.

mark0077, if it's just a single video and not a mpeg-wide issue, it's likely an issue with the video and not with ffdshow.

[ryrynz]

ryrynz, I apologize for that, I was responsible for the changes in rev. 3358, however, you have to realize we're all volunteers and we have other pressing matters in life, I became aware of this issue only last week (when mark0077 PMed me), next time, if possible, it would be best to narrow the bug down to a revision, and notify the developer who committed the changes as well.

I did narrow down the revision, I thought submitting through that website would have been enough and just waited it out expecting the bug submission process to follow it's course.
This process however seems to me to be somewhat ineffective, relying on the bug submitter to escalate issues rather than an administrator of the bug tracker.
I am aware of the development nature of this project and understand developers time constraints but I believe this is one area where things could certainly be improved.

[dann23]

@tal.aloni
last time I remember that you worked on implementing dxva on ffdshow and there were some improvements to make. do you plan to continue that work or we have to wait to get those improvements?

[tal.aloni]

dann23, while there are indeed several improvements that comes to mind, most of those will only be beneficial to a small subset of users.
for instance, when I tested graphic drivers to find out which supports DXVA hardware alpha blending (for subtiltes), my Radeon 4550 didn't support it at all, and my nVidia geforce 9300 onboard GPU offered very limited support (16 colors only - if I remember correctly), so I saw no point investing time there.

other improvements, like copying the decoded frame back to main memory and performing full post-processing fast enough to handle 24 1080p frames per second, require hardware architecture that can only be found on very recent systems, and those systems can decode H.264 without DXVA assistance.

Is there any specific improvement that you're interested in?
Regards,
Tal

[madshi]

other improvements, like copying the decoded frame back to main memory and performing full post-processing fast enough to handle 24 1080p frames per second, require hardware architecture that can only be found on very recent systems, and those systems can decode H.264 without DXVA assistance.
FWIW, whether copying decoded frames back to main memory is feasible depends mostly on the GPU. It seems that newer nVidia GPUs can do that very quickly. While all ATI and Intel GPUs are extremely slow doing that. I've just created a benchmark program for that and asked madVR users to test it. I've seen nVidia GPUs "download" NV12 1080p textures from GPU to main memory with up to 600fps. In contrast, all ATI and Intel GPU benchmarks are slower than the needed 24fps. The highest ATI result I have is 5fps.

[oddball]

Would it be possible to embed ffpresets and ffApresets in MKV files and have ffdshow autoload the presets from the MKV (Rather than have the file seperate with the same name)? It would make things much neater for me. I have a few encodes that require their own special presets and having a seperate preset file or having it listed under profiles is a bit messier than pulling it directly from an MKV file itself. Can you even embed a preset in an MKV?

[tal.aloni]

madshi! we're not worthy!

very interesting, thanks for the info!

[fastplayer]

@tal.aloni or any other dev:
Can you revert rev3358 and put the AviSynth users out of their misery?

[tal.aloni]

Can you revert rev3358 and put the AviSynth users out of their misery?

soon.

[tal.aloni]

Can you even embed a preset in an MKV?

theoretically yes, however, you have to add support for it for both the muxer (mkvtoolnix for example), and the demuxer (haali media splitter for example), and making ffdshow accept a preset in such a way sounds troublesome.
what's worse, it will benefit only a handful of users, I honestly don't see any reason to dedicate resources to such feature.

[madshi]

madshi! we're not worthy!
:eek:

very interesting, thanks for the info!
FWIW, with NVidia you can do this:

(1) DxvaNv12Surface.LockRect(READ_ONLY);

I've measured up to 500fps with newer GPUs. With ATI you can do this:

(1) StretchRect(DxvaNv12Surface, RgbRenderTargetTexture));
(2) GetRenderTargetData(RgbRenderTargetTexture)

That's quick enough for real time playback. Do not try to do "DxvaNv12Surface.LockRect(READ_ONLY)", you'll not get more than 5fps even with the latest ATI GPUs.

One problem with the suggested ATI solution is that you'll get the video data stretched without dithering (0 = black; 255 = white). So there may be banding artifacts. Also you probably can't influence which transfer matrix is used for the YCbCr -> RGB conversion. You can work around the banding problem by StretchRect-ing to a 10bit or 16bit RGB texture. Then you can stretch that back and dither it down to 8bit manually via CPU. Of course that costs performance (download + CPU).

[dann23]

dann23, while there are indeed several improvements that comes to mind, most of those will only be beneficial to a small subset of users.
for instance, when I tested graphic drivers to find out which supports DXVA hardware alpha blending (for subtiltes), my Radeon 4550 didn't support it at all, and my nVidia geforce 9300 onboard GPU offered very limited support (16 colors only - if I remember correctly), so I saw no point investing time there.

other improvements, like copying the decoded frame back to main memory and performing full post-processing fast enough to handle 24 1080p frames per second, require hardware architecture that can only be found on very recent systems, and those systems can decode H.264 without DXVA assistance.

Is there any specific improvement that you're interested in?
Regards,
Tal

I'm not interedted in something special. Just speed improvement. Last time I remember that you said about some work on improve performance when using subtitles.

[tal.aloni]

Last time I remember that you said about some work on improve performance when using subtitles.

now that you're mentioning it, there is one thing that we do that is not very efficient: we create an entire black frame at the same resolution as the video and then blend the subtitles to it, and then scan this frame pixel by pixel and for each pixel that has been modified we append it to the decoded frame.

it would be better to limit the scan range somehow (MPC-HC does a similar thing with their subtitle rendering), or write a new subtitle filter that is "write only" and can work directly on DXVA decoded surface.
both would improve performance somewhat (not sure how much), but any of them would require a lot of coding.


I'm not interedted in something special. Just speed improvement.

is it so bad when subtitles are on? which CPU?

Regards,
Tal

[tal.aloni]

regarding my build issues, apparently test.exe is part of msys,
and can be found in XhmikosR's MSYS/MinGW package here:
http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=
(thanks XhmikosR!)

however, I believe we should avoid another dependency, and I hope we can make do without test.exe.

[Inspector.Gadget]

Quick note for anybody upgrading to recent builds of ffdshow-tryouts, Haali splitter, and MPC-HC as I did: the culprit in lack of audio or stuttery decoding for MKV files with DTS audio, noticeably using ffdshow's libdts or libavcodec but not the MPC internal DTS decoder, is the 03/03/2011 version of Haali's splitter. Switching to the internal MKV splitter (and thus probably Gabest's external MKV splitter too) provides trouble-free decoding with both ffdshow decoders. It's a shame Haali has a track record of issuing updates that break various important functions of his splitter, but I hope this information will pre-empt some incorrect bug reports directed to ffdshow.

Edit: The above report is not particularly helpful as I was later able to play the previously problematic files even using the latest rev. of Haali's splitter without issue. Please see my immediate next post in this thread.

[dann23]

now that you're mentioning it, there is one thing that we do that is not very efficient: we create an entire black frame at the same resolution as the video and then blend the subtitles to it, and then scan this frame pixel by pixel and for each pixel that has been modified we append it to the decoded frame.

it would be better to limit the scan range somehow (MPC-HC does a similar thing with their subtitle rendering), or write a new subtitle filter that is "write only" and can work directly on DXVA decoded surface.
both would improve performance somewhat (not sure how much), but any of them would require a lot of coding.


is it so bad when subtitles are on? which CPU?

Regards,
Tal

CPU is athlon x2 6400+ :D
But what I tried to achieve is to watch movies using dxva and the cpu to stay at the lowest power state. At this state the cooler stops and it's complete silence :) The video card has a passive cooler so the main problem is the CPU :)
Right now it's almost perfect. The cooler starts from time to time and it's annoying.

[clsid]

Quick note for anybody upgrading to recent builds of ffdshow-tryouts, Haali splitter, and MPC-HC as I did: the culprit in lack of audio or stuttery decoding for MKV files with DTS audio, noticeably using ffdshow's libdts or libavcodec but not the MPC internal DTS decoder, is the 03/03/2011 version of Haali's splitter. Switching to the internal MKV splitter (and thus probably Gabest's external MKV splitter too) provides trouble-free decoding with both ffdshow decoders. It's a shame Haali has a track record of issuing updates that break various important functions of his splitter, but I hope this information will pre-empt some incorrect bug reports directed to ffdshow.So if I understand correctly, the previous version of Haali did not have this problem?

[fastplayer]

I can't reproduce this at all. DTS in MKV plays just fine.

[Inspector.Gadget]

So if I understand correctly, the previous version of Haali did not have this problem?

That's correct as far as my experience. I noticed about a week ago, using then-current 32-bit SVN versions of MPC-HC and ffdshow and the latest Haali splitter, that libavcodec wasn't decoding a 6.1 DTS-ES stream and producing any audible output; switching to libdts fixed this but IIRC broke decoding of normal 5.1 DTS streams. Thereafter, and now using rev. 3721, neither libavcodec nor libdts would decode a DTS-ES stream without major dropped video frames and audio stuttering but the internal MPC-HC decoder would apparently do so without issue. Now, using ffdshow rev 3721 and MPC-HC 1.5.1.2903 with the internal Matroska splitter enabled, I have no trouble. Haali still results in many dropped frames and audio drop-outs; the video stream is vanilla 720p level 4.1 stuff with a peak bitrate below 6mbps. The only change I've made to my system other than minor upgrades (e.g, 30 revisions or less) to MPC-HC and ffdshow is switching to the latest Haali from the previous versions; prior to that change, I had never seen any trouble with either libavcodec or libdts.

Edit: Dear all, please disregard the above as well as my prior report of behavior with DTS. Some hours later I re-opened the previously problematic files using all the same software (ffdshow 3721, MPC-HC 1.5.1.2903, latest Haali's) and didn't run into any problems. Nothing changed on my system in the interim. As I wasn't doing anything I/O or CPU intensive at the time I noticed the issues I can only hope this was a one-off problem. If it recurs in a reproduceable way, I will report it. My apologies for the false alarm.

[fastplayer]

Just a heads up: ffmpeg changed its name to libav.
Here's the "press release":
March 13, 2011

We, as a group of FFmpeg developers, have decided to continue developing FFmpeg under the name Libav. All existing infrastructure will be transferred to the libav.org domain.
Website: http://www.libav.org/
Git: git://git.libav.org/libav.git (see http://libav.org/download.html)
FATE: http://fate.libav.org/
Roundup: https://roundup.libav.org/
Patchwork: http://patches.libav.org/

You can update your git repository using the following command:

git remote set-url origin 'git://git.libav.org/libav'

For now we are still reachable over FFmpeg's mailing lists and irc channels but we will migrate to libav.org counterparts. For a transition period both the website and source might still contain references to FFmpeg. These will disappear over time, except where historically relevant.

Edit: No, they didn't... :rolleyes: See nevcairiel's post below.

[nevcairiel]

Actually, ffmpeg did not change its name. Some of the developers tried to take over ffmpeg, but got pushed back after a few weeks, so now they jump ship and start over with a new name (like they should've done from the start if they're unhappy and cannot reach consensus)

ffmpeg.org is still online, and will remain so.

I wouldn't put much into anything thats going on right now, just wait till it cools down again.

[fastplayer]

The "press release" reads like they're abandoning/replacing ffmpeg.org, at least to me...
Anyway, thanks for the info, nevcairiel! I usually only follow the commit log and not their discussions.

Edit: Looks like we've switched (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?revision=3774&view=revision)sides! :D

[tal.aloni]

changes made in rev. 3358 have now been reverted, I apologize for any inconvenience.

Tal

[mark0077]

Thanks Tal! Much appreciated.

[TheShadowRunner]

Edit: it was broken again in 3062.
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=3062

Edit: reason is discussed here:
http://forum.doom9.org/showthread.php?p=1312127#post1312127
http://forum.doom9.org/showthread.php?p=1319023#post1319023

A proper fix needs to be made that doesn't break resize/auto-crop.

So the bug is confirmed, thank you. Now how can I contact a developer able to fix this resize/auto-crop issue with FLV4, is someone in this thread up to it? (I'm an enduser and have no knowledge on how to do that whatsoever!)

[clsid]

There is nobody you can contact. Best you can do is open a bug report on the bug tracker. Then hope and wait until a volunteer comes to fix it.

[mark0077]

Guys, in the ffdshow video info area, where is the "Movie FPS" stat taken from? madshi kindly informed me that a file (maybe files) that I'm having issues with, are 24.000fps rather than 23.974 which ffdshow reports them as. Apart from visually looking wrong, something funky seems to be going on with these files with evr-cp renderer in mpc-hc showing a very "squiggly" looking green line in its graph rather than a perfectly smooth one which I come to expect. Even playing such files back at 24hz will drive evr-cp's graph mad so I can only assume these files have erratic / uneven timestamps....

Would it be alot of work for ffdshow to show the actual rate of the clip, perhaps calculated by looking at incoming timestamps? It might be very helpful, for me anyways, in debugging issues with frame rates of certain files / frame drops etc.

[ryrynz]

There is nobody you can contact. Best you can do is open a bug report on the bug tracker. Then hope and wait until a volunteer comes to fix it.

Best of luck with that.

BTW Bug 3158065 can now be closed.
Thanks Tal, I'm back to using new builds.

[LigH]

Just a heads up: ffmpeg changed its name to libav.

:eek: I'm getting curious if "ffdshow" will now be renamed too, e.g. to "avdshow" or similar... :rolleyes:

[madshi]

ffmpeg did not change its name at all, so why should ffdshow?

[VFR maniac]

ffdshow tryouts: clsid2 * r3774 /trunk/src/ (24 files in 4 dirs): Updated Libav
ffmpeg didn't change its name, but ffdshow has started to use name of libav.

[madshi]

Well, "libav" was always a synonym for ffmpeg, anyway. Even months/years ago I sometimes wrote "ffmpeg" and sometimes "libav", always meaning the same thing.

[LigH]

It looks like there are more or less two development teams and projects in parallel: The original "ffmpeg" and the forked "libav".

Now if the ffdshow developers decide to use source code from the "libav" project in the future (in favour over the "ffmpeg" sources – where a further development is not as obvious to me, I am not sure if there will be an active and competing team too), I wonder if that will be reflected in its name as well.

But not so much that it would ruin my sleep... we users will sit back and see how the whole issue develops.

[madshi]

Renaming a well known project usually doesn't make sense. E.g. my project "eac3to" has a really weird name. It's named that way because the very first version did nothing but convert E-AC3 to other formats. But now in the latest versions converting E-AC3 to other formats is like 0.1% of the functionality. The name should really be something completely different. But it doesn't make sense to rename it now because everybody knows it under its current name. In the same way it wouldn't make sense to rename ffdshow, because everybody is much too used to the current name.

[clsid]

Renaming is indeed a bad idea and won't happen.

[srv]

Hi All!
Simple question.
AAC encoder is supported in ffdshow ?
Thanks!

[LigH]

@ madshi & clsid:

I totally agree with you. Shouldn't eat clowns for breakfast. ;)
__

@ srv:

ffdshow can decode AAC so that you can hear it. But it does not encode anything else to AAC.

It has an on-the-fly AC3 (Dolby Digital) encoder for Home Cinema receivers connected via S/P-DIF. I don't know any of those who would accept AAC via digital connection.

[srv]

@ srv:

ffdshow can decode AAC so that you can hear it. But it does not encode anything else to AAC.

It has an on-the-fly AC3 (Dolby Digital) encoder for Home Cinema receivers connected via S/P-DIF. I don't know any of those who would accept AAC via digital connection.

I need AAC encoder for http live TS stream (H264\AAC). May be there is AAC patch for ffdshow?

[robpdotcom]

I'm pretty sure foobar will encode AAC.

[LigH]

Using an AAC encoder is not quite as simple as it sounds when you are serious about licensing models. There are hardly any free AAC encoders at all, because the "MPEG Licensing Administration" (brief: MPEG LA) protects AAC by patents. Furthermore, some AAC encoding libraries would probably not match the GPL licensing model, which some ffmpeg related projects try to respect and support (I am not certain about ffdshow specifically, but I guess it belongs there too).

Also I wonder if a DirectShow filter is the best technical solution for on-the-fly recoding of internet streams. I could imagine that stand-alone converters (like ffmpeg / mencoder) would be more convenient.

[nevcairiel]

There is the FAAC encoding library, as well as ffmepgs own encoder, both under (L)GPLv2

[srv]

There is the FAAC encoding library, as well as ffmepgs own encoder, both under (L)GPLv2

Is ffmpeg project include this library?

[srv]

Using an AAC encoder is not quite as simple as it sounds when you are serious about licensing models. There are hardly any free AAC encoders at all, because the "MPEG Licensing Administration" (brief: MPEG LA) protects AAC by patents. Furthermore, some AAC encoding libraries would probably not match the GPL licensing model, which some ffmpeg related projects try to respect and support (I am not certain about ffdshow specifically, but I guess it belongs there too).

Also I wonder if a DirectShow filter is the best technical solution for on-the-fly recoding of internet streams. I could imagine that stand-alone converters (like ffmpeg / mencoder) would be more convenient.

Yes, I need in licence for commercial using H264 and ACC. All project in ass after this news... But I can use H264 for non commercial goals - free.

[Milo.name]

Hi develovers!

Please, add the fourcc of hdv1 as an mpeg format..

[tal.aloni]

Guys, if one of you have access to Microsoft Premier support, I would appreciate if you could PM me.

Thanks,
Tal

[misterdan]

what's the difference between the SVN builds and the Official releases (normally I would think the SVN builds are modified official builds but in this case the thread goes directly to an SVN build and the official build has not been updated over a year)? What's the difference between the 4 different 'SVN builds by ...' ?

[TheShadowRunner]

There is nobody you can contact. Best you can do is open a bug report on the bug tracker. Then hope and wait until a volunteer comes to fix it.

Sure, I filed a bug report (https://sourceforge.net/tracker/?func=detail&aid=3221231&group_id=173941&atid=867360)on the tracker.

[nevcairiel]

What's the difference between the 4 different 'SVN builds by ...' ?

Thats just different people doing builds, they should not be modified from the official sources. SVN Builds just means that they are not "stable" releases, they might not be tested as extensively, but usually work fine.

[LigH]

Different people may use different compilers to build a software. Probably different compiler options too (e.g. regarding CPU optimization). Even if the source code is the same, the resulting binaries may differ in details.

For some projects, they may even differ in features, if one author links more libraries than another. But I believe that may not be the case for ffdshow... No proof.

[misterdan]

so what makes the "SVN builds by clsid" more popular than the "Official releases"? (based on number of downloads)

[LigH]

a) Up-to-date sources (official "stable" beta releases only appear once in a few months). They usually have more features and bugfixes. Sometimes also fresh bugs, though...

b) CPU optimization (the intel compiler often does a better job than others). But obviously due to the more frequent updates, "generic" builds are in favour over "icl10".

c) Trust and habit.

d) It is the file with the latest date, therefore it is offered separately as "Looking for the latest version? Download ...".

Not monitored by SourceForge: Builds at http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/

[clsid]

The last stable is quite old and I propose releasing a new stable.

I would also like to ditch the 'beta x' naming and just use the current version of ffdshow.ax, which is "1.1.revision" now. This will be bumped to 1.2.x after release.

The following tasks need to be performed:
1) Check for regressions for current SVN (r3777) compared to revision r3154 (aka beta7). Anyone know of any regressions?
2) Write changelog. (any volunteers?)
3) Compile build. (I will do that)
4) Update site. (fastplayer usually does that)

[tal.aloni]

one thing I would like to do before releasing a new stable is to add "DXVA video decoder" to the "Select Components" menu in ffdshow's setup,
this way, it could be removed completely on systems where it's not applicable.

(when I install ffdshow for friends / coworkers, I try to make it as simple as possible for them, and removing an irrelevant menu item can reduce confusion)

the next suggestion after that would be to make this component turned off by default, if you want DXVA, you'll have to be savvy enough to enable it.
any objections?

I would also like to ditch the 'beta x' naming and just use the current version of ffdshow.ax
+1

[Gleb Egorych]

Short changelog (if you need it):
Improved HD audio bitstreaming
Added DXVA decoding for MPEG2/H.264/VC-1
Improved multi-treaded H.264 decoder
Improved subtitle renderer, Blu-ray subtitles are supported now
Added VP8 decoder
Removed x264 encoder
Removed libtheora, tremor and mp3lib
Many other fixes and improvements

[dmx512]

Hi.
I am new to this forum.

Please excuse my interruption of your discussion.
I hope you don't mind, but as I like ffdshow I wanted to participate in development of the ffdshow-tryouts.

Especially in the subtitles section, because I have some problems with stereoscopic subtitles. For Text it is working fine, but with PGS it does not. Also something I am trying to do is creating an option for selecting the sources Layout (Top-Bottom or Side-By-Side).

I actually inserted some Radio-Buttons for the layout selection in the config menu (in my local version of course), but I need a little help on finding the correct sections to edit in the files. I edited some things, but I think there must be a more generic way to insert my suggestions.

Best regards

dmx512

[tal.aloni]

Hi Developers,
this patch will make DXVA an optional component,

Note: if DXVA is not selected, it will not be registered at all.
(I made some changes in the code to achieve this, if you are aware of better / cleaner method than the one I used, let me know)

I opted to uncheck DXVA by default.

http://iknowu.dnsalias.com/files/public/ffdshow/DXVA_as_option_v1.patch

Regards,
Tal

[hoborg]

DTS + jitter correction enbaled + EVR custom renderer = stuttering

Hi.
I noticed there is a stuttering in videos with DTS track if custom EVR renderer is in use (like MPC-HC one). If i use simple EVR/VMR9 - no problem.
It can be fixed by disabling jitter correction, but this cause a/v desync on some videos.

Here is a video sample (http://forum.doom9.org/showthread.php?p=1484682#post1484682).

Any ideas?

[tetsuo55]

1) Check for regressions for current SVN (r3777) compared to revision r3154 (aka beta7). Anyone know of any regressions?
I am not aware of any regressions myself. Even if there are regressions a new build can still be released, just with a note in the release notes that such-and-such is broken.

[hoborg]

DTS + jitter correction enbaled + EVR custom renderer = stuttering

Hi.
I noticed there is a stuttering in videos with DTS track if custom EVR renderer is in use (like MPC-HC one). If i use simple EVR/VMR9 - no problem.
It can be fixed by disabling jitter correction, but this cause a/v desync on some videos.

Here is a video sample (http://forum.doom9.org/showthread.php?p=1484682#post1484682).

Any ideas?

Looks like MPA decoder already fix it:

Fix : MpaDecFilter, fix playback glitches in rare cases(on some DTS track);

What about FFDshow audio decoder? :)

[nevcairiel]

Looks like MPA decoder already fix it:

Fix : MpaDecFilter, fix playback glitches in rare cases(on some DTS track);

What bout FFDshow audio decoder? :)

Oi, he stole my fix!

Since ffdshow has an option to disable jitter correction, why not simply tick that? Although i do remember some funny bugs when that was turned off with ac3 decoding...

[hoborg]

Psh he stole my fix!

Since ffdshow has an option to disable jitter correction, why not simply tick that? Although i do remember some funny bugs when that was turned off with ac3 decoding...

Yes.
I think jitter correction should be simply disabled for DTS by default in ffdshow audio decoder.
Disabling it completelly causing A/V desync for some MediaPortal users for example on LiveTV.

[tal.aloni]

AFAIK, Those DTS issues only occurs when encoding is not done properly. (usually older encoder is being used)

[hoborg]

AFAIK, Those DTS issues only occurs when encoding is not done properly. (usually older encoder is being used)

Honestly, i have no idea where is source of this problem.
But i am sure users won't re-encode thier movies, they will use decoder that play it correctly.

[clsid]

Hi.
I am new to this forum.

Please excuse my interruption of your discussion.
I hope you don't mind, but as I like ffdshow I wanted to participate in development of the ffdshow-tryouts.

Especially in the subtitles section, because I have some problems with stereoscopic subtitles. For Text it is working fine, but with PGS it does not. Also something I am trying to do is creating an option for selecting the sources Layout (Top-Bottom or Side-By-Side).

I actually inserted some Radio-Buttons for the layout selection in the config menu (in my local version of course), but I need a little help on finding the correct sections to edit in the files. I edited some things, but I think there must be a more generic way to insert my suggestions.

Best regards

dmx512
We don't have much developer resources available to help with things like this. I suggest you post a patch of your work and explain in detail what kind of problem you have with the code. Then maybe someone can help you.

[ikarad]

The last stable is quite old and I propose releasing a new stable.

I would also like to ditch the 'beta x' naming and just use the current version of ffdshow.ax, which is "1.1.revision" now. This will be bumped to 1.2.x after release.

The following tasks need to be performed:
1) Check for regressions for current SVN (r3777) compared to revision r3154 (aka beta7). Anyone know of any regressions?
2) Write changelog. (any volunteers?)
3) Compile build. (I will do that)
4) Update site. (fastplayer usually does that)
It would be usefull before to release a new stable to correct at least the bugs from to the bug tracker, doesn't it?

If not I don't see the interest to release a new stable version. The beta builds are sufficient.

[clsid]

Hi Developers,
this patch will make DXVA an optional component,

Note: if DXVA is not selected, it will not be registered at all.
(I made some changes in the code to achieve this, if you are aware of better / cleaner method than the one I used, let me know)

I opted to uncheck DXVA by default.

http://iknowu.dnsalias.com/files/public/ffdshow/DXVA_as_option_v1.patch

Regards,
Tal
I am not sure if I like the check for the existence of a reg key to include DXVA. I would prefer checking for a key/value to exclude DXVA. Also use HKLM instead of HKCU.
I suggest: HKLM\SOFTWARE\GNU\ffdshow, value: nodxva (dword)
If value exists and is set to 1, then exclude DXVA, otherwise include DXVA.

[clsid]

It would be usefull before to release a new stable to correct at least the bugs from to the bug tracker, doesn't it?

If not I don't see the interest to release a new stable version. The beta builds are sufficient.
We don't have any developers available to fix those bugs.

What matters is regressions, bugs that didn't exist in the previous 'stable' build. That build is quite old and should be replaced with a newer and better version.

[ikarad]

We don't have any developers available to fix those bugs.

What matters is regressions, bugs that didn't exist in the previous 'stable' build. That build is quite old and should be replaced with a newer and better version.

How many developpers works on ffdshow at this moment?

I am under the impression that no developpers works on ffdshow today.

[clsid]

There are a few people who occasionally do some minor work. We need more developers.

[tal.aloni]

I am not sure if I like the check for the existence of a reg key to include DXVA. I would prefer checking for a key/value to exclude DXVA. Also use HKLM instead of HKCU.

you are totally right, I indeed haven't thought this through. (custom installers, manual registration etc.)
I'll make the suggested modifications.

Edit:
here is the updated patch ( I've used HKLM\Software\GNU\ffshow -> noDxvaDecoder )

http://iknowu.dnsalias.com/files/public/ffdshow/DXVA_as_option_v2.patch

[Bruce Willis]

This is probably discussed before, but despite of searching for hours on google and this forum, I couldn't find an answer. When playing an mkv with idx/sub or idx/sup, the subtitles do show up first, but when there has been no dialog for about 30 seconds, they don't show up anymore.

I have the latest ffdshow and matroska installed.

Is this issue known?

Is there a solution or workaround?

[adam777]

This is probably discussed before, but despite of searching for hours on google and this forum, I couldn't find an answer. When playing an mkv with idx/sub or idx/sup, the subtitles do show up first, but when there has been no dialog for about 30 seconds, they don't show up anymore.

I have the latest ffdshow and matroska installed.

Is this issue known?

Is there a solution or workaround?

I've faced issued with idx/sub and the ffdshow subtitle filter myself, when trying it out about a month ago.
I believe clsid informed me of a known problem with ffdshow and this subtitle format.
You better go with some other subtitle renderer.

[clsid]

Has anyone tried the new ffmpeg-mt support for MPEG-4 and HuffYUV? Some benchmarks would be cool!
Known limitations: interlaced MPEG-4 is not supported.


I have written a preliminary changelog for the next 'stable' build. Previous one was r3154. Comments are welcome.
* Updated FFmpeg/Libav library. Brings many fixes and improvements.
* Added hardware accelerated DXVA decoders for H.264 and VC-1.
* Improved multi-threaded H.264 decoder (ffmpeg-mt).
* Added experimental multi-threading support for Vp3, Theora, HuffYUV, and MPEG-4.
* Removed several encoders. The interface that ffdshow provided for these encoding libraries was unmaintained, outdated, and buggy. The ffdshow development team recommends using the official encoders instead (such as x264VFW and Xvid). Those are always up-to-date, stable, and fully functional.
* Updated application blacklist and whitelist.
* Updated rar library to version 4.0.
* Floating point output for libavcodec MP1/2/3, AC3, E-AC3, DTS, Vorbis, and AAC decoder.
* Removed some obsolete colorspaces from output settings in ffdshow video decoder.
* Adjusted colorspace priority lists.
* "Set interlaced flags in output media type" no longer disables YV12 output.
* High quality YV12/NV12/YUY2 to RGB32 conversion is now enabled by default.
* Improved (performance of) Deband filter. Now also works properly in x64 builds.
* Code cleanup and other minor improvements.
* libavcodec.dll has been renamed to ffmpeg.dll
* Removed mp3lib.
* Improved DXVA support.
* Added partial support for COOK audio.
* Lots of subtitle related fixes and improvements.
* Added support for Bluray subtitles (PGS).
* Add an option for giving embedded subtitles priority over external subtitle files.
* The RAW video decoder now stores its preset settings separately from the regular video decoder.
* Updated libsamplerate to version 0.1.7.
* Some S/PDIF related fixes.
* Added support for bitstreaming DTSHD, TRueHD, and E-AC3.

[Gleb Egorych]

Also ff_tremor.dll and libmplayer.dll were removed.

[fastplayer]

I have written a preliminary changelog for the next 'stable' build. Previous one was r3154. Comments are welcome.
I'll go over it and prepare the homepage and wiki. As soon as it's ready, I'll notify you.

Edit: Pretty much ready. Just need the version number and download link. :)

Is this issue known?
It is. (http://sourceforge.net/tracker/index.php?func=detail&aid=2981790&group_id=173941&atid=867360)

[arestarh]

Hello!
clsid
Can you update Russian translation?
Link in this post:
http://forum.doom9.org/showthread.php?p=1483037#post1483037

[clsid]

If no major new problems are reported for the current SVN builds, then I think a new stable can be released next week.

Updated changelog:
* Updated FFmpeg/Libav library. Brings many fixes and improvements.
* Added hardware accelerated DXVA decoders for H.264 and VC-1.
* Improved multi-threaded H.264 decoder (ffmpeg-mt).
* Added experimental multi-threading support for VP3, Theora, HuffYUV, and MPEG-4.
* Added support for bitstreaming DTSHD, TrueHD, and E-AC3.
* A few S/PDIF related fixes.
* Floating point output for libavcodec MP1/2/3, AC3, E-AC3, DTS, Vorbis, and AAC decoder.
* Removed several encoders. The interface that ffdshow provided for these encoding libraries was unmaintained, outdated, and buggy. The ffdshow development team recommends using the official encoders instead (such as x264VFW and Xvid). Those are always up-to-date, stable, and fully functional.
* Updated application blacklist and whitelist.
* Removed some obsolete colorspaces from output settings in ffdshow video decoder.
* Adjusted colorspace priority lists.
* "Set interlaced flags in output media type" no longer disables YV12 output.
* High quality YV12/NV12/YUY2 to RGB32 conversion is now enabled by default.
* Improved (performance of) Deband filter. Now also works properly in x64 builds.
* Code cleanup and other minor improvements.
* Removed mp3lib.
* Removed tremor.dll.
* libavcodec.dll has been renamed to ffmpeg.dll
* Removed libmplayer.dll since all code it contained was either removed or moved to ffmpeg.dll.
* Added partial support for decoding COOK audio.
* Lots of subtitle related fixes and improvements.
* Added support for Bluray subtitles (PGS).
* Add an option for giving embedded subtitles priority over external subtitle files.
* The RAW video decoder now stores its preset settings separately from the regular video decoder.
* Updated libsamplerate to version 0.1.7.
* Updated rar library to version 4.0.

* The ffdshow development team is looking for enthusiastic C++ developers who would like to help improve ffdshow. Interested? Visit us at the doom9.org forum.
The last line is not really a change, but I think it could be a nice addition to the change log anyway, certainly knowing that most sites will simply copy/paste it. It may bring in some extra help.

[fastplayer]

^Understood.
2 questions:
- Are the 64-bit builds still "experimental" or finally on par with the 32-bit builds?
- Which decoders honor the "number of decoding threads" value (in decoder options)?

Edit: I already updated your 1st draft:
http://ffdshow-tryout.sourceforge.net/changelog2.php
I'll incorporate your 2nd one into it.

[clsid]

64-bit can be considered stable now, certainly after the Deband improvements. I don't think there are any known major issues with it anymore now.

All the ffmpeg-mt decoders mentioned in the changelog, plus the libavcodec MPEG-2 decoder (which uses slice-based MT afaik).

[fastplayer]

64-bit can be considered stable now, certainly after the Deband improvements. I don't think there are any known major issues with it anymore now.
Will we offer a 64-bit build as stable too? For this release, I mean.

All the ffmpeg-mt decoders mentioned in the changelog, plus the libavcodec MPEG-2 decoder (which uses slice-based MT afaik).
How about libavcodec's MPEG-1 decoder? It's still in the FAQ and I wanted to update it. That's why I'm asking. :)

[clsid]

Yes, 64-bit can be provided.

Yes, MPEG-1 also seems to be slice based multi-threaded.

[fastplayer]

Yes, 64-bit can be provided.

Yes, MPEG-1 also seems to be slice based multi-threaded.
OK, I'll add 64-bit as "stable" to the download page.
:thanks:

[Mr VacBob]

MPEG-1 is slice-based, which is not effective on most files, but MPEG-1 decodes so fast that you don't need it. Frame-based was implemented but disabled as it bitrotted somewhat.

MPEG-2 is slice-based. All MPEG-2 files have slices, so frame-based isn't needed (it's actually a bit slower).

[Jeremy Duncan]

This clip: link, (http://www.mediafire.com/?3jvt2k2mu25fydo) was made by petitdragon. It is 23.976fps. in ffdshow avisynth when I type: info() the osd shows the clip as 23.97 fps, using mpc-hc 32 bit build newest build.
Same problem for ntsc mpeg2 when it should read 29.976 the osd shows it as 29.97.

link to discussion about this: link. (http://www.avsforum.com/avs-vb/showthread.php?p=20198982#post20198982) Using convertfps to switch the clip to the real framerate works: ffdshow_source().changefps(23.976) but assumefps does not, because Leak said he forced ffdshow to disable the assumefps avisynth function (use search).

Hirohiko made a patch for this framerate error in revision 1668 I think, but I tried version 1670 clsid and it was still broken. :thanks: :search: :stupid: :helpful:

[setarip_old]

@Jeremy Duncan

Hi! Same problem for ntsc mpeg2 when it should read 29.976 the osd shows it as 29.97 Naah, it should be 29.970 - or 29.97...

[jmone]

I still see (or rather dont :) ) that Interlaced VC-1 produces nil output using libav. Are there any plans for this an in the interum what are people using (eg the std MS DMO decoder?)

[nevcairiel]

If you switch the VC-1 decoder in ffdshow to "wmv9" (i think it was called), it should work. avcodec just does not support interlaced vc-1.

Other people seem to be using either the MS Decoder (considering its their own format, i would figure they do a good job at decoding it), or the Cyberlink/ArcSoft solutions.

[LigH]

same problem for ntsc mpeg2 when it should read 29.976 the osd shows it as 29.97.

24000/1001 = 23.976023~

30000/1001 = 29.970029~

[jmone]

If you switch the VC-1 decoder in ffdshow to "wmv9" (i think it was called), it should work. avcodec just does not support interlaced vc-1.

Other people seem to be using either the MS Decoder (considering its their own format, i would figure they do a good job at decoding it), or the Cyberlink/ArcSoft solutions.

I've tried both the wmv9 and the MS DMO decoder, both are OK but the deinterlacing is pretty ordinary with visable fields (looks like weave to me)

[fastplayer]

@Devs:
I've fixed a few typos in the ffdshow.rc:
http://www.mediafire.com/?bobhnrul2i1fesq
Please review and commit. Thanks!

[tal.aloni]

fastplayer,
reviewed and committed, Thanks!

[tal.aloni]

Hi all,
there was an oddity that I fixed in rev. 3789:
prior to rev. 3789, all subtitles format except substation alpha formats (SSA / ASS / ASS2) could be turned on / off based on preset.
however, I couldn't see an apparent reason for this discrepancy, of course preset info is not available at early loading stage, but it seemed irrelevant to this case.
so in rev. 3789, substation alpha formats can be turned on / off based on preset as well.

if you have such subtitles and you notice any problems with rev. 3789 or later, please let me know.

b.t.w. it appears as if some other settings on this page can also be preset settings, but I'll leave it for now.

[fastplayer]

fastplayer,
reviewed and committed, Thanks!
Thanks! I see you resized the "Search in" radio button which I was about to report :D
There are some issues with colons in the "Resize & aspect" options, specifically "Specify aspect ratio" and "PAR out of device". Both "reach" into another control element. Not a biggie but maybe you can take a look at those.
Anyway, why isn't DXVA installed by default? It should be, IMO.

[tal.aloni]

Why isn't DXVA installed by default? It should be, IMO.
I believe DXVA can confuse many users who are not familiar with the technology, it's advantages and disadvantages (no post-processing, etc.), or don't even know if their hardware even support DXVA.
I think that for the non-savvy, our recommendation should be to skip DXVA usage completely, and only when there is a good reason to use DXVA, learn about it and install it,
at that stage, the user will figure out for himself to select DXVA during installation.


There are some issues with colons in the "Resize & aspect" options, specifically "Specify aspect ratio" and "PAR out of device"
fixed in rev. 3791

[fastplayer]

I think that for the non-savvy, our recommendation should be to skip DXVA usage completely, and only when there is a good reason to use DXVA, learn about it and install it,
at that stage, the user will figure out for himself to select DXVA during installation.
You're right. It requires quite a bit of knowledge to setup properly and deal with its limitations. Then there are out-of-date, buggy drivers...
fixed in rev. 3791
:thanks:

[fastplayer]

Updated German language file:
http://www.mediafire.com/?v10ngh2wi0mb9i3

[tal.aloni]

Updated German language file:
http://www.mediafire.com/?v10ngh2wi0mb9i3

committed as rev. 3794

[V!roX]

Hey, sorry for asking something that is probably really easy, but...

I just installed MPC-HC and ffdshow tryouts, because I wanted to test the superior subtitle rendering compared to VobSub.
But it looks like I can't get it to work: Apparently, my subtitles are rendered by MPC-HC itself. First without effects, and after turning them on in the MPC options, they started flickering.
It doesnt matter if the subtitles filter in the ffdshow tryouts config is activated or not, MPC-HC seems to ignore ffdshow on subtitle rendering.

How can I connect the ffdshow subtitle rendering to MPC-HC so it works without problems?
by the way, I'd prefer if subtitle effects were enabled.

[khagaroth]

Update for Czech translation:
ticket 3250134 (https://sourceforge.net/tracker/?func=detail&aid=3250134&group_id=173941&atid=867362)

[tal.aloni]

Update for Czech translation:
ticket 3250134 (https://sourceforge.net/tracker/?func=detail&aid=3250134&group_id=173941&atid=867362)

done. please submit a TortoiseSVN patch file next time.

[Gleb Egorych]

Is it known problem that ffdshow has problem with interlaced MPEG2 content?

The situation: Win7, EVR, libavcodec or libmpeg2 (doesn't matter), YV12 or NV12 output (doesn't matter), haali or gabest ts splitter (doesn't matter).
The problem: if "Set interlaced flag in output media type" is set to "Auto" then frame rate flows from ~35 to ~50 fps on my interlaced PAL samples, combing is obvious.

If force bob deinterlacing and proper field order then there is no combing and I have proper 49-50 fps.

[hoborg]

Is it known problem that ffdshow has problem with interlaced MPEG2 content?

The situation: Win7, EVR, libavcodec or libmpeg2 (doesn't matter), YV12 or NV12 output (doesn't matter), haali or gabest ts splitter (doesn't matter).
The problem: if "Set interlaced flag in output media type" is set to "Auto" then frame rate flows from ~35 to ~50 fps on my interlaced PAL samples, combing is obvious.

If force bob deinterlacing and proper field order then there is no combing and I have proper 49-50 fps.

I don't have such problems.
I use MPEG profile for output to NV12 becouse of HW deinterlacing and using it for DVB-t LiveTV.

FFDshow 3775, MSVS 2010 (x86)

[clsid]

I have found a regression related to the recent cleanup of the Output page in ffdshow video decoder. It has broken thumbnailing by Windows Explorer. I have narrowed it down to the setting "Allow output format changes during playback" (which has been removed). Thumbnailing works when that old setting is in indeterminate state, but not when fully checked.

@stargazer69
Can you have a look at this issue?

Here is a reg tweak to enable thumbnailing if needed:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.flv\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}]
@="{c5a40261-cd64-4ccf-84cb-c394da41d590}"

Edit: should be fixed in r3800

[Chikuzen]

Hi, devs.
Why did you change Japanese transration ?
r3796 changed some correct transration to wrong.

Please revert r3796, and return them to Yamagata's.

[Ger]

Is it known problem that ffdshow has problem with interlaced MPEG2 content?

The situation: Win7, EVR, libavcodec or libmpeg2 (doesn't matter), YV12 or NV12 output (doesn't matter), haali or gabest ts splitter (doesn't matter).
The problem: if "Set interlaced flag in output media type" is set to "Auto" then frame rate flows from ~35 to ~50 fps on my interlaced PAL samples, combing is obvious.

If force bob deinterlacing and proper field order then there is no combing and I have proper 49-50 fps.

I have the same problem. I always assumed this was due to badly flagged MPEG-2 streams (DVB sourced in my case). IIRC the Microsoft decoder shows the same combing as ffdshow in Auto/Auto mode.

One problem with the current flagging algo (MatMaul's code IIRC) is that if force bob is used and field order can't be detected the auto field order falls back to bottom field first even for PAL content. Since PAL is nearly always top field first it should fall back to TFF for PAL IMHO. The optimal solution would be to improve the auto field order detection and auto flagging in general, but I don't even know if that's possible. TVs and STBs don't have these combing/field order issues though.

The (automatic and not configurable) implementation in MPC-HC's libmpeg2 based MPEG-2 decoder works better for me (with JanWillem32's test build it outputs NV12 with the "set interlaced flag..." option cheked). I see no combing with that decoder with my problem sample (http://www.multiupload.com/R3C27RMK54), but it has other weaknesses compared to ffdshow, less configurable, no support for 4:2:2 sources and needs FTC to be on in MPC-HC + EVR-CP with some other samples.

[ilkertezcan]

My question to developers: There isn't Picture properties on FFDshow DxVA...
Is impossible change to gamma/brightness etc. settings of the video when actived DxVA mode?

[Gleb Egorych]

I always assumed this was due to badly flagged MPEG-2 streams (DVB sourced in my case)
Tested on DVB material too.

IIRC the Microsoft decoder shows the same combing as ffdshow in Auto/Auto mode.
Exactly.

[tal.aloni]

Hi, devs.
Why did you change Japanese transration ?
r3976 changed some correct transration to wrong.

Please revert r3796, and return them to Yamagata's.
I've contacted tnetsixenon, which supplied me with the patch.

@developers
apparently there is no constant order to the translation files,
and some people have the tendency to reorder those,
maybe we should force some order to those files?
(alphabetically or based on dialog pages are the two that comes to mind)

Regards,
Tal

[Tom Keller]

Any ideas, why this kind of wmv3 videos:

http://www.megaupload.com/?d=4UQ8SHDP

... plays all blocky/green with ffdshows DirectShow-Decoder inside MPC-HC or other DirectShow-Players, while playing perfectly fine inside VirtualDub with WMV-Plugin (using ffdshows VfW decoder) and looking fine too inside Microsofts old Media Player 6.4 (using ffdshows DirectShow decoder). It's confusing! I assume: ffdshow seems to be the source of the problem but only in combination with Microsofts qasf.dll (v11.0.5721.5145) - and since VirtualDubs WMV-Plugin didn't use it, and the old WMP6 uses the old wmpasf.dll, both work fine. Could someone confirm that?

[Midzuki]

Any ideas, why this kind of wmv3 videos:

http://www.megaupload.com/?d=4UQ8SHDP

... plays all blocky/green with ffdshows DirectShow-Decoder inside MPC-HC or other DirectShow-Players, while playing perfectly fine inside VirtualDub with WMV-Plugin (using ffdshows VfW decoder) and looking fine too inside Microsofts old Media Player 6.4 (using ffdshows DirectShow decoder). It's confusing! I assume: ffdshow seems to be the source of the problem but only in combination with Microsofts qasf.dll (v11.0.5721.5145) - and since VirtualDubs WMV-Plugin didn't use it, and the old WMP6 uses the old wmpasf.dll, both work fine. Could someone confirm that?

I have not looked at your sample videos yet :o , BUT
I suppose the problem is related to hardware acceleration,
please take a look at this thread:

http://forum.doom9.org/showthread.php?t=146346&page=2

[Tom Keller]

No... i don't think so ;) . The Microsoft DMO decoder works pretty well with the file (MPC-HCs internal decoder too) - only the ffdshow decoder won't. And since i did not use hardware accelerated VC-1 decoding and most of the "problem videos" are progressive, it's obviously neither hardware acceleration nor interlacing related...

[space1999]

No... i don't think so ;) . The Microsoft DMO decoder works pretty well with the file (MPC-HCs internal decoder too) - only the ffdshow decoder won't.

OK, I will take the time to download the samples and will "study the case". :)

And since i did not use hardware accelerated VC-1 decoding

Hardware-based video acceleration is not the same as hardware-based video decoding.

[Tom Keller]

I know - but i thought, hw based decoding via DXVA was one of the topics in the named thread (sorry... just skimmed through it... mea culpa :o )...


Just to show, what i mean...

Microsoft DMO Decoder with WM ASF Reader (qasf.dll) => no problems:
http://justpic.info/images2/f647/DMO.jpg

MPC Video Decoder with WM ASF Reader (qasf.dll) => no problems:
http://justpic.info/images2/3750/mpc_dec.jpg

ffdshow Video Decoder (libavcodec) with WM ASF Reader (qasf.dll) => grey screen; keyframes and occasional makroblocks popping through:
http://justpic.info/images2/30cd/ffdshow_libav.jpg

ffdshow Video Decoder (wmv9) with WM ASF Reader (qasf.dll) => green screen; only keyframes popping through:
http://justpic.info/images2/8378/ffdshow_wmv9.jpg

ffdshow Video Decoder (libavcodec/wmv9) with Windows Media source filter (wmpasf.dll) => no problems:
http://justpic.info/images2/4281/ffdshow_wmv_source.jpg

ffdshow Video Decoder (libavcodec/wmv9) with ArcSoft ASF Splitter (ASFSplitter.ax) => no problems:
http://justpic.info/images2/7379/arcsoft.JPG

Oh... and the problem is the same with AviSynth & DirectShowSource - since (in this case) the decoder delivers its uncompressed output directly to AviSynth, neither hardware accelerated video rendering nor video decoding is used. So i assume: it simply HAS to be the fault of the decoder.

Like i said: ffdshow in combination with qasf.dll seems to be the source of the problem. Since both, the DMO decoder and the MPC video decoder, work fine, ffdshow seems to have some problems in handling this kind of video stream delivered by the qasf.dll...

[cmbe]

Hi,

The ffdshow audio codec bitstreaming the dts core of a dts-hd track over spdif, isn't working in the latest releases (from almost a year by now).

This works ok with the old ffdshow beta 7.

Anyone knows if the support for this feature have been dropped?

thanks

[clsid]

apparently there is no constant order to the translation files,
and some people have the tendency to reorder those,
maybe we should force some order to those files?
(alphabetically or based on dialog pages are the two that comes to mind)It may be quite a lot of work, but if you want to do it, it would be great.

I would suggest sorting the dialog pages based on their numerical value, from low to high. Sort the contents of each page alphabetically.

An English template with all translatable strings would be useful as well. That would allow quicker translations compared to using the internal translation functionality. It would also allow seeing what is missing in other translations by using a text compare program (like ultracompare).

[clsid]

Hi,

The ffdshow audio codec bitstreaming the dts core of a dts-hd track over spdif, isn't working in the latest releases (from almost a year by now).

This works ok with the old ffdshow beta 7.

Anyone knows if the support for this feature have been dropped?

thanks
I don't have the hardware to confirm. Maybe anyone else here can confirm whether it works or not.

You may need to adjust the compatibility settings on the Output page, like the "connect as pcm first" setting.

[khagaroth]

It may be quite a lot of work, but if you want to do it, it would be great.

I would suggest sorting the dialog pages based on their numerical value, from low to high. Sort the contents of each page alphabetically.

An English template with all translatable strings would be useful as well. That would allow quicker translations compared to using the internal translation functionality. It would also allow seeing what is missing in other translations by using a text compare program (like ultracompare).
Yes, a template is badly needed. But I wonder how that would be created. A switch to gettext based translations would be even better.
The internal translation system works pretty similar to gettext, all the strings are marked by a keyword - _l - and are processed by a translation function. There is a catch though, the keyword is used even for strings that shouldn't be translated (so no easy migration to gettext unfortunately). Another problem with the internal translation system are the limitations of the translation file 'ini' format - one example is the inability to translate strings that contain '=' (there are a few there). And don't get me even started about the translation mode annoyances/limitations.

[cmbe]

I don't have the hardware to confirm. Maybe anyone else here can confirm whether it works or not.

You may need to adjust the compatibility settings on the Output page, like the "connect as pcm first" setting.

Thanks for your help clsid.

Nope, it won't work! no matter what settings I have.

It works perfectly with beta 7.

[tal.aloni]

Maybe anyone else here can confirm whether it works or not.

I have the hardware and will test within the next few days.

[Gew]

I feel obligated posting this here as well, since I'm not sure that any of the developers has actually read the thread I wrote ~10 months ago at SrcFrg/ffdshow board (http://sourceforge.net/projects/ffdshow-tryout/forums/forum/597593/topic/3784486).

Like this. Old builds of ffdshow are fabulous. Here, I pick an .IDX (VobSub) file from the right click menu in the system tray, you know, the ffdshow applet. Then, after choosing your .IDX VobSub file, you get to chose the desired language in the same menu; all languages found/available are shown in a list below.

This excellent feature was some how dropped(!) almost a year ago. Now it just defaults on the languages chosen in the preferred section of ffdshow configuration, which makes actual "quick change" much more a pain. Why this change? It's really only downside to it, AFAICS.

[cmbe]

I have the hardware and will test within the next few days.

:thanks:for your help.

[tal.aloni]

The ffdshow audio codec bitstreaming the dts core of a dts-hd track over spdif, isn't working in the latest releases (from almost a year by now).

EDIT:
I've nailed it down to a change in rev. 3160,
when detecting that the stream is DTS-HD, we had erroneously set the sample rate to 96000 instead of 48000 (DTS over SPDIF requires 48000),
fixed for rev. 3802, thanks for reporting.

Regards,
Tal

[hoborg]

EDIT:
I've nailed it down to a change in rev. 3160,
when detecting that the stream is DTS-HD, we had erroneously set the sample rate to 96000 instead of 48000 (DTS over SPDIF requires 48000),
fixed for rev. 3802, thanks for reporting.

Regards,
Tal

:thanks:

[cmbe]

EDIT:
I've nailed it down to a change in rev. 3160,
when detecting that the stream is DTS-HD, we had erroneously set the sample rate to 96000 instead of 48000 (DTS over SPDIF requires 48000),
fixed for rev. 3802, thanks for reporting.

Regards,
Tal

:thanks::thanks::thanks::thanks::thanks:

[madshi]

@developers, Michael Niedermayer (ffmpeg) is currently preparing for a new official ffmpeg release. He's merged some of the ffdshow changes into the ffmpeg tree. He's asking if there's anything missing that we'd like to have committed to ffmpeg. Here's your chance to checkout the latest ffmpeg sources, double check it with the ffdshow ffmpeg patches and try to get as many internal patches committed to official ffmpeg as possible.

[clsid]

I noticed that as well :)

I don't think we have any custom code left that is suitable for committing upstream. They are mostly are ffdshow specific tweaks/hacks.

[madshi]

Ok, that's fine.

BTW, he's also ffmpeg_mt fully merged in now. Do you plan to make use of it in a future ffdshow version? As far as I understand, in order to activate it you need to ask for SLICE based multi threading.

[nevcairiel]

ffdshow already uses ffmpeg-mt, but until now they used to ship two copys of ffmpeg, one "normal" and one build of the ffmpeg-mt fork. That can be disabled now, and possibly an option added instead if multithreading is supposed to be used.

[madshi]

Makes sense.

[Jeremy Duncan]

This clip: link, (http://www.mediafire.com/?3jvt2k2mu25fydo) was made by petitdragon. It is 23.976fps. in ffdshow avisynth when I type: info() the osd shows the clip as 23.97 fps, using mpc-hc 32 bit build newest build.



Could somebody dl the clip, it's not mpeg2 it's vc1 I think, or mkv. Run the code: info() in megui and then in ffdshow avisynth tab to see the frame rate info the osd shows is not the same?

[clsid]

Most -mt stuff has also been merged in Libav, but not yet the H.264 decoder because there are a few issues they want to fix first. Ronald and Alexander are working on that afaik.

@madshi
One thing Michael forgot is to add a configure option for the float stuff. Maybe he can also SIMDify the interleaving function that was added. The noscale one used by AC3 can maybe be dropped if scaling is adjusted (currently *1.0f). Dunno if that matters for quality, you know more about it.

[nevcairiel]

One thing Michael forgot is to add a configure option for the float stuff.
He didn't forget, he commented on the mailing list that its lacking configure support, so he knows.

Overall the patch he merged seems to be pretty low-quality in ffmpeg standards. I should do a patch to clean it up.

For the scaling thing, the noscale version could be dropped completly if you just don't touch the scale value in ac3dec at all.
The float-to-int conversion expects all values in the range of 32767 to -32768, so converting those to float 1.0 to -1.0 could always be done in that function, and you don't need to have different scale values based on the configure option.

Unless someone beats me to it, i will create a patch that adds the option to the configure script later.

[madshi]

Overall the patch he merged seems to be pretty low-quality in ffmpeg standards. I should do a patch to clean it up.
That would be welcome - thanks!

[Reimar]

Unless someone beats me to it, i will create a patch that adds the option to the configure script later.

I don't know if/when I will have time, but I actually intended to change it to make it possible to select at runtime.
I just can't imagine that that should be hard to do, and it would be a lot more useful than just a configure option.

[madshi]

I don't know if/when I will have time, but I actually intended to change it to make it possible to select at runtime.
I just can't imagine that that should be hard to do, and it would be a lot more useful than just a configure option.
That would be even better. BTW, if you look a bit through the older posts, a couple of days/weeks ago Justin already proposed a fully featured patch to allow runtime selection for AC3 decoding. The patch looked good to me, it just was never reviewed/applied, as far as I could see.

[nevcairiel]

Of course runtime would be preferable, no question.

[betaking]

last ffdshow_rev3807_20110404_xhmikosr_MSVC2010.exe can not decoder some media files use audio codec by use libavodec!I use last mpc-hc svn 3011 and use mpc-hc Internal splitter,but use ffdshow_rev3803_20110402_xvidvideo-ru_x86-MSVC2010.exe play is fine!
I have up use 3803 working and 3807 not woking screen Capture!
http://www.mediafire.com/?5d1z6jqn6oqwjbt

[clsid]

I will look into the crash later today. It would save me some time if someone would pinpoint the exact revision, but there probably aren't any public builds in between.

Are only libavcodec AC3/DTS affected? Please let me know if others are broken as well.

[betaking]

I will look into the crash later today. It would save me some time if someone would pinpoint the exact revision, but there probably aren't any public builds in between.

Are only libavcodec AC3/DTS affected? Please let me know if others are broken as well.

test some ffdshow audiodecoder ! you can see my up screen Capture! iadpcm amr
msadpcm otherAdpcm qdm2 vorbis not work! lpcm truehd aac mlp mp2 eac3 flac not test! but i think maybe this not work too!

[clsid]

Found the cause. Fixing it now.

[betaking]

Found the cause. Fixing it now.

:thanks:
test ffdshow_rev3808_20110405_xhmikosr_MSVC2010.exe all is ok!

[Tom Keller]

Any news on this problem(?):

http://forum.doom9.org/showthread.php?p=1488274#post1488274

[Midzuki]

@ Tom Keller:

"For the time being" :devil: , I confirm the problem does seem to be in ffdshow itself. However, perhaps the "releaser" :p of that clip should be blamed as well:

Video
ID : 2
Format : VC-1
Format profile : MP@HL
Codec ID : WMV3
Codec ID/Info : Windows Media Video 9
Codec ID/Hint : WMV3
Description of the codec : Windows Media Video 9
Duration : 7mn 45s
Bit rate mode : Variable
Bit rate : 1 378 Kbps
Width : 768 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Resolution : 24 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.125
Stream size : 76.5 MiB (89%)
Language : English (GB)


AFAIK, the MP@HL "Conformance Template" should be used only for WMV-HD resolutions (height = 720 or 1080). Until now, the only non-HD WMV3 files which ffdshow has had problems with are the ones encoded @ non-compliant width or height (nothing that a quick resizing cannot workaround, though).

P.S.: Next time, please try to upload a smaller sample --- just 1 minute of video is sufficient in most cases. ;)

[Tom Keller]

Well... to be honest: i didn't create or upload this clip ;) . It simply was a link already posted in this very thread (a couple of hundred pages before) from someone with the same problem on older ffdshow revisions. And since my uploading speed is fairly low, i did use this already uploaded clip...

But since i have some non-HD main profile (MP@ML) clips with the same problem... is it safe to assume: this "template-misuse" for SD resolutions has nothing to do with ffdshows misbehavior!?

[Midzuki]

Well... to be honest: i didn't create or upload this clip ;) . It simply was a link already posted in this very thread (a couple of hundred pages before) from someone with the same problem on older ffdshow revisions. And since my uploading speed is fairly low, i did use this already uploaded clip...

Thanks for the information,
probably you meant this post by Inventive Software:

http://forum.doom9.org/showthread.php?p=1332474#post1332474

But since i have some non-HD main profile (MP@ML) clips with the same problem...

is it safe to assume: this "template-misuse" for SD resolutions has nothing to do with ffdshows misbehavior!?

Yes and no. :) I grave-digged some ancient back-up CDs, and found other ASF files which contained those ridiculous :) Windows Media metadata... and well, in spite of the MP@*L tags, ffdshow accepted the WMVs fine... BUT, after some "MediaInfo-ing", I noticed those "good ASFs" included a "NTSC/PAL" flag, whereas the one I downloaded today doesn't have it... So, in order to remove the pesky WM-metadata, I remuxed the clip with the SolveigMM ASF Multiplexer, and voilà :) qasf.dll was sending the video stream to ffdshow without any kind of interference. :cool: BTW, the stupid WM-metadata apparently are filtered out by the VfW interface (namely, the ASF ICM Handler), so that remuxing to MKV :devil: is another functional workaround.

Bottom lines:

--- don't use Windows Movie Maker ;

--- don't use Windows Media Encoder ;

--- don't use Expression Encoder ;

--- don't use Silverlight ;

That's all. :D

[Midzuki]

Small update — I've found a .ASF file which, in spite of not having the NTSC/PAL flag, is correctly-processed by ffdshow anyway:

ID : 2
Format : VC-1
Format profile : MP@ML
Codec ID : WMV3
Codec ID/Info : Windows Media Video 9
Codec ID/Hint : WMV3
Description of the codec : Windows Media Video 9
Duration : 20s 42ms
Bit rate mode : Variable
Bit rate : 563 Kbps
Width : 464 pixels
Height : 260 pixels
Display aspect ratio : 16:9
Frame rate : 24.000 fps
Resolution : 24 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.195
Stream size : 1.35 MiB (86%)
Language : English


Still, me keeps thinking that, in this particular case, remuxing the problematic files is better than trying to fix ffdshow itself. If you wish so, I might send you a PM which would list the 10,000,000 reasons why the ASF container suckxs. :p

[Tom Keller]

:thanks: for taking a look at it. Remuxing seems to do the trick!

I already know, that ASF sux big time :p . That's why i've never created ASF/WMV files myself. But since it's still a widely spread file format, you can't entirely avoid to stumble upon it from time to time...

[Midzuki]

:thanks: for taking a look at it. Remuxing seems to do the trick!

You're wellcome ^_^

[Carpo]

under the output option which should be ticked, should all of them be ticked, or just some of them?

[fastplayer]

under the output option which should be ticked, should all of them be ticked, or just some of them?
http://ffdshow-tryout.sourceforge.net/wiki/video-output (http://ffdshow-tryout.sourceforge.net/wiki/video:output)

[tetsuo55]

Can anyone tell me what the difference is between the audio option to decode everything using dolby pro logic VS letting the matrix expand?

[nevcairiel]

Hey guys,

i have a patch that extends the LAV Splitter support in ffdshow for the next LAV Splitter release (just a small GUID addition), would be great if you can apply it.

http://files.1f0.de/patches/ffdshow-lavfsplitter-guids.patch

Thanks!

[Damien147]

Hi there.

I get image distortion with xvid and libavcodec.ffmpeg-mt works fine.edit:Nope,the same but with libavcodec it's worst

rev3811

[burfadel]

Hi there.

I get image distortion with xvid and libavcodec.ffmpeg-mt works fine.edit:Nope,the same but with libavcodec it's worst

rev3811

Same thing here! particularly on the edges of the image, and especially with panning motion etc.

[VipZ]

Same thing here! particularly on the edges of the image, and especially with panning motion etc.

I can confirm, MT seems to give less corruption, but I find it loses sync.

[clsid]

Should be fixed for libavcodec in 3812. Will fix for ffmpeg-mt later if that still has the issue.

[clsid]

Hey guys,

i have a patch that extends the LAV Splitter support in ffdshow for the next LAV Splitter release (just a small GUID addition), would be great if you can apply it.

http://files.1f0.de/patches/ffdshow-lavfsplitter-guids.patch

Thanks!
Committed.

[nevcairiel]

Thanks.

[VipZ]

Should be fixed for libavcodec in 3812. Will fix for ffmpeg-mt later if that still has the issue.

Thanks, all seems good now. MT doesn't seem to cause sync issues anymore as well.

@Tal

With the recent change regarding DXVA, how is the noDxvaDecoder registry entry handled? I build a custom pack and would like to include this option for installation. My installer register's files before writing to registry so that I may override self reg info if desired, I am thinking this may make that registry entry not work as intended.

Thanks

[sneaker_ger]

Can someone take a look at this (http://forum.doom9.org/showthread.php?t=160500)?

[Shark007]

Hi develovers!

Please, add the fourcc of hdv1 as an mpeg format..

Just wondering if anyone can add the fourcc's hdv1 and hdv2 to be recognized by ffdshow as mpeg2 ps formats?

[Blight]

bug report:
The FFDShow subtitle renderer crashes the moment it tries to display the first subtitle line.

sample file:
http://www.megaupload.com/?d=O6WKVB6J or
http://fileape.com/index.php?act=download&id=loPs1tRVLOBxBGpa

More details:
http://forum.inmatrix.com/index.php?showtopic=12768

[Blight]

Here's an odd one:
ffmpeg-mt crashes if you play this game trailer:
http://games.on.net/file/30341/Borderlands_-_Australian_launch_trailer

To get it to crash, you must use Haali as the MP4 splitte and FFDShow as the Audio decoder.
The same clip plays if you switch the MP4 splitter to the 'MPC MP4 Source' and the audio decoder to 'MPC MPA Decoder'.

A second issue with the same clip exists. If you use the 'MPC MP4 Source' as the splitter, the ffdshow audio decoder wont connect (a second bug), even though FFDShow supports the audio format in this clip (QDesign Music 2).

Testing was performed is with ffdshow_rev3785_20110323_clsid.exe, latest Haali and MPC standalone_filters-1.5.1.2959_x86_msvc2010.7z

[clsid]

Here's an odd one:
ffmpeg-mt crashes if you play this game trailer:
http://games.on.net/file/30341/Borderlands_-_Australian_launch_trailer

To get it to crash, you must use Haali as the MP4 splitte and FFDShow as the Audio decoder.
The same clip plays if you switch the MP4 splitter to the 'MPC MP4 Source' and the audio decoder to 'MPC MPA Decoder'.

A second issue with the same clip exists. If you use the 'MPC MP4 Source' as the splitter, the ffdshow audio decoder wont connect (a second bug), even though FFDShow supports the audio format in this clip (QDesign Music 2).

Testing was performed is with ffdshow_rev3785_20110323_clsid.exe, latest Haali and MPC standalone_filters-1.5.1.2959_x86_msvc2010.7z
No crash here with latest revision.

[VipZ]

I found a bug in this file, ffdshow x86 and MPC x86/x64 play this, but ffdshow x64 crashes on this file. Tried lastest rev and one 2-3 weeks old, same issue.

Here's the sample, http://www.mediafire.com/?krlxvlj8sb67n90

[Blight]

clsid:
You used the same graph as I specified? Is there a revision newer than 3785? (couldn't find one on source forge that you compiled).

[pankov]

Blight,
you can find the latest builds of ffdshow and MPC here
http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/
or here
http://xhmikosr.1f0.de/

[clsid]

I found a bug in this file, ffdshow x86 and MPC x86/x64 play this, but ffdshow x64 crashes on this file. Tried lastest rev and one 2-3 weeks old, same issue.

Here's the sample, http://www.mediafire.com/?krlxvlj8sb67n90It might be a broken file, because it plays fine when remuxed to Matroska. I am not going to investigate this further unless you have more files with the same problem.

[VipZ]

It might be a broken file, because it plays fine when remuxed to Matroska. I am not going to investigate this further unless you have more files with the same problem.

Thanks for looking into it.

I have around 30 such files all same issue, I assumed it to be a broken file as well at 1st, but the only decoder that doesn't seem to work is ffdshow x64, Microsoft+MPC (Software and DXVA)+ffdshow x86 decoders all work perfectly.

[nevcairiel]

If it works on x86, but fails on x64 - i would always assume something is wrong in the decoder. *shrug*
There isn't a real reason why it should fail on one but work just fine on the other.

[clsid]

To make it even more fun, the crash happens randomly, and occurs before decoding has started.

Edit: lol, it seems it is another one of those compiler issues with golomb stuff.

Edit2: fixed in 3816

[Sebastiii]

To make it even more fun, the crash happens randomly, and occurs before decoding has started.

Edit: lol, it seems it is another one of those compiler issues with golomb stuff.

Edit2: fixed in 3816

Thanks :)

[VipZ]

To make it even more fun, the crash happens randomly, and occurs before decoding has started.

Edit: lol, it seems it is another one of those compiler issues with golomb stuff.

Edit2: fixed in 3816

Thanks all good now :)

[Mr VacBob]

To make it even more fun, the crash happens randomly, and occurs before decoding has started.

Edit: lol, it seems it is another one of those compiler issues with golomb stuff.

Edit2: fixed in 3816

I'm curious, would you happen to have the non-working and working asm for that function with ICL? It could be an aliasing problem in the code.

I pushed a fix for some PAFF files to ffmpeg-mt.

[clsid]

It is not an asm issue. The problem is in the bitstream reading code. See here:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/libavcodec/golomb.h?r1=3816&r2=3815&pathrev=3816

[XhmikosR]

That change should have fixed the remaining crashes I had with ICL builds and h264 videos. So far I cannot reproduce any crash anymore which is a good thing.

[Milardo]

Hello,
Is it possible to compile ffdshow with postprocessing enabled in ffvdub and ffdshow encoder? Also, is it easy to change the code for this so i could compile ffdshow myself?

[fastplayer]

@Devs:
Isn't branches/ obsolete by now? Everything's been merged with trunk already.

[clsid]

Hello,
Is it possible to compile ffdshow with postprocessing enabled in ffvdub and ffdshow encoder? Also, is it easy to change the code for this so i could compile ffdshow myself?We can't help you with this. You will hve to try and see for yourself.

Some PP algorithms use data that is only available during decoder, so they can't be used in situations where ffdshow isn't doing the decoding.

@Devs:
Isn't branches/ obsolete by now? Everything's been merged with trunk already. Yes, they are obsolete. Removing them is fine with me.

[SamuriHL]

Stupid question time. I'm trying to pull from SVN and in the last day or two I keep getting an error when it goes to pull the boost source.


C:\dev\projects\ffdshow-tryout\src\boost
OPTIONS of 'http://svn.boost.org/svn/boost/branches/release/boost':
authorization failed: Could not authenticate to server: rejected Basic
challenge (http://svn.boost.org)


It's popping up an authentication dialog box. The first time I pulled the source it didn't ask me for this. Am I doing something incredibly stupid? Any help here would be greatly appreciated. I've been enjoying building my own builds of ffdshow, lav splitter, and mpc-hc in the last week or so and would like to continue doing so. Thanks!

[Snowknight26]

FPS1 -> RGB32 conversion results in flipped B and R components. It seems to be outputting BGR32 instead. I believe it happened after the recent reduction of RGB colorspaces but I'm can't verify that.

[magic144]

quick Q

just noticed that on my PC attached to my TV (ATI gfx card, HDMI to plasma), a particular 1280x720 file renders with RGB32 output color space, whereas in my office on another PC attached to LCD monitor (NVidia gfx card, DVI), it chooses to use YV12 (both using clsid rev 3814, both have multiple color-spaces selected for output) when playing the same file

(in fact, if I disable ALL BUT YV12 on my plasma setup PC for this file, ffdshow won't load to play the file and another M$oft filter gets used instead)

also strange, a different 1280x720 file on the plasma setup WILL render with YV12 color-space output chosen...

what affects the choice of output color space, and why would two h.264 files with the same resolutions choose different output color-spaces??

thanks in advance!

[clsid]

FPS1 -> RGB32 conversion results in flipped B and R components. It seems to be outputting BGR32 instead. I believe it happened after the recent reduction of RGB colorspaces but I'm can't verify that.Will fix that.

[magic144]

also, does the "ATI Pixel Format" play a part in how the output color space is chosen? - I don't explicitly set that, but it's possible a newer driver could have changed the default?

*EDIT* apparently not... tried them all and no change in YV12->RGB32 choice @ ffdshow, even though YV12 is also selected as an option
...by the way, driver is AMD Catalyst 11.3 (latest)

[Ger]

@magic144
Normally ffdshow should use this output priority from top to bottom: YV12, NV12, RGB32, YUY2, YUVU.

In your case, if all colorspaces are checked, when YV12 is used it found/negotiated a match with the next filter right away. When RGB32 is used (with all colorspaces checked) it usually indicates that both YV12 and NV12 were rejected by the next filter (normally the video renderer). If you get RGB32 with everything checked with ATI hardware that implies either VMR7 renderless or Haali video renderer is in use (both of those reject YV12 and NV12 on my ATI system) or some other filter that rejects both of those.

Which colorspaces are accepted by the video renderer is consistent in some cases (madVR accepts YV12, NV12 and in theory two more not available in ffdshow while Haali accepts YUY2 and RGB32) and depends on the driver/hardware in other cases (YV12 is accepted with EVR+Nvidia, but rejected by EVR+ATI meaning NV12 will be used for EVR+ATI).

[magic144]

@Ger - thanks!

fyi I believe everything is checked EXCEPT NV12 in this case... I found that NV12 would tend to have been chosen and gave a somewhat unnatural appearance on my plasma set. I DO use NV12 for interlaced material (to enable HW deinterlacing), but that's about the only time.

I am using EVR. Maybe I never noticed this propensity to select RGB32 in favour of YV12 with this setup in the past...
However, like I said, there is (at least) one 1280x720 (progressive video) file which DOES render with YV12 with this setup, hence my confusion... perhaps there is some other aspect of the video attributes that EVR is considering?? Does the DISPLAY play any part in the negotiation?

Lastly, if RGB32 is the chosen output color space, doesn't that mean that an extra processor usage burden now exists since ffdshow has to perform the YV12 (input) to RGB32 (output) conversion in software?

Thanks so much,
m

[Kaotech]

i've a bug with ffdshow audio processor.

i'm using Arcsoft audio decoder HD and ffdshow audio processor for bass mangement, Delay and volume. If i check "enable jitter correction", the audio track HD play fine, but when i change audio track during playback, the BluRay stop to play. If i uncheck "enable jitter correction, i haven't sound but i can change track without the video stop to play.

http://cinetips.com/images/smilies/icon_doute.gif

[JEEB]

As I didn't see any comments on this on this thread and as I saw nothing relating to this in the svn log, here I go.

I have no idea of your geopolitical location on the whole ffmpeg/libav ordeal, but michael seems to have merged(* (http://git.videolan.org/?p=ffmpeg.git;a=search;s=Oskar+Arvidsson;st=author)) irock's high bit depth (9-10bit) H.264 decoder(* (https://github.com/irock/FFmpeg/)).

Thus, as an advocate of 10bit H.264 usage, I have to tell you that you can hereby feel yourself being poked (as at least one of the major trees merged it).

Of course, just like H.264 -mt, high bit depth doesn't at the moment pass all of its FATE tests, which is why it's still being in the 'working on' phase on the libav side, currently in line after -mt for the related developers. But not like we haven't used -mt for a few years already ;) . Thus, I felt like a poke was more than a bit adequate.

[Blight]

Hi Everyone,
My brother works at Intel and took upon himself the task of adding support for SandyBridge (I7-2500K/I7-2600K series) non DXVA based hardware acceleration for H.264/MPEG2/VC-1 as well as hardware deinterlacing to FFDShow as an alternative option to LibAVCodec/ffmpeg-mt.

These CPUs will be filling the marketplace over the next few years and will enable cheap HTPC systems and lower battery use in mobile devices.

What he needs is your help in pointing out which ffdshow source code files he should access in order to integrate this support.
If anyone can help, please contact me.

[CruNcher]

Yeah though all these just supports Vista/7 (officially) not like other still support Nvidia/AMD(ATI) XP so 0 backward compatibility if you have such a system you are forced to Vista/7 to use the Media Capabilities, also one guy from Intel worked already closely with the MPC-HC team to implement support for the older GPUs not sure though if he still does for the newer HD2000/3000 inside Sandy Bridge, maybe that was also your brother ;)
Also you shouldn't call it Hardware acceleration its like Nvidia VPx and AMD UVD Hardware Decoding (fixed function)

[Ger]

@Ger - thanks!

fyi I believe everything is checked EXCEPT NV12 in this case...
Makes sense then. YV12 rejected by EVR and NV12 unchecked means RGB32 is next.


I am using EVR. Maybe I never noticed this propensity to select RGB32 in favour of YV12 with this setup in the past...
However, like I said, there is (at least) one 1280x720 (progressive video) file which DOES render with YV12 with this setup, hence my confusion...

Feel free to PM a sample link if you can. I can't tell you why it would happen, but I'm just curious to see if I can reproduce it.

perhaps there is some other aspect of the video attributes that EVR is considering?? Does the DISPLAY play any part in the negotiation? ATI drivers work in mysterious ways, or to put it another way, I don't know. ;)

Lastly, if RGB32 is the chosen output color space, doesn't that mean that an extra processor usage burden now exists since ffdshow has to perform the YV12 (input) to RGB32 (output) conversion in software?
I just tested and didn't see a noticeable difference on my 5 year old C2D, so I don't think that is something to worry about.

[Snowknight26]

Will fix that.

Fixed indeed, thanks.

[clsid]

Hi Everyone,
My brother works at Intel and took upon himself the task of adding support for SandyBridge (I7-2500K/I7-2600K series) non DXVA based hardware acceleration for H.264/MPEG2/VC-1 as well as hardware deinterlacing to FFDShow as an alternative option to LibAVCodec/ffmpeg-mt.

These CPUs will be filling the marketplace over the next few years and will enable cheap HTPC systems and lower battery use in mobile devices.

What he needs is your help in pointing out which ffdshow source code files he should access in order to integrate this support.
If anyone can help, please contact me.
With non-DXVA I assume it works similar to NVIDIA's CUVID (cuda) decoder? Thus allowing copying decoded data back to CPU memory?

Most relevant code is in /src/codecs/. The libmpeg2 or xvid4 files are probably a good starting point as an example.

[Kaotech]

i've a bug with ffdshow audio processor.

i'm using Arcsoft audio decoder HD and ffdshow audio processor for bass mangement, Delay and volume. If i check "enable jitter correction", the audio track HD play fine, but when i change audio track during playback, the BluRay stop to play. If i uncheck "enable jitter correction, i haven't sound but i can change track without the video stop to play.

http://cinetips.com/images/smilies/icon_doute.gif

Nobody knows the reason ?

[Blight]

clsid:
Yes, it should work similar to the 'NVIDIA's CUVID (cuda) decoder'.
The Intel hardware is capable of a good hardware deinterlacer and a lanczos 8-tap adaptive scaler, which may be interesting in low-end HTPC implementations.

[CruNcher]

clsid:
Yes, it should work similar to the 'NVIDIA's CUVID (cuda) decoder'.
The Intel hardware is capable of a good hardware deinterlacer and a lanczos 8-tap adaptive scaler, which may be interesting in low-end HTPC implementations.

Do you know of any indepth compares vs AMD/ATI and Nvidias Vector Adaptive Deinterlacing ?

[hoborg]

clsid:
Yes, it should work similar to the 'NVIDIA's CUVID (cuda) decoder'.
The Intel hardware is capable of a good hardware deinterlacer and a lanczos 8-tap adaptive scaler, which may be interesting in low-end HTPC implementations.

Hi.
Sound good, but I7-2500K/I7-2600K? Such powerfull CPU doesnot seems to be ideal for HTPC. i3-2100T should be the one :)

[nevcairiel]

There will be a i3-2105 "soon" which comes with the more powerful HD3000 iGPU, which might be worth getting if you want to go that route. I would however still miss madVR, and for that even the HD3000 is not fast enough.

[ericgur]

With non-DXVA I assume it works similar to NVIDIA's CUVID (cuda) decoder? Thus allowing copying decoded data back to CPU memory?

The 2000/3000 GPUs use dedicated HW (ASIC) for encoding/decoding and most of the video pre/post processing. So it's not using the cores for any significant work. It uses very little power and has a high throughput (should be ~5 real time HD streams) but this comes at the expense of programmability. Unlike previous generations of GPUs, this one (and future GPUs) shares the CPU's L3 cache and ring bus and both CPU cores and GPU cores use the same integrated memory controller. So there's no PCIe traffic when sending/receiving data to the GPU. Both the 2000 and the 3000 have the same video related HW with a different core count. Since the GPU cores aren't too busy with decoding and post processing, a modified ffdshow should work (perform decoding+deinterlacing)

[Singularity]

Hi,

I'm starting to think I may have found a bug with 25fps h264 in MP4s. Whenever one is played in either WMP11 or Tversity, ffdshow.ax produces a crash in the program. The same audio and video remuxed into an mkv is fine however.

I've tried a couple of different versions of MP4Splitter to make sure it wasn't that (it used to work fine, but I seem to remember an update for WMP11?), the only solution appears to be to use the beta7 version of ffdshow-tryouts from sourceforge. Both ffdshow_rev3356_20100411_clsid_icl10 and ffdshow_rev3721_20110107_clsid_icl10 produce the error.

My OS is XP SP3, any ideas?

Thanks
Singularity

[clsid]

Can you upload a sample file?

Please also try builds in between beta7 (=r3154) and r3356 to narrow it down further.

[CruNcher]

The 2000/3000 GPUs use dedicated HW (ASIC) for encoding/decoding and most of the video pre/post processing. So it's not using the cores for any significant work. It uses very little power and has a high throughput (should be ~5 real time HD streams) but this comes at the expense of programmability. Unlike previous generations of GPUs, this one (and future GPUs) shares the CPU's L3 cache and ring bus and both CPU cores and GPU cores use the same integrated memory controller. So there's no PCIe traffic when sending/receiving data to the GPU. Both the 2000 and the 3000 have the same video related HW with a different core count. Since the GPU cores aren't too busy with decoding and post processing, a modified ffdshow should work (perform decoding+deinterlacing)

At least how i understand it the EUs (comparable term Shader) are where the load of the Post Pro goes too so here would the HD2000/3000 difference set in (Performance). The Same for other tasks such as 3D Rendering, Raytracing or Compute. The major difference is as you said the SOC approach away from the PCI-E which eliminates the whole transfer problem bottleneck.

[Gleb Egorych]

Small bug: if libavcodec is choosed as MP2 decoder than in same cases it detects MP2 as MP3. Circumstance: DVB TS, Haali or LAV splitter. With MPC-HC splitter MP2 is detected correctly. ffdshow b3825.

[ericgur]

At least how i understand it the EUs (comparable term Shader) are where the load of the Post Pro goes too so here would the HD2000/3000 difference set in (Performance). The Same for other tasks such as 3D Rendering, Raytracing or Compute. The major difference is as you said the SOC approach away from the PCI-E which eliminates the whole transfer problem bottleneck.

The EUs (execution units == cores) can be used for a variety of computing tasks, video processing is one of them. But in order to gain performance and save power, fixed function units are used to perform various tasks (decode, encode, sample, various video processing, transform and lighting, etc). The price for these fixed functions are silicon area and loss of generality. A good example is Lanczos4 scaling. The 3000 is borderline strong on doing it in shader code (MadVR) for (or to) full HD, but the dedicated HW should scale 4-5 (to/from) full HD streams simultaneously with very low EU utilization (they can do other things). The power it takes to use the dedicated HW scalers is very low (close to zero) and it allows the GPU to enter a lower power state faster (because the task finishes faster), saving even more power.

[CruNcher]

Hmm so Deinterlacing and Scaling on HD2000/3000 are available also as Fixed function via Media SDK 2.0 ? did you looked @ the Quality of the Hardware implementation yet is it up to Nvidia/AMD(ATI) Quality, what about FRC ?. Seeing that they beat at least AMD(ATI) (about Nvidia im not so sure, i don't trust reviews here as most of them are application limited) in Encoding i guess they could have not so bad algos either for the PP :) Having those optional then available inside ffdshow would be a blast indeed especially combined with GPU Decode when possible, though Vista/7 would be a requirement for those then :)

[ericgur]

Hmm so Deinterlacing and Scaling on HD2000/3000 are available also as Fixed function via Media SDK 2.0 ? did you looked @ the Quality of the Hardware implementation yet is it up to Nvidia/AMD(ATI) Quality, what about FRC ?. Seeing that they beat at least AMD(ATI) (about Nvidia im not so sure, i don't trust reviews here as most of them are application limited) in Encoding i guess they could have not so bad algos either for the PP :) Having those optional then available inside ffdshow would be a blast indeed especially combined with GPU Decode when possible, though Vista/7 would be a requirement for those then :)

The deinterlacer quality was much better than Nvidia/AMD last year, not sure about current generation. Decode and encode performance and quality were reviewed by Anandtech and were very good (Nvidia encode wasn't that good). I don't think FRC is done in dedicated HW, probably done in SW/shader. I'm not familiar with that. The other PP algorithms like denoise and sharpen were better quality than Nvidia/AMD last year as well (both fixed function). I don't have current quality comparisons. Unfortunately there isn't as very good benchmark for video quality. Only HQV 1 & 2 exist and they put a lot of weight on uncommon film cadences and very little on scaling and deinterlacing which are critical to image quality. HQV also makes a video processor and these tests show how good their (expensive) HW is…
The media SDK uses HW if it exists, there's a new version (3.0 beta) available which abstracts the memory surfaces for easier programming (didn't get to that yet).
OS support is Vista and up due to the different (and much better) driver model introduced in Vista. On a side note, XP drivers are harder to write and maintain as they are almost 100% in kernel mode (no visual studio for you ) while vista/7 drivers are almost 100% user mode. Anyway, do we still need XP these days on new computers? Windows 8 is out next year…

[madshi]

The deinterlacer quality was much better than Nvidia/AMD last year, not sure about current generation.
Were you comparing to NVidia/AMD integrated solutions or to NVidia/AMD middle/high end dedicated solutions? Of course comparing to NVidia/AMD integrated solutions would be the fair thing to do, but it's still important to know what you compared to, because IIRC only the middle/high end dedicated solutions from NVidia/AMD do some kind of motion compensated deinterlacing, which seems to be of pretty high quality. Does Sandy Bridge also do motion compensated deinterlacing? That would be kinda surprising to me cause I think you'd probably need quite high memory bandwidth for that and integrated solutions can't compete with dedicated GDDR5 GPUs with wide bus widths, I'd expect? What deinterlacing technology does Sandy Bridge use (if you can comment on that)?

A technical question just for my interest: How does Intel count scaling taps? E.g. for Lanczos4 upscaling, does that mean 4 pixels input for 1 pixel output when scaling in one dimension? Or does it mean 8 pixels input for 1 pixel output? FWIW, madVR counts 4 taps upscaling = 8 pixels input. Basically madVR understands taps as max pixel distance.

Thanks! :)

[CruNcher]

The deinterlacer quality was much better than Nvidia/AMD last year, not sure about current generation. Decode and encode performance and quality were reviewed by Anandtech and were very good (Nvidia encode wasn't that good). I don't think FRC is done in dedicated HW, probably done in SW/shader. I'm not familiar with that. The other PP algorithms like denoise and sharpen were better quality than Nvidia/AMD last year as well (both fixed function). I don't have current quality comparisons. Unfortunately there isn't as very good benchmark for video quality. Only HQV 1 & 2 exist and they put a lot of weight on uncommon film cadences and very little on scaling and deinterlacing which are critical to image quality. HQV also makes a video processor and these tests show how good their (expensive) HW is…
The media SDK uses HW if it exists, there's a new version (3.0 beta) available which abstracts the memory surfaces for easier programming (didn't get to that yet).
OS support is Vista and up due to the different (and much better) driver model introduced in Vista. On a side note, XP drivers are harder to write and maintain as they are almost 100% in kernel mode (no visual studio for you ) while vista/7 drivers are almost 100% user mode. Anyway, do we still need XP these days on new computers? Windows 8 is out next year…



I hope someday finally this Annandtech failure gets corrected so i do it again they didn't test Nvidias Encoder Quality they compared with Arcsofts Encoder and they use their own modified x264 with GPU support and bugs inside Mediaconverter 7 ;)
Also Toms Hardware Guide comparision was in that regard much better, still some issues as it's running also in the enclosed ISV frameworks but much better then Annandtechs also from the fact that the Reviewer released all the Final Encode samples if oyu interested http://forum.doom9.org/showpost.php?p=1477694&postcount=88 there is no comparision here yet to Nvidias Encoder :)

[nevcairiel]

Quality-wise, no hardware encoder will ever beat x264. Its just a question of quality vs speed.

[CruNcher]

Correct but Quicksync seems to be @ least able to stay on course with x264 @ its fastest setting and mabye even in the Range of subme 2 (@ much faster speed and lower power consumption compared to a SB itself using x264) (Nvidia pretty much dies @ subme 1 vs x264 with its Diamond Search).

OS support is Vista and up due to the different (and much better) driver model introduced in Vista. On a side note, XP drivers are harder to write and maintain as they are almost 100% in kernel mode (no visual studio for you ) while vista/7 drivers are almost 100% user mode. Anyway, do we still need XP these days on new computers? Windows 8 is out next year…

Also surely the reason why Intel isn't investing into XP anymore is clear not because Win XP runs out officially or because it would be harder to maintain (Nvidia and AMD also do it) that's partly a reason but the main reason is to transfer as fast as possible many users to Vista/7 with SB so they become potential customer of their Hollywood approved fast release Distribution chain utilizing their Hardware AES and the Protected Audio Video Path (PAVP) ;) As under Windows XP you can't assure the protection so low that Hollywood denied it and Vista/7 is the only OS where Microsoft and others invested a lot of time Kernel wise as you said to make sure the Dataflow is all the time not capture able or breakable (especially when additionally using a secured Hardware flow as PAVP) though with the HDCP master key out it seems rather odd to speak about "Protected" anymore, so all the investment here for 0 the whole chain collapsed with the master key leak ;)

[Didée]

... because IIRC only the middle/high end dedicated solutions from NVidia/AMD do some kind of motion compensated deinterlacing, which seems to be of pretty high quality. Does Sandy Bridge also do motion compensated deinterlacing?
Can't give proof, but I strongly doubt that they use any kind of active motion compensation. The naming is "vector adaptive", which I'd rather see in relation to "motion adaptive". (Motion adaptive analyses image data for significant change. If present, the deinterlacer kicks in. In the same spirit, I think that vector adaptive simply uses vector length data to decide where to deinterlace and where not.)

Or the other way round: if there would be any kind of active motion compensation, then the PR department would tout that in much boulder letters. ;)

[madshi]

Can't give proof, but I strongly doubt that they use any kind of active motion compensation. The naming is "vector adaptive", which I'd rather see in relation to "motion adaptive". (Motion adaptive analyses image data for significant change. If present, the deinterlacer kicks in. In the same spirit, I think that vector adaptive simply uses vector length data to decide where to deinterlace and where not.)

Or the other way round: if there would be any kind of active motion compensation, then the PR department would tout that in much boulder letters. ;)
I originally doubted motion compensated deinterlacing very much, too. But if you look at the cheese slice test results, I can't really see how the results would be possible without at least a simple form of motion compensation. See here:

http://www.avsforum.com/avs-vb/showthread.php?t=1157287

[ericgur]

Does Sandy Bridge also do motion compensated deinterlacing? That would be kinda surprising to me cause I think you'd probably need quite high memory bandwidth for that and integrated solutions can't compete with dedicated GDDR5 GPUs with wide bus widths, I'd expect? What deinterlacing technology does Sandy Bridge use (if you can comment on that)?

I can't comment on it. BTW, the HW encoder uses motion estimation so memory bandwidth isn't an issue...
Another thing, I've worked on deinterlacing a few years ago and it was very hard to find content that actually shows significant improvement when using motion compensation. The interlaced video suffers from severe aliasing because no vertical low-pass filter is performed prior to interlacing in order to keep the vertical resolution in still images (guessing). The aliasing makes the MC DI very hard to implement and rarely works properly as images move in sub pixels distances.

A technical question just for my interest: How does Intel count scaling taps? E.g. for Lanczos4 upscaling, does that mean 4 pixels input for 1 pixel output when scaling in one dimension? Or does it mean 8 pixels input for 1 pixel output? FWIW, madVR counts 4 taps upscaling = 8 pixels input. Basically madVR understands taps as max pixel distance.

Lanczos4 is a lowpass function like all classic scalers that uses 8 consecutive pixels as input (either horizontal or vertical) for both upscaling and downscaling. In downscaling the function is modified depending on the scale factor. For upscaling it's always the same coefficients no matter how much scaling is done. If someone is interested, I can explain the signal processing theory behind this.

[madshi]

Another thing, I've worked on deinterlacing a few years ago and it was very hard to find content that actually shows significant improvement when using motion compensation.
Soccer might be a good test candidate.

The interlaced video suffers from severe aliasing because no vertical low-pass filter is performed prior to interlacing
Really? I thought it was common practise to apply vertical filtering!

Lanczos4 is a lowpass function like all classic scalers that uses 8 consecutive pixels as input (either horizontal or vertical) for both upscaling and downscaling. In downscaling the function is modified depending on the scale factor. For upscaling it's always the same coefficients no matter how much scaling is done. If someone is interested, I can explain the signal processing theory behind this.
Nah, thanks, I know the theory and practise. Just wanted to double check whether we're on the same page with counting taps, since companies like HQV etc sometimes don't use the scientific way of counting things, but rather the marketing way. Good to hear you're sticking to science.

[ericgur]

Were you comparing to NVidia/AMD integrated solutions or to NVidia/AMD middle/high end dedicated solutions?

The quality was always compared to the strongest card. AMD and Nvidia, both have fixed functions that are the same across models.
Another thing is that vector adaptive deinterlacing is a meaningless marketing name and doesn't imply motion compensation. It MIGHT mean that vectors/blocks of pixels are evaluated as a block like motion estimation in an encoder works (which is pretty bad for DI). The thing is that when an encoder finds the wrong motion vector, you pay in bits, the file will get bigger because there's error correction. In DI you'll get severe artifacts.

[nevcairiel]

The deinterlacing is not done in the decoder core, at least on NVIDIA. I see obvious performance differences when deinterlacing between my GTX570 and my GTS450 (both a VP4 decoder). I've also seen references to the processing pipeline in chats between developers and NVIDIA techs, where they put all post-processing in the 3D engine, not in the decoder.

I also haven't found a video where the deinterlacing looks bad, it always looks really good - no artifacts, perfect smooth movement, even on hard scenes like diagonal lines, where you need something like vector adaptive deinterlacing for them to look good. See the chese slices test pattern (http://www.avsforum.com/avs-vb/showthread.php?t=1157287), which was originally designed to detect which deinterlacing algorithm is currently active on ATI cards - which shows obvious differences between vector adaptive, motion adaptive and bob/weave.

[madshi]

Another thing is that vector adaptive deinterlacing is a meaningless marketing name and doesn't imply motion compensation. It MIGHT mean that vectors/blocks of pixels are evaluated as a block like motion estimation in an encoder works (which is pretty bad for DI). The thing is that when an encoder finds the wrong motion vector, you pay in bits, the file will get bigger because there's error correction. In DI you'll get severe artifacts.
Yeah, I fully agree. Still, the cheese slice test results with the recent generations of AMD and NVidia cards look very very good to me. Too good for simple "motion adaptive deinterlacing with edge diagonal processing à la DCDi", IMHO.

[ericgur]

Yeah, I fully agree. Still, the cheese slice test results with the recent generations of AMD and NVidia cards look very very good to me. Too good for simple "motion adaptive deinterlacing with edge diagonal processing à la DCDi", IMHO.

The MA DI as shown by the avsforum link (ATI) doesn't do DCDi (interpolation using edge direction) at all, it interpolates the missing moving pixel by a simple vertical interpolation. Then again, this is a synthetic clip that moves objects at integer distances. In real world video the objects can moves 2.3 pixels so this clip is useless because if your MC DI is tuned to this sort of clips they'll probably fail when movement isn't an integer. On many real world clips, the movement isn't just translation (x,y motion vector), it's a more complex affine (x,y,zoom,rotate) or even a full blown perspective transform. In most sports (basketball, football) the players movement is mostly affine, the court/field/distant audience is mostly translation. Affine motion vectors are very costly to calculate and I'm not aware of anyway doing it in realtime.

Too bad we have to deal with deinterlacing in 2011. Interlaced video should have died with analog video...

[madshi]

The MA DI as shown by the avsforum link (ATI) doesn't do DCDi (interpolation using edge direction) at all, it interpolates the missing moving pixel by a simple vertical interpolation.
Yes, agreed.

Then again, this is a synthetic clip that moves objects at integer distances. In real world video the objects can moves 2.3 pixels so this clip is useless because if your MC DI is tuned to this sort of clips they'll probably fail when movement isn't an integer.
Well, I haven't really done any tests on GPU deinterlacing quality myself yet. So I don't really know for sure how well it works on real life content. It was just one heck of a surprise to me when seeing those synthetic clip results because they do appear to suggest that AMD/NVidia are doing some sort of motion compensation. I simply didn't expect that.

On many real world clips, the movement isn't just translation (x,y motion vector), it's a more complex affine (x,y,zoom,rotate) or even a full blown perspective transform. In most sports (basketball, football) the players movement is mostly affine, the court/field/distant audience is mostly translation. Affine motion vectors are very costly to calculate and I'm not aware of anyway doing it in realtime.
Yeah, I know. Add to that lighting variations when objects are moving/transforming and things become even more difficult. It seems Optical Flow algorithms have been improving quite nicely recently, though. Maybe there's hope for the future. There's already one Optical Flow CUDA implementation running in realtime. It's probably not artifact free enough yet, though. I think a good Optical Flow + Warp algorithm could be the ticket for motion compensated deinterlacing, especially it you track motion over several consecutive frames to make sure all detected motion vectors are sound. Sometime in the future...

Too bad we have to deal with deinterlacing in 2011. Interlaced video should have died with analog video...
Agreed, especially considering that compression efficiency is noticeably higher with progressive content. So the bandwidth cost of going progressive would probably be rather small.

But even if we make the transition to progressive now, there's still lots of old natively interlaced content out there. So the need for deinterlacing isn't likely to go away anytime soon.

[Reimar]

(Was about int vs. float output)
I don't know if/when I will have time, but I actually intended to change it to make it possible to select at runtime.
I just can't imagine that that should be hard to do, and it would be a lot more useful than just a configure option.

I finally sent patches for that to FFmpeg, hopefully we'll soon have this solved once and for all in FFmpeg.

[madshi]

Thanks! Justin has been active about this recently, too, btw (in libav, of course).

[CruNcher]

clsid, volt please add this subtype to the ffdshow audio decoder {AACE71A1-8259-4250-8583-49613AF31C93}

[kc7bfi]

I've downloaded the latest svn build for Windows 64bit machines. I can play h.264 video when I configure ffdshow to use libavcodec but I cannot play video when I select ffmpeg-mt. Is there something I need to do to enable windows to be able to play video using ffmpeg-mt?

[Singularity]

Hi again clsid,

Sorry for the delay, my Easter Holidays were spent lying down after I threw my back out.

Sample file:
http://www.megaupload.com/?d=KU5KJQVZ
Excuse the quality, but I resized it to what I usually use

The last official build (pre-compiled from sourceforge that is) that works is 3507 icl10, however, 3721 generic actually works. This makes no sense because it's the same code just compiled differently no? 3356 not working earlier was an error on my part, hopefully this whole bug isn't the same...

If you need a finer revision number than that I could grab the 30 day trial of the intel c compiler if you would like? This will however take me a bit to figure out.

Thanks
Singularity

[clsid]

I can reproduce the crash with a ICL10 build of the latest revision as well. Since the regular builds don't have this problem, I am not going to invest any time in trying to fix it. Try a recent ICL12 build to see if that also has the problem. I am switching to MSVC2010 and will probably stop making ICL10 builds.

[J_Darnley]

Apologies if this a repeated question. Do any builds have the new 10-bit H.264 decoder yet?

[Nexin]

Not been a big fan of ffdshow for many years, after been stung with early version upsetting the system. Never used the tryouts for same reason, though did find when it worked of use. However for past three months i have used ffdshow_tryouts. And for a while i didn't use it, selected ask me before ffdshow could be used as didn't need it.

Now i do need to use it again i'm having problems with it. Have since tried serveral versions and still no go. Have tried both generic or ICL varieties, neither install old version fixes it. Problem is any version of ffdshow doesn't seem to work any longer. And when it does, it doesn't fully work and crashes with xp crash popup saying ffdshow.ax as the fault.

I have tried with the setup with allow for any and all softwares to use ffdshow full access with no restrictions set. Even allowing unlimited uses, and still either nothing or same crashes. After i will uninstall and try another ffdshow version. I install another version with default setup accepted (with no changes) that includes 'clear old settings'. Gspot showing no codecs missing or any other problems.

Q. Is there some other settings that could be causing this or known softwares or other that can conflict ?


_

[oddball]

I've got a real issue with profiles and automatic preset loading. My problem is that some HDTV encodes start out with a DD2.0 stream during the intro then switch to DD5.1 which causes it to load a profile I have set for 2.0 stereo. However when it switches to DD5.1 it still stays on 2.0 stereo and I lose the voices in the center channel and surrounds etc obviously.

Is there any way to get ffdshow to detect channels during playback (and switching profiles automatically) rather than using the somewhat primitive method of loading only at startup? This is a real drag as I have to switch the profile manually. I've had to stop using ffdshow for 5.1 decoding because of this and forgo profiles and just use AC3Filter instead (Not my preferred method).

[Mark_A_W]

Can you edit the junk out of the streams? (VideoReDo is good.)

I'm surprised you have profile loading based on channel number working! I've tried and tried to get that to work - it just doesn't. However, I am using madFLAC as the decoder, and ffdshow as the processor, so maybe the fact that fddshow is not "decoding", rather getting 6 or 8 channels uncompressed, is screwing me.

[hoborg]

Hi.
Anbody here managing FFDshow DXVA decoder?
I found that this MKV (VC-1) sample (https://rapidshare.com/files/459398345/test.mkv) play extreme sturreting while plaback using FFDShow DXVA + LAVF .24 splitter/audio decoder.
Normal FFDshow wmv9 decoder (or PDVD11 decoder in DXVA mode) play it perfectly.

EDIT:
The problem doesn't happend with MPC-HC DXVA decoder, so must be FFDShow DXVA decoder issue.

[oddball]

I've given up on audio profiles. It's very hit or miss. For some reason when I decode with the internal decoder I get 2.1 output on a profile I setup on 5.1 inputs. But if I let AC3Filter do the decoding it correctly recognises 5.1 to 5.1. Bug?

Anyhow I have now found the DPLII decoding option for 2.0 sources which is what I was trying to do really and just output everything in 5.1 now. Thanks for adding that devs. I would however like to see a DPLII Music mode option. But it's not a big deal if it's not added.

[Nexin]

Not been a big fan of ffdshow for many years, after been stung with early version upsetting the system. Never used the tryouts for same reason, though did find when it worked of use. However for past three months i have used ffdshow_tryouts. And for a while i didn't use it, selected ask me before ffdshow could be used as didn't need it.

Now i do need to use it again i'm having problems with it. Have since tried serveral versions and still no go. Have tried both generic or ICL varieties, neither install old version fixes it. Problem is any version of ffdshow doesn't seem to work any longer. And when it does, it doesn't fully work and crashes with xp crash popup saying ffdshow.ax as the fault.

I have tried with the setup with allow for any and all softwares to use ffdshow full access with no restrictions set. Even allowing unlimited uses, and still either nothing or same crashes. After i will uninstall and try another ffdshow version. I install another version with default setup accepted (with no changes) that includes 'clear old settings'. Gspot showing no codecs missing or any other problems.

Q. Is there some other settings that could be causing this or known softwares or other that can conflict ?


_

Ok sorted it, seems many if not all splitters and have tried many are rubbish for mkv (halli, gabest and many more free and commecial).

The LAVSplitter (http://forum.doom9.org/showthread.php?t=156191) works without fail and ffdshow is available for any media to use not just mkv.

I re-read what i wrote first and noted i didn't include mkv. It was there but i remeber editing before posting and must have removed that paragraph. Obvious reason for no replies to it.

Problem though why are so many splitters rubbish for mkv. Mkvs from lots of different dates past and present. Shame ffdshow hasn't a fully qualified splitter included. Maybe it could use also the LAVSplitter (http://forum.doom9.org/showthread.php?t=156191) . I read MPC-HC will have it, though i prefer to use MPlayer with older ui since is the nearest perfect player over all others i have used.

FFDShow devs please consider, really consider inclusion of LAVSplitter (http://forum.doom9.org/showthread.php?t=156191) even now include as is. Ok i know is far from release standard but is working. If included in each beta version then no one can complain, but will have easier time of playing much more media with it. Ok if they don't like so what they can easily disable it by deselection. As nevcairiel says LAVSplitter (http://forum.doom9.org/showthread.php?t=156191) is a multi-format media splitter that uses libavformat (the demuxing library from ffmpeg) to demux all sorts of media files.

Thanks goes out to nevcairiel and to Ti-BEN from the XBMC DSPlayer team for developing LAVSplitter (http://forum.doom9.org/showthread.php?t=156191) . I know this is far from release standard, yet it is working and really is testing and using atm with the v0.23 installer version.

[clsid]

Nothing will be included. If you want an all-in-one pack, get a codec pack. There aren't ones yet that use LAVSplitter, but there will be soon.


@devs,
Can anyone that knows a bit about the audio parser have a look at this bug report? The problem has already been narrowed down to a specific revision.
https://sourceforge.net/tracker/?func=detail&aid=3294017&group_id=173941&atid=867360

[Nexin]

There aren't ones yet that use LAVSplitter, but there will be soon.

Looking forward to using it :)


update: nevcairiel has said there would be problems if they were combined (http://forum.doom9.org/showthread.php?p=1496625#post1496625)

[adam777]

Hello all,
Just a small heads up - last few builds crash for me upon launching a movie in MPC-HC (3052).
Crash happens with rev3829 and rev3831 (both MSVC2010), rev3828 works fine.
Adam.

[clsid]

Adam, can you upload a sample file?

[adam777]

Adam, can you upload a sample file?

Sure.
Here - http://www.mediafire.com/?w0jfpn4ztyq7xzm
It's a few seconds from a 1080p60 clip linked here - http://forum.doom9.org/showthread.php?p=1488827#post1488827, spliited with mkvtoolnix
:thanks:

[clsid]

Fixed in 3832.

[adam777]

Fixed in 3832.

Indeed. :thanks:

[moonrak]

Fixed in 3832.
Where can I download 3832 from?
Moonrak

[fastplayer]

Where can I download 3832 from?
http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

[moonrak]

http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

My real question should have been:
Where is r3832 compiled by clsid?
:)
Moonrak

[Superb]

My real question should have been:
Where is r3832 compiled by clsid?
:)
MoonrakWhy does it matter to you? :confused:
You can also download it from http://www.xvidvideo.ru/

[moonrak]

Why does it matter to you? :confused:
You can also download it from http://www.xvidvideo.ru/

One hour ago the update was not in http://www.xvidvideo.ru/.
Now I can see it is.
In the past I have had issues with xhmikosr builds (don't know why) so I try to stay away from them.
:)
Moonrak

[tal.aloni]

@devs,
Can anyone that knows a bit about the audio parser have a look at this bug report? The problem has already been narrowed down to a specific revision.
https://sourceforge.net/tracker/?func=detail&aid=3294017&group_id=173941&atid=867360

I'll have a look in the next few days.

Edit: Fixed for rev. 3835

p.s. if any of you have a legal license to Windows Home Server (2003) please PM me

[Superb]

Very annoying regression:
ffdshow crashes when used to convert colorspace (NV12 -> RGB32) in Subtitle Workshop.
Worked w/ many revisions (including Beta 7), but started crashing a while ago.
Crashes randomly (my guess is ~80% of the time) on playback start/middle or when closing SW.

Background:
Subtitle Workshop 2.51. Windows 7. Nvidia card capable of H.264 dxva decoding (I have GT 430).
When tried opening mkv-h.264 file in SW, one has to use ffdshow in order to convert colorspace due to a SW's bug.
You would simply enable ffdshow video decoding for raw video (all supported) and it made SW work w/ mkv-h.264 files.
This workaround worked great until recently, when ffdshow started crashing.

EDIT: I started testing various revisions and will update here w/ results...
ffdshow_rev3832_20110429_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3802_20110402_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3700_20101226_xvidvideo-ru_x86-MSVC2010.exe - works
ffdshow_rev3750_20110125_xhmikosr_MSVC2010.exe - works
ffdshow_rev3775_20110314_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3762_20110219_xhmikosr_MSVC2010.exe - works
ffdshow_rev3768_20110304_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3765_20110225_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3763_20110219_xhmikosr_MSVC2010.exe - works

[oddball]

I'm unable to play a 1080p60fps clip fluidly with ffdshow in the filter chain. I get massive amounts of dropped frames. I'm using MPC-HC latest, internal splitter (tried external and makes no difference), CUVID as the decoder, ffdshow as the filter and MadVR as the renderer. When ffdshow is not in the chain the clip 'Birds' plays fluidly.

Clip is linked to in this thread.

http://forum.doom9.org/showthread.php?t=156660&highlight=birds+1080p

Likewise if I disable any filters in ffdshow and let it pass unmolested it plays near fluidly with the occasional dropped frame (It does not drop ANY frames if ffdshow is not in the chain).

GPU load is under 10%. CPU climbs to 60-70% on an Intel E7600. If I untick the filters then the video plays much more fluidly but the CPU hardly drops so I doub't it's a CPU usage issue. MPC-HC remains around the 60-70% usage mark regardless if I tick or untick any ffdshow filters. But it plays smoother with them unticked.

Any ideas why it's dropping massive amounts of frames when any filters are enabled? I am only seeing this on 1080p60fps video.

[tal.aloni]

oddball:
does it happen on default configuration as well?
try uninstalling and reinstalling to reset configuration, perhaps there is some setting that you're missing that's causing it.

also, please try beta 7 (rev 3154) as well as the latest revision.

[oddball]

I noticed it plays smoother with random pauses using overlay or ever. evr-cp it freezes more often and evr-sync it just stops playing altogether. I will try with the latest build on default configuraiton. Usually I output at YV12 with high quality YV12 to RGB conversion. If I untick that as well as drop frames after 1500 delay in decoder options it plays fluidly. But only using overlay.

[oddball]

I just tried with PotPlayer which is using even less CPU. Odd thing is using PotPlayer with ffdshow RAW filter and no filters ticked at all it plays slow motion video (audio stays the same) using EVR-CP. MadVR is an absolute no go. Continuous stutter and massive frame drops. Ah it does the slomo thing with EVR in MPC-HC too. It's like ffdshow can't process the frames fast enough to the renderer.

[oddball]

I uninstalled ffdshow completely and reinstalled the latest build 3836 and when using it for decoding the 1080p60fps Girl Yoon clip it EATS the CPU! Using MPC-HC internal decoder even with non-DXVA it hardly makes an impact on the CPU. What's wrong with ffdshow or my setup?

[oddball]

ffdshow is unable to keep up when using filters on RAW decoded video. It is dropping frames all over the place when trying to present frames to MadVR and does not do much better with any other renderer. Also if I allow ffdshow to decode the video it EATS the CPU using ffmpeg-mt or libav. I don't think CPU overhead is an issue anyhow. When I use a decoder that loads onto the GPU it makes no difference. ffdshow just cannot seem to push 1080p60fps video through it's filters fast enough and even drops a few odd frames with no filters ticked.

BTW I don't seem to have issues with 1080p @ 23.976fps I will have to test a 30FPS clip and see if that gives issues.

EDIT: No problems with 1080p @ 30FPS even with filters ticked. Only the 60fps stuff does not want to play ball with ffdshow in the chain.

EDIT2: For now I've had to setup a profile so that anything fps>30 gets sent unfiltered. Not ideal but the only way to get 1080p60fps playback with ffdshow in the chain.

EDIT3: btw I can just about use Sharpen (unsharp). If I do High quality YV12 to RGB conversion I start to see glitches here and there. Deband is a no go. I can only assume ffdshow has limits on certain filters when it comes to high res + high framerates or perhaps it's a system IO problem. Not too sure.

[mindbomb]

hey you guys, i have a question about ffdshow audio processor.

I'm using lav audio as my decoder, and ffdshow audio processor to downmix.

So, I'm wondering if selecting 24 bit output in ffdshow in this capacity actually leads to proper 24 bit output?

Let's say I have a 24 bit truehd file, then the processing chain would look like this with just 24 bit selected on the output page:

24 bit int from lav audio ->32 bit int for ffdshow processing -> 24 bit int again for ffdshow output

is that correct?

[nevcairiel]

f If I do High quality YV12 to RGB conversion I start to see glitches here and there. Deband is a no go. I can only assume ffdshow has limits on certain filters when it comes to high res + high framerates or perhaps it's a system IO problem. Not too sure.

Sounds like your CPU is just maxxed out. HQ RGB conversion takes alot of power.

Rather use a YUV output (YV12 or NV12), and let the renderer convert to RGB - madVR does a better job at it anyway. :)
Note that not everything is multithreaded (or can be), so if you see >50% load on a dual core, it could mean that one core is completely maxxed out.

[Superb]

Very annoying regression:
ffdshow crashes when used to convert colorspace (NV12 -> RGB32) in Subtitle Workshop.
Worked w/ many revisions (including Beta 7), but started crashing a while ago.
Crashes randomly (my guess is ~80% of the time) on playback start/middle or when closing SW.

Background:
Subtitle Workshop 2.51. Windows 7. Nvidia card capable of H.264 dxva decoding (I have GT 430).
When tried opening mkv-h.264 file in SW, one has to use ffdshow in order to convert colorspace due to a SW's bug.
You would simply enable ffdshow video decoding for raw video (all supported) and it made SW work w/ mkv-h.264 files.
This workaround worked great until recently, when ffdshow started crashing.

EDIT: I started testing various revisions and will update here w/ results...
ffdshow_rev3832_20110429_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3802_20110402_xvidvideo-ru_x86-MSVC2010.exe - broken
ffdshow_rev3700_20101226_xvidvideo-ru_x86-MSVC2010.exe - works
ffdshow_rev3750_20110125_xhmikosr_MSVC2010.exe - works
ffdshow_rev3775_20110314_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3762_20110219_xhmikosr_MSVC2010.exe - works
ffdshow_rev3768_20110304_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3765_20110225_xhmikosr_MSVC2010.exe - broken
ffdshow_rev3763_20110219_xhmikosr_MSVC2010.exe - worksAlright, reduced the problem to either 3764 or 3765.

3764 commit log (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&sortby=date&revision=3764) (by clsid2):
Updated FFmpeg

3765 commit log (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&sortby=date&revision=3765) (by stargazer69):
Output tab overhaul:
- Removed some never used colorspaces
- New colorspace priority lists
- Enable "Set interlaced flags in output media type" by default
- "Set interlaced flags in output media type" no longer disables YV12 output
- Enable high quality YV12/NV12/YUY2->RGB32 conversion by default

My guess is that 3765 caused the new crash regression (is has to do more w/ colorspace stuff), but I can't be sure unless someone provides me w/ 3764 compilation.

[oddball]

I tried overclocking my E7600 from stock 3.06Ghz to 3.8Ghz. CPU load hit's a max of 75% but generally stays under this when playing back Birds 1080p60fps. The big hitter is the deband filter. If I enable it I tend to get dropped frames all over the place. GPU load is low. CPU load as stated hits a max of 75% but general stays under 70% so it's not maxxed out at all. If I enable all colorspace outputs I get green on side of my HDTV and black and white on the other half. Most peculiar.

I still think something is up with ffdshow not being able to pass 1080p60fps through deband fast enough for some reason. I can get sharpening to work with 2 dropped frames on Birds 1080p60fps (always drops the 2 frames at the exact same points too).

Or is it really a case of when ffdshow load MPC-HC (Or the system in general) beyond 65% CPU then it all goes to hell?

EDIT:NV12 was the culprit for the green and black and white screen. If I untick that it looks correct.

[clsid]

CPU usage percentages are meaningless with multiple cores. If one core is maxed out, then the load it too high. It is as simple as that.

[e-t172]

Besides, you don't seem to realize that using image filters on 1920x1080 images 60 times per second means huge amounts of computing power. I wouldn't be surprised if current CPUs are unable to handle that. Especially if it's not multithreaded.

[mindbomb]

iirc, the hq rgb conversion is multithreaded, i think iv read that before. the other filters, idk.

another ffdshow raw audio processor question:
should i uncheck 16 bit int for processing?

It appears to be used for 16 bit sources, but wouldn't be better to convert them to 32 int and then process them, as is the case with 24 bit audio?

[oddball]

Well if Cameron and Jackson have their way high speed video will become the norm. Hopefully computers will catch up enough to process it with all the bells and whistles. Since the GPU is not loaded much though is there any way for something like ffdshow to throw some of the load onto the GPU (I'm talking about development not now obviously)? It just seems crazy that the CPU is having to do all of the work when the GPU is hardly being taxed at all (and since video is what the GPU is for....well you get the picture).

[mindbomb]

mpc-hc shaders or madvr might suit your needs oddball

[jmone]

I'm unable to play a 1080p60fps clip fluidly with ffdshow in the filter chain. I get massive amounts of dropped frames.

I have no issue with my own (or the birds) 50/60p content using FFDSHOW with ffmpeg-MT as the decoder - libav will drops frames as you have described.

[oddball]

MadVR is what I am using. Shaders do not give the fine control like ffdshow does. I like to use the sharpening + deband + high quality YV12 to RGB + MadVR because I'm like that. :)

Anyhow it all works with everything up to 720p @ 60FPS. Just not 1080p @ 60FPS. I can live without it for now ;o]

[nevcairiel]

"high quality YV12 to RGB" does not work with madVR, because madVR does not accept RGB input. Chances are, its just not doing anything for you. :p

[oddball]

I did wonder about that. Unticked.

[VipZ]

I have a small request, if its to much hassle just ignore this :p

I would like to be able to remove non libav components and not show up in the configuration, ie ff_kernelDeint, ff_samplerate, TomsMoComp_ff. Similar how the audio/video decoder's if not present don't show up as a decoder option.

Also what purpose does this file, openIE.js serve?

Thanks

[fastplayer]

Also what purpose does this file, openIE.js serve?
Creates a URL and passes arguments to a database for ffdshow's whitelist/blacklist feature.

[VipZ]

Creates a URL and passes arguments to a database for ffdshow's whitelist/blacklist feature.

Thanks, so its one more file on the chopping block.

[mark0077]

Hi guys, is anyone here involved with ffmpeg-mt. I was using a audio / video sync test today and actually surprisingly found more issues with several decoders / filters / renderers in my setup.

It has mpeg4 x-vid 320x288 video. One issue I now notice is that with ffmpeg-mt as the video decoder, audio / video goes significantly out of sync, maybe 0.5 of a second.
(I notice a seperate issue with audio / video desync also with madVR which is seperate from this issue). This ffmpeg-mt issue happens with any video renderer so its definitely ffmpeg-mt related.

Using libavcodec in ffdshow as the video decoder, I don't get the audio / video out of sync issue. Is this something that someone could be interested in looking into.

I'm using ffdshow 32bit 3838. The avi is on this page.

Page: http://editorsean.com/blog/49-audiovideosynctest
Direct Link: http://editorsean.com/content/video/av_sync/sound_in_sync_test.avi

Let me know if you'd like any more information if anyone wants to take a look at fixing it.

[clsid]

Unless anyone knows why it happens, I think I will just remove MPEG4 from ffmpeg-mt. Maybe it is an issue with packed bitstream.
Does anyone have similar sync issues with ffmpeg-mt VP3 and HuffYUV?

[mindbomb]

so, is it actually ideal to uncheck 16 bit int in the processing tab of ffdshow in my case, where i am using the mixer of it?

[Andy o]

I should have posted this in this thread in the first place, but TrueHD 7.1 swaps sides and rear surrounds:
http://forum.doom9.org/showthread.php?p=1498728

[nevcairiel]

The channel order was actually wrong in ffmpeg - at least up until a few weeks ago until it was fixed in ffmpeg. I guess ffdshow didn't compensate for the upstream fix. I had to remove my custom reordering of TrueHD at that poin.

[clsid]

Was the channel order correct before, or was it always wrong with ffdshow?

Changing this line in reorder_ch.h might fix it:
change
#define AF_CHANNEL_LAYOUT_LAVC_MLP_8CH_DEFAULT AF_CHANNEL_LAYOUT_7_1_B
to
#define AF_CHANNEL_LAYOUT_LAVC_MLP_8CH_DEFAULT AF_CHANNEL_LAYOUT_7_1_A

[CruNcher]

could somebody add it

videocodec ffmjpegb
info "FFmpeg MJPEG-B"
status working
fourcc mjpb ; Apple MJPEG-B (Quicktime)
driver ffmpeg
dll mjpegb
out 444P
out 422P
out 440P
out YUY2 ; queryed (conversion from yuv422p)
out YV12,I420,IYUV

i guess only the fourcc is missing but i could be wrong and the whole mjpb part is,as mjpa works ;)

[clsid]

Tried adding it a while ago. It didn't work properly.

[iSunrise]

Hi guys, is anyone here involved with ffmpeg-mt. I was using a audio / video sync test today and actually surprisingly found more issues with several decoders / filters / renderers in my setup.

It has mpeg4 x-vid 320x288 video. One issue I now notice is that with ffmpeg-mt as the video decoder, audio / video goes significantly out of sync, maybe 0.5 of a second.
(I notice a seperate issue with audio / video desync also with madVR which is seperate from this issue). This ffmpeg-mt issue happens with any video renderer so its definitely ffmpeg-mt related.

Using libavcodec in ffdshow as the video decoder, I don't get the audio / video out of sync issue. Is this something that someone could be interested in looking into.

I'm using ffdshow 32bit 3838. The avi is on this page.

Page: http://editorsean.com/blog/49-audiovideosynctest
Direct Link: http://editorsean.com/content/video/av_sync/sound_in_sync_test.avi

Let me know if you'd like any more information if anyone wants to take a look at fixing it.
Nice find there mark0077.

Yes, it seems to be ffmpeg-mt related, there´s no problem whatsoever, when using ffmpeg (libavcodec) instead.

@clsid:
Did some various tests with mpeg4 (xvid) and VP3 (vp31) encoded files (.avi container) and all of them exhibit the same problem.

[clsid]

Is the sync is correct with 1 thread, and the difference bigger with more threads?

[mark0077]

Hi clsid, yes that seems to be the case. Using 1 thread I get no desync. With 2 I can't hardly notice any problem to be honest. With 4 I notice a desync. With 8 its very noticible.

Turns out the madVR issue I thought was there because of differences in desync between on/off of one of its settings "prevent several frames in advance", doesn't exist at all. I can't explain why ffmpeg-mt might show differences in video / audio desync with this madVR option but using libavcodec shows no desync issues with any other combination of settings so theres no madVR issues at all. Let me know if you'd like to test any builds with any potential fixes etc. No problem.

[clsid]

Sync problem does not happen with H264, right?
I haven't found the code yet that handles the delay caused by frame threading.

[hoborg]

Hi.
Can be FFDShow dxva decoder updated to latest MPC-HC source (including fix in 3090)?

[Falcon4]

Okay. Help me out here, because I think in answering this question, one of two things will happen: either I'll find a much easier way to get this simple task done, or the ffdshow devs will see why VFW encoders are important. Either way, I can't figure out at what point VFW encoders were removed - or why, since it's part of ffmpeg's functionality that ffdshow is supposed to expose to dshow. Thread is kind of a mess...

Here's what I'm trying to use ffdshow for. I have a crappy capture adapter that uses DirectShow. It's connected to a night-vision VHS-C camcorder mounted on a tripod on my porch. It watches my car. It works good. However, the software is a godd*mn nightmare. My intended purpose is to capture the incoming video, encode it quickly (dual-core Atom D510 can keep up with lossless x264 and temporal smoothing filters in realtime with ffdshow), and drop it onto HDD. 1 full day of video is about 30gb. Absolutely perfect for my needs.

Small problem, though. VFW sucks, but there are no alternatives. I really want to be able to use DirectShow directly, not mucking with ffdshow's VFW afterthought. But there don't seem to be any real DirectShow capture applications on the internet... at ALL. I've googled it endlessly, and always come up blank*. The cleanest I could find is using GraphStudio to manually link a filter chain together, and it worked (barely) for a while, but that's completely unacceptable as a long-term solution.
(* - edit: take a look at this page of useless results yourself: http://www.google.com/search?hl=en&safe=off&qscrl=1&q=x264+video+capture+software&aq=f&aqi=&aql=f&oq= )

Then there's the x264 side, which has been quoted as saying that x264vfw is a dirty hack and no longer maintained. Um... what?!

So, ffdshow-VFW no longer serves any useful purpose whatsoever (no encoders, no purpose... wtf?)... and x264-VFW is no longer maintained because it's a "dirty hack". In addition, I've seen a good number of people complaining about the decision to remove encoders from ffdshow... and the official version (beta) still has them! Imagine when this change goes through to the beta. You think it's a minority now? I think a lot more people use ffdshow's VFW encoder than is being given credit ;)

Now, the question: Without any modern and supported VFW encoders, what am I supposed to use to capture video to x264?

edit: think I'll start collecting "reasons why ffdshow's VFW encoders are the keystone of x264 video capture and removing them is practically suicide"...
http://doom10.org/index.php?topic=905.0

[clsid]

What you have read about x264VFW are no facts, but opinions from people who hate VFW (or rather putting H.264 in AVI). They would say the same about ffdshow.

Fact is that x264VFW is better and more up-to-date than ffdshow ever was. If you are stuck with VFW, x264VFW is what you should use.

[Falcon4]

What you have read about x264VFW are no facts, but opinions from people who hate VFW (or rather putting H.264 in AVI). They would say the same about ffdshow.

Fact is that x264VFW is better and more up-to-date than ffdshow ever was. If you are stuck with VFW, x264VFW is what you should use.

I only wish the fantasy world of opinion were true. Sadly, no, it's an x264 admin/dev that I'm quoting, directly from a Google search for "x264 vfw", second result.

http://forum.doom9.org/showthread.php?t=89979
"Q11: What'st the difference between VFW and CLI?
A: VFW is Video For Windows, an ancient tech created by microsoft (copying some stuff from quicktime), full of quirks and not able to support modern codecs. x264VFW is a ugly hack to make x264 work (more or less) with VFW, hence softwares like virtualdub and its modifications. The use of x264VFW is NOT recommended. x264 VFW is no longer officially supported."

(sadly, the 21,000+ downloaders of the latest version (http://sourceforge.net/projects/x264vfw/files/x264vfw/32_1913bm_27769/) of x264vfw would beg to differ on that "ugly hack" and "more or less" thing)

So who's gonna support capture? I've got the old, useless, buggy, outdated, clunky, piece of junk (according to... well, not many people but the devs) x264 encoder in ffdshow running in VDub right now cranking out 30fps lossless and noise-reduced video crunching through my Atom right now at 19% CPU. I think it works pretty g*ddamn well! :P

[nevcairiel]

Who says a x264 developer can't have opinions? They may think x264VfW is bad, and don't officially support it, it may however still work just fine, and other people seem to actively maintain it.

x264 in ffdshow vfw has not been maintained for ages, and is guaranteed to be more out of date then any x264vfw.
Did you try x264vfw? Maybe it just works, no matter what some x264 developer claims. :p

So you have x264 in ffdshow vfw, which the devs claim is a dirty hack, and was therefor removed (and not supported or maintained before anyway)
And you have x264vfw, which the x264 devs claim is a dirty hack, and do not officially support it - however other developers do!

Now you choose. :D

[Falcon4]

Seems that x264 inside ffdshow gets more love than x264vfw, and it's hard to see why users of ffdshow, inside an ffdshow thread, would be arguing against one of--... nay, it's only true calling in life, IMO. MPC-HC has a better h264 implementation, and the other encoders in ffdshow are pointless if x264 can do it all better... so I really don't understand why the idea could even be conceived to take x264 out of "the x264 implementation for Windows", ffdshow.

I mean, you might as well say that Steve Jobs' opinions of Apple don't really matter about Apple. That's about as much sense as watering-down an x264 dev's opinion of x264vfw makes... :P

At least ffdshow provides a GUI for x264's options... I installed x264vfw and tested it out, it provided the same quality (same exact settings as I used in ffdshow-VFW far as I could interpret) and the same filtering at about half the performance of what ffdshow's implementation gave me: it averaged 17FPS (from 30fps capture), with 100% CPU on one core, while ffdshow-VFW skidded away with 30FPS at about 60% CPU on one core (17% CPU usage on 4 logical CPUs). Put simply, x264vfw really does suck in comparison to what ffdshow already had implemented.

It's pretty rare for an application to take such a huge step in functionality, on a developer's whim, and actually have that decision be disputed by more than a small number of people, and still be supported by the developers. Seriously, it's project suicide.

[clsid]

If you want to be stubborn it is your choice. Fact is that x264 encoding support was removed from ffdshow for a valid reason. It was buggy and outdated. Plus it was just as much of a 'hack' as x264VFW and also was not officially supported by the x264 devs.

x264VFW is still being maintained and works much better.

If you don't like the minimalistic GUI of the official x264VFW build, then either use its command-line field for configuring options, or use Komisar's modified version which has a more extensive GUI.
http://komisar.gin.by/

[Falcon4]

Not trying to be stubborn... just stuck between a rock and a hard place - between ffdshow and x264vfw. Each one points at the other and calls it broken... well, with ffdshow doing more of the pointing-at-itself thing, it seems.

I think I speak for a lot more than just myself when I say that I don't really care for VFW. I'd MUCH rather use DirectShow itself. I mean, if that even makes any sense... I'd really love to see a DirectShow-based clone of VirtualDub. Anything, anything at all, that would allow me to accomplish my one basic task: capturing video directly to x264. I really don't care how it's done, I just want such a utility to exist!

I mean, are there seriously no alternatives? We have ffdshow-VFW (which is inexplicably being given the axe), and we have x264vfw, and that's it? Do I need to dust off the "C for Dummies" book and write my own? Hell, I can't even wrap my head around Visual C++ 6.0, I barely manage to code for Atmel AVR with AVR libc - and admittedly I do have a pretty good understanding of that code now, I wrote an interrupt-based multiplexed LED display driver for fun the other day and integrated it into an "ice maker turbo" project... but I have no idea how to write a Windows GUI application. I'd really want to develop a DirectShow-based VDub alternative for MP4 formats, that's not just a front-end for command-line apps like mp4box and friends...

[iSunrise]

Sync problem does not happen with H264, right?
I haven't found the code yet that handles the delay caused by frame threading.
H.264 works just fine.

[LigH]

The complaints were mainly related to a) using AVC video streams in the AVI container, and b) using the VfW API specifically.

a) AVI was not made for B-frames (an issue for Indeo 4 already, and all MPEG-1/2/4-in-AVI codecs as well, see Xvid with/without packed bitstreams) – especially not weighted ones, differences between non-IDR and IDR I-frames, multiple reference frames ... as the english idiom visualizes it, it is "pushing a square peg into a round hole". In contrast, the MP4 container has a matching square hole, the MKV container even an adjustable one... ;)

b) The VfW API is limited in several areas. Unfortunately, it is simply the most widely used one. Software supporting DirectShow encoder filters is possibly more sparse than CLI encoders. And Microsoft is already about to deprecate DirectShow, substituting it with the Media Foundation. How long will it take until programmers will accept that API (not only for decoders, but for encoders as well)?

But debating capturing directly into AVC is even more interesting, as it looks like the german idiom of "shooting sparrows with cannons": To make an AVC codec encode in real time, you may have to disable (or at least severly limit) all the features which make it most efficient. Especially long-term predictions and wide-range motion search, multiple referencing, weighted B-frame relations... Of course, x264 may be able to store live input. Just with a limited efficiency and complexity. So limited that it even fits in the AVI container ... uhm, what did I just say?! :o
__

P.S.: Just mentioning it – are there already any plans to expand ffdshow with Media Foundation API features?

[madshi]

And Microsoft is already about to deprecate DirectShow, substituting it with the Media Foundation.
Haha, yeah, sure. They also planned to replace the win32 API with the DotNet framework. You can't force developers to switch if they don't want to, unless you want to break compatability, which Microsoft never does, if they can help it.

[nevcairiel]

Except, Media Foundation is actually nice, its just the usual problem - someone has to actually start using it. I could write a player, and port my splitter and audio decoder - but that still leaves me short a video decoder and a proper renderer (the default EVR in MF is rather bad).

Personally, i would love to ditch DirectShow and use Media Foundation - it just needs more then one person do slowly steer the community in that direction. ;)

However, i don't exactly expect ffdshow to go MF, it just doesn't have any development resources at all anymore.

[madshi]

In what way do you like MF better? From what I've seen pretty much the only thing it does better is copy protection... ;)

[nevcairiel]

I actually ended up writing a small MF player one day, and in the process reading up about the whole pipeline from start to end, and it just feels more "designed" to do what it does, rather then DirectShow which basically just happend to end up as what it is now, without much design or logic behind it.

Anyhow, some key points that stood out for me:
- They got rid of the stupid media types and replaced it with a fully dynamic system, with pre-defined attributes for many of the information that were missing previously (especially decoder->renderer communication)
- Connection-less design, the filters don't have to manage the connection between each other anymore, the Media Session does that for you (and seems to work pretty good)

One of the biggest advantages, which i guess is rather subjective, but still "real" for me:
- A chance to get rid of the sub-par "standards" defined by Gabest filters, and the bugs in them that every other filter seems to actively work around, rather then fix it at its source.

Overall, it just felt alot more like you're actually focusing on developing the task you're trying to solve, and not trying to get your code to work with DirectShow.

PS:
I'm not really talking about end-user visible features, more like how working with the APIs feels from a coders perspective.. :)

[madshi]

Ok, sounds like a minor improvement to me, but you have to re-learn the whole framework, and you can't drop DirectShow support, unless you want to break compatability with 99% of the software out there. So I don't really see the sense of it.

[nevcairiel]

Thats the problem, isn't it. Advancement is impossible, because backwards compat is required.

[madshi]

I think advancement would still be possible, but the advantages of the advancement would have to be big enough to be worth supporting two different code paths.

[nevcairiel]

All the advantages from easier working with MF go down the drain if you still have to maintain DirectShow at the same time, eh.

[madshi]

Yeah. Maybe MS could have tried to hack in an intermediate layer to make every MF filter automatically DirectShow compatible somehow. That would have helped.

[SamuriHL]

Windvd 2010 uses solely media foundation and as a player is pretty darn stable. Ui blows but i've never seen it crash or slow down or any other "weirdness". I'd love to see an end to end open source mf playback solution. As Nev said, it seems cleaner.

[clsid]

Using MF instead of DS will not suddenly makes things more stable. Crashes are purely a code quality issue, not the fault of DS.

I assume that LAV Filters can relatively easily be made compatible with MF. I also assume that there will be a LAV Video decoder in the future. That leaves the need for a good renderer and subtitle support. madVR might one day fill the void of the first. Subtitle support is best implemented directly in the renderer. An external library for subtitles then comes to mind. That could then also be re-used to for example replace the current sub renderer in MPC-HC.

Two reasons for using MF would be (1) to use in a new player, and (2) to extend the current capabilities of WMP/MC.

Question in case 2 is: is it possible to replace or override the existing MS MF codecs? Afaik there is no merit system and the registry keys are protected (which can be worked around, but that is obviously not ideal).

[nevcairiel]

You cannot easily override the MF codecs used by WMP, except removing them from the "preferred codecs" list (the protected keys you're talking about), but isnt that the same with DS?

[clsid]

There are fewer DS filters from MS, so the problem is less obvious in that case. It is mostly WMV and MP3 that are 'locked in'. Things like the preferred MPEG2/AC3 decoder are configurable.

Maybe things will be better in Windows 8. For example support for VC1 in M2TS is non-existent simply because they didn't have enough time to implement it before win7 was finished.

[HeadlessCow]

Two reasons for using MF would be ... (2) to extend the current capabilities of WMP/MC.
.

Media Center (and Media Center Extenders) are exactly the reason I'd love to see more MF support. Divx5 offers an MKV splitter that's able to work (and stream to the Xbox360) but, since that's the only thing it adds, you still end up giving up and just installing Directshow codecs for everything.

Of course, given the lack of any useful MF codecs, who knows what will actually stream properly to the 360... :(

[therobin]

Is anyone here willing to add a hack to ffdshow VFW implementation to accept HDYC FourCC input? HDYC is the FourCC used by Blackmagic Design hardware for HD input to indicate UYVY input using BT.701 color space. Doing this will allow the use of ffdshow's HUFFYUV codec to capture HD video with ease (no need for massive HDDs or RAID with a good CPU). Currently the only hack of huffyuv that allows this is 32bit only and is difficult to install on 64bit systems. And it would be great to have access to all the tools in ffdshow VFW for capturing HD video.

See this thread on VirualDub forum for more details: http://forums.virtualdub.org/index.php?act=ST&f=6&t=16116&hl=hdyc&
The author of the mod states "The huffyuv build does nothing special. All I did was modify GetBitmapType to accept UYVY || HDYC."

[pankov]

dear developers,
I've been struggling for a long time when using FFDShow audio decoder in MPC-HC (you can look at my posts in the MPC-HC thread here http://forum.doom9.org/showthread.php?p=1498882#post1498882 and in a few followup posts) and finally tonight I found which setting is causing the problem.
It's the "addToROT"=dword:00000001 registry value.
Can somebody, please, explain what it does and what's its GUI representation?
Also does anybody have an idea why it can cause MPC-HC behave so strage? Is it a bug in FFDShow or is it in MPC-HC?

[clsid]

There is no setting in the GUI for that. The default value is 0, so I am curious why it was at 1 for you.

[clsid]

Some info about the purpose of the option:
http://msdn.microsoft.com/en-us/library/dd390650(v=vs.85).aspx

[pankov]

There is no setting in the GUI for that. The default value is 0, so I am curious why it was at 1 for you.
I have absolutely no idea, but since I've been using the same settings for several years (imported from .reg files) I guess it's default value could have been different in the past ... or something else could have changed it. In fact I've just looked at my backups and saw that this setting was set to "1" even in my oldest Registry export from 26.02.2005.
I've turned it off now but the question why it causes such behavior in MPC-HC remains. Is this MPC's fault ... or is it a fault at all? Sadly I don't understand that much about DirectShow, but what's the purpose of this setting in ffdshow itself? is it ffdshow that's connecting to remote graphs or it's the other way around?

[clsid]

It is for other apps to connect to a graph in which ffdshow is present. For example the "connect to remote graph" function in GraphEdit. Or apps that make use of the RemoteAPI for controlling ffdshow settings.

[XhmikosR]

@clsid: ffdshow is crashing for me after r3842 (probably r3844 is the rev which the crash started) with this (http://www.mediafire.com/file/4x636dmmrrfgv56/CrowdRun_720p50.x264.CRF23.10bit.mkv) 10bit h264 video using ffmpeg-mt. r3847 still crashes.

BTW, I'm getting the following warnings when compiling ffmpeg-mt which I guess it's cause by #define HAVE_PTHREADS 1 in ffmpeg-mt's config.h.


In file included from libavcodec/pthread.c:33:0:
libavcodec/../../pthreads/pthread.h:108:0: warning: "PTW32_LEVEL" redefined [enabled by default]
libavcodec/../../pthreads/pthread.h:95:0: note: this is the location of the previous definition
In file included from libavcodec/../../pthreads/pthread.h:302:0,
from libavcodec/pthread.c:33:
../pthreads/sched.h:64:0: warning: "PTW32_LEVEL" redefined [enabled by default]
../pthreads/sched.h:51:0: note: this is the location of the previous definition libavcodec/utils.c: In function 'avcodec_open':

As for the ICL12 builds and the crashes I mentioned in my previous (https://forum.doom9.org/showthread.php?p=1492027#post1492027) post, I'm still getting them with ffmpeg and ICL12 builds but it doesn't happen with all the h264 videos. And the problem is that if I cut a sample I cannot reproduce the crash. I'll try to find the smallest available sample which can be used to reproduce the crashes. BTW, it doesn't matter if I use ffmpeg or ffmpeg-mt, it's crashing in both cases.

EDIT: r3848 still crashes with the above 10bit h264 video.

[clsid]

To fix it support needs to be added to ffdshow for handling the newlly added PIX_FMT_YUV420P9 and PIX_FMT_YUV420P10 colorspaces.

[nevcairiel]

swscale supports them as input formats , so you can convert them to any of the supported output formats using that pretty easily (even with dithering for the 10->8 conversion). Of course it would be preferable to output the actual 10bit data, if the renderer supports it, but thats alot more work, as these special 10bit DirectShow formats are not supported by swscale. ;) (and only madVR supports them for rendering, anyhow)

PS:
I don't follow libav development, as i use ffmpeg - so i cannot comment if the swscale support arrived in libav as well.

[clsid]

I have added a workaround to get the old behavior. That fixes the crash until the proper colorspace conversion is added.

swscale is already up-to-date, so it is just a matter of updating ffdshow.

[XhmikosR]

It seems to work like before in r3850, i.e. no crashes with 10bit videos.

Now about the ICL12 builds crash, I though I'd remove any workarounds in "libavcodec\golomb.h". And what do you know? It doesn't crash anymore. I haven't tried any debug builds though.
So clsid, since MSVC2010 and ICL12 work fine for me and you are the only one know who's using ICL10 and MSVC2008, can you confirm that this (http://pastebin.com/1DvjP0Lz) patch doesn't cause any crashes for you?
Test builds here (http://www.mediafire.com/?f36tdla8g54fw) for anyone who had crashes with h264 videos and ICL12.

Also, how about the ffmpeg-mt pthreads warnings I told you in my post above?

[VipZ]

I was about to post a bug that I had a file with h264 that crashed under x64 but was ok under x86, XhmikosR's golomb fix has fixed this now :)

[clsid]

This file posted by VipZ crashes with MSVC2008 x64 build with that change:
http://www.mediafire.com/?krlxvlj8sb67n90

Do you have more files that I should test?

The weird thing is about this whole issue is that the workaround is for compilers that somehow fail to expand the macro properly. It should not have a negative effect on compilers that do process the macro properly, since the manually expanded code should be equivalent.

[VipZ]

Clsid, here is the sample I was going to post about the crash issue, http://www.mediafire.com/?aajakpfoe8utg24

[XhmikosR]

This file posted by VipZ crashes with MSVC2008 x64 build with that change:
http://www.mediafire.com/?krlxvlj8sb67n90

Do you have more files that I should test?

The weird thing is about this whole issue is that the workaround is for compilers that somehow fail to expand the macro properly. It should not have a negative effect on compilers that do process the macro properly, since the manually expanded code should be equivalent.

Well all I know is that with that change the ICL12 crashes are gone for me. MCVS2010 x86 builds work as before, i.e. no crashes, with or without the patch.

But with that sample the ICL12 build indeed crashes, even with that pacth. The MSVC2010 build with my patch doesn't crash. The MSVC2010 build without my patch doesn't crash either. I cannot try the x64 builds since I'm on 32bit Windows. BTW, that sample doesn't play smoothly for me anyway.

Clsid, here is the sample I was going to post about the crash issue, http://www.mediafire.com/?aajakpfoe8utg24

With this sample, the unpatched ICL12 build crashes. The patched ICL12 build doesn't. MSVC2010 isn't affected, it doesn't crash with or without the patch.

[clsid]

x86 builds work fine. It is only the MSVC x64 builds that are having problems.

[SamuriHL]

I just built msvc2010 x86. No problem. I did not do an x64 build.

[VipZ]

As far as I discovered about this issue ICL12 and MSVC2010 x64 behave the same way, while MSVC2010 x86 seems to never have an issue.
I tested a MSVC2008 x64 build (ffdshow_rev3844_20110510_clsid_x64.exe) which crashes as well.

With this test patch it would seem to fix 3 builds, but break 1.

[XhmikosR]

Well, I don't use MSVC2008. Does the MCVS2010 x64 build crash, with or without the patch?

[clsid]

The problem is with the files. I got three test files, MKV/MP4/FLV. Either the FLV crashes and the other two work, or vice versa.

What bothers me is that the code is essentially the same, so I don't understand why the results are different.

[XhmikosR]

If the MSVC2010 builds work I'm fine with it. If not then it's something someone should dig into more.

[VipZ]

Well, I don't use MSVC2008. Does the MCVS2010 x64 build crash, with or without the patch?

Without patch MCVS2010 x64 crashes and with patch its fine.

IMO the patch is good.

[XhmikosR]

Then I'm good. No one is using MSVC2008 except for clsid. So unless he can find a better fix (like using #if _MSC_VER < 1600), I will commit the patch tomorrow.

I still wait for this


BTW, I'm getting the following warnings when compiling ffmpeg-mt which I guess it's cause by #define HAVE_PTHREADS 1 in ffmpeg-mt's config.h.

In file included from libavcodec/pthread.c:33:0:
libavcodec/../../pthreads/pthread.h:108:0: warning: "PTW32_LEVEL" redefined [enabled by default]
libavcodec/../../pthreads/pthread.h:95:0: note: this is the location of the previous definition
In file included from libavcodec/../../pthreads/pthread.h:302:0,
from libavcodec/pthread.c:33:
../pthreads/sched.h:64:0: warning: "PTW32_LEVEL" redefined [enabled by default]
../pthreads/sched.h:51:0: note: this is the location of the previous definition libavcodec/utils.c: In function 'avcodec_open':

[clsid]

Try this patch:
Index: golomb.h
===================================================================
--- golomb.h (revision 3848)
+++ golomb.h (working copy)
@@ -3,25 +3,25 @@
* Copyright (c) 2003 Michael Niedermayer <michaelni@gmx.at>
* Copyright (c) 2004 Alex Beregszaszi
*
- * This file is part of FFmpeg.
+ * This file is part of Libav.
*
- * FFmpeg is free software; you can redistribute it and/or
+ * Libav is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
- * FFmpeg is distributed in the hope that it will be useful,
+ * Libav is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
+ * License along with Libav; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/

/**
- * @file libavcodec/golomb.h
+ * @file
* @brief
* exp golomb vlc stuff
* @author Michael Niedermayer <michaelni@gmx.at> and Alex Beregszaszi
@@ -37,9 +37,6 @@
#include <stdint.h>
#include "get_bits.h"
#include "put_bits.h"
-#ifdef HAVE_AV_CONFIG_H
-#include "libavutil/common.h"
-#endif

#define FFMIN(a,b) ((a) > (b) ? (b) : (a))

@@ -63,18 +60,31 @@
unsigned int buf;
int log;

- OPEN_READER(re, gb);
/* ffdshow custom code */
-#if defined(__INTEL_COMPILER) || defined(_MSC_VER)
- #ifdef ALT_BITSTREAM_READER_LE
- re_cache= AV_RL32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #else
- re_cache= AV_RB32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #endif
+#if 1 /*&& defined(_MSC_VER) && defined(WIN64)*/
+ unsigned int re_index = (gb)->index;
+ unsigned int re_cache = 0;
+ re_cache= av_bswap32( ((((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[3] << 24) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[2] << 16) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[1] << 8) | ((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[0]) ) >> (re_index&0x07);
+ buf=(uint32_t)re_cache;
+
+ if(buf >= (1<<27)){
+ buf >>= 32 - 9;
+ re_index += ff_golomb_vlc_len[buf];
+ (gb)->index = re_index;
+
+ return ff_ue_golomb_vlc_code[buf];
+ }else{
+ log= 2*av_log2(buf) - 31;
+ buf>>= log;
+ buf--;
+ re_index += 32 - log;
+ (gb)->index = re_index;
+
+ return buf;
+ }
#else
- // ICL and MSVC compilers sometimes mess up this macro
- UPDATE_CACHE(re, gb);
-#endif
+ OPEN_READER(re, gb);
+ UPDATE_CACHE(re, gb);
buf=GET_CACHE(re, gb);

if(buf >= (1<<27)){
@@ -92,6 +102,7 @@

return buf;
}
+#endif
}

/**
@@ -101,23 +112,25 @@
static inline int get_ue_golomb_31(GetBitContext *gb){
unsigned int buf;

+ /* ffdshow custom code */
+#if 1 /*&& defined(_MSC_VER) && defined(WIN64)*/
+ unsigned int re_index = (gb)->index;
+ unsigned int re_cache = 0;
+ re_cache= av_bswap32( ((((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[3] << 24) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[2] << 16) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[1] << 8) | ((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[0]) ) >> (re_index&0x07);
+ buf=(uint32_t)re_cache;
+
+ buf >>= 32 - 9;
+ re_index += ff_golomb_vlc_len[buf];
+ (gb)->index = re_index;
+#else
OPEN_READER(re, gb);
- /* ffdshow custom code */
- #if defined(__INTEL_COMPILER) || defined(DEBUG)
- #ifdef ALT_BITSTREAM_READER_LE
- re_cache= AV_RL32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #else
- re_cache= AV_RB32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #endif
- #else
- // ICL9.1-Release and MSVC8-DEBUG build can't process this macro properly.
UPDATE_CACHE(re, gb);
- #endif
buf=GET_CACHE(re, gb);

buf >>= 32 - 9;
LAST_SKIP_BITS(re, gb, ff_golomb_vlc_len[buf]);
CLOSE_READER(re, gb);
+#endif

return ff_ue_golomb_vlc_code[buf];
}

[XhmikosR]

I don't see why you have to complicate things and not use the vanilla code from libav. Anyway, I'll try it tomorrow, but I prefer my solution since it's cleaner and it works for the newer compilers.

[clsid]

Yours doesn't work in all cases. I am going to commit a better patch.

The pthread warning should be harmless. See the pthread headers.

[XhmikosR]

Mine works for all the recent compilers. The fact that you want to use an old compiler means nothing.
Do whatever you want, the crash was there for so long, I know my patch works, while yours is just complicating things and doesn't use vanilla code. Your patch is untested except from you with your compiler. ffdshow has enough custom code where no one really knows if it's needed except from you. You can go this way, or try to make things cleaner. If something is present in vanilla libav code then forward the problem to the respective developers.

[clsid]

MSVC2008 is not an old compiler. Besides, the alternate code will only be used for compilers that have an issue. Since it is a compiler issue, the Libav developers can not and will not fix it.

[hoborg]

It is only me? I got graphstudio freezes -black screen (audio still play) if i try to play h.264 using FFDshow DXVA decoder.
Using x86 2010 build 3844

I tryed older build 3775 and there is no such issue.
I will try track down revision where the problem is introduced later.

[adam777]

Hello all,
A sort of bug - the change introduced in rev 3843 causes some codecs that were set to ffmpeg-mt to remain blank in the codecs list, and crashes FFDShow as soon as one is being accessed (see http://i.imgur.com/3MBLK.png).
Should fallback to default libavcodec.
Adam.

[TheRyuu]

Fix libmpeg2 compilation with gcc/g++.
That FORCECPP flag is nice consider it never gets read anywhere...

libmpeg2 should get compiled with gcc though I thought, not g++. So would the proper way to fix this be to #ifdef _cplusplus the extern "C" parts (or does it not really matter)?

Index: src/codecs/libmpeg2/Makefile
===================================================================
--- src/codecs/libmpeg2/Makefile (revision 3851)
+++ src/codecs/libmpeg2/Makefile (working copy)
@@ -34,7 +34,6 @@
### SETTINGS ###

CFLAGS+= -I. -Iinclude
-FORCECPP=1

#CFLAGS+=-fverbose-asm -save-temps

@@ -45,6 +44,7 @@
### INCLUDES ###

include ../../makefile_c.inc
+CC=g++.exe


### TARGETS ###

[VipZ]

I just complied the 3851 x64 build with MCVS2010, no more crashes for me.

I got a question regarding the solution files, is there any reason for all builds to go into same folder instead of something like bin_MCVS2010_x64?

[VipZ]

Currently there are no good batch files to build ffshow and created one due to this. The main difference for this one is that is doesn't create an installer, but creates a rar file (I make my own custom installers)

buildall_2010.bat,
@ECHO OFF

call "%VS100COMNTOOLS%vsvars32.bat"

cd bin
rm *.exe *.dll *.ilk *.ax *.vdf *.acm
cd ..\
devenv ffdshow_2010.sln /Rebuild "Release|Win32"
rd /S /Q obj\MinGW32
FOR %%A IN (ffmpeg ffmpeg-mt
) DO (
PUSHD "src\%%A"
make clean
make -j4
POPD
)

cd bin
"%programfiles%\WinRAR\rar.exe" a ffdshow_x86.rar *.exe *.dll *.ilk *.ax *.vdf *.acm
cd ..\

cd bin
rm *.exe *.dll *.ilk *.ax *.vdf *.acm
cd ..\
devenv ffdshow_2010.sln /Rebuild "Release|x64"
rd /S /Q obj\MinGW64
FOR %%A IN (ffmpeg ffmpeg-mt
) DO (
PUSHD "src\%%A"
make 64BIT=yes
make -j4
POPD
)

cd bin
"%programfiles%\WinRAR\rar.exe" a ffdshow_x64.rar *.exe *.dll *.ilk *.ax *.vdf *.acm
cd ..\

cd bin
rm *.exe *.dll *.ilk *.ax *.vdf *.acm
cd ..\

Would it be asking to much for this to be added to the svn? And modified if required.

[hoborg]

It is only me? I got graphstudio freezes -black screen (audio still play) if i try to play h.264 using FFDshow DXVA decoder.
Using x86 2010 build 3844

I tryed older build 3775 and there is no such issue.
I will try track down revision where the problem is introduced later.

OK, 3842 is working, 3844 - 3847 = black screen.

No one have this issue?

[clsid]

Yes, it gets stuck on the first frame. I will try to fix it later today.

[TheRyuu]

What's the status on fixing 10bit h264?

I think currently ffdshow requests YV12 8bit no matter what the input is.

[sneaker_ger]

What's the status on fixing 10bit h264?

I think currently ffdshow requests YV12 8bit no matter what the input is.

I'm totally confused about 10bit encoding/decoding. A few posts above XhmikosR posted this supposedly 10bit sample (http://www.mediafire.com/file/4x636dmmrrfgv56/CrowdRun_720p50.x264.CRF23.10bit.mkv) and it decodes just fine using ffdshow 3850, but when I encode something using x264-10bit it's totally garbled. :confused:

[clsid]

9bit/10bit H.264 is not yet supported.

@hoborg
DXVA is fixed in 3853

[betaking]

3853 use ffdshow dxva if seek mpc-hc crash!
General
ID : 1 (0x1)
Complete name : E:\TEST.ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 51.6 MiB
Duration : 29s 770ms
Overall bit rate : 14.5 Mbps
Maximum Overall bit rate : 35.5 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
Codec ID : 27
Duration : 29s 655ms
Bit rate mode : Variable
Bit rate : 13.9 Mbps
Maximum bit rate : 40.0 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.279
Stream size : 48.4 MiB (94%)
Writing library : x264 core 67 r1139M 1024283

[clsid]

I have no seeking problems here with DXVA. Please upload a sample file.

[CiNcH]

Hey guys, I don't like installers too much. So I always register ffdshow manually and import my settings into the registry. ffdshow DXVA is not working this way however. The app simply crashes when using the DXVA decoder for H.264. Which file do I have to copy where to get it working?

[EDIT]
OK, I think it's latest builds that break DXVA for me, somewhere between 3814 and 3851.

[VipZ]

Hey guys, I don't like installers too much. So I always register ffdshow manually and import my settings into the registry. ffdshow DXVA is not working this way however. The app simply crashes when using the DXVA decoder for H.264. Which file do I have to copy where to get it working?

[EDIT]
OK, I think it's latest builds that break DXVA for me, somewhere between 3814 and 3851.

I may be wrong, but all you need to do is make sure HKEY_LOCAL_MACHINE\SOFTWARE\GNU\ffdshow\noDxvaDecoder is set to 0 in your reg file and import this before you register the ax.

[CiNcH]

I used the installer by clsid now. With Rev. 3814, DXVA works, with Rev. 3851, it doesn't.

[Superb]

I used the installer by clsid now. With Rev. 3814, DXVA works, with Rev. 3851, it doesn't.
Read:
9bit/10bit H.264 is not yet supported.

@hoborg
DXVA is fixed in 3853

[CiNcH]

Ah sh**. Sorry guys :( . I just read the revision history within SVN and there was no mention about that...

Thanks!

[CruNcher]

Could somebody take a look @ this and maybe try to reproduce ? http://forum.doom9.org/showpost.php?p=1501021&postcount=559

[hoborg]

Hi.
Can be FFDShow dxva decoder updated to latest MPC-HC source (including fix in 3090)?

@clsid:
Can you please integrate this fix? Just tryed 3853 and it is still crashing :/
DXVA working now again, thanks for fixing it!

[god_md5]

i find ass 4.0++ is not support in ffshow
get info here
http://code.google.com/p/vsfiltermod/
http://docs.aegisub.org/manual/Attaching_subtitles_to_video
http://asa.diac24.net/
http://dl.dropbox.com/u/3668343/ScreenHunter_19%20May.%2016%2021.18.jpg
http://dl.dropbox.com/u/3668343/Rainbow__To%20Me%20_GomTV.ass
h264 i use 3842 is work ,other is black or hang..

[_xxl]

Maybe it is a good time to start a new ffdshow tread, this one is really big 679 pages. Just ffdshow ( ffdshow - tryout ) something like this. I would like to hear your opinion.

[cyberbeing]

If a new thread is started, there should be some sort of landmark dividing the two. Revision ranges? New beta released? Significant new features landing? Splitting for length alone isn't a great reason, unless the forum software on Doom9 has issues with massive threads.

If you want an excuse to start a new thread, wait for all the FFDshow-specific coding to complete (hopefully very soon if not already) which will bring full-support of High10 H264 decoding to FFDshow. There appears to be an push by Dark Shikari and others for people to code what is necessary for FFDshow ASAP. That would be as good a landmark as any to start a new thread.

[Mr VacBob]

i find ass 4.0++ is not support in

ASS++ should not be supported.

[clsid]

@clsid:
Can you please integrate this fix? Just tryed 3853 and it is still crashing :/
DXVA working now again, thanks for fixing it!
Those changes have already been integrated.

[hoborg]

Those changes have already been integrated.

Strange, it still crashing for me :/
MPC-HC decoder working fine.
Only difference is, that it will now popup some kind of VC++ error message.
http://www.volny.cz/hoborg/crash.jpg

[TheRyuu]

So about that libmpeg2 gcc fix (http://forum.doom9.org/showthread.php?p=1500198#post1500198)...

[Mr VacBob]

I made a commit to ffmpeg-mt which should fix the problem with 'Avatar-Bluray-ffmpeg-mt-corruption.m2ts'. However, since the problem doesn't reproduce with ffplay, I haven't actually tested this. Also, I suspect it's made the decoder noticeably slower per thread :/

10-bit is also merged in, but one of the tests fails with threading on, and I haven't spotted the problem yet.

[CruNcher]

recent tests i did showed the libavcodec mpeg-2 part is much faster in a multithreaded framework then the libmpeg2 decoder in the current ffdshow (4 cores), ffdshow_rev3853_20110512_xhmikosr_icl12.exe <- tested, does this include the newest ffmpeg-mt ?
Dscaler IVTC mod was surprisingly being such old the fastest (+ 3 fps) :), though Dscaler differs output wise from libavcodec/libmpeg2 in ffdshow on interlaced material with it's field selection it seems (it's not identical to ffdshow)

[clsid]

@hoborg
Wasn't that a broken file? Can you upload it for me? Then I can try to fix the crash.

@TheRyuu
I will have a look at it this weekend.

@Mr VacBob
Great! I will update asap.

@CruNcher
The libavcodec mpeg2 decoder uses slice based threading. It has done that for ages already. It doesn't use frame based threading like ffmpeg-mt does.

[CruNcher]

@hoborg
Wasn't that a broken file? Can you upload it for me? Then I can try to fix the crash.

@TheRyuu
I will have a look at it this weekend.

@Mr VacBob
Great! I will update asap.

@CruNcher
The libavcodec mpeg2 decoder uses slice based threading. It has done that for ages already. It doesn't use frame based threading like ffmpeg-mt does.

Ahh sorry i see ffmpeg-mt for mpeg-2 is not in ffdshow yet, but seeing that dscaler does better then libavcodec in ffdshow (performance) still surprises me wasn't it based on libmpeg2 ?

[hoborg]

@hoborg
Wasn't that a broken file? Can you upload it for me? Then I can try to fix the crash.


Here. (https://rapidshare.com/#!download|174l33|460405805|Vier-001.mkv|208343|R~DAD95AF63AE21AE41766FD0C84817C44)

[Mr VacBob]

@CruNcher
The libavcodec mpeg2 decoder uses slice based threading. It has done that for ages already. It doesn't use frame based threading like ffmpeg-mt does.

MPEG2 uses slice threading in ffmpeg-mt. All MPEG2 files have lots of slices, so I think this is faster.

[Sven75]

I have a specific issue in PowerPoint 2010 which seems to be caused by ffdshow. Starting with builds > 3763 PowerPoint freezes when trying to play dv files (at least dvsd) in the 2010 native mode (the mode in which the PowerPoint displays a timeline for the videos).

I tried several other decoders (Medialooks, Microsoft - among others) and they do not exhibit this behaviour. Also, I tried it on different computers with Win7 64 bits (e. g. Intel H55 - Intel Graphics, Intel P35 - AMD ATI Graphics, etc.).

Maybe someone here using PowerPoint 2010 (or the free player) can help me with this. I already posted this issue in the bug tracking system and I would be very grateful for a solution.

The following 2 files demonstrate the problem:

http://www.mediafire.com/?3q2wxwne4bxnxb5 (DVSD_Example.avi)
http://www.mediafire.com/?gcarlp7h4k66vbh (DVSD_Example.pptx with linked video)

Beside the PowerPoint 2010 issue, I came across the following two files which could not be decoded at all by ffdShow (using LAVSplitter):

http://www.mediafire.com/?8fwcaxepy3xca4v (Apple_DVCP_small.mov)
http://www.mediafire.com/?ch5rgnqbam6gi1v (WMV3_WMV9.wmv)

Could this just be a matter of a missing media type or are these formats simply not implemented? If they are not available at all, does someone know which ds decoders support these? (while not being dmo decoders/source filters/splitters at the same time as I would very much prefer to keep using LAVSplitter as my default splitter for wmv/mov files)

[hoborg]

Strange, it still crashing for me :/
MPC-HC decoder working fine.
Only difference is, that it will now popup some kind of VC++ error message.
http://www.volny.cz/hoborg/crash.jpg

I noticed this error popup with a lot of *.TS HD/FullHD recordings too, even if i disable FFDShow DXVA decoder and use FFMPEG-MT.

[clsid]

I have a specific issue in PowerPoint 2010 which seems to be caused by ffdshow. Starting with builds > 3763 PowerPoint freezes when trying to play dv files (at least dvsd) in the 2010 native mode (the mode in which the PowerPoint displays a timeline for the videos).

I tried several other decoders (Medialooks, Microsoft - among others) and they do not exhibit this behaviour. Also, I tried it on different computers with Win7 64 bits (e. g. Intel H55 - Intel Graphics, Intel P35 - AMD ATI Graphics, etc.).

Maybe someone here using PowerPoint 2010 (or the free player) can help me with this. I already posted this issue in the bug tracking system and I would be very grateful for a solution.

The following 2 files demonstrate the problem:

http://www.mediafire.com/?3q2wxwne4bxnxb5 (DVSD_Example.avi)
http://www.mediafire.com/?gcarlp7h4k66vbh (DVSD_Example.pptx with linked video)

Beside the PowerPoint 2010 issue, I came across the following two files which could not be decoded at all by ffdShow (using LAVSplitter):

http://www.mediafire.com/?8fwcaxepy3xca4v (Apple_DVCP_small.mov)
http://www.mediafire.com/?ch5rgnqbam6gi1v (WMV3_WMV9.wmv)

Could this just be a matter of a missing media type or are these formats simply not implemented? If they are not available at all, does someone know which ds decoders support these? (while not being dmo decoders/source filters/splitters at the same time as I would very much prefer to keep using LAVSplitter as my default splitter for wmv/mov files)
The powerpoint issue is probably related to some colorspace changes that were made some time ago. Please play a bit with the settings on the Output page in an older version of ffdshow to see if you can reproduce the problem of the newer versions. For example disable RGB24.

[Sven75]

This is what I was assuming too when I read the changelogs after version 3763.

I already tried enabling and disabling all output colorspaces and related options. In every version (I tried) after 3763 and up to 3853 PowerPoint always freezes in the same way when starting the video (not displaying a single frame of the clip).

In version 3611 I cannot make PowerPoint freeze - no matter which colorspace setting I use. Also, as soon as I deactivate all YUV colorspaces and 32 bit RGB (leaving enabled only 24 bit RGB in the settings) PowerPoint will no longer use ffdshow at all but fallback to AVI Compressor (resulting in a terrible image quality, but not freezing).

[clsid]

I will try to reproduce once I have all the parts of my new dev PC.

[Sven75]

Ok, great - thank you!

[Superb]

The powerpoint issue is probably related to some colorspace changes that were made some time ago. Please play a bit with the settings on the Output page in an older version of ffdshow to see if you can reproduce the problem of the newer versions. For example disable RGB24.You guys should also see: http://forum.doom9.org/showthread.php?p=1498171#post1498171

Probably caused by the same commit.

[Spynask]

I found a problem with ffdshow video decoder. It detects my x264-encoded video's framerate as 25 fps, which is incorrect (23.976 is the correct framerate), this causes the video and audio to be unsynced. The problem occurs only when I set x264's input directly to the mkv, not AviSynth script. I tried CoreAVC and MPC-HC internal decoder, they are fine. I'm using ffdshow tryouts r3800 (MSVC 2008, x86, unicode).
Here is the sample: http://www.mediafire.com/?fxp9699r9ius6gh

[Chikuzen]

I found a problem with ffdshow video decoder. It detects my x264-encoded video's framerate as 25 fps, which is incorrect (23.976 is the correct framerate), this causes the video and audio to be unsynced. The problem occurs only when I set x264's input directly to the mkv, not AviSynth script. I tried CoreAVC and MPC-HC internal decoder, they are fine. I'm using ffdshow tryouts r3800 (MSVC 2008, x86, unicode).
Here is the sample: http://www.mediafire.com/?fxp9699r9ius6gh

I reproduced it with ffdshow-tryouts r3853.
Strangely, when I remuxed your sample with mkvmerge v4.5.0, that problem was solved.
http://www.mediafire.com/download.php?2dv9a61eq9ow482
I cannot judge the cause is either ffdshow or mkvmerge :confused:

[BloodySword]

Hi everybody. I have a small problem with mpeg2 decoding with ffdshow tryouts.

System details:
Windows 7 Professional x64
ffdshow tryouts rev3851 May 12 2011 03:05:21 (ICL 10, x86, unicode, r)

When I use libavcodec to decode mpeg2 I have massive A/V synch problems when using Yadif or Kernel bob deinterlacing while playing vob files.
When I use libavcodec to decode DVB-T (Hauppauge WinTV 7) everything's fine, deblocking and deringing works
But I can not play vob files well :(

When I use libmpeg2 instead it works find for both vob and DVB-T. But: Deblocking and deringing does not work.
It seems like the quantizer reported from libmpeg2 is so high (1 or 0) that deblocking does simply nothing,
regardless if I set strenghth to 200% or not. I use mplayer deblocking with all filters active: Deblock, Dering, H V Luma and Chroma.

How can I force libmpeg2 to deblock and dering? :(

Edit: The newest version of ffdhow (above) crashes at the end of a VOB file (looks like while retrieving last frame).

Thank you in advance.

[cyberbeing]

@Spynask & Chikuzen

No 'Default Duration' (default frame duration aka frame-rate) is specified in Spynask's MKV container, but since that element is non-mandatory, the MKV is still following spec and should be able to be handled correctly. A bug in FFDshow must causing it to default to 25fps when the splitter doesn't report a 'Default Duration', rather than determining the frame-rate from the video stream. Chikuzen, your file does specify a 'Default Duration', so you must have specified a frame-rate when re-muxing with mkvmerge.

[VipZ]

Hi,

I have found that with this sample, ffdshow doesn't honour the AR flag's, MPC displays at the correct AR.

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

Thanks

[clsid]

AR is correct when using Haali splitter. But that replaces some data in the video stream with AR info from the container.

You might be able to 'fix' the problem by remuxing the file.

[VipZ]

I was using LAV Splitter for this, which does pass the AR to MPC decoders. When creating the sample I verified the AR was set correctly when remuxing (mkvmerge 4.7.0)

[hoborg]

Strange, it still crashing for me :/
MPC-HC decoder working fine.
Only difference is, that it will now popup some kind of VC++ error message.
http://www.volny.cz/hoborg/crash.jpg

Here is a .ts sample. (https://rapidshare.com/files/1479703935/crash.zip)

FFDShow DXVA = crash
FFDShow ffmpeg-mt = crash
FFDShow libavcodec = working fine

[clsid]

H.264 crash is fixed.

[alexins]

clsid, in ffdshow r.3857 not fully work decoding of video files using the libavcodec and ffmpeg-mt. Via DXVA decoding works well.

[clsid]

Please be more specific about what is wrong. I don't notice any problems.

Also test 3855.

[hoborg]

H.264 crash is fixed.

I just tested 3855 and both samples (MKV + TS) still crashing with FDshow DXVA decoder.
ffmpeg-mt working now.

[clsid]

DXVA crash fixed in 3858.
Powerpoint freeze fixed in 3859.

[Sven75]

Any specific reason why it only froze with dvsd and PowerPoint? From what I can deduce from the code changes it does not have anything to do with colorspaces but rather with setting ar info for the video renderer, does it?

Anyway, I will try 3859 asap. Thanks a lot - really!

[clsid]

I don't know. I have just replicated the behavior of a setting present in older versions of ffdshow that worked.

[betaking]

last ffdshow3855-3859 borker all libavcodec for ffdshow audio codec like this post
http://forum.doom9.org/showthread.php?p=1489956#post1489956
I test 3853 no problem!

[god_md5]

3859 still crashing ..
sample
http://dl.dropbox.com/u/3668343/not_saw_sub-2011-05-16.ts
http://dl.dropbox.com/u/3668343/%E5%86%92%E9%9A%AA%E7%8E%8B%20-%20J2%20-%202011-05-16.ts

[adam777]

Rev. 3856 or 3857 (MSVC2010) breaks H.264 using ffmpeg-mt.
Works fine in 3855, crash in 3857 and 3859. I was unable to find a 3856 binary.
Sample - http://www.mediafire.com/?w0jfpn4ztyq7xzm

[clsid]

Crash seems to happen when converting to NV12. Can you confirm if the crash is gone when you uncheck NV12 on the Ouput page?

[alexins]

Crash seems to happen when converting to NV12. Can you confirm if the crash is gone when you uncheck NV12 on the Ouput page?

Yes, I confirm! If you disable conversion in NV12, it all works without errors!

[adam777]

Confirmed here as well, YV12 works fine.

[clsid]

3856 breaks it but I don't know why yet. Help is appreciated to get this fixed quicker.

[nevcairiel]

The changes to swscale in libav are just broken. This was confirmed by Michael Niedermayer (the ffmpeg maintainer) on the mailing list this morning, when he tried to merge them over to ffmpeg.

So much for "libav is the more stable version". :p

[clsid]

The NV12 bug is from a bit older code. Yesterdays code indeed had another crash, this time with resizing, that is probably due to the bugs Michael has fixed now.

[CruNcher]

Didn't i reported that problem ;) http://forum.doom9.org/showthread.php?p=1501095#post1501095
so 80% ffdshow was correct then ? :)

Yes, I confirm! If you disable conversion in NV12, it all works without errors!

thx for reproducing, though still not sure if it's the exact same issue i experienced :)

The NV12 bug is from a bit older code. Yesterdays code indeed had another crash, this time with resizing, that is probably due to the bugs Michael has fixed now.

So my reported issue still belongs to this older NV12 code ?, the issue is still active madvr still shows this grayscale half green output with ffdshows nv12 in the chain ffdshow_rev3861_20110527_xhmikosr_icl12.exe and ffdshow_rev3861_20110527_xhmikosr_MSVC2010.exe :(
The issue isn't visible using Leads Colorspace converter NV12 http://www.leadtools.com/help/leadtools/v16/Multimedia/api/Filters/LEADVideoYUVConverter.htm

Lead Colorspace Converter (OK, no crashes on vmr output is ok on every renderer):
Input: Video: NV12 1920x1080 23.98fps
Output: Video: NV12 2048x1080 (16:9) 23.98fps 596594kbps

FFdshow Colorspace Converter (MadVR strange chroma issues,VMR renderer causes crashes):
Input: Video: NV12 1920x1080 23.98fps
Output: Video: NV12 2048x1080 (16:9) 23.98fps

3856 breaks it but I don't know why yet. Help is appreciated to get this fixed quicker.

back to 3703 i tried it now every build no matter if clsid or xhmikosr both show the same issue (so old NV12 code would make perfect sense) so i guess those are 2 different issues we are talking now about 1 based on this old NV12 code and 1 that was fixed based on the scaling issue ?

[clsid]

That is a different issue. Add it to the bug tracker.

[hoborg]

Here is a .ts sample. (https://rapidshare.com/files/1479703935/crash.zip)

FFDShow DXVA = crash


Just tested with "ffdshow_rev3863_20110530_xvidvideo-ru_x86-msvc2010.zip" - still crashing :/

[clsid]

That file does not crash here (with libavcodec/mt/dxva). Using MPC-HC and Haali splitter.

[hoborg]

That file does not crash here (with libavcodec/mt/dxva). Using MPC-HC and Haali splitter.

I am using LAVF .28

Libavcodec+FFMpeg-MT = no problem, only FFDshow DXVA crashing.
LAVF .28+PDVD11 DXVA = no problem.

Hmm, MPC-HC mpeg splitter + FFDShow DXVA working too. Strange.

[clsid]

I am not going to invest any more time in this. The stream is corrupt. Don't use DXVA or use a different splitter. Or find someone else to fix it.

[kieranrk]

I am not going to invest any more time in this. The stream is corrupt. Don't use DXVA or use a different splitter. Or find someone else to fix it.

The stream is fine. The only problem with it is that the AUDs in the first two access units have a missing zero in their startcodes.

[hoborg]

I am not going to invest any more time in this. The stream is corrupt. Don't use DXVA or use a different splitter. Or find someone else to fix it.

I have more of them. All af them are "normal" h.264 recordings.
But i understand you.

[hoborg]

BTW, here (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_thx_cavalcade.rar) is another FFDshow DXVA + LAVF crashing sample.
This one is from High Definition Trailers (HD) (http://www.demo-world.eu/trailers/high-definition-trailers.php)

[nevcairiel]

Here is a fix for the DXVA crash with LAV Splitter. It was clearly ffdshows problem, as it mis-detected a H264 AnnexB Startcode in a MKV/MP4 type H264 stream.
I'm a bit unsure why it only happend with LAV, maybe because my MKV/MP4 style length field is 4 bytes - do the other splitters only ever use 2? Oh well.

Anyway, crash fixed for me:
http://files.1f0.de/ffdshow-dxva-lav.patch

[hoborg]

Anyway, crash fixed for me:
http://files.1f0.de/ffdshow-dxva-lav.patch

You rule! :D

[mandarinka]

What needs to be done on the side of ffdshow to enable decoding high 10 profile h264 video? As I understand it, 8bit yv12 or rgb32 has to be output to video renderers in majority of cases (or vsfilter if it is being used). WIll it be possible to refurbish the present hq yv12 to rgb32 converter, or will it require using swscale instead?

[Sebastiii]

Here is a fix for the DXVA crash with LAV Splitter. It was clearly ffdshows problem, as it mis-detected a H264 AnnexB Startcode in a MKV/MP4 type H264 stream.
I'm a bit unsure why it only happend with LAV, maybe because my MKV/MP4 style length field is 4 bytes - do the other splitters only ever use 2? Oh well.

Anyway, crash fixed for me:
http://files.1f0.de/ffdshow-dxva-lav.patch

Thanks :)

[e-t172]

I'm posting here in case anyone's interested: I just released a patch which adds an IVTC (pulldown removal) filter to the ffdshow video filter chain. It handles hard 30i, soft 30i, and hard 60p. I don't have time to debug or improve it however, so you should see it as a proof-of-concept filter, provided "as-is" and not suited for everyday use. Its main goal is to be VERY fast: with the right parameters it is able to handle hard 1080i30 in realtime with near-perfect results and very low CPU usage. Details here (http://forum.doom9.org/showpost.php?p=1505473&postcount=778).

[BloodySword]

Why is the setting "Set pixel aspect ratio in output media type" gone? I don't want that ffDshow reports the aspect ratio in output media type! How can I disable it?

[kostik]

Hey,
Recently Madshi has updated MADVR Renderer and added new colorspace formats which include 16bit and 10 bit.
Is it going to be difficualt to implement those formats to output to MADVR?
* added support for 10 bit 4:2:2 media types P210, Y210, v210
* added support for 10 bit 4:4:4 media types Y410, v410
* added support for 16 bit 4:2:2 media types P216, Y216, v216
* added support for 16 bit 4:4:4 media types Y416, v416
* added support for 16 bit RGB media types RGB48, RGB64, b48r, b64a, ...

Pleassseee!
Thanks!!!

[hoborg]

Here is a fix for the DXVA crash with LAV Splitter. It was clearly ffdshows problem, as it mis-detected a H264 AnnexB Startcode in a MKV/MP4 type H264 stream.
I'm a bit unsure why it only happend with LAV, maybe because my MKV/MP4 style length field is 4 bytes - do the other splitters only ever use 2? Oh well.

Anyway, crash fixed for me:
http://files.1f0.de/ffdshow-dxva-lav.patch

Just tested ffdshow tryouts project, svn 3871 (x86) - MSVC2010
The crash is fixed, but this sample (https://rapidshare.com/files/1479703935/crash.zip) freeze instead :/

[nevcairiel]

I'll try to fix that in LAV Splitter soon, already have some ideas for improvements.

[RealSnoopyDog]

Hi, thanks for all the updates. nevcairiel's patch definitely fixes the DXVA decoder crash on several H.264 sources.

But there is another issue with H.264 playback on latest build 3871: when jumping around (seeking) in the media file or when subtitles should pop up, the decoder crashes - regardless if i use the DXVA or the non-DXVA version. If i replace the 2 DLLs "ffmpeg.dll" and "ffmpegmt.dll" with those from the previous build 3866 (11-05-30) everything works fine, including nevcairiel's patch.

[robpdotcom]

I'm posting here in case anyone's interested: I just released a patch which adds an IVTC (pulldown removal) filter to the ffdshow video filter chain. It handles hard 30i, soft 30i, and hard 60p. I don't have time to debug or improve it however, so you should see it as a proof-of-concept filter, provided "as-is" and not suited for everyday use. Its main goal is to be VERY fast: with the right parameters it is able to handle hard 1080i30 in realtime with near-perfect results and very low CPU usage. Details here (http://forum.doom9.org/showpost.php?p=1505473&postcount=778).

I've tried this out, and it works pretty well, some material better than others, but overall it seemed ok - it would be very nice if someone would take it over to "finish" it.

I think it's suited particularly well to be used in ffdshow - it would allow you to easily switch between IVTC and deinterlacing (such as yadif), depending on whether the source is film or video based. It's a lot better than having to switch decoders.

BTW: While I was playing with it, I was trying to set up a keyboard shortcut to toggle deinterlacing on/off (so I could set a button on my remote), but I never could get it, or any other keyboard shortcuts, to work. Is there some trick to get the shorcuts to work? Something simple I could be overlooking?

These are my settings. Could someone tell me what keys I would press to, say, toggle the OSD?:

http://666kb.com/i/bu55mh3bd29q9ce4i.jpg

[BloodySword]

Why is the setting "Set pixel aspect ratio in output media type" gone? I don't want that ffDshow reports the aspect ratio in output media type! How can I disable it?

[burfadel]

Both the xhmikosr and xvidvideo builds of ffdshow rev 3671 doesn't work for me. Only tried playing back h264, as that is what I wanted to watch! all previous versions worked, including 3668.

The issue is there are big strips running vertical on the screen (not moving).

[hoborg]

BTW: While I was playing with it, I was trying to set up a keyboard shortcut to toggle deinterlacing on/off (so I could set a button on my remote), but I never could get it, or any other keyboard shortcuts, to work. Is there some trick to get the shorcuts to work? Something simple I could be overlooking?

These are my settings. Could someone tell me what keys I would press to, say, toggle the OSD?:


By default CTRL+ALT+O - no problem here.

[clsid]

Why is the setting "Set pixel aspect ratio in output media type" gone? I don't want that ffDshow reports the aspect ratio in output media type! How can I disable it?Unless you explain what kind of problem you are having, we can't help you.

[clsid]

I am not having any problem with H.264 with r3871. More details please.

[burfadel]

Just tried r3871 again, its the resize filter which is broken! I simply disabled that whilst playing a video and it worked fine, re-enabling it caused the issue again. I tried a few different resize methods and that didn't help.

I use the resize filter (sinc, with some luma sharpen) to upsample playback to a HDTV. Its for this reason I'm going back to r3868 again! I'm guessing it got broken with r3869 when swscale was updated :) Both MSVC2010 and ICL12 builds are affected.

[clsid]

Yes, just found out the vertical stripes issue is indeed caused by resize.

[BloodySword]

Unless you explain what kind of problem you are having, we can't help you.

The problem is that while displaying the picture has a fixed aspect ratio, no mather how I resize my Player's window. My Player has it's own Aspect ratio resizing method by placing the window in the correct position and with correct size.

I now reverted back to rev3853, this version does not report the aspect ratio in media type but the newest version does. But in both versions there is no checkbox to tell ffDShow not reporting the aspect ratio in the media type. I would be VERY pleased if you would place the checkbox in the new revision whee the User could control this behaviour. Thank you!

[nevcairiel]

That sounds like your player is not doing what you want.
ffdshow just tells the player the aspect ratio of the movie, what the player does with that is only the players responsibility. In fact, without this info, it would never know which AR the movie was supposed to be in the first place!

I suggest you fix your player. That option does not change anything about the image, it just tells the player about the AR. If the player forces that on you and doesn't let you change the AR, its the players fault.

[BloodySword]

No, I set the IMediaWindow.Left, Top, With and Height. The Video-Renderer uses its own AspectRatio, wich is reported from ffDShow and that is what I want to disable! So I want, that the renderer fills the Rect I give with the propertys above.

NOT the Player is told about aspect ratio, it is the Vireo Renderer that gets this information on DirectShow.

Edit3: To clarify, when ffDSHow sets 4:3 aspect ratio, and I set 16:9 in my player because 16:9 is the correct AR, the Video Renderer makes it 4:3 INSIDE the 16:9 frame... That is what my problem is.

Edit 2: The main reason is, this would not be a problem when the aspect ratio in my videos would be correct... I could set the aspect ratio "free" in my player but 90% of my videos have a wrong setting in the video stream or container... Is there a method to change this without reencoding?

[nevcairiel]

But you can still tell the video renderer how you want it to handle AR, they usually at least implement a mode to keep AR and letter box, or just ignore AR.

For VMR, its for example IVMRWindowlessControl9::SetAspectRatioMode, for EVR IMFVideoDisplayControl::SetAspectRatioMode

[BloodySword]

The problem is that this player is written in VB6, a C#.NET WPF-Version is in development but I just want to use my old player till I completed the new one.

In VB6, I don't know how to determine wich Video Renderer is used and I don't know if there are typelibs for COM wich is compatible to VB6 for the classes you mentioned. :(

[clsid]

If 3853 works, then it is probably 3859 that 'broke' it.

Send me your player and a small sample video for testing and I can fix it.

[BloodySword]

In very old versions there was a check box to disable it: "Set aspect ratio in media type" on the "Output" page. I would be pleased if you just would add it again. I think 3853 is "broken" and not 3859, 3859 does it "right" but not for all users as you can see. So getting back this option checkbox is the best thing you can do for all users. By default the checkbox should be checked.

Should I send the source code or just the binary?

Just for info: The player uses its "own" codec "on/off switcher", and I install ffDShow in it's codecs path with must relay there where the player is. But as long you don't use the codec on/off switcher: don't worry about that. Just ignore it.

@All: How can I change the aspect ratio in an H264 stream without reencoding? Can the container (MP4) override this setting?
On MPEG-2 (VOB / PS) I have a header modifier program. "ReStream"

Edit: Player will follow...
Edit2: http://www3.zippyshare.com/v/756077/file.html

Edit3: Regarding the sample file, can it be a shot piece of video and audio? Because of copyright problems?

I have found more information: In the info page of ffDShow rev3853 it shows DAR: 16/9 but the video renderer dosn't take care about it so I can change the AR in my player like I want. In the latest version, DAR: 4/3 is reported and the video renderer respects it.

[Chikuzen]

@All: How can I change the aspect ratio in an H264 stream without reencoding? Can the container (MP4) override this setting?

MP4Box -add clip.mp4:par=num:den -new remuxed.mp4

[BloodySword]

MP4Box -add clip.mp4:par=num:den -new remuxed.mp4

Thank you, I will try this. But what is with the information in the H264 video stream itself?
Created a batch script: "C:\Program Files (x86)\megui\tools\mp4box\MP4Box.exe" -add %1:par=%2 -new %1_arcorrection.mp4
How can I remove .mp4 out of %1 within this one liner?

@nevcairiel:

Could you please help me develop my new WPF-Based player?
In my first tests I use QuartzTypeLib via Interop. Is this correct?

I need a full list of Classes and DLL Imports I must use for full functionality (eg AspectRatio control of renderers etc.)

We could communicate via E-Mail. Many Thanks!

[Chikuzen]

But what is with the information in the H264 video stream itself?

IIRC, MP4Box overwrites information not only in the container but also in the stream at the same time.

[madshi]

In very old versions there was a check box to disable it: "Set aspect ratio in media type" on the "Output" page. I would be pleased if you just would add it again.
This option was removed because hiding the aspect ratio information from the renderer doesn't really make too much sense. I've had a couple of bug reports for my madVR video renderer which were caused by this old option being accidently disabled. So removing the option helped fixing accidental bugs. Now adding the option back in just to work around a player issue doesn't sound like a good idea to me. It'd be better to improve your player so that it can tell the renderer to use the aspect ratio you want.

[BloodySword]

That is simply not possible because the librarys I have to use are not usable in VB6. I'm working on a new, more modern player (latest change on my old player was effectively 2005, from there on I only fixed some small bugs) but I need help to use the correct librarys. The player will be written in C#.NET4 with WPF. I use Quartz.dll via Interop. Is this correct or is there another libary wich is better for DirectShow on XP SP3+?

But since the new player is even not in alpha stage, I want to use my old one.

The new player will get his own GraphBilder code (but "RenderFile" can be used as well when you switch it) you can specify source filter, splitter, decoder, add other filters and finally the renderer in the "Graph building options" by file extension or recognized media type. In this case the graph would be built much faster. And if it fails, it will use "RenderFile()" as a fallback.

When the player is compleded, am I allowed to include the download of newest ffDShow in my installer?

[madshi]

But since the new player is even not in alpha stage, I want to use my old one.
If this is just a temporary fix until your new player is ready, then why not simply using an older ffdshow build for now? Then when your new player is ready to use, you can switch to the latest ffdshow build.

[BloodySword]

So removing the option helped fixing accidental bugs.

But a registry setting could be possible...

If this is just a temporary fix until your new player is ready, then why not simply using an older ffdshow build for now? Then when your new player is ready to use, you can switch to the latest ffdshow build.

This is what I actually do, but the performance of the new version is much better on my system: Core2Duo T3200M (2x2GHz) 3GByte RAM, Intel GMA 4500M Series Graphic.

[Sven75]

Could support for Apple DV (DVCP) files be added to ffdShow? I tried the following file with ffplay.exe from current ffmpeg and it's playing just fine. Also, lavsplitter accepts the file in GraphStudio, but it cannot be rendered from there on, (obviously) because no decoder in my system will support it.

http://www.mediafire.com/?8fwcaxepy3xca4v (Apple_DVCP_small.mov)

If a file is supported by ffmpeg what does it take to make it work with ffdShow? Is it just a matter of adding an additional MediaType or are there substantial differences in the decoder codebase between current ffdShow and current ffmpeg or libav?

[clsid]

It plays when I add support for the FourCC "DVCP" to ffdshow. However, the video stutters. I will not commit this change, since I only want to support things that can be properly played.

[Sven75]

Yes, you are right. Playback is not 100% perfect and I understand and support your point.

So, to fix this, the best will be to upload the file at ffmpeg/libav and file a bug, right?

In the meantime, does anyone know a Windows decoder (beside the source filters which use the QuickTime framework) which supports Apple DVCP?

[Jason Leach]

I have a new problem: When I was playing a Blu-ray, I noticed when I increased the Gamma correction (under Picture Properties) it was as if I'd increased the brightness setting--that is, areas of the image that are pure black become brighter, which should not happen with the gamma setting (it does not in Photoshop or when I use my ATI 4350's gamma control). I verified these areas are true black by using the Print Screen key to make a screenshot and measuring the RGB level with the eyedropper tool in Photoshop. (Actually it was R:0 G:1 B:0, but I adjusted just the R and B independently and the same thing happened.)

1).operating system (OS)

Windows 7 x64

2).ffdshow version, rev, compiler, ansi or unicode

ffdshow tryouts rev3867 May 31 2011 18:45:44 (MSVC 2010, x86, unicode, r)

3).ffdshow settings and used filters, ex:queue, resize, sharpening, noise, levels...

No others active.

4).media player used and settings ex: mpc, media player2, wmplayer...

BSPlayer but the same thing happens in MPC-HC.

5).output colorspaces "YUY2", "YV12", "RGB32", "RGB24"...

RGB32

6).internal/external splitters ex: Haali Media Splitter, Gabest's Splitters...

Haali

7).video renderers ex:Haali renderer, Overlay Mixer, VMR9, VMR7, EVR...

Happens in both DirectDraw, Overlay, and EVR Custom Pres.

8).video/audio samples <10MB

I tested on both a Blu-ray m2ts and an uncompressed AVI with 0-255 levels, so its not the file, but here's a sample just in case:

https://rapidshare.com/files/1669032072/Mr._and_Mrs._Incredible__2011__Trailer_720p.mp4

9).what you were trying to accomplish, the problem you encountered...anything else that could be useful in reproducing that bug.

It should be easy to reproduce--just raise the Gamma correction on a widescreen Blu-ray and you'll see the black bars above and below the image become light, just as if you'd raised the brightness instead.

[clsid]

Yes, you are right. Playback is not 100% perfect and I understand and support your point.

So, to fix this, the best will be to upload the file at ffmpeg/libav and file a bug, right?

In the meantime, does anyone know a Windows decoder (beside the source filters which use the QuickTime framework) which supports Apple DVCP?If the same happens with ffplay, then please report to FFmpeg devs.

VLC plays the file properly here.

[Snowknight26]

FPS1 -> YV12 is broken again. Chroma planes are reversed.

[Thunderbolt8]

is there a ffdshow picture settings which can change contrast for red, green and blue, BUT leaves black levels untouched?

theres such a setting in TMPGEnc encoder (a filter named "contrast (black base)"), but I like to avoid reencoding my video for that and rather have the colour change applied during playback instead.

[clsid]

FPS1 -> YV12 is broken again. Chroma planes are reversed.
Do you perhaps have a small sample?

[Snowknight26]

Do you perhaps have a small sample?

http://stfcc.org/misc/ffplay_fraps_video_stutter_with_audio.avi

[sneaker_ger]

Now that ffmpeg-mt has been merged: is there any difference between choosing libav and ffmpeg-mt? Any advantages/disadvantages?

[clsid]

Libavcodec is still single-threaded for H.264. It uses w32threads instead of pthreads. Last time I tried changing that it crashed, and haven't looked into it deeper yet.

[sneaker_ger]

I see, thx.

[mark0077]

Guys, when using things like avisynth frame interpolation in ffdshow, is it upto ffdshow or avisynth to correctly set the pin out details.

I frame interpolate everything to 50.00fps using avisynth, yet madVR video renderer reports "movie 23.974 fps (says source filter)". ffdshow pin out also says the following, rather than the correct output rate of 50.00 fps


Filter : ffdshow Video Decoder - CLSID : {04FE9017-F873-410E-871E-AB91661A4EF7}

- Connected to:

CLSID: {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
Filter: madVR Renderer
Pin: Input

- Connection media type:

Video: YV12 2048x1080 (16:9) 23.97fps

[TheRyuu]

Libavcodec is still single-threaded for H.264. It uses w32threads instead of pthreads. Last time I tried changing that it crashed, and haven't looked into it deeper yet.

Don't use w32threads then.

ffmpeg-mt was merged. There's zero reason to maintain both of them as separate entities in ffdshow.

Also what still needs to get done for 10bit h264 decoding support?

[clsid]

It crashed when using pthreads. But like I have said, I haven't looked into it yet.

For the 10bit stuff, ffdshow needs to be updated to recognize the 9/10/16bit colorspaces of ffmpeg and use swscale to convert them to the standard output colorspaces. Patches are welcome.

[clsid]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

[sneaker_ger]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

Looking good, performance of libav and ffmpeg-mt are identical.

[TheRyuu]

I'm not completly sure but doesn't autostatic in pthreads mean code like this:
--- trunk/src/ffmpeg/DllEntry.c 2011/06/18 11:59:34 3884
+++ trunk/src/ffmpeg/DllEntry.c 2011/06/18 23:43:03 3885
@@ -28,33 +28,37 @@

CRITICAL_SECTION g_csStaticDataLock;

+BOOL pthread_win32_process_attach_np(void);
+BOOL pthread_win32_process_detach_np(void);
+BOOL pthread_win32_thread_attach_np(void);
+BOOL pthread_win32_thread_detach_np(void);
+
// --- standard WIN32 entrypoints --------------------------------------
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
- //static int count=0;
- //char pomS[40];
- switch (dwReason)
- {
- case DLL_PROCESS_ATTACH:
- //count++;
- //snprintf(pomS,40,"ffmpeg: %i %i\n",count,hInstance);OutputDebugString(pomS);
- DisableThreadLibraryCalls(hInstance);
- InitializeCriticalSection( &g_csStaticDataLock );
- break;
- case DLL_PROCESS_DETACH:
- //count--;
- //snprintf(pomS,40,"ffmpeg: %i %i\n",count,hInstance);OutputDebugString(pomS);
- DeleteCriticalSection( &g_csStaticDataLock );
- break;
- }
- return TRUE;
+ switch (dwReason)
+ {
+ case DLL_PROCESS_ATTACH:
+ pthread_win32_process_attach_np();
+ pthread_win32_thread_attach_np();
+ DisableThreadLibraryCalls(hInstance);
+ InitializeCriticalSection( &g_csStaticDataLock );
+ break;
+
+ case DLL_PROCESS_DETACH:
+ pthread_win32_thread_detach_np();
+ pthread_win32_process_detach_np();
+ DeleteCriticalSection( &g_csStaticDataLock );
+ break;
+ }
+ return TRUE;
}

static char av_datetime[]=__DATE__" "__TIME__;
void getVersion(char **version,char **build,char **datetime,const char* *license)
{
- if (version) *version=AV_STRINGIFY(LIBAVCODEC_VERSION)", "COMPILER COMPILER_X64 COMPILER_INFO;
- if (build) *build=AV_STRINGIFY(LIBAVCODEC_BUILD);
- if (datetime) *datetime=av_datetime;
- if (license) *license="";
+ if (version) *version=AV_STRINGIFY(LIBAVCODEC_VERSION)", "COMPILER COMPILER_X64 COMPILER_INFO;
+ if (build) *build=AV_STRINGIFY(LIBAVCODEC_BUILD);
+ if (datetime) *datetime=av_datetime;
+ if (license) *license="";
}

Isn't needed anymore since "libav" is built using the gnu linker. I'm only curious because it looks so similar to the (really) old way of doing static pthreads in ffmpeg:
Index: libavcodec/allcodecs.c
===================================================================
--- libavcodec/allcodecs.c (revision 15966)
+++ libavcodec/allcodecs.c (working copy)
@@ -41,6 +41,14 @@
extern AVBitStreamFilter x##_bsf; \
if(ENABLE_##X##_BSF) av_register_bitstream_filter(&x##_bsf); }

+#ifdef PTW32_STATIC_LIB
+static void detach_ptw32(void)
+{
+ pthread_win32_thread_detach_np();
+ pthread_win32_process_detach_np();
+}
+#endif
+
/**
* Register all the codecs, parsers and bitstream filters which were enabled at
* configuration time. If you do not call this function you can select exactly
@@ -59,6 +67,12 @@
return;
initialized = 1;

+#ifdef PTW32_STATIC_LIB
+ pthread_win32_process_attach_np();
+ pthread_win32_thread_attach_np();
+ atexit(detach_ptw32);
+#endif
+
/* video codecs */
REGISTER_DECODER (AASC, aasc);
REGISTER_DECODER (AMV, amv);

You shouldn't need any custom code for pthreads to work.

[jmone]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

Nice Work!

Also Looking good for me and if anything the CPU useage of libav "may" be just slightly better thant ffmpeg-mt (hard to really tell), but it is certainly no worse.

Anyway, are there any benefits now to use ffmpeg-mt over libav? If not are you goint to remove the ffmpeg-mt option?

Thanks
Nathan

Next you will say that libav now supports interlaced VC-1!

[JEEB]

Anyway, are there any benefits now to use ffmpeg-mt over libav? If not are you goint to remove the ffmpeg-mt option?
It was merged, thus the ffmpeg-mt source tree by itself is now pretty much obsolete, if there will be any fixes, they will get into libav/ffmpeg's trunks, not into ffmpeg-mt from now on :) .

Next you will say that libav now supports interlaced VC-1!
Saw people on #libav-devel working on it at least, but this was a while ago.

[VipZ]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

All seems good here

[clsid]

@TheRyuu
It crashes in ntdll without that custom code. It probably needs it because out pthread lib is a bit old. I will try updating it and see if that code is still needed. Thanks for the hint.

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

@JEEB
Afaik, there is not much active development going on regarding interlaced VC-1. But there is a GSOC project for it, but there has been in past year as well without much results.
http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011#VC-1_decoder_missing_features

[VipZ]

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

I have thrown all my previous known issue files at this in x64 as well and haven't had any issues, playback has become much more stable in the last 1-2 months :)

The only issue is but its been around for a while, is that ffdshow doesn't seem to read this info on h264 in MKV when using LAV Spiltter,
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

[roytam1]

@TheRyuu
It crashes in ntdll without that custom code. It probably needs it because out pthread lib is a bit old. I will try updating it and see if that code is still needed. Thanks for the hint.

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

@JEEB
Afaik, there is not much active development going on regarding interlaced VC-1. But there is a GSOC project for it, but there has been in past year as well without much results.
http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011#VC-1_decoder_missing_features

What about vp3/theora/mpeg4/huffyuv in ffmpeg-mt in the past? Will they have multi threading with new libavcodec?

[upyzl]

sorry to trouble, I've been meaning to ask...

what does splineResize stand for? spline16resize? spline36resize? spline64resize? could I tweak it as LanczosResize(taps)?

[clsid]

What about vp3/theora/mpeg4/huffyuv in ffmpeg-mt in the past? Will they have multi threading with new libavcodec?Those codecs have sync issues when MT is enabled for them. So unless someone figures out a solution for that they won't be multi-threaded.

[Superb]

clsid: did you use the latest winpthreads from http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/winpthreads/ ?

[mandarinka]

sorry to trouble, I've been meaning to ask...

what does splineResize stand for? spline16resize? spline36resize? spline64resize? could I tweak it as LanczosResize(taps)?

Spline resize in ffdshow isn't related to avisynth scalers, it comes from ffmpeg's swscale library. AFAIK it has a different effect from say spline36resize, too.

[clsid]

clsid: did you use the latest winpthreads from http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/winpthreads/ ?
I use this:
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/pthreads/

[VipZ]

I cant seem to compile ffmpeg x64 anymore, had no issue with build 3886

As a reference, I used the below cmd and currently use mingw_gcc_461_v20110506_x86-x64-pre-release.7z from xvidvideo.ru
rd /S /Q obj\MinGW64
cd src\ffmpeg
make 64BIT=yes
cd ..\..
pause

[Wilbert]

Spline resize in ffdshow isn't related to avisynth scalers, it comes from ffmpeg's swscale library.
Perhaps the same as this one: http://forum.doom9.org/showthread.php?p=1356563#post1356563 ?

[clsid]

I cant seem to compile ffmpeg x64 anymore, had no issue with build 3886

As a reference, I used the below cmd and currently use mingw_gcc_461_v20110506_x86-x64-pre-release.7z from xvidvideo.ru
rd /S /Q obj\MinGW64
cd src\ffmpeg
make 64BIT=yes
cd ..\..
pause
This MinGW64 build should work:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20110616.zip/download

[upyzl]

@ mandarinka & Wilbert

Thank you for the reply! I see...

[RealSnoopyDog]

Builds 3886 and 3892 show very bad artefacts when playing back H.264 with the DXVA codec. Build 3882 (and previous) does not have this.

[VipZ]

This MinGW64 build should work:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20110616.zip/download

Thanks :)

I have tried the 4.7.0 pre release from xvidvideo.ru before (mingw_gcc_470_v20110507_x86-x64-pre-release.7z) with the same issue and also crashed on a few h264 video's on build 3886 and before, so I assume the build you posted is much more stable now?

I will test this build tonight, if this is the same version you used, I did some testing and had no h264 crashing on me, but I did forget which file crashed for me, maybe I should do a test build and test this.

[Sven75]

Playback of the following file is broken if I use the current LAVFilters and ffdshow. It plays but the video image remains completely grey:

http://www.mediafire.com/?1nr37wujo5g8c65 (cvid in mov container)

However, it does work if I use the MS AVI decompressor. Also, it works with ffdShow, if I use LAVFilter versions <= 0.26-31 (a change in avformat-53.dll broke the compatiblity with ffdShow).

So, it's either a problem with ffdShow or LAVFilter (I also posted it at the LAV thread).

Of course, I can use MS AVI decompressor for it just fine, but maybe it is a problem affecting other formats as well and someone cares to have a look and solve the underlying problem.

[Mr VacBob]

Those codecs have sync issues when MT is enabled for them. So unless someone figures out a solution for that they won't be multi-threaded.

That must be a wrapper issue. vp3 and huffyuv are well behaved. It's possible that mpeg4 (with packed B-frames) isn't.

[clsid]

That must be a wrapper issue. vp3 and huffyuv are well behaved. It's possible that mpeg4 (with packed B-frames) isn't.
Any idea what might be wrong? The sync difference seems to be proportional to the number of threads.

[clsid]

Thanks :)

I have tried the 4.7.0 pre release from xvidvideo.ru before (mingw_gcc_470_v20110507_x86-x64-pre-release.7z) with the same issue and also crashed on a few h264 video's on build 3886 and before, so I assume the build you posted is much more stable now?

I will test this build tonight, if this is the same version you used, I did some testing and had no h264 crashing on me, but I did forget which file crashed for me, maybe I should do a test build and test this.Older versions from MinGW64 project should also work. TDM's build probably as well.

I used the exact same mingw64 build and no crashes have been reported so far, so things are looking good.

[Reimar]

Any idea what might be wrong? The sync difference seems to be proportional to the number of threads.

Frame multithreading creates a delay. Since vp3 and huffyuv do not use B-frames those wrappers probably aren't prepared to handle a decoding delay.
I guess you'll either have to pass the timestamps through properly (I think the requires using the most recent decode API) or just delay them by the (I think) has_b_frames value.

[clsid]

I know that threading causes a delay, but I can't find any code that does things differently for H.264 in that regard. ffdshow seems to use reordered_opaque for the timestamp handling. I am also not really familiar with the parts of the ffdshow code involved in this, so I doubt I can fix it. These formats can easily be decoded even on old CPUs, so I don't consider multi-threading to be important for them. If anyone wants it, submit a working patch.

[roozhou]

Frame multithreading creates a delay.
Is this delay caused by ffmpeg-mt or the current framework of ffdshow?

[pwimmer]

I would like to control the ffdshow Audio Decoder from my application, specifically I would like to turn the tray icon off and disable the mixer.

While

IffdshowBase :: putParam(IDFF_trayIcon, 0)

works as expected

IffdshowBase :: putParam(IDFF_isMixer, 0)

does not.

What is the correct way to change the filter settings temporarily (only for my application)? Do I have to init/create/set a profile for the second call to work? It would be preferred if my application uses the default settings, so that config changes done by the user do not affect my application.

[clsid]

Builds 3886 and 3892 show very bad artefacts when playing back H.264 with the DXVA codec. Build 3882 (and previous) does not have this.
I have one M2TS file that shows this problem. I haven't pinpointed the cause yet.

[Reimar]

Is this delay caused by ffmpeg-mt or the current framework of ffdshow?

It is a direct result of the _concept_ frame-multithreading itself. You obviously can't decode multiple frames in parallel unless you have the data for all these frames.
So if you want to decode n frames in parallel your decoded frame output has to lag behind about n frames from the encoded frame input.

[fastplayer]

@clsid:
You've renamed the ICL10 directory to "...(old)". This means you won't offer ICL builds anymore, right?

[clsid]

Yes, it is unlikely there will be any new ICL10 builds. I currently only have MSV2010 installed on my new PC.

[fastplayer]

OK, thanks. I've jumped the gun and already removed the ICL10 reference from the homepage.

[xv]

Current ffdshow crashes on H.264 4:4:4 files (included ffmpeg has decoding support), sample file: http://www.mediafire.com/?s28158q8rwq2ob8
Here is a x264 build to encode 4:4:4: http://forum.doom9.org/showthread.php?p=1509669#post1509669 (You need AviSynth 2.6, older versions don´t support YV24 colorspace)

[clsid]

Same situation as with H.264 10-bit, it requires support for additional colorspaces in ffdshow.

[xv]

Other codecs (just tested ffv1) work fine with yuv444p? But it is converted to YV12 somewhere. That would be a temporary workaround that those files at least play and do not crash ffdshow.

[ney2x]

ffdshow rev3899 crashed with H.264. Using latest mpc-hc v1.5.2.3257, lav suite, madvr and reclock. Back to ffdshow rev3897, which is stable for me.

[clsid]

Other codecs (just tested ffv1) work fine with yuv444p? But it is converted to YV12 somewhere. That would be a temporary workaround that those files at least play and do not crash ffdshow.Fixed in 3904

[clsid]

ffdshow rev3899 crashed with H.264. Using latest mpc-hc v1.5.2.3257, lav suite, madvr and reclock. Back to ffdshow rev3897, which is stable for me.
Please try one of my recent builds. It might be build related.

[ney2x]

Please try one of my recent builds. It might be build related.

Thanks rev3904 working flawlessly :D

[RealSnoopyDog]

Just a positive feedback for the new version 3904: On my notebook, with a nVidia 1600M onboard, i never could use the DXVA decoder for H.264 playback because it is stuttering for some reason. So i need to use the "non DXVA" decoder. On all previous builds up to 3892 i had 90-99% CPU load when playing back some material in full HD 1920x1080. With the new build 3904, i constantly have 75-80% CPU load with the same material! This is a great improvement. Just had no time to check, if the artefacts with H.264 DXVA are gone now.

[clsid]

Good to hear. Perhaps you were using libavcodec instead of ffmpeg-mt in the past? That would explain the performance difference.

[fastplayer]

@clsid:
The "ffmpeg-mt" reference in the tooltip for "Number of decoding threads" (under "Decoder options") is obsolete.

I was wondering what the long-term plans are for liba52 and libdts. If we're gonna remove them at some point (as discussed a few months ago), how about switching to libavcodec as the new default for now and see what it all breaks?
This is under the assumption that libavcodec >= liba52/libdts in terms of features and stability, of course.

[clsid]

I will update that tooltip.

Here is at least one reason to keep libdts:
http://forum.doom9.org/showthread.php?p=1482937#post1482937

I think we should first release a new official stable, and after that change the default for AC3.

[fastplayer]

Here is at least one reason to keep libdts:
http://forum.doom9.org/showthread.php?p=1482937#post1482937
Ouch. I remember trying that sample, too.

I think we should first release a new official stable, and after that change the default for AC3.
I agree. Let's see how the current builds act in the wild and then go from there.

[fastplayer]

While we're talking about a new stable release, here's the current changelog:
* Added hardware-accelerated DXVA decoders for H.264 and VC-1.
/* Added experimental multithreading support for VP3, Theora, HuffYUV, and MPEG-4.*/
* Added support for bitstreaming E-AC3, DTS-HD, and TrueHD.
* Added support for Blu-ray subtitles (PGS).
* Added VP8/WebM support.
* Added partial support for Cook audio.
* Updated FFmpeg/Libav library. Brings many fixes and improvements.
* Removed several encoders. The interface that ffdshow provided for these encoding libraries was unmaintained, outdated, and buggy. The ffdshow development team recommends using the official encoders instead (such as x264VFW and Xvid). Those are always up-to-date, stable, and fully functional.
/* Improved multithreaded H.264 decoder (ffmpeg-mt). Used now by default on multi-core CPUs.*/
* Improved (performance of) Deband filter. Now also works properly in 64-bit builds.
* Floating point output for libavcodec MP1/2/3, AC3, E-AC3, DTS, Vorbis, and AAC decoder.
* Adjusted colorspace priority lists.
* Removed some obsolete colorspaces from output settings in ffdshow video decoder.
* "Set interlaced flags in output media type" no longer disables YV12 output.
* High quality YV12/NV12/YUY2 to RGB32 conversion is now enabled by default.
* The RAW video decoder now stores its preset settings separately from the regular video decoder.
* Added an option for giving embedded subtitles priority over external subtitle files.
* Lots of subtitle-related fixes and improvements.
* Some S/PDIF-related fixes.
* Updated application blacklist and whitelist.
* Updated libsamplerate to version 0.1.7.
* Updated RAR library to version 4.0.
* libavcodec.dll has been renamed to ffmpeg.dll.
* Removed ffmpeg-mt which has been integrated into libavcodec.
* Removed mp3lib, libtheora, libmplayer, realaac, and tremor.
* Code cleanup and other minor improvements.

[PetitDragon]

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

Hi clsid,

I found all revisions that integrated ffmpeg-mt into libavcodec have problem to deinterlace (bob) h-264 1080i content (big performance hit). Before integration ffmpeg-mt has no such problem. Libavcodec in rev. 3886 deinterlaces fine too.

Please check.

[Atak_Snajpera]

I did a tests on my Q6600@3ghz with .mts (AVCHD 24mbps 1920x1080i50)
1) without Yadif double framerate I have cpu utilization at ~42 %
2) with Yadif double framerate i have cpu utilization at ~62 %

I also tested with rev. 3886 (ffmpeg-mt) and results are almost identical.

[PetitDragon]

Hi clsid and Atak_Snajpera,

Sorry I forgot to memtion the deinterlacing problem is for HW deinterlacing (that set in the "Output" menu), not for yadif or other SW deinterlacer.

[clsid]

I don't see how the ffmpeg changes could have any effect on the HW deinterlacing stuff. And when you say performance hit, are you talking about CPU or GPU performance? It more likely seems some kind of driver issue.

[JEEB]

I was wondering what the long-term plans are for liba52 and libdts. If we're gonna remove them at some point (as discussed a few months ago), how about switching to libavcodec as the new default for now and see what it all breaks?
This is under the assumption that libavcodec >= liba52/libdts in terms of features and stability, of course.
I personally think the libavcodec decoders are more upkept and at least on the level of the specific decoding libraries.

We tested the libavcodec option at CCCP some time ago, but unfortunately it seemed to bork DTS-ES in -tryouts (LAVAudio worked fine).

No other problems were reported during the (relatively short) testing period.

[clsid]

Might be a bug in the audio parsing code of ffdshow. You could poke around a bit in there.

[me7]

Same situation as with H.264 10-bit, it requires support for additional colorspaces in ffdshow.

Is 10-bit support planned for the near future? AFAIK libav already supports it.
I don't mean to rush anybody, just curious when I can start to make use of the additional efficiency x264 gains that way.

[mark0077]

Guys, when using things like avisynth frame interpolation in ffdshow, is it upto ffdshow or avisynth to correctly set the pin out details.

I frame interpolate everything to 50.00fps using avisynth, yet madVR video renderer reports "movie 23.974 fps (says source filter)". ffdshow pin out also says the following, rather than the correct output rate of 50.00 fps


Filter : ffdshow Video Decoder - CLSID : {04FE9017-F873-410E-871E-AB91661A4EF7}

- Connected to:

CLSID: {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
Filter: madVR Renderer
Pin: Input

- Connection media type:

Video: YV12 2048x1080 (16:9) 23.97fps

Just bumping one more time guys, it seems to me like it might be easy to fix, and seems more cosmetic than anything else, but would anyone suggest what I should do regarding this issue, should I post it as an official bug report or would you know how to fix clsid? I actually notice today, even with input of 29.97 interlaced into lavcuvid, output as 59.94 fps to ffdshow, ffdshows pin in says 59.94 in, 29.97 out so it seems to be just outputting some value its reading from somewhere higher up in the stream rather than the correct value..

[Eliminateur]

latest x64 revision from xhmikosr crashes mpc on EVERY H264 video in win7 x64

ffdshow_rev3911_20110624_xhmikosr_x64.exe

i've updated mpc-hc to latest and problem persists, not using DXVA and RGB32 output no other filters enabled.

now i've downgraded to my old version and the problem persists :S, something in latest ffdshow has broken my system

edit2: old non-h264 vids work fine i've tried full HD and HD h264 vids to no avail they all crash
i'm also getting render pin failures on videos i could play before(only decode audio):
Media Type 0:
--------------------------
Video: CCV1 1920x1080 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31564343-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 171

i've checked decode, codecs settings and everything is the same as i had before

[PetitDragon]

I don't see how the ffmpeg changes could have any effect on the HW deinterlacing stuff. And when you say performance hit, are you talking about CPU or GPU performance? It more likely seems some kind of driver issue.

Hi clsid (attention to Atak_Snajpera),

I did the testing for h-264 1080i deinterlacing problem again:

1, For 1080i50 content

With libavcodec and ffmpeg-mt in Rev. 3886 (before integration), it plays fine at steady 50fps using whether yadif (FD) or HW bob deinterlacer.

With libavcodec integrated with ffmpeg-mt after Rev. 3886, it plays fine too at steady 50fps using whether yadif (FD) or HW bob deinterlacer.

2, For 1080i60 content

With libavcodec and ffmpeg-mt in Rev. 3886 (before integration), it plays fine at steady 60fps using whether yadif (FD) or HW bob deinterlacer.

With libavcodec integrated with ffmpeg-mt after Rev. 3886, it plays stutterly at 4x-5x fps keeping frame dropping using whether yadif (FD) or HW bob deinterlacer.
------------

So it seems the new libavcodec integrated with ffmpeg-mt has problem to deal with h-264 1080i60 content. All tests were done with ffdshow x86 ICL12 versions, and the NV video driver was always the same during tests. I am wondering why the ffmpeg changes could have any effect on the deinterlacing stuff too.

[fastplayer]

@PetitDragon:
Can you please test 1080i60 with the regular (non-ICL) builds?
Try this one:
http://xhmikosr.1f0.de/ffdshow/ffdshow_rev3911_20110624_xhmikosr.exe

[PetitDragon]

@PetitDragon:
Can you please test 1080i60 with the regular (non-ICL) builds?
Try this one:
http://xhmikosr.1f0.de/ffdshow/ffdshow_rev3911_20110624_xhmikosr.exe

With the rev. you suggested, it plays stutterly at 4x-5x fps keeping frame dropping using whether yadif (FD) or HW bob deinterlacer. Same problem.

[fastplayer]

OK, that rules out some Intel compiler quirks.
Another thing you might try is limit the number of cores/threads under "Decoder options". If you're on quad-core try limit it to 3 or 2 decoding threads.
Other than that, I'm out of ideas... :(

[PetitDragon]

Hi fastplayer,

Unfortunately changing the number of cores/threads under "Decoder options" still doesn't help. Thanks anyway.

It seems the new integrated libavcodec switches to single thread mode when decoding H-264 interlaced content?! I guess.

[fastplayer]

I don't think so because your 1080i50 results are totally fine.
Have you checked CPU load during playback of 1080i60 content? Does it get close to 100% on any one of your CPU's cores?
I hope clsid has another idea. :)

[Eliminateur]

ok, more testing(bear in mind 3911 broke ffmpeg-mt for me even after downgrading):
mpc-hc x64 3262
ffdshow r3755 x64 msvc2010:
H264 SD & HD
*) ffmpeg MT: reproduced ~0.2S and crashes
*) libavcodec: works fine
other codecs work fine(libavcodec)

ffdshow r3911 x64 msvc2010:
H264 SD/HD:
*) pin fails to render or mpc-hc crashes
Other codecs:
*) mpc-hc crash
only internal mpc-hc filter works
only ffd audio works

any ideas...... i'm still unable to play anything as even a downgrade is broken now.....


should i uninstall and delete folders and then reinstall to make this work?
also, is there a way to export ONLY one part of the config?, i want to export with ffdshow audio config for backup as i a use a complex custom output matrix that's a pain to recreate.

edit1:
did a full uninstall and then reinstall of 3911 resetting settings and everything is still broken

[clsid]

@Eliminateur,
Please try my x64 build. Crashes might be toolchain related.

[Eliminateur]

@Eliminateur,
Please try my x64 build. Crashes might be toolchain related.
downloaded r3904 x64 from your sig link, everything working as expected!
much smooches to you clsid! :thanks:

@xhmikosr: there's something in your x64 build that's chrashing stuff on my pc

[Atak_Snajpera]

@PetitDragon
Do you have NV12 selected?
http://www.picamatic.com/show/2011/06/26/03/24/7653322_591x503.png


I did more tests on my second machine with Q8200@2,8Ghz + Radeon 4850 (Ati Catalyst 11.2) + Windows 7 x64 +ffdshow_rev3904_20110623_clsid.exe

1920x1080i50 (AVCHD 24mbps) with NV12 checked (GPU deinterlacing) cpu utilization is ~21%
1920x1080i50 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and no yadif cpu utilization is ~28%
1920x1080i50 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and yadif (double framerate) cpu utilization is ~48%

1920x1080i60 (AVCHD 24mbps) with NV12 checked (GPU deinterlacing) cpu utilization is ~23%
1920x1080i60 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and no yadif cpu utilization is ~29%
1920x1080i60 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and yadif (double framerate) cpu utilization is ~51%

[PetitDragon]

@Atak_Snajpera

Yeah I tried both yv12 and nv12 outputs. When playing H-264 1080i60 content it keeps frame dropping with ffdshow_rev3904_20110623_clsid.exe. Switching to rev. 3886 it plays rock solid at steady 60fps. Both tests the cpu utilization is ~23%, like yours.

[Px]

There was a discussion about postprocessing filter more that year ago:
Is it normal that the postprocessing filter is applicable only to the following codecs :
Raw codecs, then :
case CODEC_ID_MPEG1VIDEO:
case CODEC_ID_MPEG2VIDEO:
case CODEC_ID_LIBMPEG2:
case CODEC_ID_MPEG4:
case CODEC_ID_MSMPEG4V1:
case CODEC_ID_MSMPEG4V2:
case CODEC_ID_MSMPEG4V3:
case CODEC_ID_H263:
case CODEC_ID_SVQ1:
case CODEC_ID_FLV1:
case CODEC_ID_INDEO2:
case CODEC_ID_INDEO3:
case CODEC_ID_XVID4:
case CODEC_ID_MJPEG:
case CODEC_ID_MJPEGB:
case CODEC_ID_MSVIDEO1:
case CODEC_ID_CINEPAK:
case CODEC_ID_VP5:
case CODEC_ID_VP6:
case CODEC_ID_VP6F:
For example it is disabled for H264 formats
and now I have small question: why PP disabled for WMV formats? I've got several "blocky" wmv videos, and thinking that PP might help in this case

[andybkma]

Hi, dumb question... what is the difference between icl12 and VS2010 builds as displayed on XvidVideo.RU page? I have both XP and Windows 7 (both 32-bit) machines. Is icl12 or VS2010 build preferable over the other? Reason I ask is because I don't see those types of builds on the Sourceforge page (https://sourceforge.net/projects/ffdshow-tryout/files/)

Thank you kindly...

[fastplayer]

Read the FAQ:
http://ffdshow-tryout.sourceforge.net/wiki/faq

[clsid]

Generic = VS2010 (VS2008 in the past)

ICL builds have little benefit for most users.

[fastplayer]

@clsid:
Can you release rev3912 builds as release candidates? Or do you wanna wait and choose a different rev?

[djonline]

How to enable FFV1 with slices ?

[clsid]

For decoding: goes automatic.
For encoding: there doesn't seem to be an option to control it.

[arestarh]

Hello!

In last revisions of ffdshow hints in configure dialog don't appear (when I call configure dialog through link in Start menu), I see only following hints:
http://i047.radikal.ru/1106/2b/0a79637655f0t.jpg (http://radikal.ru/F/i047.radikal.ru/1106/2b/0a79637655f0.jpg.html)

But when other application call ffdshow.ax, configure dialog looks like this:
http://i006.radikal.ru/1106/4e/e1e76d27cf81t.jpg (http://radikal.ru/F/i006.radikal.ru/1106/4e/e1e76d27cf81.jpg.html)

Windows XP SP3, ffdshow build 3912.
Maybe it's problem at my side. I don't know for sure.

[fastplayer]

Confirmed on XP SP3 (Win7 is OK). Tooltips don't appear when calling ffdshow's configuration dialogs via start menu shortcuts.

Edit: Narrowed it down to rev3897-->tooltips OK, rev3899-->tooltips broken.
Edit#2: It's not just the tooltips but obviously the manifests are broken too for XP SP3.

[clsid]

Manifests are installed again in 3913. Embedded one doesn't work properly on XP. Will probably also fix the tooltips.

[arestarh]

Manifests are installed again in 3913. Embedded one doesn't work properly on XP. Will probably also fix the tooltips.
It helped. Thanks.

clsid
Updated Russian translation:
http://www.mediafire.com/?38zgb35hkur8f4g

[Snowknight26]

More Fraps regressions (tested with r3914):

FPS1 -> RGB32 has inverted chroma planes.
FPS1 -> YV12/NV12 has a 16 pixel-wide bright bar on the very right side of the video.
FPS1 -> YUV2/UYVY is fine.


Sample: http://stfcc.org/misc/ffplay_fraps_video_stutter_with_audio.avi

[Px]

There was a discussion about postprocessing filter more that year ago:
and now I have small question: why PP disabled for WMV formats? I've got several "blocky" wmv videos, and thinking that PP might help in this case

Em, bump?

[clsid]

More Fraps regressions (tested with r3914):

FPS1 -> RGB32 has inverted chroma planes.
FPS1 -> YV12/NV12 has a 16 pixel-wide bright bar on the very right side of the video.
FPS1 -> YUV2/UYVY is fine.


Sample: http://stfcc.org/misc/ffplay_fraps_video_stutter_with_audio.avi
Should be fixed now. I also fixed a similar issue with ZMVB video.

[Hypernova]

Hi,

So, from my skimming the past 10 pages, audio un-sync problem with multithread is still a known problem, correct? In my case it only happen with avi. H264 in mkv works fine for me.

[clsid]

It was not known in case of H.264. But if it also happens, then that sucks. A good reason to avoid H.264 in AVI.

[Atak_Snajpera]

In my case it only happen with avi.
Smart people don't use ancient avi (http://en.wikipedia.org/wiki/Audio_Video_Interleave#Limitations) container with h.264 stream. See also this http://en.wikipedia.org/wiki/Comparison_of_container_formats#Video_formats_supported

[clsid]

Does anyone have a sample where the sync issue is really noticeable?

I can limit the number of threads in case of AVI to a number where the sync issue isn't noticeable anymore.

[Hypernova]

Does anyone have a sample where the sync issue is really noticeable?

I can limit the number of threads in case of AVI to a number where the sync issue isn't noticeable anymore.

I have at least two examples of h264 in AVIs that has noticable lag (~500ms). It's quite old anime fansubs, Cyber Formula Double-one by Ayu and Akazukin ChaCha by the group I don't know the name. If you need help to get a hold of that please let me know. Noted that I do notice the lag even in 2 threads (out of 8) though.

Smart people don't use ancient avi (http://en.wikipedia.org/wiki/Audio_Video_Interleave#Limitations) container with h.264 stream. See also this http://en.wikipedia.org/wiki/Comparison_of_container_formats#Video_formats_supported

I'm not the one who create the file, so it's not really a choice on my part.

[VipZ]

I cant seem to be able to compile the latest x64 build anymore

I get the below message when using MSYS_MinGW_GCC_461_x86-x64_Full.7z,
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb00f): undefined reference to `_ff_pb_F8'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb01c): undefined reference to `_ff_pb_3'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb025): undefined reference to `_ff_pb_4'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb090): undefined reference to `_ff_pb_1'
collect2: ld returned 1 exit status
C:\MSYS\mingw\bin\x86_64-w64-mingw32-dllwrap.exe: C:\MSYS\mingw\bin\x86_64-w64-m
ingw32-gcc exited with status 1
make: *** [../../bin/ffmpeg.dll] Error 1

[Hypernova]

Not sure if this is useful but I tried using MPC-HC (3283, MSVC 2010SP1, with ffmpeg by MinGW GCC 4.6.1), which as far as I can tell also use mutithread decoding. There is no lag.

Note: By lag I mean the video lag behind audio.

[clsid]

I have at least two examples of h264 in AVIs that has noticable lag (~500ms). It's quite old anime fansubs, Cyber Formula Double-one by Ayu and Akazukin ChaCha by the group I don't know the name. If you need help to get a hold of that please let me know. Noted that I do notice the lag even in 2 threads (out of 8) though.Cut a sample with DGSplit and upload it for me.

Does the sync difference grow with more threads? It should.

Not sure if this is useful but I tried using MPC-HC (3283, MSVC 2010SP1, with ffmpeg by MinGW GCC 4.6.1), which as far as I can tell also use mutithread decoding. There is no lag. MPC does not have multi-threaded decoding.

[clsid]

I cant seem to be able to compile the latest x64 build anymore
There is a working mingw64 package on the SourceForge page.

[Hypernova]

I don't know if I did any wrong but only the first part seem to playable after splited by DGSplit. Please use the second half where the karaoke appear to see the lag.

http://www.mediafire.com/?9jf19139i6e0uh2

[alexins]

I cant seem to be able to compile the latest x64 build anymore

I get the below message when using MSYS_MinGW_GCC_461_x86-x64_Full.7z,
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb00f): undefined reference to `_ff_pb_F8'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb01c): undefined reference to `_ff_pb_3'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb025): undefined reference to `_ff_pb_4'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb090): undefined reference to `_ff_pb_1'
collect2: ld returned 1 exit status
C:\MSYS\mingw\bin\x86_64-w64-mingw32-dllwrap.exe: C:\MSYS\mingw\bin\x86_64-w64-m
ingw32-gcc exited with status 1
make: *** [../../bin/ffmpeg.dll] Error 1

Use this patch:

Index: src/ffmpeg/config.h
===================================================================
--- src/ffmpeg/config.h (revision 3919)
+++ src/ffmpeg/config.h (working copy)
@@ -43,8 +43,8 @@
#define ASMALIGN(ZEROBITS) ".p2align " #ZEROBITS "\n\t"

#if ARCH_X86_64
- #define EXTERN_PREFIX "_"
- #define EXTERN_ASM _
+ #define EXTERN_PREFIX ""
+ #define EXTERN_ASM
#else
#define EXTERN_PREFIX "_"
#define EXTERN_ASM _
Index: src/makefile_c.inc
===================================================================
--- src/makefile_c.inc (revision 3919)
+++ src/makefile_c.inc (working copy)
@@ -12,7 +12,7 @@
TARGET_OS=x86_64-w64-mingw32
CFLAGS+=-DWIN64 -D_WIN64 -D__MINGW64__
OPTFLAGS+=-O2 -m64
- YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64 -DPREFIX
+ YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64
else
TARGET_OS=i686-w32-mingw32
CFLAGS+=-DWIN32 -D_WIN32 -D__MINGW32__
@@ -21,7 +21,7 @@
endif

CFLAGS+=-mdll -mthreads -pipe
-OPTFLAGS+=-fno-common -fno-tree-vectorize
+OPTFLAGS+=-fno-common
CPPFLAGS+=-fno-rtti
OUTPUTFLAG=-MMD -o\

@@ -30,7 +30,7 @@
YASMFLAGS+=-g cv8
else
CFLAGS+=-DNDEBUG -UDEBUG
- OPTFLAGS+=-fomit-frame-pointer
+# OPTFLAGS+=-fomit-frame-pointer (with GCC4.6.x - 4.7.x it is not used.)
LDFLAGS+=-s
endif

And also, in the folder \bin\lib_x64 put the file libpthreadGC2.a (libpthreadGC2 x64 generic cvs.20110403). (http://www.mediafire.com/?rtpyqzyqrcdd5ck)

[Atak_Snajpera]

I'm not the one who create the file, so it's not really a choice on my part.
Wouldn't be easier to just remux from stupid avi to modern mkv/mp4???

[roozhou]

Wouldn't be easier to just remux from stupid avi to modern mkv/mp4???
Some DV also produce AVC in AVI. Actually AVC in AVI is just AnnexB in AVI. If the decoder cannot correctly handle AVC in AVI, it cannot handle AnnexB stream either.

[clsid]

And also, in the folder \bin\lib_x64 put the file libpthreadGC2.a (libpthreadGC2 x64 generic cvs.20110403). (http://www.mediafire.com/?rtpyqzyqrcdd5ck)I will test this to see if this results in a stable x64 build. Can you make a build x86/x64 for latest cvs?

Edit: can you test this file with x64 build:
http://www.zshare.net/video/92250008bfd03cce/
It crashes for me with new pthreads, but not with old. But might also be GCC bug.

Edit2: Build made with GCC 4.5.2 does not crash. So it looks like a bug in newer versions of GCC.

[robpdotcom]

I'd like to use ffdshow video for W7MC recordings (.wtv files) inside MPC-HC, but it will not connect. Should I open a ticket for this?

[Atak_Snajpera]

I'd like to use ffdshow video for W7MC recordings (.wtv files) inside MPC-HC, but it will not connect. Should I open a ticket for this?
Convert to .dvr-ms format. (Right click) or to .ts (http://experts.windows.com/frms/windows_entertainment_and_connected_home/f/49/t/95712.aspx)

[Boulder]

When encoding an RGB source in VDub using ffdshow's HuffYUV and YV12 colorspace, how does ffdshow perform the colorspace conversion? Is it similar to ConverttoYV12 (using the same matrix, Rec601) in Avisynth?

[VipZ]

@ alexins

Thanks for the help :)

@clsid

That video you mentioned to be crashing, on my builds it isn't crashing which is the build I am currently using, Rev 3916 built with mingw_gcc_461_v20110623_x86-x64-pre-release.7z from xvidvideo.ru

[hoborg]

Hi.
There seems to be a problem with FFDshow DXVA decoder when removing from graph - it will cause Graphstudio (and other software) to crash.

It is easy to reproduce - just open any DXVA compatible video in graphstudio then try to remove FFDShow DXVA decoder from graph - Graphstudio will crash.

This doesn't happend with normal FFDshow video decoder (and other DXVA decoders like PDVD).

[clsid]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

[hoborg]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

VMR9 on XP and EVR on Win7.

I changed default renderer on my OS, so Graphstudio use EVR by default on my Win7.

[Midzuki]

In the "Version Details" window (r3919):
ff_kernelDeint.dll Not found
:confused:

Also: the MJPG VfW decoder swaps the channels U and V :(

[clsid]

Do you have a sample? I only have one mjpeg in avi file and that gives correct colors in VirtualDub.

It is easy to adjust colorspace in VirtualDub. Video -> Color Depth.

[zummi]

Hi Gurus :)

Quick question: I'm having trouble with my PGS subtitles. They always appear in the *upper left* corner of my screen. I've tried playing with the subtitles settings in ffdshow, and I'm able to change font size etc...but the placement won't change. Have I completely overlooked something basic here...?

I'm running the latest version of ffdshow of course. Thanks :)

[andybkma]

Greetings, just a quick question. Is ffdshow supposed to be able to decode all wmv content without any problems? Cuz I have many .wmv vids (mostly WMV3/9) for which I only get a grey screen when selecting libavcodec for WMV3/9 and a green screen when I select wmv9 (the vids play fine if I use the internal windows wmv decoder). It doesn't matter which renderer I use, the resulting blocky green & grey screens still occur making the vid unwatchable. This has been going on for as long as I have been using ffdshow (7+ years) and even the most recent builds within the past week still have the same problem. Was just wondering if there is something I can do to finally fix this problem...

Thanks for any tips/guidance...

[hoborg]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

So you was not able to reproduce it?

This is how it can be reproduced (Vista/Win7):

Start Graphstudio, look for EVR renderer, then change merit to max.
Restart PC
Open any DXVA compatible video in graphstudio, graph will be now builded using FFDshow DXVA decoder + EVR renderer (instead of video renderer).
Try to remove FFDshow DXVA decoder from graph (click on ffdshow dxva decoder and hit delete key).
Graphstudio will crash.

[clsid]

Greetings, just a quick question. Is ffdshow supposed to be able to decode all wmv content without any problems? Cuz I have many .wmv vids (mostly WMV3/9) for which I only get a grey screen when selecting libavcodec for WMV3/9 and a green screen when I select wmv9 (the vids play fine if I use the internal windows wmv decoder). It doesn't matter which renderer I use, the resulting blocky green & grey screens still occur making the vid unwatchable. This has been going on for as long as I have been using ffdshow (7+ years) and even the most recent builds within the past week still have the same problem. Was just wondering if there is something I can do to finally fix this problem...

Thanks for any tips/guidance...
Please post a sample file that gives you this problem, so that we can test it.

[clsid]

Hi Gurus :)

Quick question: I'm having trouble with my PGS subtitles. They always appear in the *upper left* corner of my screen. I've tried playing with the subtitles settings in ffdshow, and I'm able to change font size etc...but the placement won't change. Have I completely overlooked something basic here...?

I'm running the latest version of ffdshow of course. Thanks :)PGS support may be buggy and it is unlikely that it will get fixed if no additional developers join the project.
Try the internal subtitle renderer of MPC instead.

[clsid]

So you was not able to reproduce it?Can´t reproduce. Can´t fix. Sorry. Maybe someone else can.

[Midzuki]

Please ignore the apparent "anomaly" in the MJPEG decoder --- it "magically" disappeared after I (re-)installed ReClock :eek: :confused: Yep, the rootkits are getting more and more evil, their "residual symptoms" are completely "absurd", but they do exist and happen anyway. :( :( :(

[zummi]

PGS support may be buggy and it is unlikely that it will get fixed if no additional developers join the project.
Try the internal subtitle renderer of MPC instead.

Thanks. I'm running Windows Media Player (within Win MCE) for higher WAF :P So I guess I'm screwed :p

Thanks anyway :)

[andybkma]

Please post a sample file that gives you this problem, so that we can test it.

Thanks so much... I have pm'd you.

Andy

[clsid]

@zummi
DirectVobSub has the same capapbilities as the internal subtitle renderer of MPC.

@andybkma
This is a splitter problem. It does not work properly with the standard MS splitter. The files play properly when forcing LAV Splitter as the source filter. Here is a Registry tweak for that:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.wmv]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

[wOxxOm]

is it known that AVC/m2ts terribly lags with newer builds?
Older builds still work correctly in the same environment.

builds pre-3892: OK
builds post-3904: FAIL

[clsid]

You are the first to mention such problems.

What exactly do you mean with lag? A sync delay? Stuttering?
Does the problem go away if you adjust the number of decoding threads in the decoder options?
Does it only happen with M2TS? MKV and MP4 are fine?

[wOxxOm]

ehm, have you tried playing avc in m2ts container?
lags will be seen at once, e.g. video plays at half the speed, total desync, etc.
all options are set to defaults

this issue is confirmed by 3 users btw.

[dwild]

Does the problem go away if you adjust the number of decoding threads in the decoder options?
Nothing changes.


Does it only happen with M2TS? MKV and MP4 are fine?
Every file that requires more than one cpu core to decode.
Looks like threading problem.
Quad-core cpu utilisation (same m2ts file):
builds 3904-3925 - 25-30%, lags.
build 3892 and earlier - 40%, no lags.

[clsid]

I have a fast CPU. CPU usage is below 10% here when playing 1080p H.264 in TS. No lag at all.

Please point to a sample file I should test.

Also try builds in between 3892 and 3904.

[dwild]

I have a fast CPU. CPU usage is below 10% here when playing 1080p H.264 in TS. No lag at all.
It's an i7, I guess?

Please point to a sample file I should test.
From previous quote - that doesn't matter. It's every .m2ts file.

Also try builds in between 3892 and 3904.
Sorry, but I'm seeing only those two on your site, nothing in-between.

[wOxxOm]

@clsid: any BD will do, however I sent you a 15s sample via pm (look at fps in MPC's Statistics pane)

p.s. also you should use a utility to slowdown speed of your CPU for testing purposes, or wait! there's a neat trick - rightclick a player process in Windows' TaskManager, select Affinity and set it to only 1 core. This way you'll be able to spot any problems at once.

and btw, you're not using DXVA, are you?

[clsid]

BD playback is smooth here. Even with a single thread. No DXVA.

Here are two other builds:
http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-3894-x86-x64.html
http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-3897-x86-x64.html

[dwild]

Here are two other builds:
...
They both lag.
So it was introduced in 3893 or 3894.

[JEEB]

I have to agree that there seems to be a performance regression or a synchronization regression around revision 3888 or so with H.264 that comes up mostly with blu-ray streams (mpeg-ts, splitter doesn't seem to matter). Haven't done specific testing, but when building things on the 26th of June trunk HEAD seemed to already have the regression, and revision 3887 seemed to be alright (the libavcodec multithreading used in both cases). This seems to have been reported at the Japanese 2ch board as well (example (http://hibari.2ch.net/test/read.cgi/software/1299337855/549)).

Other than with just plain eyes, the difference can be seen by looking at the green and red lines on MPC-HC's stats output. 3887 and before might have had some sudden rises in the synch difference or whatever it shows, but with a revision affected by this regression the rises would be MUCH bigger. As the effects of this regression are seemingly overall smaller with newer CPUs (I'm on a 2.26GHz Penryn C2D), I would guess that the difference would be visible via this kind of output in case of no visible stutter.

Will try to build and test revision-by-revision later on.

MSVS2010 SP1, GCC 4.5.3

[clsid]

3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=commitdiff;h=ea6331f8bbaf3343faec6ffe77a6218a016a3af5

[JEEB]

3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=commitdiff;h=ea6331f8bbaf3343faec6ffe77a6218a016a3af5
Re-built with that commit reverted, and it unfortunately was still stuttering all around the place.

Edit: the libavcodec/h264.c change, that is.
Edit2: I take my words back, same problem came up with mplayer2, and reverting that commit fixed it in there. Uploading a sample for BBB now.

[PetitDragon]

You are the first to mention such problems.

What exactly do you mean with lag? A sync delay? Stuttering?
Does the problem go away if you adjust the number of decoding threads in the decoder options?
Does it only happen with M2TS? MKV and MP4 are fine?

Hi clsid,

I mentioned the similar problem at 25th June.:) (http://forum.doom9.org/showthread.php?p=1510105#post1510105)

[ikarad]

3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=commitdiff;h=ea6331f8bbaf3343faec6ffe77a6218a016a3af5

How to decide to make a release candidate even when important bugs are still present?
By curiosity I would like to know.


Moreover i don't know if anybody works on sub renderer (which is still buggued) today but this problem is not yet corrected
https://sourceforge.net/tracker/index.php?func=detail&aid=3186705&group_id=173941&atid=867360

[hoborg]

Can´t reproduce. Can´t fix. Sorry. Maybe someone else can.

Too bad :(
But here is video (http://www.youtube.com/watch?v=KZreMRTsuXk) what happening.
Tested h.264 in mp4/m2ts/mkv container - all of them crash Graphstudio when deleting FFDshow DXVA decoder from graph.
No problem with FFDshow video decoder - tested on xvid AVI.

[clsid]

How to decide to make a release candidate even when important bugs are still present?
By curiosity I would like to know.There isn't any RC.

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.

[ikarad]

There isn't any RC.

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.

I don't know what bug you told but I speak about sub renderer bugs (bug that I post the link above: here https://sourceforge.net/tracker/index.php?func=detail&aid=3186705&group_id=173941&atid=867360).

If you speak about ffdshow-mt, I never have bugs with ffdshow-mt since one or two year with blu-ray movies or anime in h264 (I stop at version 3614 (I only test briefly the next versions then I don't know if the next versions are buggued with ffdshow-mt).

[JEEB]

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.
Basically the cause was a fix to the threading code that could produce incorrect results with H.264 streams having slices:
// packets can sometimes contain multiple PPS/SPS
// e.g. two PAFF field pictures in one packet, or a demuxer which splits NALs strangely
// if so, when frame threading we can't start the next thread until we've read all of them
Cases NAL_IDR_SLICE and NAL_SLICE were added to it, to take sliced streams into mention (basically more stuff is done with slice-having streams [blu-ray specs mandate all level 4.1 blu-ray streams to have slices, f.ex.] before threads can continue/be started). Which is a valid fix.

Now, of course I have no idea if this fix actually touches us, as in -- is it needed in our use case of ffdshow-tryouts (probably is), but BBB answered my calls right away, and I gave him out a ~420MB sample that might help him develop something that not only fixes the borked cases, but also does less damage towards decoding capabilities with frame-based multithreading (slice-based multithreading is unaffected, as is single-threaded decoding).

[clsid]

You can enable slice-based threading by modifying "ffcodecs.h". I did a quick test and it gives similar performance here for a BR sample. Slice was even marginally faster than frame-based. Can you test on your PC if slice-based balances the load better?

Using slice-based threading on streams without slices will of course give crappy performance, so if we would ever use it it must be done conditionally.

Who is BBB btw?

[JEEB]

You can enable slice-based threading by modifying "ffcodecs.h". I did a quick test and it gives similar performance here for a BR sample. Slice was even marginally faster than frame-based. Can you test on your PC if slice-based balances the load better?Will see in a momento... or tomorrow (today) after I get some sleep. Been a rather hectic weekend.

Who is BBB btw?Ronald S. Bultje's nickname on IRC, as I don't use the mailing list much (read: at all).

[ikarad]

I don't know where I can post this thing but Ihave noticed that in the versions from xvidvideo.ru (icl12 and mvsc2010), deband filter doesn't work since several months. With versions from ffdshow site deband filter works well.

[andybkma]

@andybkma
This is a splitter problem. It does not work properly with the standard MS splitter. The files play properly when forcing LAV Splitter as the source filter. Here is a Registry tweak for that:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.wmv]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

Ah, thanks for your kind response and advice, clisd. So ummm... just curious as to why ffdshow won't work properly with the standard MS Splitter for those vids? Were the vids encoded improperly by their makers or something like that? Unfortunately setting the LAV Splitter to split all my wmv content is a no go solution but is nice to know all the same :)

[Sebastiii]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

Hi clsid :)

I can reproduce this issue in graphstudio and mediaportal too.
With different source splitter (Haali/LAV/MPC Matroska), i made my test on mkv.

On the all combination (all crash when i remove FFDShow DXVA):
http://dl.dropbox.com/u/10536084/FFDShow_DXVACrash/Crash1_DXVA_FFDShow.jpg
http://dl.dropbox.com/u/10536084/FFDShow_DXVACrash/Crash2_DXVA_FFDShow.jpg
http://dl.dropbox.com/u/10536084/FFDShow_DXVACrash/Crash3_DXVA_FFDShow.jpg

I do like Hoborg, set EVR Renderer as High merit to be the one loaded first.

If we disconnect output pin of FFDShow DXVA before remove filter = no crash :)

This is strange that you can't get it.
Thanks.

[hoborg]

Hi.
I noticed there is an ugly pixelation on some h.264 video streams if FFDShow DXVA decoder is in use.
This pixelation wasn't here before, so i did some research. I tracked down that the relase 3883 introduce the pixelation, becouse 3882 is ok.
Here is video sample (http://www16.zippyshare.com/v/37666086/file.html).
Normal FFDshow video decoder is not affected.

[clsid]

Sample link is broken.

[hoborg]

Sample link is broken.

Sample link is fixed now, sorry...

[Sven75]

The following CVID in MOV container is still not working with current LAVFilter and ffdShow:

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

See this posting (http://forum.doom9.org/showthread.php?p=1509376#post1509376) for more details.

[clsid]

@hoborg
DXVA decoding issue is fixed.

@Sven75
Decoding with the Cinepak VFW codec of Windows is fine too.
I don't know what is wrong, so you have to ask nevcariel to check what changed in ffmpeg.

[hoborg]

@hoborg
DXVA decoding issue is fixed.

:thanks:

[JEEB]

libavcodec/h261.c
libavcodec/h261dec.c
libavcodec/h261dec.c: In function 'h261_decode_frame':
libavcodec/h261dec.c:623:1: error: 'Picture' has no member named 'pict_type'
libavcodec/h261dec.c:623:1: error: 'Picture' has no member named 'pict_type'
libavcodec/h261dec.c:624:1: error: 'Picture' has no member named 'pict_type'
make: *** [../../obj/MinGW32/ffmpeg/libavcodec/h261dec.o] Error 1
It seems like I cannot build a debug ffmpeg.dll at the moment, can anyone replicate this (r3936)? Normal compilation works fine.

[Dstruct]

Some ffdshow crash that I'm getting in VirtualDub:

VirtualDub crash report -- build 34610 (release)
--------------------------------------

Disassembly:
6d1b0e00: 140f adc al, 0fh
6d1b0e02: 85f9 test ecx, edi
6d1b0e04: fd std
6d1b0e05: ff db 0ffh
6d1b0e06: ff83c4205b5e inc dword ptr [ebx+5e5b20c4]
6d1b0e0c: 5f pop edi
6d1b0e0d: 5d pop ebp
6d1b0e0e: c3 ret
6d1b0e0f: 90 nop
6d1b0e10: 55 push ebp
6d1b0e11: 57 push edi
6d1b0e12: bf08000000 mov edi, 00000008
6d1b0e17: 56 push esi
6d1b0e18: 89fe mov esi, edi
6d1b0e1a: 53 push ebx
6d1b0e1b: 83ec24 sub esp, 24h
6d1b0e1e: 8b5c244c mov ebx, [esp+4ch]
6d1b0e22: 8b6c2448 mov ebp, [esp+48h]
6d1b0e26: 8b4c2438 mov ecx, [esp+38h]
6d1b0e2a: 8b542440 mov edx, [esp+40h]
6d1b0e2e: 29df sub edi, ebx
6d1b0e30: 29ee sub esi, ebp
6d1b0e32: 89f8 mov eax, edi
6d1b0e34: 0fafc6 imul eax, esi
6d1b0e37: 0faffd imul edi, ebp
6d1b0e3a: 0faff3 imul esi, ebx
6d1b0e3d: 0fafdd imul ebx, ebp
6d1b0e40: 8b6c2444 mov ebp, [esp+44h]
6d1b0e44: 89442408 mov [esp+08h], eax
6d1b0e48: 897c240c mov [esp+0ch], edi
6d1b0e4c: 89742410 mov [esp+10h], esi
6d1b0e50: 85ed test ebp, ebp
6d1b0e52: 895c2414 mov [esp+14h], ebx
6d1b0e56: 0f8ea7020000 jle 6d1b1103
6d1b0e5c: 8b44243c mov eax, [esp+3ch]
6d1b0e60: 89d6 mov esi, edx
6d1b0e62: c7442418000000 mov dword ptr [esp+18h], 00000000
00
6d1b0e6a: f7de neg esi
6d1b0e6c: 8d742600 lea esi, [esi+00h]
6d1b0e70: 0fb638 movzx edi, byte ptr [eax]
6d1b0e73: 0faf7c2408 imul edi, [esp+08h]
6d1b0e78: 897c2404 mov [esp+04h], edi
6d1b0e7c: 0fb67801 movzx edi, byte ptr [eax+01h]
6d1b0e80: 0faf7c240c imul edi, [esp+0ch]
6d1b0e85: 897c241c mov [esp+1ch], edi
6d1b0e89: 0fb66c1001 movzx ebp, byte ptr [eax+edx+01h] <-- FAULT
6d1b0e8e: 01d0 add eax, edx
6d1b0e90: 8d1c30 lea ebx, [eax+esi]
6d1b0e93: 891c24 mov [esp], ebx
6d1b0e96: 0fb639 movzx edi, byte ptr [ecx]
6d1b0e99: 0faf6c2414 imul ebp, [esp+14h]
6d1b0e9e: 897c2420 mov [esp+20h], edi
6d1b0ea2: 0fb63c13 movzx edi, byte ptr [ebx+edx]
6d1b0ea6: 0faf7c2410 imul edi, [esp+10h]
6d1b0eab: 8d7c3d1c lea edi, [ebp+edi+1ch]
6d1b0eaf: 8b6c2420 mov ebp, [esp+20h]
6d1b0eb3: 037c2404 add edi, [esp+04h]
6d1b0eb7: 037c241c add edi, [esp+1ch]
6d1b0ebb: c1ff06 sar edi, 06h
6d1b0ebe: 8d7c3d01 lea edi, [ebp+edi+01h]
6d1b0ec2: d1ff sar edi, 1
6d1b0ec4: 89fb mov ebx, edi
6d1b0ec6: 0fb67901 movzx edi, byte ptr [ecx+01h]
6d1b0eca: 8819 mov [ecx], bl
6d1b0ecc: 8b1c24 mov ebx, [esp]
6d1b0ecf: 897c2404 mov [esp+04h], edi
6d1b0ed3: 0fb66c1302 movzx ebp, byte ptr [ebx+edx+02h]
6d1b0ed8: 0fb67c1301 movzx edi, byte ptr [ebx+edx+01h]
6d1b0edd: 0faf6c2414 imul ebp, [esp+14h]
6d1b0ee2: 0faf7c2410 imul edi, [esp+10h]
6d1b0ee7: 8d7c3d1c lea edi, [ebp+edi+1ch]
6d1b0eeb: 0fb66c3001 movzx ebp, byte ptr [eax+esi+01h]
6d1b0ef0: 0faf6c2408 imul ebp, [esp+08h]
6d1b0ef5: 8d2c2f lea ebp, [edi+ebp]
6d1b0ef8: 0fb67c3002 movzx edi, byte ptr [eax+esi+02h]
6d1b0efd: 0f db 0fh
6d1b0efe: af scasd
6d1b0eff: 7c db 7ch

Built on Althena on Sat Jun 18 14:40:53 2011 using compiler version 1400

Windows 5.1 (Windows XP x86 build 2600) [Service Pack 3]
Memory status: virtual free 1942M/2048M, commit limit 4967M, physical total 2046M

EAX = 02a9ce50
EBX = 00000081
ECX = 01d75ed0
EDX = 000001b0
EBP = 0000205c
ESI = fffffe50
EDI = 00000000
ESP = 0012f6e8
EIP = 6d1b0e89
EFLAGS = 00010296
FPUCW = ffff027f
FPUTW = ffffaaaa

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'ffmpeg'...

...reading address 02A9D001.

Pointer dumps:

EAX 02a9ce50: 81818181 81818181 81818181 81818181 83838383 83838383 83838383 83838383
ECX 01d75ed0: 81818181 81818181 81818181 81818181 83838383 83838383 83838383 83838383
ESP 0012f6e8: 02a9cca0 00002040 00000040 00000000 00000000 00000000 00000007 00000000
0012f708: 00000081 01c962a0 00000000 01cb25c0 00000000 6d1a29b2 01d75300 02a9c280
0012f728: 000001b0 00000008 00000000 00000000 00000000 fffff4c4 00000000 fffff884
0012f748: 00000000 00000000 00000000 00000000 000002c0 01d160e0 00006428 000002c0

Thread call stack:
6d1b0e89: ffmpeg!av_vc1_decode_frame [6d000000+1ade00+3089]
6d1ab778: ffmpeg!avcodec_default_get_buffer [6d000000+19cb70+ec08]
016dcde0: ffdshow!configureEnc [01590000+1013b0+4ba30]
016dcd20: ffdshow!configureEnc [01590000+1013b0+4b970]
6d2204ef: ffmpeg!av_vc1_decode_frame [6d000000+1ade00+726ef]
6d147a8f: ffmpeg!av_h264_decode_frame [6d000000+a8b50+9ef3f]
6d078f29: ffmpeg!avcodec_get_encoder_info [6d000000+71030+7ef9]
6d1ad0c8: ffmpeg!avcodec_default_get_buffer [6d000000+19cb70+10558]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c92019b: ntdll!RtlAllocateHeap [7c910000+100c4+d7]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c92019b: ntdll!RtlAllocateHeap [7c910000+100c4+d7]
7c9201db: ntdll!RtlAllocateHeap [7c910000+100c4+117]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c92019b: ntdll!RtlAllocateHeap [7c910000+100c4+d7]
7c9201db: ntdll!RtlAllocateHeap [7c910000+100c4+117]
6d19c421: ffmpeg!avcodec_decode_video2 [6d000000+19c390+91]
017be45c: ffdshow!configureEnc [01590000+1013b0+12d0ac]
016d57f8: ffdshow!configureEnc [01590000+1013b0+44448]
7e383416: USER32!EditWndProc [7e360000+23000+416]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
017cbd66: ffdshow!DllGetClassObject [01590000+236d60+5006]
7c9201db: ntdll!RtlAllocateHeap [7c910000+100c4+117]
017cec6a: ffdshow!DllGetClassObject [01590000+236d60+7f0a]
017bee3a: ffdshow!configureEnc [01590000+1013b0+12da8a]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
017bf071: ffdshow!configureEnc [01590000+1013b0+12dcc1]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
017cbd66: ffdshow!DllGetClassObject [01590000+236d60+5006]
017bf1dd: ffdshow!configureEnc [01590000+1013b0+12de2d]
00c52ed1: ff_vfw!DriverProc [00c50000+2c40+291]
75ec1938: MSVFW32!ICSendMessage [75ec0000+190d+2b]
75ec4df4: MSVFW32!ICDecompress [75ec0000+4db7+3d]
10005d0a: WMV!VDGetPluginInfo [10000000+4010+1cfa]
10005ed2: WMV!VDGetPluginInfo [10000000+4010+1ec2]
004eb8c4: VDVideoSourcePlugin::streamGetFrame()
0043bdc0: VDFilterFrameVideoSource::RunRequests()
00437965: VDFilterAccelUploader::RunRequests()
00447af2: FilterSystem::Run()
0046ff78: VDProject::UpdateFrame()
7e36882a: USER32!GetDC [7e360000+86c7+163]
7e3689cd: USER32!GetWindowLongW [7e360000+88a6+127]
7e3689ea: USER32!GetWindowLongW [7e360000+88a6+144]
7e37a43b: USER32!PeekMessageA [7e360000+1a340+fb]
00472ba3: VDProject::Tick()
0045facc: WinMain@16()
005e2df6: __tmainCRTStartup()
7c817077: kernel32!RegisterWaitForInputIdle [7c800000+1702e+49]

-- End of report

VirtualDub 1.10.1-test11
fccHandler WMV Plugin 2.5 for VirtualDub
ffdshow tryouts 1.1.3919


Crashing file example:

General
Format : Windows Media
File size : 335 MiB
Duration : 30mn 55s
Overall bit rate mode : Constant
Overall bit rate : 1 514 Kbps
Maximum Overall bit rate : 1 612 Kbps
Encoded date : UTC 2011-07-06 20:54:49.364

Video
ID : 2
Format : VC-1
Format profile : AP@L1
Codec ID : WVC1
Codec ID/Hint : Microsoft
Description of the codec : VC-1 - VC-1 Advanced Profile
Duration : 30mn 55s
Bit rate mode : Constant
Bit rate : 1 500 Kbps
Width : 852 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.122
Stream size : 332 MiB (99%)
Language : English (US)

Audio
ID : 1
Format : WMA
Format version : Version 2
Codec ID : 161
Codec ID/Info : Windows Media Audio
Description of the codec : Windows Media Audio 9.2 - 96 kbps, 44 kHz, stereo 2-pass CBR
Duration : 30mn 55s
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 21.2 MiB (6%)
Language : English (US)

[clsid]

Does it also crash in DirectShow?
I doubt I can fix it, but please post a sample file anyway.

[Dstruct]

Does it also crash in DirectShow?

Doesn't seem to crash in MPC-HC + ffdshow.


I doubt I can fix it, but please post a sample file anyway.

I'll send you a link when uploaded ....

[god_md5]

ffdshow_rev3933_20110712_clsid.exe

問題簽章:
問題事件名稱: APPCRASH
應用程式名稱: mpc-hc.exe
應用程式版本: 1.5.2.3314
應用程式時間戳記: 4e110c47
錯誤模組名稱: ffmpeg.dll
錯誤模組版本: 0.0.0.0
錯誤模組時間戳記: 4e1b9114
例外狀況代碼: c0000005
例外狀況位移: 0024e3a0
作業系統版本: 6.1.7601.2.1.0.256.1
地區設定識別碼: 3076
其他資訊 1: 0a9e
其他資訊 2: 0a9e372d3b4ad19135b953a78882e789
其他資訊 3: 0a9e
其他資訊 4: 0a9e372d3b4ad19135b953a78882e789

[clsid]

Need more info. You did not even mention what kind of file it is.

If it only crashes with a particular file, then I need a sample.

[Dstruct]

Doesn't seem to crash in MPC-HC + ffdshow.




I'll send you a link when uploaded ....

Upload done!

[alexins]

Need more info. You did not even mention what kind of file it is.

If it only crashes with a particular file, then I need a sample.

Hi! This happens when the video is done through NV12. When NV12, disabled, everything works without errors. I got it going on on any video files (avi, mkv, mpg, ts, ...). ffdshow x86/x64 rev. 3932, 3933, 3934, 3935, 3936, 3937.

[clsid]

Fixed

[_xxl]

I can't compile with MinGW GCC 4.3.3. What version is supported?
http://i55.tinypic.com/2v8ob53.jpg

[clsid]

You need at least 4.4.0, or enable SSE.

[_xxl]

Can you please provide a link all in one for MinGW GCC?

[JEEB]

Can you please provide a link all in one for MinGW GCC?Use xhmikosr (http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=)'s base full msys/mingw package? And then get a 4.5.3 mingw package from either komisar or xvidvideo.ru (and use /etc/fstab to make another folder be mounted as /mingw) >_>

...or just use the included 4.6.1 if that works for you.

[TONPumper]

So when will a new stable release come out?

[Octo-puss]

So when will a new stable release come out?
When it's done.

[madshi]

Hmmmm... I'm currently trying to compile 32bit ffmpeg. It seems that ffdshow uses a custom config.h for compilation. I've found that the following switches are different from the config.h file I'm getting:

#define HAVE_CMOV 1
#define HAVE_EBP_AVAILABLE 1
#define HAVE_FAST_CLZ 0
#define HAVE_FAST_CMOV 1
#define HAVE_ISATTY 0
#define HAVE_MEMALIGN 1
It that an intentional change and if so what purpose does it have to change these defines, if I may ask?

Also I'm wondering: Is it recommended to change the CFLAGS? E.g. I've seen people use "-march=i686 -mmmx -msse -msse2 -mfpmath=sse". Is that a good idea, when using GCC?

Thanks!!

[nevcairiel]

In general, using sse fpmath can be a good idea, however i've had some weird issues with it in ffmpeg, so i stick to "-march=i686 -mmmx"

HAVE_MEMALIGN is wrong on Win32, windows doesn't have the required functionality.
Not sure about the others, i stick to the ffmpeg configure script and use what it creates for me - never run into any problems with that.

This is my current build script - alot of those configure options are probably default, but shrug.
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=build_ff_win32.sh;hb=refs/heads/video

[JEEB]

Hmmmm... I'm currently trying to compile 32bit ffmpeg. It seems that ffdshow uses a custom config.h for compilation. I've found that the following switches are different from the config.h file I'm getting:

#define HAVE_CMOV 1
#define HAVE_EBP_AVAILABLE 1
#define HAVE_FAST_CLZ 0
#define HAVE_FAST_CMOV 1
#define HAVE_ISATTY 0
#define HAVE_MEMALIGN 1
It that an intentional change and if so what purpose does it have to change these defines, if I may ask?
Config.h is usually generated by the configure script in ffmpeg, so those settings are usually either picked by system checks and configure settings. You shouldn't be touching it by yourself in most cases :3

The only one that matters here is --enable-memalign-hack (which is HAVE_MEMALIGN methinks Edit: no, it wasn't), which should be used on 32bit windows at least (64bit Windows doesn't seem to need it). Otherwise you should see configure output with your configure line and see if the configuration matches what you are hoping to achieve.

Example configure output with just --enable-memalign-hack on my msys/mingw system:
jeeb@patchouli ~/libav
$ ./configure --enable-memalign-hack
install prefix /usr/local
source path .
C compiler gcc
ARCH x86 (generic)
big-endian no
runtime cpu detection no
yasm yes
MMX enabled yes
MMX2 enabled yes
3DNow! enabled yes
3DNow! extended enabled yes
SSE enabled yes
SSSE3 enabled yes
AVX enabled yes
CMOV enabled no
CMOV is fast no
EBX available yes
EBP available no
debug symbols yes
optimize for size no
optimizations yes
static yes
shared no
postprocessing support no
new filter support yes
network support yes
threading support pthreads
SDL support no
Sun medialib support no
libdxva2 enabled no
libva enabled no
libvdpau enabled no
AVISynth enabled no
frei0r enabled no
libdc1394 support no
libdirac enabled no
libfaac enabled no
libgsm enabled no
libmp3lame enabled no
libnut enabled no
libopencore-amrnb support no
libopencore-amrwb support no
libopencv support no
libopenjpeg enabled no
librtmp enabled no
libschroedinger enabled no
libspeex enabled no
libtheora enabled no
libvo-aacenc support no
libvo-amrwbenc support no
libvorbis enabled no
libvpx enabled no
libx264 enabled no
libxavs enabled no
libxvid enabled no
zlib enabled yes
bzlib enabled yes

<List of enabled stuff too long for the post it seems>

License: LGPL version 2.1 or later
Creating config.mak and config.h...
libavutil/avconfig.h is unchanged

Also I'm wondering: Is it recommended to change the CFLAGS? E.g. I've seen people use "-march=i686 -mmmx -msse -msse2 -mfpmath=sse". Is that a good idea, when using GCC?I don't usually edit these flags for optimizational purposes.

My current configure to build static libraries filled with old stuff (TM):
./configure --prefix=/mingw/i686-pc-mingw32 --enable-gpl --enable-postproc --enable-filters \
--disable-network --enable-memalign-hack --extra-cflags='-U__STRICT_ANSI__' \
--enable-runtime-cpudetect --enable-pthreads --extra-cflags='-DPTW32_STATIC_LIB' \
--disable-hwaccelsPostproc should be now enabled with --enable-gpl, and in my case --enable-pthreads was default as well. Network functions and hardware accelerated stuff isn't needed by me, so I leave them disabled. -U__STRICT_ANSI__ and -DPTW32_STATIC_LIB were needed for ffms and friends when making a library, possibly. Not sure if either is needed any more :/

[nevcairiel]

The only one that matters here is --enable-memalign-hack

That option is auto-detected by the configure script these days, a plain call to ./configure will build you a working ffmpeg these days.

[JEEB]

That option is auto-detected by the configure script these days, a plain call to ./configure will build you a working ffmpeg these days.Ha! Kind of thought that'd happen :P Scratch one configure option off my lines.

[madshi]

Thanks for the comments, guys.

I've done some experiments and if I just use the standard config.h produced by "configure bla bla" then multi threaded h264 video decoding is a bit slower than ffdshow's latest build. On my PC a h264 trailer pushes the CPU to 85% with standard ffmpeg, while ffdshow only consumes 75%. Changing those config options I listed in my previous post reproduces the same results as ffdshow. So at least on my PC, modifying the config.h file to match ffdshow noticeably improves performance. FWIW, ffdshow also has a different "mem.c" compared to standard ffmpeg. ffdshow's mem.c uses "__mingw_aligned_malloc" which is nowhere to be found in the latest ffmpeg. Maybe that explains why the ffdshow config.h uses "HAVE_MEMALIGN"?

[clsid]

Yes, ffdshow uses those mingw functions instead of the memalign hack. I didn't know its performance benefit was that big. Maybe it is useful for LAV Filters as well? Or better yet, ask the FFmpeg developers to detect these functions and use them.

[madshi]

I don't think the mingw functions alone make the difference. They did seem to help a bit, but I found some of the other config "tweaks" to improve performance, too. E.g. CPU consumption went down noticeably by setting "HAVE_EBP_AVAILABLE 1" and "HAVE_ISATTY 0". Didn't separate those two so I don't know which one did it.

[nevcairiel]

Sadly manually modifying the config.h after the ./configure would really break my process.

I should check the configure script and see how it detects those things.

FWIW, i doubt HAVE_ISATTY makes such a big difference. EBP on the other hand adds an additional register to the assembly, which on pure x86 can make a difference.

I should get my decoder running good enough for performance tests. ;)

Edit:
Numbers!

EBP adds around 10% single-threaded performance here. 50fps becomes 55fps. The memalign thing doesn't change a thing, but i suppose its nicer then using the hack, so i'll go with that.

Too bad i suck at configure scripting, or i would somehow code a detection for this and try to push it upstream.

[jeremy33]

There is a problem with h264 interlaced content since ffmpeg-mt was integrated to libavcodec.

Now the h264 interlaced video stutters. Is it the same for you ?

Here is a 1080i sample part 1 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part1.rar) & part 2 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part2.rar)

[dann23]

after the recent changes to ffdshow, subtitles do not work with wmp12 on windows 7 64 bit. it appears just for some seconds and after that nothing. If I seek it appears again for some seconds. I tried with lav splitter and with matroska splitter from mpc-hc.

[clsid]

There is a problem with h264 interlaced content since ffmpeg-mt was integrated to libavcodec.

Now the h264 interlaced video stutters. Is it the same for you ?

Here is a 1080i sample part 1 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part1.rar) & part 2 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part2.rar)That is not because of the integration. A recent fix in the FFmpeg/Libav code is the cause of this performance regression. One of the devs has been notified, so hopefully the situation can be improved.

after the recent changes to ffdshow, subtitles do not work with wmp12 on windows 7 64 bit. it appears just for some seconds and after that nothing. If I seek it appears again for some seconds. I tried with lav splitter and with matroska splitter from mpc-hc. Afaik, that bug has been there for a long time already. Without more devs I don't see it being fixed any time soon.

[TheShadowRunner]

I see mention of a stable release, before it happens if any coder knows his way around the resize/crop code to fix this bug: http://sourceforge.net/tracker/?func=detail&aid=3221231&group_id=173941&atid=867360 that'd be great!

[jeremy33]

That is not because of the integration. A recent fix in the FFmpeg/Libav code is the cause of this performance regression. One of the devs has been notified, so hopefully the situation can be improved.
Ok thank you.

[TONPumper]

When it's done.

Well is it still Beta 7 or has there been a new stable release?

[clsid]

@JEEB
Have you had any more contact with Ronald with regard to the H.264 performance regression?

I took a look at Lord's 10bit patch and it looks good. You guys were talking about too little room for more colorspaces, but isn't there still room for 3 additional ones? Enough for the 9-bit stuff. I have a patch to extends the enum to 64-bits, adding room for 32 more colorspaces. Let me know if you need it. I will probably commit it soon.

Are there any known problems with the current patch? For example, does DXVA still work?

[Blight]

Small question:
Is there a performance hit if I set the video decoder's 'number of decoding threads' to "4" on a 2-Core system (or even a single core system)?
And if the answer is 'Yes', then how big is the hit?

[nevcairiel]

Over-taxing the CPU does not decrease performance, in fact it usually still speeds it up.

For example, i have a i7 with 8 threads (4 cores + 4 HT).
On one sample i get around 220fps with 8 threads. Increase that to 12 or even 16 threads, i get 250 fps. The gain won't be large once you hit the limit, but it certainly won't be slower.

If you do this when transcoding, and running at 100% all the time, you might impact the responsiveness of the system, however. :)
During playback, i see no harm setting it like that.

[e-t172]

The gain won't be large once you hit the limit, but it certainly won't be slower.

To a point, obviously. If you set 100 threads then you'll have horrible performance because of all the context switches and related cache misses. The only way to know the correct number of threads to use is to mesure it.

[madshi]

In my tests I had worse performance with 4 threads than with 2 threads on my dual core CPU. But maybe that's just me, and I didn't test very long.

[Underground78]

I did some tests a few days ago using the new MPC-HC branch with updated internal decoders and I did see an improvement when using 4 threads even with my dual core CPU: http://pastebin.com/NkmM3jCg.

[Blight]

Thanks everyone for the input on the thread counts, much appreciated.

e-t172:
Of course, I just worried that context switching would have a negative affect even at 4 cores (on a 2 core system).

[cyberbeing]

For a 2-core AMD X2 (939), setting threads to "3" gives higher frame-rate than "2". Setting threads to "4" or higher has around the same performance as "3" threads but with slightly higher CPU usage. Each additional thread beyond "3" seems to add slightly higher CPU usage with no performance benefit, so if you set the thread count too high you might notice it.

[Atak_Snajpera]

For a 2-core AMD X2 (939), setting threads to "3" gives higher frame-rate than "2". Setting threads to "4" or higher has around the same performance as "3" threads but with slightly higher CPU usage. Each additional thread beyond "3" seems to add slightly higher CPU usage with no performance benefit, so if you set the thread count too high you might notice it.
x264 encoder also uses 1.5*cores formula = optimal number of threads

[JEEB]

@JEEB
Have you had any more contact with Ronald with regard to the H.264 performance regression?Yes, pinged him a few times, and he is still quite occupied with other things for the moment -- thus no updates on that front yet.

I took a look at Lord's 10bit patch and it looks good. You guys were talking about too little room for more colorspaces, but isn't there still room for 3 additional ones? Enough for the 9-bit stuff. I have a patch to extends the enum to 64-bits, adding room for 32 more colorspaces. Let me know if you need it. I will probably commit it soon.Lord wasn't sure if we could put it that much up safely -tryouts-wise, so we kept to just 10bit so far. I see the 64bit'ification patch went in already, after we get filters etc. related stuff working more properly'ish we'll move over to the 64bit side and adding possible 9bit colorspaces into the mix.

Are there any known problems with the current patch? For example, does DXVA still work?There are various problems not related to just playback, such as the filter problems, but these are under work atm.

Also, btw -- is it a known problem that in case of no installed Avisynth on the system the Avisynth filter, when enabled, just crashes? This seems to have come up while testing various filters.

[sumawo13]

Does ffdshow-tryouts have official support for 4:4:4 H.264 yet? I've encoded some clips with x264 and, when viewed using ffdshow-tryouts, the chroma is noticeably quartered in resolution, as though it's 4:2:0 up-sampled with a point filter.

[JEEB]

Does ffdshow-tryouts have official support for 4:4:4 H.264 yet? I've encoded some clips with x264 and, when viewed using ffdshow-tryouts, the chroma is noticeably quartered in resolution, as though it's 4:2:0 up-sampled with a point filter.
-tryouts defaults all H.264 to 4:2:0 output (it basically is hardcoded to "If this is H.264, it's 4:2:0. QED."). And yes, the default swscale flags have SWS_POINT, as well as lack full precision. Not usually visible because the swscale codepaths get used very rarely :)

Lord has worked around the 4:2:0 hardcoding in H.264, and I got to editing the swscale flags, the first is in Lord's 10bit H.264 patch at the moment, and the latter is in a separate commit atm on my github repo's blitzkrieg branch.

[clsid]

I noticed Avisynth crash as well. A fix for that would be useful.

When adding 9-bit, also add 10-bit 4:2:2.

[Eliminateur]

Hello,
i've been trying to playback a H264 Hi10P L4.0 file and i get horrible blocking artifacts of quite distinct colour which makes me suspect it isn't supported, will this be supported with Lord's 10 bit patch?

this is the info:
Format/Info : Advanced Video Codec
Format profile : High 10@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 19s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits

[mark0077]

clsid / guys, would you know if ffdshow doesn't set the output pin to the correct fps by design, or if it would be much work to get it to do it correctly. For example if I use yadif, or an avisynth script that changes the fps, ffdshow doesn't indicate this to the next filter / or renderer in the chain.

EDIT: I also notice it effects use cases in ffdshow like

---------------
Input to ffdshow: 25.00fps interlaced content
De-interlacing: ON (yadif - double frame rate) - outputs 50fps
Avisynth Script: (Performs certain actions for Framerate==25fps and other actions for Framerate==50fps, uses ffdshow_source() to get input)
---------------

I find the above Avisynth script will have trouble as it actually thinks the video input its getting is 25.00 fps but its actually getting 50.00fps output from Yadif. Took me a while to figure out what was going wrong in my avisynth script. This was the problem. Again, would you know if this is a bug or by design? Thanks

[clsid]

Probably a bug. Put it on the bugtracker and hope someone comes along to fix it.

[mark0077]

np, done, thx https://sourceforge.net/tracker/?func=detail&aid=3375672&group_id=173941&atid=867360

[VipZ]

clsid, I am not sure if you interested. I made a patch to make ffdshow more modular in filter registration, I extended how DXVA is done to all the other filters. I didn't made changes to the installer, as this is probably more catered to those who make custom installers.

Patch, http://www.mediafire.com/?5i0rhls7cxh8fsi

[Snowknight26]

How would one go about changing the prefered order of colorspaces used when connecting to other filters? If I have YV12 and NV12 checked, FPS1 -> x is converted to YV12 first (causing bad colors) instead of NV12 (normal colors).

[Delerue]

Does anybody knows if there is any progress with MJPB support, since FFMpeg already supports it? This sample can't be opened with just MPC-HC + FFDShow: http://red.cachefly.net/video/milkgirls1080p.mov

[Blight]

bug report:
Users are reporting problems playing some MKV files with H264/AC3 using ffdshow to output to S/PDIF (while other MKV files with apparently the same codecs play just fine).
The problem is that the ffshow audio decoder refuses to connect to the Default DirectSound audio renderer.
When disabling S/PDIF output, the audio renderer connects just fine.

The problem also depends on the splitter used:
If Haali's or MPC's Matroska splitter i used, the audio decoder wont connect.
If I switch to LAV Splitter, the filter connects and the media plays.

Here's the settings I modified to get the filters to connect (with no success):
1. AC3 decoders (liba52 and libavcodec).
2. 'Connect as PCM' enabled/disabled.
3. 'try all formats' and 'try only standard formats'.
4. Enabling 24bit,32bit and 16bit LPCM output (tested LPCM separately from 24bit/32bit).

I've tested this procedure using the latest ffdshow (ffdshow_rev3949_20110725_clsid.exe), latest MPC standalone filters, Haali splitter and LAV Splitter v0.30.
It appears that the ffshow's output pin presents a different format for the problematic files (see screenshot below).
With mkv files that do play (with exactly the same filters), the pin output looks the identical to the pin output when using the LAV Splitter with the problematic MKV files.

Here's a graphedit screenshot showing with some additional information:
http://t.inmatrix.com/ffdshow_ac3bug.png

[nevcairiel]

If i had to guess, i would say the following:

- The MKV headers contain wrong audio information (apparently it names the sample rate 8kHz, instead of 48kHz?).
- Haali and MPC Matroska simply output the informations as they were contained in the container, while LAV Splitter actually checks the stream to get the information (and therefor, figures out that its 48kHz)
- ffdshow uses the information supplied from the input pin to create the output media type.
- DirectSound refuses a connection to a 8kHz sample rate.

Of course, this is just guess-work. Also, not sure if this can be fixed in ffdshow easily, as it really has to rely on the source-filter provided data. Of course there are ways around that, especially when outputting for SPDIF, because the sample rate doesn't matter there.

PS:
I still wonder why people use GraphEdit when GraphStudio is so much nicer to work with. ;)

[Blight]

nevcairiel:
GraphStudio used to be unstable for me, but it was years since I last tested it.
Next screenshot ;)

Since this problem doesn't affect decoded output, only S/PDIF,
Could the fix be to present a 48kHz media-type for S/PDIF connections that have 8kHz listed in the headers?

[nevcairiel]

I wonder anyway why the sample rate is used for the SPDIF media type - its sample rate is independent of the actual stream sample rate.

[clsid]

A quick and dirty fix could be adding sample rate check in TsampleFormat::createMediaTypeSPDIF. But I don't have the hardware to test. One of the other devs has to fix this.

[blah123]

I dont' know, what this matter is problem with, but I think it has strong connection with ffdshow... I'll call it "sudden artifacts".
I try to encode MPEG-TS AVC/H264 to AVI XviD (recording from DVB, interlaced). I tried MeGUI and StaxRip - these two apps gives the same bug.
This is Win7 x64 and installed: ffdshow x86 (based on libvacodec), Haali, LAV x86&64, XviD.
Like I've written - this is interlaced DVB-T recording, so I use "Linear blending" deinterlacing in ffdshow. After re-encoding and playing AVI or using the option from StaxRip to preview in deafult system player, sudden artifacts appear very often in it, sometimes in 1 minute.

You can see them here (3 frames in a row, the second with macroblocs):

http://i.imgur.com/X3ARv.jpg (http://imgur.com/X3ARv) http://i.imgur.com/DisG5.jpg (http://imgur.com/DisG5) http://i.imgur.com/9ZuAu.jpg (http://imgur.com/9ZuAu)

These artifacts aren't always in the same frames, but they change their positions. After I re-open the file, artifacts are in different frames.
I don't know, how to resolve this problem.

Couple of details about this MPEG: it hasn't WSS (resolution: simple 720x576), but it's 16:9 letterbox - so I needed to crop letterboxes, and then put in 16/9 LanczosResize (624x352).

[jmone]

That is not because of the integration. A recent fix in the FFmpeg/Libav code is the cause of this performance regression. One of the devs has been notified, so hopefully the situation can be improved.

FYI, It is not just interlaced material my AVC/264 1080/50p stuff also stutters now even on an i7-920 (same with LAVVideo)

[nevcairiel]

FYI, It is not just interlaced material my AVC/264 1080/50p stuff also stutters now even on an i7-920 (same with LAVVideo)

I can play 1080p/60 high-bitrate material just fine on my i7-2600k. Granted, its faster then a 920, but still, the "birds" killer sample, or the CrowdRun 2160p sample are the most complex H264 clips i really know, and they play fluently. Maybe i should benchmark them.

There must be some other factor involved that is hidden somewhere.
Did someone ever link a clip that very obviously shows the performance problem?

[jmone]

Here is a sample AVC 1080/50p file that used to without ffdshow breaking a sweat with ffmpeg-mt, now it is all dropped frames with madVR (OK on EVR) as the queues are never full. http://www.megaupload.com/?d=7JIIQC7C

[nevcairiel]

I just benchmarked that sample, and it topped out at around 80fps, which really isn't fast. In comparison, the very complex high-bitrate Birds sample still runs at around 340fps.

[jmone]

Thanks nevcairiel - I'm not sure what that all means (is more better or worse?) - I have never had issues with it prior and it really is not taxing. All I know is if I use a current version of FFDSHOW then madVR drops frames, roll back to V3882 (13 June) and it plays fine! Looking at the CPU Thread Graph - there is also a big difference in what cores are being used.

EDIT: Should also say no probs with CUVID on a Q6600 PC.

[nevcairiel]

It looks like something in that video causes it to not multi-thread properly.
I know which change caused it, but not sure if reverting it is safe.

[jmone]

OK I went back and tried various builds:
- Last Good = ffdshow_rev3892_20110620_clsid
- First Broken = ffdshow_rev3904_20110623_clsid

I did not change any config settings between the two. 100% repeatable on my rig but please let me know if there are any other FFDSHOW settings to try though both these builds are post the ffmpeg-MT merge.

[jmone]

It looks like something in that video causes it to not multi-thread properly.
I know which change caused it, but not sure if reverting it is safe.

This content will become more common as it is footage straight from a Pana HS700 Video Cam (and I presume the new Sony's will also spit out the same as they share the "format").

[makakam]

Guys, I'm having this problem with Dolby True HD bitstream when using ffdshow with mpc-hc. When I play the movie from the beginning everything's fine but whenever I ffwd or shut down the player and want to pick up the movie where I left off the audio is broken, I mean I can't hear anything or there's some cracking noise. How can I fix it? Just to be clear, it's only the case with movies that contain dolby true hd, dts hd is always fine. I use ATI gpu btw. Hope someone can help me out here. Thanks in advance.

[clsid]

Support for decoding H.264 Hi10P has been committed.

The Libav patch that caused the performance regression for certain H.264 files has been reverted.

[jmone]

The Libav patch that caused the performance regression for certain H.264 files has been reverted.

Thanks! - EDIT: I can confirm that the H.264 performance issues have been fixed for me in ffdshow_rev3958_20110731_clsid

[Blight]

clsid:
If you can provide a patched copy that checks the bad s/pdif values, I'll test it and report if the patch works.

[makakam]

Had to help me myself, Lav filters did the job perfectly.

[roytam1]

It seems that ffdshow doesn't support ATRC (Real's ATRAC3 FourCC) and COOK.
ATRC GUID from MPC RealMedia Splitter: {4B4F4F43-0000-0010-8000-00AA00389B71}
ATRC GUID from LAV Splitter: {6B6F6F63-0000-0010-8000-00AA00389B71}

COOK GUID from MPC RealMedia Splitter: {4B4F4F43-0000-0010-8000-00AA00389B71}
COOK GUID from LAV Splitter: {6B6F6F63-0000-0010-8000-00AA00389B71}

[clsid]

Blight, roytam1

Try this test build:
http://www.mediafire.com/download.php?vxq5ud5h6zioeik

[roytam1]

Blight, roytam1

Try this test build:
http://www.mediafire.com/download.php?vxq5ud5h6zioeik

It works for ATRC.
But it not work for cook from LAV Splitter. Sample: http://roy.orz.hm/samples/rv30_chroma_drift.rm

And ffdshow crash with this sample:
http://roy.orz.hm/samples/rv20_cook_640x352_realproducer_plus_8.51.rm

[clsid]

You should use LAV Audio/Video for realmedia. That works better than ffdshow, and it is unlikely that things will get better in ffdshow.

[roytam1]

You should use LAV Audio/Video for realmedia. That works better than ffdshow, and it is unlikely that things will get better in ffdshow.

But the crash should be prevented.

For LAV Audio, as I want to use MPC Audio Renderer which needs integer input, I can't use LAV Audio.

[clsid]

For those who are wondering why Hi10P isn't working with the x64 build. It has been disabled because it crashed.

The crash happens in the golomb code used in the SPS parser. It isn't the first time that this code has been causing problems in x64 builds. It really needs to be replaced with something better.

I tried replacing it with the CByteParser class from LAV Filters, but a simple function call replace didn't work properly (assertion failures in both x86 and x64 build). Need to be analyzed deeper. If anyone else want to give it a go, please do.

[roytam1]

For those who are wondering why Hi10P isn't working with the x64 build. It has been disabled because it crashed.

The crash happens in the golomb code used in the SPS parser. It isn't the first time that this code has been causing problems in x64 builds. It really needs to be replaced with something better.

I tried replacing it with the CByteParser class from LAV Filters, but a simple function call replace didn't work properly (assertion failures in both x86 and x64 build). Need to be analyzed deeper. If anyone else want to give it a go, please do.

r3964 binary tested.
"cook" and "ATRC" is missing in TffDecoder_reg.cpp (i.e. they are not registered to DirectShow framework). I can see only 90 media types (0-89) in ffdshow audio decoder.

And if ffdshow is connected from MPC RealMedia Splitter, the RV30 video is broken (played fine with LAV Splitter).
ffdshow crash when RV10/RV20 video stream is fed, regardless from LAV Splitter or MPC RealMedia Splitter.

[clsid]

ffdshow uses a "catch all" mediatypes. So everything listed there is optional and has not direct functional purpose. Since there is a maximum on the total amount of mediatypes, just the most common ones are listed.

Add the realvideo issue to the bugtracker.

[Blight]

clsid:
The patch works, the problematic file that previously exposed 8khz now exposes a proper 48khz output and connects to the audio renderer with no issues.

[Blight]

clsid:
Please let me know 'official' which build contains the patch.

[Blight]

Bug report:
The latest ffdshow build behaves badly when using Haali as an MP4 splitter for H.264 video.

If Haali's 'use custom media type for H.264' setting is enabled, Haali exposes the following on it's output pin:
Major Type: Video - Sub Type: UnKnown {31564343-0000-0010-8000-00AA00389B71} Format: MPEGStreams CCV1 1280X720, 24 bits
This results in a black video screen (the filters connect with no issues).

If I disable Haali's 'use custom media type for H.264' setting, Haali exposes the following on it's output pin:
Major Type: Video - Sub Type: UnKnown {31435641-0000-0010-8000-00AA00389B71} Format: MPEGStreams avc1 1280X720, 24 bits
And the video plays just fine.

Here's a sample video:
http://www.youtube.com/watch?v=J1UFnUdX_xw
You'll need to stream-rip the 720p version for testing, I used the 'FlashGot' Firefox Addon to do this by starting to play the 720p video on youtube and then right-clicking the Flashgot icon and selecting the MP4 file.

And here's a link to an MOV (1.2gb) file that crashes ffdshow after a few seconds where it displays a partially decoded image with lots of artifacts:
http://games.on.net/file/42753/Fry_Cry_3_E3_2011_Demo_Walkthrough_Trailer

[clsid]

SPDIF patch has already been committed.

[clsid]

I have played the first minute of FC3_demo.mov and there were no problems when using LAV Splitter and ffdshow.

Please try some older versions for the other problem. It used to work.

[Blight]

clsid:
The 'bug' is, ffdshow going haywire with the {31564343-0000-0010-8000-00AA00389B71} H.264 sub-type.

The problem is specific to ffdshow receiving the "{31564343-0000-0010-8000-00AA00389B71}" sub-type from Haali (I'm not aware of another splitter that uses this sub-type and I believe this sub-type is used specifically for CoreAVC compatibility).
LAV Splitter doesn't expose this sub-type, it exposes the "{31435641-0000-0010-8000-00AA00389B71}" sub-type which works.

And you can instantly see something is wrong when playing the samples I linked as either you don't get any image (youtube sample) or ffdshow crashes (linked sample).

P.S.
Thanks for the S/PDIF patch.

[nevcairiel]

Haali uses this subtype so WMP does not use its own decoder and instead uses CoreAVC - its another truly ugly hack, copyright CoreCodec.

Regarding ffdshow, i believe it just needs to be added to the list of subtypes in TvideoCodecLibavcodec.cpp on line 366
I did not try it, but it would make sense.

[clsid]

Fixed.

Does LAV Video already support the CCV1 fourcc?

[Blight]

clsid:
Can you post a new build to SF? I'd like to test it and inform my users.

[nevcairiel]

Does LAV Video already support the CCV1 fourcc?

It should, yes. I did however not test.

[Budtz]

Hey all

I think that sharpening is one of the best features of ffdshow. However im not sure wicth one is best of the different sharpening methods. only the first few are explained. Im now using swscale.

Are they listed by quality and cpu-intensity or just random?

Any1 know anything about this or has a link somewhere. I have not been able to find a guide to sharpening.

thx

[Blight]

bug report:
In build 3966, the FFDShow subtitle filter (the separate filter) is completely broken.
It's enough to just connect the filters in graphedit and press play and it crashes (even if i disable the "Subtitle" checkbox in the subtitle filter property page).
At times, a split second before the crash, graphedit throws this an "The graph could not change states" 0x80040209 error.

Here's what I eliminated:
1. Tried both EVR and Haali as the video renderer.
2. Tried both LAV, Haali and the microsoft AVI Splitter as the source filter.
3. Tried both AVI and MKV as the source material (both with external SRT subs).
4. Tried ffdshow, MPC and the Microsoft video decoders.

Here's the crash data:

Problem signature:
Problem Event Name: APPCRASH
Application Name: graphedt.exe
Application Version: 10.0.0.0
Application Timestamp: 4a5bcc05
Fault Module Name: ffdshow.ax
Fault Module Version: 1.1.3966.0
Fault Module Timestamp: 4e4197eb
Exception Code: c0000005
Exception Offset: 0002e9fc
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 1d32
Additional Information 2: 1d32409995138d855a2b9bb446ccc159
Additional Information 3: 591c
Additional Information 4: 591c8f267d7c87f1375dd28c7ce78903


P.S.
1. Using the FFDShow video decoder itself as the subtitle renderer does work.
2. Using DirectVobSub as the subtitle renderer works (the sub files are valid).

[Blight]

bug report update:
With the help of Mitko on my forum, we managed to track down the crash to a specific ffdshow setting:
On the output page, if the "Set interlaced flag in output media type" is enabled, it crashes.

There's actually two issues:
1. If "Set interlaced flag in output media type" is enabled on the ffdshow subtitle filter and a non-ffshow video decoder is used.
2. If "Set interlaced flag in output media type" is enabled on either the ffdshow video decoder or the ffdshow subtitle filter if they are both used in the same graph.

[clsid]

The purpose of that option is to simply pass on any interlaced flags from input to output. That is correct and should give no problems. There is probably a bug somewhere that causes a null pointer dereferencing in the subtitle filter case. I will have a look at it when I have some time.

[clsid]

Please narrow down the revision in which it got broken.

[Blight]

clsid:
Are you referring to my report?

[clsid]

Yes, and any bug report in general.

[Matt Ashland]

Hi clsid,

I'm wondering if a simple change could get added to TffdshowDecVideo::checkAllowOutChange(...)

J. River needs (clsid==CLSID_JREncoderFilter) added to the white-list used to fill the compatibleFilter variable. This encoder supports on-the-fly format changes, just the same as a video renderer.

This is the GUID:
const CLSID CLSID_JREncoderFilter = { 0xe3eabdee, 0x2a0e, 0x4b3f, 0xa7, 0x59, 0x58, 0x5a, 0x1b, 0x62, 0xbe, 0x8a };

Thanks for all of your excellent work.

[clsid]

Added in 3971.

[Matt Ashland]

Added in 3971.

Thank you very much clsid.

[dann23]

problem with ati catalyst 11.8 and hardware acceleration.
ffdshow and mpchc don't work with dxva enabled. the same problem with wmp12 and ffdshow with dxva enabled. just a green image and audio is working (until seeking). I tried to use just wmp12 and lavsplitter. the same problem.
I tried with vlc but the same green image.
So it seems that the latest driver has gpu decoding broken.

[cca]

problem with ati catalyst 11.8 and hardware acceleration.
ffdshow and mpchc don't work with dxva enabled. the same problem with wmp12 and ffdshow with dxva enabled. just a green image and audio is working (until seeking). I tried to use just wmp12 and lavsplitter. the same problem.
I tried with vlc but the same green image.
So it seems that the latest driver has gpu decoding broken.

Can't say about ffdshow or VLC since I didn't try, but DXVA works in MPC-HC with Catalyst 11.8 on my system. I have the Radeon HD 5850 GPU, which one do you have?

[dann23]

I have a Radeon 5750.

[ikarad]

Added in 3971.
Deband filter doesn't work with ffdshow clsid 3966
bug tracker
https://sourceforge.net/tracker/?func=detail&aid=3395695&group_id=173941&atid=867360

With 3914 deband works

[ikarad]

I find a bug with Hi10p mkv video with ffdshow clsid 3966
image here
http://img838.imageshack.us/img838/9944/sansreewo.jpg (http://imageshack.us/photo/my-images/838/sansreewo.jpg/)

video here (bug at 12"37)
http://www.nyaa.eu/?page=torrentinfo&tid=236877

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

[clsid]

I can't fix that.

[clsid]

Deband filter doesn't work with ffdshow clsid 3966
bug tracker
https://sourceforge.net/tracker/?func=detail&aid=3395695&group_id=173941&atid=867360

With 3914 deband works
3943 broke it, but I don't know why yet.

[ikarad]

I can't fix that.

Who can fix it?

[ikarad]

3943 broke it, but I don't know why yet.

I hope a fix soon because since the support of hi10p, deband doesn't work.

[clsid]

The deband problem was not caused by a code bug, but it is caused by a bug in GCC. It is broken with GCC 4.6.1 and it works with GCC 4.5.3.

[ikarad]

The deband problem was not caused by a code bug, but it is caused by a bug in GCC. It is broken with GCC 4.6.1 and it works with GCC 4.5.3.

Why don't use anymore GCC4.5.3 for this moment before problem is corrected?

[Midzuki]

r3974

libavcodec's VC-1 decoder still crashes VirtualDub, MPC, WMP, whatever, when it meets a stream containing DisplayWidth and DisplayHeight flags:

( http://forum.doom9.org/showthread.php?t=162221 )

-.-

[Midzuki]

^ According to the changelogs @ xvidvideo.ru (http://www.xvidvideo.ru/chlog/ffdshow.html), it seems one did update vc1.c, BUT simply "forgot" to update vc1dec.c :rolleyes:

[LigH]

@ ikarad:

Looking at the image, this looks like a data error in the video stream; unfortunately I am not able to analyze the video stream to point at "that byte is wrong"...

If you encoded the file yourself, don't trust your harddisk or controller anymore; if you got it from elsewhere, don't trust this source anymore.

[Reimar]

^ According to the changelogs @ xvidvideo.ru (http://www.xvidvideo.ru/chlog/ffdshow.html), it seems one did update vc1.c, BUT simply "forgot" to update vc1dec.c :rolleyes:

That is a sync from Libav, not FFmpeg. Libav only contains the aspect fix, not the crash fix (so far at least).

[Wile-E-Coyote]

Hello. I could use someone's opinion about something that bothers which I first reported on madvr's thread here (http://forum.doom9.org/showthread.php?p=1521073#post1521073), but which in the end seems to be cause by ffdshow. (I play DVDs with MPC-HC / LAV Splitter / ffdshow / madVR exclusive mode)

To sum up : I use yadif with its "double framerate" option to deinterlace PAL interlaced DVDs. However judging by the pin media type information ffdshow reports outputting 25fps (AvgTimePerFrame=400000) instead of 50 (AvgTimePerFrame=200000).

Is there any way to fix this?

[VipZ]

clsid, with the change to pthreads, x64 builds don't compile with alexins 4.6.1 gcc toolchain.

Thanks

[clsid]

Those changes are required to compile with 4.5.3.
4.6.1 gives broken deband.

[VipZ]

Those changes are required to compile with 4.5.3.
4.6.1 gives broken deband.

If I revert that change locally, and with future modifications to libav. Should I expect the compiles to be unstable in anyway or just as before with deband not working?

[Eliminateur]

is Sandy Bridge DXVA operational in ffdshow?

[clsid]

If I revert that change locally, and with future modifications to libav. Should I expect the compiles to be unstable in anyway or just as before with deband not working?You only need to revert the prefix changes in makefile_c.inc and config.h

[ikarad]

You only need to revert the prefix changes in makefile_c.inc and config.h

CLSid, where can I donwload ffdshow 3975 where you have corrected problem with deband?

On xvidvideo.ru last version is 3972 and on official ffdshow site, last version is 3974.

[Midzuki]

@ ikarad: The latest source-code is r3978 already :–/

[ikarad]

@ ikarad: The latest source-code is r3978 already :–/

Yes but the last ffdshow version downloadabled is 3974

[Midzuki]

Yes but the last ffdshow version downloadabled is 3974

Translation: your crystal ball said, r3975 will rock and r3978 will suck :)

[nevcairiel]

by the way, if a popular and common compiler like GCC can break your code, then your code is broken in the first place. :)

[ikarad]

Translation: your crystal ball said, r3975 will rock and r3978 will suck :)

No my sentence said: I have only need r3975 because it's the version that correct problem with deband. After if clsid release r3978 no problem but I have for the moment only need r3975.

[ikarad]

by the way, if a popular and common compiler like GCC can break your code, then your code is broken in the first place. :)

Maybe but it's the only filter to make deband available in ffdshow and I can't create new deband filter for ffdshow

[Midzuki]

For the impatient :rolleyes: , r3978 can be downloaded from here (http://this-file.has-been-deleted.ne.jp/404.phtml). I don't recommend the build by Dirk Paehl (http://www.paehl.com/open_source/?Welcome), because he forgot to include an apparently-necessary libpthread-2.dll in the package :rolleyes: , so that, for example, you cannot use his ffdshow for decoding VP5 or Indeo Video :rolleyes:

[ikarad]

For the impatient :rolleyes: , r3978 can be downloaded from here (https://skydrive.live.com/?cid=5ACF098E0EBAE8D5&id=5ACF098E0EBAE8D5%21147&sc=documents). I don't recommend the build by Dirk Paehl (http://www.paehl.com/open_source/?Welcome), because he forgot to include an apparently-necessary libpthread-2.dll in the package :rolleyes: , so that, for example, you cannot use his ffdshow for decoding VP5 or Indeo Video :rolleyes:
Deband is buggued with your link.

CLSID has uploaded r3978 in ffdshow site and deband works.

[Midzuki]

Deband is buggued with your link.

CLSID has uploaded r3978 in ffdshow site and deband works.

Thanks for testing and reporting, :thanks:

I will remove that suspicious :devil: build from my Skydrive folder A.S.A.P. :)

EDIT: b0rked build has been eliminated ^.^;;

[Matt Ashland]

I believe there's an ffdshow decoder bug that results in a grey screen being output with certain files. The grey screen is displayed with madVR and our own encoder, so I don't think it's a renderer or allocator problem.

A sample file is here (sorry for the large size, it's HDTV):
http://files.jriver.com/temp/jtv_ffdshow_problem.7z

It's possible this file has multiple resizes when first starting, but LAV Video, LAV CUVID, and the Microsoft MPEG decoder all work properly. The gray screen only appears when using ffdshow.

To test with our software, install Media Center (jriver.com), pick 'Red October HQ' to use madVR in Options > Video, and play the .jtv file from the package above.

Thanks for any help.

[Mike89]

This may sound like a stupid question, but is ffdshow ever going to get to the point of "it's done"? Still almost daily builds for years now and doesn't seem like there is an end in sight. I know the saying, "it's done when it's done" but man, how many more years of daily builds is it going to take? I also know the saying, "a work in progress" but seems there would be a point where the progress would just start going around in a circle.

[Mike89]

I agree with that but for example if using a codec pack (like shark 007), it updates every time a new build comes out, like a couple of times a week sometimes. Seems a bit excessive to "always be up to the latest" especially when this frequency goes on for years.

[Snowknight26]

I must be missing something. Are you replying to yourself?

Whatever the answer, why would you want ffdshow to stop being updated?

[Mike89]

There was a post in between my two. Must have got deleted for some reason. I didn't say I wanted it to stop being updated. I was saying it seems kind of excessive being updated almost daily or weekly for the last few years. I just wondered how many more years this is going to continue with this frequency as there seems to be no end in sight.

[SamuriHL]

They typically work towards a major release and I thought a while back they had one planned. But daily development isn't going to stop on an open source project. :) The key is to get more "milestone" releases out there that are considered stable. That hasn't been happening.

[Midzuki]

I must be missing something. Are you replying to yourself?

There was a post in between my two. Must have got deleted for some reason.

Yes, that was a reply from Stephen R. Savage, who, as usual, deletes his posts without any apparent good-reason :devil: :D

http://forum.doom9.org/showthread.php?p=1379292#post1379292

[Mike89]

Well I wish the makers of the codec packs would take notice (or understand) of what a "milestone" release is instead of them updating almost as fast as these builds come out. I don't think I'm the only one confused as to why there are so many releases and when one should update. The codec pack makers sure don't seem to know.

[SamuriHL]

Everyone typically wants the "latest" when dealing with software which is not always a good thing. When dealing with open source it's often difficult because there isn't a solid "release cycle". (At least, typically....being open source doesn't preclude a project from having a solid release cycle, just that typically there isn't a defined process). This makes it difficult to know when to upgrade and when not to. So called "nightlies" are just the accumulation of changes that devs commit that day. Often they aren't fully tested until end users get ahold of them and find bugs. It's not like the devs submit their changes to a review process and have a full qa test suite to run against them. :) An end user has almost no chance of finding the right balance between stable and "new features". I understand the frustration, but, that's the nature of this type of software development. Buyer beware. :D

[ryrynz]

Yeah there is no AFAIK true "stable" release when it comes to ffdshow, if you have an issue you downgrade (and submit a big report) or upgrade and hopefully that fixes it, not terribly hard. There is no real alternative to this software so just accept the state of development for what it is, as it is something for nothing and we can't really complain about that now can we? :D

[Thunderbolt8]

Yes, that was a reply from Stephen R. Savage, who, as usual, deletes his posts without any apparent good-reason :devil: :D

http://forum.doom9.org/showthread.php?p=1379292#post1379292last name says it all

[Wile-E-Coyote]

Did no one see this?

Hello. I could use someone's opinion about something that bothers which I first reported on madvr's thread here (http://forum.doom9.org/showthread.php?p=1521073#post1521073), but which in the end seems to be cause by ffdshow. (I play DVDs with MPC-HC / LAV Splitter / ffdshow / madVR exclusive mode)

To sum up : I use yadif with its "double framerate" option to deinterlace PAL interlaced DVDs. However judging by the pin media type information ffdshow reports outputting 25fps (AvgTimePerFrame=400000) instead of 50 (AvgTimePerFrame=200000).

Is there any way to fix this?

[kirakami]

ffdshow r3978 20110825

bugs:
VobSub Hangs.

[mindbomb]

hi, im using r3978.

This version, in raw video mode, and it appears every version before, has a buggy RGB conversion when used with the cyberlink powerdvd 10 or 11 decoder in HAM mode.
By buggy, i mean green lines at the edges. Usually just the bottom edge, the right edge, or both.

[SledgeHammer_999]

Are there any plans to improve ASS/SSA rendering or use libass for that instead?

[clsid]

No. There are currently no developers working on ffdshow.

[SledgeHammer_999]

No. There are currently no developers working on ffdshow.

oh I didn't know that. Bummer.

[kirakami]

Are there any plans to improve ASS/SSA rendering or use libass for that instead?

agreed. FFDShow really needs to improve SSA/ASS render.
there are still problems rendering new versions of SSA/ASS subs
also vobsub hangs. ffdshow r3978 20110825
would be good if there comes option to use libass instead.

[kirakami]

libass Render Download for windows
http://srsfckn.biz/assrender/

Start =>Run => regsvr32 "C:\assrender.dll"

[Stephen R. Savage]

AssRender.dll is an Avisynth plugin. You can't register it or use it in DirectShow, or anything like that.

As for ffdshow needing a new subtitle renderer, there's nothing stopping you from using the MPC-HC one or DirectVobSub. ffdshow development has halted and it is already planned to be replaced by LAVFilters anyway, so there's no sense in petitioning for feature changes.

[egur]

clsid:
Hi,
I'm releasing a test build from the latest ffdshow build that include Intel SandyBridge accelerators.
Eventually, I would like to create a separate installation build that defaults to the Intel decoder for supported codecs.
Could you please point me to where I can find the installation script? I've looked at the SVN, but I can't seem to find it.


Everyone:
Here is doom9 release thread for ffdshow DLLs supporting hardware acceleration with the SandyBridge CPU:
http://forum.doom9.org/showthread.php?p=1523738

[Eliminateur]

ffdshow development has halted and it is already planned to be replaced by LAVFilters anyway, so there's no sense in petitioning for feature changes.

what..?, so ffdshow-tryouts is essentially... dead?, what happened to all the developers?, so we can expect no new versions with nothing new in them? :confused:

[pirlouy]

I need help with one little issue: I've selected "ffdshow audio processor" in MPC external filters. But I can't access options window. With another computer, it works.
I've tried uninstall and reinstall (with ICL or MSVC2010) without success. Any idea ? I have no problem if I choose ffdshow audio decoder. :/

[ryrynz]

what..?, so ffdshow-tryouts is essentially... dead?, what happened to all the developers?, so we can expect no new versions with nothing new in them? :confused:

Yup Stephen is correct, it's basically dead. There haven't been "developers" for ffdshow in a long while, a handful of people fixing small issues, but mostly just updates to Libav.

[fastplayer]

Could you please point me to where I can find the installation script?
Look for ffdshow_installer.iss in /trunk/bin/distrib.

[kirakami]

so ffdshow really no more
& here i thought it will reach r4000

[ikarad]

AssRender.dll is an Avisynth plugin. You can't register it or use it in DirectShow, or anything like that.

As for ffdshow needing a new subtitle renderer, there's nothing stopping you from using the MPC-HC one or DirectVobSub. ffdshow development has halted and it is already planned to be replaced by LAVFilters anyway, so there's no sense in petitioning for feature changes.

Directvobsub is dead since 2008 and doens't support bluray subs.
MPc-HC sub rendere is dead since many years and no developpers works on sub renderer in mpc-hc.


If ffdshow is dead (how do you know that it's dead?), there is not alternative.

I doubt that lavfilters replace ffdshow because it's not the same thing. lav filters is just for decode audi oand video but there is no filters and no support of avisynth.

[ikarad]

No. There are currently no developers working on ffdshow.

Why?

is it too difficult?

one year ago only, there were lots of progress with ffdshow (support of HD subs, support of dxva, support of HD audio, support of ffmepg-mt etc...)

Even some developpers like albain speak about the fusion between mpc-hc and ffdshow

[kirakami]

can't ffdshow keep going at least until r4000?
there r still issues with subtitles rendering
Vobsub hangs
still no support for SSA/ASS subs version 3 & 4 yet.

[nevcairiel]

Its not a matter of choice, there is just no-one capable and willing to work on it.

[Thunderbolt8]

what about these directvobsub builds, arent they working rather well? http://xhmikosr.1f0.de/index.php?folder=bXBjLWhjL21wYy1oY19hcHBzL3ZzZmlsdGVy

anyone able to explain why ffdshow is going to be discontinued? are its features superfluous now or kind of included in other tools as well and people dont want to waste time for the same thing twice?

if so which projects are going to replace (most of) the functions ffdshow ? LAVsplitter? mpc-hc?

[pirlouy]

Bah. Don't be that sad. One day, someone will feel a need for the same thing as you, and he will develop something. Think about Madshi, Nevcairiel; some time ago, nobody heard of those. Now you have good splitters, audio & video decoders, and a good renderer. In some time, someone will work on a good subtitle renderer (but maybe the best solution if it's developed by the one who works on renderer), and who knows, someone will rewrite post-processing stuff...

[hoborg]

Yes, subtitles need some good solution. But it should work undepended on aplication.

[Keiyakusha]

Bah. Don't be that sad. One day, someone will feel a need for the same thing as you, and he will develop something. Think about Madshi, Nevcairiel; some time ago, nobody heard of those. Now you have good splitters, audio & video decoders, and a good renderer. In some time, someone will work on a good subtitle renderer (but maybe the best solution if it's developed by the one who works on renderer), and who knows, someone will rewrite post-processing stuff...

Noone really interested in subtitles that much cause there is no reliable standard to begin with. There was attempts by aegisub devs to start the project on new fast crossplatform renderer but it was put in hold until standard fully developed and finalized. The problem is, they don't want to release any specifications till its done so noone will implement partial support in vsfilter or something (which is right thing). So someone need to motivate them i guess...

[Thunderbolt8]

so which are the lastest available versions of ffdshow and which problems do they still have? 3972 can be found on xvidvideo.ru

[clsid]

ffdshow has not been discontinued. There simply won't be any significant changes for the foreseeable future. That will remain the case until new developers join the project.

Latest builds can be found on the SourceForge project page.

[Midzuki]

so which are the lastest available versions of ffdshow and which problems do they still have? 3972 can be found on xvidvideo.ru

r3979 can be gotten from Dirk Paehl's site, or from
software d0t vladbazar d0t com :-/

[Thunderbolt8]

theres no ICL12 version though, arent these supposed to be faster for multithreading intel CPUs?

[Gser]

theres no ICL12 version though, arent these supposed to be faster for multithreading intel CPUs?

Doesn't make much of a difference since its quite light weight to begin with. The only thing that doesn't work fast enough with my i7 is SPP deblocking. But I use deblock QED anyways.

[clsid]

ICL12 does not have any real-life advantages. It only helps in very specific cases that do not apply to the majority of people.
Get the latest build from SourceForge and you will have a proper build with working deband. Builds you get elsewhere are possibly broken.

SPP deblocking strength can be adjusted with the slider on the PP page. Move the slider to the left to lower CPU usage.

[Thunderbolt8]

well I use sharpening and sometimes deinterlacing. if it helps with those, then I'd need it

[clsid]

Probably little difference for those.

[Thunderbolt8]

little is better than nothing. no multithreading for VC-1, no DXVA with interlacing, no nothing. I need every bit I can get

[nevcairiel]

little is better than nothing. no multithreading for VC-1, no DXVA with interlacing, no nothing. I need every bit I can get

Then go buy the compiler and built it yourself.

[Thunderbolt8]

nöööö

[kirakami]

Real Audio Cook Decoder Codec is Buggy
audio while playing creates dub..dub..dub sound

[j19861986]

I don't know if I can post this....
I have modified an IDCT matrix that can be loaded to FFDSHOW that you might try out... it is modified and used against a calibrated screen (with hardware calibrator)...
It is developed by me over one year, that makes it good, I think it is quite precise...
It works very well generally... for all video formats
sure to be check it out?
I have uploaded it in depositfiles.com
please check this out for me
her is the link to IDCT Matrix
JT_IDCT_0.98.xcm (http://depositfiles.com/files/50c1b4e60)
Want the developers to FFDSHOW to check it out, and requesting the file to be available in the "custom matrices" folder (when installed FFDSHOW) and Call it like "Precise IDCT Matrix" or something... :D

[j19861986]

Little Guide How to use the IDCT Matrix:
Open up FFDSHOW Video Decoder
Click the "DCT" in the left menu and check mark it..
Check mark from the upper window that says "Process Whole Image"
then select: "MPEG quantization" and Quantizer to "1" in the main screen
then click "Quantization Matrix" in the main screen
new window will come up, and click "Load matrix..."...
select the IDCT Matrix that you have downloaded and load it...
The load screen will close, and click close to the Quantization Matrix Window...
And Apply in the Main Screen
Then you have applied the IDCT Matrix

[kirakami]

What are proper steps to Enable DXVA Decoder Configuration for H.264 with subs & how do i confirm it?
using ffdshow r3978.

[Gser]

I don't see why we would need to apply a IDCT again.

[LigH]

IDCT = "Inverse Discrete Cosine Transformation" is applied while decoding. If you want to use a quantization matrix while encoding, omit the "I" = "Inverse".

Waiting 60 seconds to download 128 bytes - how lame ... you could have exported the matrix via CQME (http://forum.doom9.org/showthread.php?t=73666) and pasted its text representatipon in any pastebin.

Hmm, I wonder why such a matrix should be "better" than others, it is almost flat, therefore won't reduce high frequencies which are usually mostly part of noise. Especially I wonder if you knew what you did, because the Intra coefficient (0,0) is not 8 in this matrix, and the Inter matrix is not coarser than the Intra matrix (which is usually useful because interframe quantization errors are less persistent).

If you are looking for finer matrices to preserve more details, yet with compliance to general rules of DCT quantization matrix dynamics, you may try instead:

Didée's SixOfNine (and the HVS variant)
Fox Home Entertainment (although that one is a bit exaggerated for the Inter part)
Professional
Selur - high datarate

from my matrix collection.

[Sven75]

Just a bug report...

Crashing with ffdShow, but working fine with current ffplay.exe:

MS RLE (http://www.mediafire.com/?c4y5wyow7n233y7)

[j19861986]

IDCT = "Inverse Discrete Cosine Transformation" is applied while decoding. If you want to use a quantization matrix while encoding, omit the "I" = "Inverse".

Waiting 60 seconds to download 128 bytes - how lame ... you could have exported the matrix via CQME (http://forum.doom9.org/showthread.php?t=73666) and pasted its text representatipon in any pastebin.

Hmm, I wonder why such a matrix should be "better" than others, it is almost flat, therefore won't reduce high frequencies which are usually mostly part of noise. Especially I wonder if you knew what you did, because the Intra coefficient (0,0) is not 8 in this matrix, and the Inter matrix is not coarser than the Intra matrix (which is usually useful because interframe quantization errors are less persistent).

If you are looking for finer matrices to preserve more details, yet with compliance to general rules of DCT quantization matrix dynamics, you may try instead:

Didée's SixOfNine (and the HVS variant)
Fox Home Entertainment (although that one is a bit exaggerated for the Inter part)
Professional
Selur - high datarate

from my matrix collection.

Here is the export (intra first, inter last) I made in text:
8,18,18,19,20,22,21,23
17,17,19,19,22,22,23,24
18,19,21,20,22,23,23,25
19,21,20,22,23,24,26,26
20,22,22,24,26,27,27,28
20,21,23,23,27,28,28,30
22,23,23,25,27,28,30,31
23,25,24,28,29,31,32,34

15,18,18,19,20,22,21,23
17,17,19,19,22,22,23,24
18,19,21,20,22,23,23,25
19,21,20,22,23,24,26,26
20,22,22,24,26,27,27,28
20,21,23,23,27,28,28,30
22,23,23,25,27,28,30,31
23,25,24,28,29,31,32,34

Save it in text file (txt file)
Import via CQME (http://forum.doom9.org/showthread.php?t=73666), just check-mark "Text (Comma......", then the import screen comes up, select files of type to "Text files", load the text file you saved, import options: just check-mark "Comma" and click "OK", and "OK" again in "Text (Comma...." check-marked
Save it in xcm file
load it then in ffdshow
(one thing is that the intra's first number isn't the same as the inter's first one), the modification is from ffdshow idct modifier... and saved the xcm from FFDSHOW, is it an issue or what? suppose to be same?

[Midzuki]

...

(one thing is that the intra's first number isn't the same as the inter's first one),

Many encoders/decoders will refuse an intra-matrix whose very-first coefficient is not 8. mpeg2enc is one of the rare applications that ignore this "rule".

[LigH]

CQME assumes the Intra coefficient (0,0) always being 8. Many MPEG2 encoders assumed so as well. It is a kind of common level, basis of comparison, for the other matrix coefficients.

If anyone will prove to me that this is not necessary, and there are encoders which respect different values in this coefficient (especially Xvid does), I may publish a new version which releases this restriction.

Nevertheless, my doubts persist that this matrix is so remarkably useful as it is. Quoting it here was not outstanding by itself; adding a link to its origins and to a description of its purpose would be very appreciated.
__

Wait ... is that a matrix for MPEG4-AVC (H.264)? -- That one is probably not optimized for use with DCT in MPEG2 or MPEG4-ASP.

[kirakami]

request support for ASS subs v3/4.
why ASS ver 3/4 subs renderer still not added to ffdshow?

[kirakami]

ffdshow r3981 fails to decode 10bits depth all green screen :(
r3978 works fine

[clsid]

request support for ASS subs v3/4.
why ASS ver 3/4 subs renderer still not added to ffdshow?There are no developers available that are interested in working on the subtitle functionality. You should use DirectVobSub instead.

ffdshow r3981 fails to decode 10bits depth all green screen :(
r3978 works fineFixed.

[kirakami]

There are no developers available that are interested in working on the subtitle functionality. You should use DirectVobSub instead.

Fixed.

already using DirectVobSub for years
if ffdshow doesn't render ass v3/4
same happens DirectVobSub (using latest ver 1.5.3.3644)
only potplayer properly

wont merging libass Render into ffdshow work?
http://srsfckn.biz/assrender/

[clsid]

I will repeat it again: there are no developers

[Midzuki]

wont merging libass Render into ffdshow work?
http://srsfckn.biz/assrender/

That's the site of lachs0r alright — so,

¿ why don't you use his mplayer2 instead ? :confused: :confused: :confused:

[sneaker_ger]

There also seems to be some opposition to new ass extensions:
http://blog.aegisub.org/2010/02/old-and-present-vsfilter.html

[Keiyakusha]

There also seems to be some opposition to new ass extensions:
http://blog.aegisub.org/2010/02/old-and-present-vsfilter.html

Maybe i'm wrong but i guess ass3/4 means ScriptType: v4.00+ which is nothing new and this is the default format of the aegisub. Just ffdshow's subtitles filter is broken compared to vsfilter

[sneaker_ger]

Ah, ok, I thought he talked about some extensions. Well, it's dead. libass+madVR with MPC-HC would of course be nice.

[nevcairiel]

The main issue is that most ASS scripts are designed for vsfilter, and designed around all the bugs in vsfilter, therefor probably not looking 100% correct in libass