ffdshow tryouts project: Discussion & Development

[MatLz]

Unless you mean the difference between ICL10 and ICL11 builds, then the difference between MSVC2008 and ICL11 with resizing+deband+HQRGB32 is ~=15%. Which reminds me I have to finish that benchmark at some point. :) But you can find some previous results by searching this thread.Nope, I only meant the pure decoding speed compared to regular builds, with no filtering.
So am I wrong ?

[clsid]

For pure decoding all builds give the same performance because GCC is used as compiler for libavcodec.dll

[MatLz]

For pure decoding all builds give the same performance because GCC is used as compiler for libavcodec.dllThanks for this precision.
In fact, the only 'filtering' I use is the 'gamma-contrast-brightness...', so can it be the cause of the small speed gain I noticed ?

[clsid]

That filtering is done using the GPU, so it does not affect performance. You need to do benchmarks to see if there are actual differences.

[Sebastiii]

@SamuriHL : I thought that both mkv/mpeg splitters acted the same way.
So MPC M2TS splitter + PGS => ok but one should wait for the first parsed gub
MPC MKV splitter + PGS => not detected

But Haali still suffer from HD audio splitting, no ?

And do you have any news concerning audio dropouts with radeons 5xxx series ?
Thanks

Hi,

Casimir666 has added support for MPC Matroska Splitter for PGS sub today :)

Thanks to him :)
And it's working great :)
Seb.

[gametiger]

Sorry if this has been discussed already, but I just couldn't find anything useful.

I'm using the ffdshow DXVA video decoder for all my DXVA compliant files, but I also have a few H.264 encodes that aren't DXVA compliant (too many reference frames). So I thought I could use the "normal" software ffdshow video decoder for these, i.e. only use the DXVA decoder for files it's going to support. Is it possible to (automatically) do this?

I'm using the latest MPC-HC and ffdshow builds. CPU is a Core 2 Duo E8400, ATI HD5750 graphics. Thanks!

[clsid]

The DXVA decoder checks for compliance and only decodes streams that pass that test. Whatever other decoder you have installed will take care of the rest.

[pankov]

clsid,
am I correct to read your words that if the stream is not DXVA compliant the building of the graph will fail and then the player will have to select another decoder?
If that's the case this is very inconvenient because for example if one (like I do) uses ZoomPlayer's "Smart Play" functionality and have configured FFDShow DXVA decoder for H264 when the building of the graph fails an error message will appear and then the default directshow graph creation will kick in. In most cases this default graph will be a mess ... at least not what the user wants. As we all know most if not all computers have more than one filter for each format and also most of us have configured ffdshow raw decoding both for audio and for video but use it only in certain cases. All this usually leads to 2-3 decoders in both the video and audio chains and this is never good.
So isn't it possible to add an option in the ffdshow DXVA decoder to fallback to the defaul ffdshow decoder when the stream is not DXVA compliant?

[clsid]

The graph won't fail. The decoder will simply deny the connection. Then DirectShow will try inserting the next available decoder into the graph (which usually is the regular ffdshow decoder).

[STaRGaZeR]

There has been a lot of talk about ATI cards being able to decode 5.1 streams, and I keep seeing files that crash the driver, play with artifacts or simply BSOD, like this one. It's 4.1 compliant in everything except resolution, so it's actually 5.0. MPC reverts to software decoding, but ffdshow uses DXVA and the driver crashes. Play it a second time and you'll get a BSOD.

http://www.megaupload.com/?d=QH4TWGBO (35MB)

[pankov]

well, if the decoder denies the connection this means that ZoomPlayer will fail to build the graph with the preconfigured decoders and will fallback to the default directshow graph building.
I tried the following:
1. disabled the H264 DXVA codec in ffdshow DXVA configuraiton.
2. configured ffdshow DXVA decoder as the prefered H264 decoder
3. played a H264 file and got the following warning
Could not find a suitable Decoder for "[Source File: Smart Play Graph].Video"

SubTypes:
{31435641-0000-0010-8000-00AA00389B71}
and then the following error

Could not create a Smart Play Graph, will now try a standard graph...
So I as I see it - this is not working for ZoomPlayer users
:(

[dann23]

There has been a lot of talk about ATI cards being able to decode 5.1 streams, and I keep seeing files that crash the driver, play with artifacts or simply BSOD, like this one. It's 4.1 compliant in everything except resolution, so it's actually 5.0. MPC reverts to software decoding, but ffdshow uses DXVA and the driver crashes. Play it a second time and you'll get a BSOD.

http://www.megaupload.com/?d=QH4TWGBO (35MB)

The Ati cards are capable to decode 5.1 streams. I tried to play the sample. It works afters waiting 3 minutes :) but I after it started my monitor entered in sleep mode but audio worked. I think it will be more usefull to report this in Ati forums. This way they will correct in a future driver release. Also I think it's important to specify that ffdshow dxva is playing this file if compatibility mode is set to skip all checks.

[clsid]

Disabling DXVA and then setting it as preferred decoder will obviously fail. Duh. First do things the right way and if it still fails then you should ask the ZoomPlayer developers to handle this kind of situation properly.

[pankov]

clsid,
I was just trying to simulate an non dxva compliant stream playback, because I couldn't quickly find one that isn't. That's the only reason I changed ffdshow's config. Of course I won't leave it this way.
Well I'm not sure it's players responsibility to change decoders depending on the DXVA compliance of the stream. AFAIK there is only one media subtype for both DXVA and non DXVA H264 streams so the player cannot have different configurations for different H264 streams. One more reason that brings me to the same conclusion is that all other DXVA capable decoders fallback to software mode without the need to rebuild the graph or change the decoder. This is true for MPC's Video decoder, Cyberlink's one, DivX's one and I'm pretty sure it's the same with Microsoft's DTV-DVD decoder too.
So I think it's only FFDShow that's making it in different way which is not very convenient for the users.
I'll be glad to be proven wrong here and somebody to show me how to use ffdshow DXVA decoder in Zoomplayer or DVBViewer (another player in which you can configure only one H264 decoder at a time)

[STaRGaZeR]

The Ati cards are capable to decode 5.1 streams. I tried to play the sample. It works afters waiting 3 minutes :) but I after it started my monitor entered in sleep mode but audio worked. I think it will be more usefull to report this in Ati forums. This way they will correct in a future driver release. Also I think it's important to specify that ffdshow dxva is playing this file if compatibility mode is set to skip all checks.

ffdshow r3480 plays this file with compatibility mode set to normal, not skip all checks. So waiting 3 minutes is being capable of decoding it? I'd really like to know what would happen if I make a test encode with this resolution plus 16 ref frames, of course 5.1 compliant ;)
Writing on ATI forums is useless IMO. ATI cards definitely have bad support for high resolution and high number of ref frames. The issue I see here is that this particular file is blocked by MPC, but not by ffdshow. Looking at how it crashes the driver here I'd say MPC is right and ffdshow is not. Also, why MPC blocks it if this card can play 5.1 streams? :p

[dann23]

be patient :) They've just added support for 5.1 streams. Maybe they will fix it. But I don't know why I have to choose skip all checks in ffdshow to play 5.1 streams if my card and my driver support it. I didn't have problems with 5.1 streams until this sample of yours :D
And I believe that wating 3 minutes to play that sample is equal to the blue screen you had.:p because my monitor went black after that yet my computer was working. I could hear the sound. stupid driver:D

[clsid]

clsid,
I was just trying to simulate an non dxva compliant stream playback, because I couldn't quickly find one that isn't. That's the only reason I changed ffdshow's config. Of course I won't leave it this way.
Well I'm not sure it's players responsibility to change decoders depending on the DXVA compliance of the stream. AFAIK there is only one media subtype for both DXVA and non DXVA H264 streams so the player cannot have different configurations for different H264 streams. One more reason that brings me to the same conclusion is that all other DXVA capable decoders fallback to software mode without the need to rebuild the graph or change the decoder. This is true for MPC's Video decoder, Cyberlink's one, DivX's one and I'm pretty sure it's the same with Microsoft's DTV-DVD decoder too.
So I think it's only FFDShow that's making it in different way which is not very convenient for the users.
I'll be glad to be proven wrong here and somebody to show me how to use ffdshow DXVA decoder in Zoomplayer or DVBViewer (another player in which you can configure only one H264 decoder at a time)
If the "preferred" decoder fails, then ZoomPlayer should just pick the next available decoder. If ZoomPlayer shows you an error after trying just one decoder, then that is simply stupid behavior of ZoomPlayer. They can easily fix that flaw.
The behavior of ffdshow is working fine and is intentional to allow fallback to software decoders other than ffdshow. This will not change!

[SamuriHL]

Hi,

Casimir666 has added support for MPC Matroska Splitter for PGS sub today :)

Thanks to him :)
And it's working great :)
Seb.

SERIOUSLY?? Man all the fun happens when I'm on vacation. I came back home just for tonight but I'll have to grab that and give it a quick test before I leave for the rest of the week. Do you have a link?

[Sebastiii]

Hi :)
You can try this :)

Filter MPC Matroska ans MPEG LAST SVN (http://sebinternet.free.fr/mediaportal/2010.06.20-MKVHD.rar)

Enjoy :)
Seb.

[SamuriHL]

Hi :)
You can try this :)

Filter MPC Matroska ans MPEG LAST SVN (http://sebinternet.free.fr/mediaportal/2010.06.20-MKVHD.rar)

Enjoy :)
Seb.

Thanks, Seb! I'll give it a try. Won't get to do much after I leave again in the morning as I'm beaching it up for a week. :D This is great, though, as I can finally drop Haali.

[gametiger]

The DXVA decoder checks for compliance and only decodes streams that pass that test. Whatever other decoder you have installed will take care of the rest.
I have a H.264 720p High@5.1 (16(!) ref frames) video that stops playing after 7 seconds (audio stops a few seconds later), isn't this regarded DXVA non compliant?

Also, I noticed some major artefacts with SD (both 4:3 and 16:9) H.264 3.1 w/ 8/9 ref frames material. What's up with that?


Maybe the way I setup my external filters in MPC-HC has something to do with it: I have both the DXVA and the normal ffdshow video decoder set to preferred in the External Filter settings.

I hope someone can help, thanks!

[Sebastiii]

hehe it's works here :) and good vacation to you :)
The next step it to add the full support of EDITION (multi end of movie).
Some issue to fix about DVDSUB i have see on one mkv sample.
And the splitter goes to 100% :)
Seb.

[Snowknight26]

The DXVA decoder checks for compliance and only decodes streams that pass that test. Whatever other decoder you have installed will take care of the rest.

So why does High 4:4:4 Predictive pass?

[clsid]

I have a H.264 720p High@5.1 (16(!) ref frames) video that stops playing after 7 seconds (audio stops a few seconds later), isn't this regarded DXVA non compliant?Cut a sample of that file and post it in the MPC-HC topic. Then the MPC devs can test it. (ffdshow uses the same DXVA code as MPC-HC)
Also, I noticed some major artefacts with SD (both 4:3 and 16:9) H.264 3.1 w/ 8/9 ref frames material. What's up with that?
The SD issue is a bug in the ATI driver.
So why does High 4:4:4 Predictive pass? The DXVA compliance test currently only looks at the number of reference frames. Post problematic files in the MPC-HC discussion topic.

[STaRGaZeR]

be patient :) They've just added support for 5.1 streams. Maybe they will fix it. But I don't know why I have to choose skip all checks in ffdshow to play 5.1 streams if my card and my driver support it. I didn't have problems with 5.1 streams until this sample of yours :D
And I believe that wating 3 minutes to play that sample is equal to the blue screen you had.:p because my monitor went black after that yet my computer was working. I could hear the sound. stupid driver:D

What I don't really like is that after a driver is out saying something like "support for 5.1 H.264 streams blabla" there's a lot of people in the MPC thread saying "ey, I've tested this sample with 16 ref frames and it worked!". Then one dev removes the checks for it, and then a lot of users complain because it really doesn't support 5.1 at all. After that you can read things like "UVD cards can't play it, UVD2 cards can!". This is also not true, and we have the problem again. Anything above 4.1 (and above 10 ref frames or so) has very high chances of not working with DXVA on ATI, and thus software decoding should be used instead.

Can anybody test this sample with Microsoft's decoder?

[Snowknight26]

Anything above 4.1 (and above 10 ref frames or so) has very high chances of not working with DXVA on ATI, and thus software decoding should be used instead.

Have any figures to back up that claim?

[Midzuki]

Only now that I'm planning to build a "trashy" 8.1 sound system by using two sound cards at the same time, I perceive there is no "back center" in the Volume tab of the audio decoder/processor. What's up? :confused: :confused: :confused:

[Eliminateur]

@xhmikosr: i've been following your build and wanted to ask you a question, is the x64 build also ICL11?

[ptr727]

Hi, where do I get the debug symbols for ffdshow tryout builds posted on SF?

They do not appear to be posted anywhere, if they are being posted, please point me to them.

Reason I ask is that my player crashes die to ffdsow, and I would like to help fix the problem.

If symbols are not being posted, how can the community help with ffdshow crashes?
E.g. is ffdshow registered with Microsoft WinQual, do the symbols have source server integration, etc.?

Regards
P.

[XhmikosR]

@xhmikosr: i've been following your build and wanted to ask you a question, is the x64 build also ICL11?

No, I get lots of errors when compiling ffdshow x64 with ICL.

Hi, where do I get the debug symbols for ffdshow tryout builds posted on SF?

They do not appear to be posted anywhere, if they are being posted, please point me to them.

Reason I ask is that my player crashes die to ffdsow, and I would like to help fix the problem.

If symbols are not being posted, how can the community help with ffdshow crashes?
E.g. is ffdshow registered with Microsoft WinQual, do the symbols have source server integration, etc.?

Regards
P.

I don't think you'll find any symbols anywhere unless clsid has kept them. Not to mention that the linker option /DEBUG is not enabled for release builds, which should change in my opinion along with the IntDir.

[Dislikeyou]

Has the multithread bug in ffdshow (ffmpeg-mt) been fixed? i mean when u select to use ffmpeg-mt for h264 and have 8 threads it would make garbaged picture..

Thanks!

[madshi]

It is not really a splitter error. If it works with other renderers, then I see no reason why it shouldn't be possible to make it work with the modified EVR renderers. In fact, the pre-beliyaal EVR CP worked ok with VC-1.
FWIW, it definitely is a splitter error. The MPC HC splitter outputs "shuffled" timestamps for VC-1 m2ts files. When using Haali to split the m2ts file, the problem disappears. When remuxing the VC-1 m2ts file to MKV, the problem disappears (regardless of which splitter is used). Some VC-1 decoders seem to reorder the shuffled timestamps, others don't. Some renderers cope with the shuffled timestamps, other don't. The next madVR renderer version will be able to handle the shuffled timestamps, but it's not ideal, because there can be a audio/video sync problem, because it's not possible for the decoder/renderer to know which timestamp belongs to which frame exactly.

[clsid]

Has the multithread bug in ffdshow (ffmpeg-mt) been fixed? i mean when u select to use ffmpeg-mt for h264 and have 8 threads it would make garbaged picture.Does it also happen with 2 or 4 threads? Does it happen with all files, or just some? A sample file would be useful.

[ptr727]

I don't think you'll find any symbols anywhere unless clsid has kept them. Not to mention that the linker option /DEBUG is not enabled for release builds, which should change in my opinion along with the IntDir.

You don't need debug builds to generate symbols, you just need to generate symbols.

It is standard practice to generate PDB's, ideally with source server integration, for release builds, without them, it is very difficult to debug crashes, you need at least a MAP file, with them, it is much simpler.

If PDB's are generated, but not made public, is it expected that testers send the crash dumps to developers?

P.

[XhmikosR]

I never said anything about debug builds. I said about the /DEBUG switch regarding the linker which generates the PDB files. Other than that, see my previous post and you'll see I suggested the same thing about release builds. I cannot give you an answer about PDB files not be released in public.

[ptr727]

I never said anything about debug builds. I said about the /DEBUG switch regarding the linker which generates the PDB files. Other than that, see my previous post and you'll see I suggested the same thing about release builds. I cannot give you an answer about PDB files not be released in public.

Apologies, misinterpreted.

[STaRGaZeR]

Have any figures to back up that claim?

The sample I posted before, all the complaints each time MPC devs change something in the compatibility code, all the x264 encoded videos that give me black screen, crash the driver or simply BSOD, etc.

[clsid]

The main MPC-HC discussion topic is too unorganized to deal with this properly.
Perhaps you or anyone else that is having lots of DXVA problems could take the initiative to open a new topic to discuss those problems.
The main task of the topic starter would be to keep the first post updated with the information posted in the topic. So it requires a bit of effort.
It should also contain a few (problematic) samples that people can use for testing. As the topic progresses, any useful samples posted could be added to the first post. For each sample a mediainfo log should be included (or perhaps just the relevant parts: reference frames, resolution, level).

People who test the files should provide as much details as possible like:
- Name of sample tested
- Result: artifacts/crash/bsod/plays fine/something else
- Graphics card brand and model number
- Driver version
- Windows version
- The splitter that was used (if relevant)

If enough people post test results, then we should be able to improve the compatibility check.

[Snowknight26]

The sample I posted before, all the complaints each time MPC devs change something in the compatibility code, all the x264 encoded videos that give me black screen, crash the driver or simply BSOD, etc.

Ah, so it only affects you, not 'DXVA on ATI' like you said, which is a blanket statement.

[STaRGaZeR]

The main MPC-HC discussion topic is too unorganized to deal with this properly.
Perhaps you or anyone else that is having lots of DXVA problems could take the initiative to open a new topic to discuss those problems.
The main task of the topic starter would be to keep the first post updated with the information posted in the topic. So it requires a bit of effort.
It should also contain a few (problematic) samples that people can use for testing. As the topic progresses, any useful samples posted could be added to the first post. For each sample a mediainfo log should be included (or perhaps just the relevant parts: reference frames, resolution, level).

People who test the files should provide as much details as possible like:
- Name of sample tested
- Result: artifacts/crash/bsod/plays fine/something else
- Graphics card brand and model number
- Driver version
- Windows version
- The splitter that was used (if relevant)

If enough people post test results, then we should be able to improve the compatibility check.

I don't use DXVA very often, just after some relevant updates, or to test some samples, so I can't really be of any help with this. That's how I discovered this one, I asked myself: "Would this play with DXVA? I think it won't". Boom, BSOD. There's already a thread about this, but it's old and abandoned (http://forum.doom9.org/showthread.php?t=153006). What about resurrecting it?

Ah, so it only affects you, not 'DXVA on ATI' like you said, which is a blanket statement.

No, it isn't. Read some pages from here: http://forum.doom9.org/showthread.php?p=1395672#post1395672, and skip the SD blockiness posts, it has been fixed. The hangs with 16 ref frames material is not fixed. >1080p doesn't work either.

Read dann23 posts again. The sample I posted is 2516x1700 and 5.0 compliant.

Bottom line: 5.1 on ATI is a disaster with ffdshow/MPC. I still want to know if this sample crashes with Microsoft's H.264 decoder, or if anybody has been able to properly play any >1080p video with DXVA on ATI.

[Dislikeyou]

Does it also happen with 2 or 4 threads? Does it happen with all files, or just some? A sample file would be useful.

This is what im talking about:
Image corruption while using ffmpeg-mt with more than 1 thread. (libavcodec and DVXA are also ok)
http://img265.imageshack.us/img265/5303/avatarblurayffmpegmtcor.png

Tested with ffdshow r3370 xxl and r3390 from http://www.xvidvideo.ru

This must be some very old bug because it occurs even in very old revisions as well.

Remuxed BD sample http://www.sendspace.com/file/f9s4te

[dimitrik]

I want to start by apologizing for what might be an off-topic post, however I'm hoping that others might also find it useful as part of a discussion on ffdshow.
Moreover the people in this thread are probably the most qualified on the planet to answer...

I have been wondering what is the effect of CPU cache on ffdshow performance (e.g. between Athlon II & Phenom II CPU's).

I have never found any clear info except generic stuff like "more is better":rolleyes: and "intel is better than AMD" (possibly due to the SSE2 units?). But cache is something you can pay more for, so knowing if it's worth it seems useful.

Again I apologize if the post is OT and thank you for any opinions offered.

[clsid]

In general more CPU cache gives better performance. But it is just one of the many factors that play a role in the performance of a CPU. So you better just look at a CPU benchmark to compare different CPUs. You can find lots of such benchmarks on hardware sites.

[clsid]

This is what im talking about:
If I can remember correctly fixing that specific problem would require using FFmpeg's H.264 parser in ffdshow.
We need a volunteer to do that.

[dimitrik]

Sadly the hardware sites concentrate much too much on 3D games benchmarks and too little on multimedia performance - it is taken as a given (wrongly so IMO).

Still this is helpful info. Thank you!

[Midzuki]

Plus 10 points for the old school reference!
Thanks for the 10 points.
Even though I'm not sure about your meaning for "old school reference"...

Anyway, "labels" are not very important,
especially if/when they can mislead us.
Stubbornness is bad, and it doesn't care at all if the source-code refers to a web-browser or to a DirectShow decoder. :(

[pankov]

Guys,
since svn build 2067 of MPC's splitter the problem with some H264 streams in TS container is fixed I found a problem in FFDShow ... or it could be still in the splitter - you know better.
If I try to play the sample I used to report the problem of the splitter here
http://forum.doom9.org/showthread.php?p=1410473#post1410473
and use ffdshow as H264 decoder I only get black screen with audio.
If I use CoreAVC or Microsoft DTV-DVD Decoder everything is fine.
Am I doing something wrong or it's really a bug in ffdshow?

[pankov]

and two more problems when using the sample from my previous post and ffdshow:
1. If I add the ffdshow Video Decoder filter as a postprocessor after Microsoft DTV-DVD Decoder I get black and white picture. There is no problem if I add it after CoreAVC but then again if I don't add it after Microsoft's decoder I have coloer
Ideas???
2. If I add the ffdshow raw video filter as a postprocessor after any other filter I get
---------------------------
Zoom Player
---------------------------
Access violation at address 58793E56 in module 'ffdshow.ax'. Read of address 00000504.
---------------------------
OK
---------------------------

What am I doing wrong?

[jeremy33]

This is what im talking about:

If I can remember correctly fixing that specific problem would require using FFmpeg's H.264 parser in ffdshow.
We need a volunteer to do that.

If you remux the sample to mkv there is no probleme with multi threads in ffdshow

[magic144]

Is anybody (else) still seeing sys-tray FFv icon right-click induced crashes (I know this has been reported here on a couple of occasions in the recent past). I have been getting these regularly for several weeks' worth of the latest revisions.

It never used to happen, and it only seems to happen with some content - though not WMV for some reason - using the regular (NOT DXVA) decoder filter. The DXVA filter's video sys-tray icon is fine.

Manually creating a graph and playing the same file using GraphStudio - seems to work OK too. I am using Zoom Player MAX 7.1a5.
Is there any particular data-set I can provide here that would help point to the cause? The M$oft crash window always points to ffdshow.ax as the 'fault module' - here is a typical output:-

Problem signature:
Problem Event Name: APPCRASH
Application Name: zplayer.exe
Application Version: 7.0.0.0
Application Timestamp: 2a425e19
Fault Module Name: ffdshow.ax
Fault Module Version: 1.1.3476.0
Fault Module Timestamp: 4c179977
Exception Code: c00000fd
Exception Offset: 0004c344
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 4105
Additional Information 1: c6b1
Additional Information 2: c6b143c661515d69d4d8c4d358f23b56
Additional Information 3: 73ae
Additional Information 4: 73aedc52574d1a2c0c1aadf1d653516b

----

I should point out that at least one op on the ZP forum does not see the same failure mode, however they do report that rather than a crash, 'nothing' sometimes happens when right-clicking the video tray icon for them.

For me, the crash has been observed on 3 separate Windows-7 32-bit Home Premium platforms, including one fresh (clean) Win7 install with no 3rd party apps, right after having installed latest ffdshow + Haali + ZP.

[hoborg]

Hi.
Is there a way how to prevent FFDShow DXVA decoder to load for VC-1i?
Should not be VC-1i disabled by default or it is not possible?

I tryed to create an profile, but i didnt found a way how to detect "is interlaced" ...

[lordadmira]

Thanks for the 10 points.
Even though I'm not sure about your meaning for "old school reference"...
Netscape 4 and CSS.


LA

[hoborg]

Hi.
MPC-HC fix playback on interlaced h.264 in TS, but FFDshow DXVA decoder still doesnot work.

Revision 2074 - Directory Listing
Modified Thu Jun 24 12:26:24 2010 UTC (18 hours, 13 minutes ago) by aleksoid

Fix : temporary hack for use MPC Video Decoder to decode H.264 stream in .ts;

Can be FFDshow DXVA decoder updated too?
Thanks.

[dann23]

maybe they will update it to support MPEG2 DXVA like MPC-HC does.

[EpsilonX]

A small question for the devs... :D
How many taps do the Spline algorithm in Resize uses..?
Spline16, 36 or 64..?
Or is it a different "variant"..?
Is it difficult to implement a tap slider like in Lanczos method..?
Thanks in advanced...

[Delerue]

Today I've figured out that Nvidia settings (like dynamic range, edge enhancement, noise reduction, etc.) don't work if I select just RGB32 as output in FFDShow; to make it work I must check UYVY colorspace. But if I select UYVY, then FFDShow resize filter gives me wrong colors. Is there a way to use Nvidia settings and at the same time FFDShow resize filter without wrong colors?

Also, is there any plans to add WMA Pro audio decoder, as FFMpeg already support it?

[Snowknight26]

Fraps decoding is broken to some extent.

With ffdshow outputting RGB32 or RGB15,flipped:
http://stfcc.org/pics/i/b65bbe6baa26254a1eb1fecf29e78868_th.jpg (http://stfcc.org/pics/i/b65bbe6baa26254a1eb1fecf29e78868.png)

With ffdshow outputting NV21,VU or YV12/YV12,adj/YV12,adj,VU (notice the brighter bar on the right.. the issue is back, again):
http://stfcc.org/pics/i/c6db069c8c7f25f4e0b7f25ba45636bd_th.jpg (http://stfcc.org/pics/i/c6db069c8c7f25f4e0b7f25ba45636bd.png)

RGB16,flipped (different video, worse issue):
http://stfcc.org/pics/i/815492691d975591b88c3f3c14b4e692_th.jpg (http://stfcc.org/pics/i/815492691d975591b88c3f3c14b4e692.png)

YUV2, RGB24,flipped and UYVY output the video properly.

Strangely, the issue only appears when recording the desktop. Nevertheless, here's a sample:
http://stfcc.org/misc/ffdshow.fraps.bug.rar

[albain]

@albain
Closed captions are decoded by ffdshow even when the subtitle filter is disabled. This sometimes confuses people, making them unable to figure out how to disable the subtitles. Perhaps an option called "Closed Captions" could be added to the tray context menu (visible only if CC are present) where users can toggle the display of CC on/off. The option could be placed where "Flip" and "Keyboard & Remote" are also located.

Hi clsid, there is a closed caption option in subtitles section.
It does not fill its role ?

[tetsuo55]

What does the "updated ffmpeg API" commit mean exactly?

[clsid]

Hi clsid, there is a closed caption option in subtitles section.
It does not fill its role ?Currently the CC option also functions when the subtitle filter itself is disabled. That confuses people because they usually won't look in ffdshow's subtitle section when that is not enabled.

What does the "updated ffmpeg API" commit mean exactly? See the changes in avcodec.h. Currently the old API functions are still used by ffdshow.ax.

[tetsuo55]

ok thanks

[Atak_Snajpera]

is there any particular reason why VP8 decoding is disabled by default?

[pankov]

Guys,
is there a way to open the Audio Processor configuration window with a shortcut?
I'm talking about something like rundll32.exe ffdshow.ax,configureAudio
And don't you think it'll be good to add shortcuts for all the configuration windows in the default installer.

[Atak_Snajpera]

Is everything ok with you?
http://img404.imageshack.us/img404/6618/69407075.png

[pankov]

Atak_Snajpera,
since Audio Processor can have different settings from Audio decoder and Video Processor (raw video decoder) can have different settings from Video decoder I think they deserve their own shortcuts in the program group.
After I checked the functions that ffdshow.ax exports I found that the shortcuts need to be
raw video decoder (Video processor) - rundll32.exe ffdshow.ax,configureRaw
Audio processor - rundll32.exe ffdshow.ax,configureAudioRaw

btw
won't it be more consistent to either have the Audio processor called "raw audio decoder" or rename the "raw video decoder" to "Video processor"?

[magic144]

clsid's x86 build today (rev 3495) seems to crash ZoomPlayer 7.1a5 MAX
(win7 Home Premium, 32-bit)

(at least for DXVA h264 .mkv files)
not for non-DXVA h264 apparently, or other video types

hmm, it kills graphstudio too, so it seems to be an issue with libavcodec.dll, like this:-

Problem signature:
Problem Event Name: APPCRASH
Application Name: graphstudio.exe
Application Version: 0.3.2.0
Application Timestamp: 4a34defb
Fault Module Name: libavcodec.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4c2daa61
Exception Code: c0000005
Exception Offset: 000cbe33
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 4105
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[dimitrik]

Strange thing with several video types (mainly Xvid/divx but also on h264).

I enable OSD (which by the way could use a clean up of its options cause they're pretty messy), and set up display of "CPU use", "input bitrate", and "video delay".

While playing standard SD videos (sometimes on HD too) I occasionally see video delay go from 0 (where it stays normally) to some pretty high numbers e.g. 109215ms or 111526ms. It fluctuates around there for a while - if I pause it and then continue playback the delay stays - if restart the video of course it goes away. I doesn't happen in particularly high bitrate scenes (around 3-4Mbps) and the CPU use never goes above 30-35%. :confused:

The thing is - I cannot notice any delay in playback! It looks fine and with these numbers it should be noticeable - I mean if ms=milliseconds then these indicators should be >100 seconds which I cannot believe I would miss:p!

So it seems the OSD indicator is wrong (or maybe the units are not ms) and I'm also wondering if the video delay itself is really correct since I can't notice it. But possibly its just so imperceptible that I can't see it if the units are say millionths of a second...

In case it's useful, here's my set up:

The system is an Athlon II X3 3GHz, 4GB Ram, 7200rpm HDD, Vista x86, no other software running.

I have ffdshow set up to decode everything inside Windows Media Center, with:
- Resizing to 1280x720 with lanczos (taps=2).
- Picture properties set up to do luminance fix
- Output set to RGB32 with "high quality RGB conversion"

[ikarad]

First problem
There is random crash (not at the same time) with blu-ray subs and ffdshow 3496 (same problem with ffdshow 3361 or 3367) with YUY2 or rgb32 and mpc-hc 1426 or 2099 under seven 64.
I try with the last directx redist (june or may 2010) and there is the same problem.

If blu-ray subs are not selected, there is no crash.

Have you got the same problem?

Second problem
I find that the update Kb982519 and KB980248 under windows update make crash more often with ffdshow and blu-ray subs under vista 32. Without these updates there is less crash.
config: ffdshow 3361, mpc-hc 1426, YUY2, vista 32 with all updates except kb982519 and kb980248, I don't use dxva.

[clsid]

Please upload a sample file.

[clsid]

clsid's x86 build today (rev 3495) seems to crash ZoomPlayer 7.1a5 MAX
(win7 Home Premium, 32-bit)

(at least for DXVA h264 .mkv files)
not for non-DXVA h264 apparently, or other video types
Fixed

[ikarad]

Please upload a sample file.

It's this sample (random crash between 7'30 min and 9'30 min (I don't try before 7'30min))
part 1
http://www.zshare.net/info.html?72194780-3f3de5a523000d960412ca4e70f4959e
part2
http://www.zshare.net/info.html?72228704-870148d21c7371e7a2cb0c45e37239c1
part3
http://www.zshare.net/info.html?72228942-da539adec6856595c9fa215e89fcfdf2

part 4
http://www.zshare.net/info.html?72879609-e7005b47f97bd593cc1fac7d6620cda5

part 5
http://www.zshare.net/info.html?72894035-f4d916b0cbd3fbf999835142beff854c
part 6
http://www.zshare.net/info.html?72901975-036b32dfe47b4378533fe6974fb1237c

partie 7
http://www.zshare.net/info.html?72152693-cff6f6453a85c6f497a94c0fc61987f5

But it's not available today. Although Albain has used this sample two months. If He still has this sample I don't upload anew. If not tell me and I will upload anew but the problem is that It take lot of times to upload 3 go.

[magic144]

Fixed

Thanks! That was quick!

[clsid]

@albain

1) External DTS audio file now works in MPC, but only if the stream switcher in ffdshow audio decoder is disabled. When enabled, switching to the DTS stream is possible, but there is no data throughput.

2) I think we could cleanup the tray icon menus a bit. For example, the audio decoder shows "OSD" twice. In video decoder, we perhaps could remove "Flip" and "Keyboard & remote", as I don't think many people use that (during playback). And perhaps the DS filter lists could be placed in a submenu. What do you think?

[magic144]

Hmmm, whilst clsid's build 3498 seems to allow h.264 DXVA content to work, apparently VC-1 content (via DXVA ONLY) causes an app-crash due to libavcodec.dll... only just noticed this whilst trying to play BBC's LIFE disc!

again, non-DXVA seems to be unaffected here

build 3483 seems immune to this problem

[albain]

@albain

1) External DTS audio file now works in MPC, but only if the stream switcher in ffdshow audio decoder is disabled. When enabled, switching to the DTS stream is possible, but there is no data throughput.

It should work now (in the revision 3499)

However it won't work with Haali, I am not sure why but there is a deadlock somewhere in Haali due to this event blocking mode
AC3/DTS MPC filter needs to work in blocking mode instead of returning FALSE when the stream is not active (otherwise no buffer is fed) .
But this mode is not compatible with Haali (the player hangs). So I disabled blocking mode when Haali is in the graph
Haali & AC3/DTS source filter => FFDshow audio => audio renderer
=> Not working




2) I think we could cleanup the tray icon menus a bit. For example, the audio decoder shows "OSD" twice. In video decoder, we perhaps could remove "Flip" and "Keyboard & remote", as I don't think many people use that (during playback). And perhaps the DS filter lists could be placed in a submenu. What do you think?
Ok for that


About the closed caption issue (displayed even when disabled) : someone has a sample ? thanks

[davidsama]

In revision 3507 whenever i load an mp4 file into ripbot 16.0 and i click properties in the preview that is displayed it only shows a gray screen and outputs a video file that has no video and no audio just a gray screen. I know for a fact that ripbot can encode this file with video and audio because it successfully did it with revision 3477. This also occurs with revisions 3489, 3495 and 3498. It does not seem to do it with any revision before 3483.

[Atak_Snajpera]

@davidsama
send 50mb sample to www.mediafire.com. Use DGSplit.

[hoborg]

Hi.
I just tested "ffdshow_rev3507_20100707_clsid.exe" build and Audio/Subtitles stream switching by keyboard now working for me - not sure if this was fixed between 3488-3507 build or it was "http://www.xvidvideo.ru/" build problem.

Now it is working as it should, thanks !

[madshi]

Two things:

(1) The latest madVR v0.22 now fully supports ffdshow's "Allow output format changes during playback" feature. Could an ffdshow dev please add madVR to the list of "compatible filters"? Thanks!

(2) What purpose does the "Set pixel aspect ratio in output media type" option have? Yes yes, I know it switches between VIDEOINFOHEADER and VIDEOINFOHEADER2. That's not what I mean. Why would anybody want to have this option turned OFF? I don't really see a sense in that. And every option which can be removed without negative side effects is a good thing for usability. So is there a good reason for why anybody would want to *not* have the aspect ratio in the media type?

[Midzuki]

since Audio Processor can have different settings from Audio decoder and Video Processor (raw video decoder) can have different settings from Video decoder I think they deserve their own shortcuts in the program group.

Definitely.

After I checked the functions that ffdshow.ax exports I found that the shortcuts need to be
raw video decoder (Video processor) - rundll32.exe ffdshow.ax,configureRaw
Audio processor - rundll32.exe ffdshow.ax,configureAudioRaw

:goodpost: && :thanks:

But there is more: :devil:

configureEnc

configureDec

configureSubtitles

:helpful:

btw
won't it be more consistent to either have the Audio processor called "raw audio decoder" or rename the "raw video decoder" to "Video processor"?

Yep. :)

No pins will be removed.

Which makes me ask,

¿
what is the point of a "standalone" subtitle filter in ffdshow,
then,
?

[cyberbeing]

http://img441.imageshack.us/img441/6797/outputformatchange.png

madVR now supports Output Format Changes During Playback, so a patch for FFDshow needs to be written to add madVR to the list of filters which support dynamic format change. Currently the indeterminate state for that setting produces incorrect aspect ratios with certain videos with the latest madVR. Forcing the setting on fixes it.

[clsid]

[I]what is the point of a "standalone" subtitle filter in ffdshowRead this topic and you shall find the answer (hint: zoomplayer). It certainly not exists for the reason you seem to be thinking of.

I shall repeat things again.
1) The subtitle pin of ffdshow video decoder shall not be removed. That is a wrong solution. You don't even understand what it does. There is a huge difference between a pin existing and a pin actually being connected to another pin (and thus having any effect).
2) Post a proper bug report with a detailed description of your problem and the settings that you are using. Then people here can attempt to reproduce your problem and confirm whether a bug really exists or if you are just doing things wrong.

[Midzuki]

It certainly not exists for the reason you seem to be thinking of.

That's just your opinion of course.

1) The subtitle pin of ffdshow video decoder shall not be removed. That is a wrong solution.

That's just your opinion of course.

2) Post a proper bug report with a detailed description of your problem and the settings that you are using.

Been there, done that.

[clsid]

@cyberbeing
Added in rev3508

[Midzuki]

To whom this may concern
(albain, Mr. K-Lite, etc.) :

http://forum.doom9.org/showthread.php?p=1401862#post1401862

http://forum.doom9.org/showthread.php?p=1402171#post1402171

http://forum.doom9.org/showthread.php?p=1409500#post1409500

http://forum.doom9.org/showthread.php?p=1402596#post1402596

http://forum.doom9.org/showthread.php?p=1393330#post1393330

http://forum.doom9.org/showthread.php?t=148056

P.S.:

IF "official" "bug reports" are "always required",

THEN,

¿what is the point of this thread?

[clsid]

If you would have better read this topic, particularly the recent discussions about closed captions, then you would have already found the solution to your problem. Uncheck "closed captions" in the subtitle options and the problem is solved.

[leeperry]

hey, I unsubscribed from this thread a while back...but I can see that there's still a lotta love :D

anyway, I'm not sure what that new option will do in mVR, but I guess it could help w/ KMPlayer/PotPlayer's seamless playback mode when switching between 2 files that have different specs/AR...so thanks for implementing it :)

[Midzuki]

OK, this may be "old news" for the devilopers ;) ,
but it is an interesting finding for myself.

In ffdshow, the video processor includes, in its MEDIATYPE_Video, the support for the subtype MEDIASUBTYPE_DVD_SUBPICTURE. And it really should NOT do that, not only because it screws the SUP pics for any non-D1 video, but also because it works in an "all-or-nothing" way, —
— that is to say, if it processes a video stream, it WILL also process a SUP stream, and, if it cannot connect to a SubPicture pin, it will "naturally" refuse to connect to a raw video output as well (just tested and confirmed via Media Player Classic,
with ffdshow r3426 --- I serious doubt the result would have been different if I had "upgraded" to the latest revision). Bottom line is,
in its current status, the so-called "raw video filter" is just a
"glorified" subtitling filter, period.

Just my 2x10^(-2) dollars. :devil:

[dann23]

I have some questions about ffdshow.
1.When we'll be able to change the font and size for ASS subtitles using the sliders froms size,colors and alpha. it's annoyng to use the sliders from scale x and y.
2. I believe that tal.aloni was working on improving subtitles performance in ffdshow dxva but since weeks never heard of him. Is he still working on this?
3. if there are external subtitle files and movies in the same folder and the movie has internal subtitles then ffdshow chooses to load the external subtitles which is wrong. I saw a discussion about this behaviour but please make an option to revert to the old logic. or if there is such option please tell me how to activate it.
4. Also I found a bug. When decoding dts tracks in video files using libavcodec the movie plays fast. but it works ok if using libdts. I'll provide a sample if necessary.
5. And can some update the wiki to include some information on how to use the deinterlace capability from video cards?
I tried by checking set pixel aspect ratio in output media type. didn't work. when I choose set interlace flag in output media type it works. I also found on the internet that I have to uncheck all color spaces except nv12(also it works wit YU12). it works this way but how to see if the video card makes deinterlacing? and it applies deinterlacing to all the videos? even when there is no need to do deinterlacing?
6. with the latest madvr and ffdshow when I close the player (wmp11) it stays in memory. ffdshow audio icon is still present until I kill it using task manager. this didn't happen before.
7. how to invoke madvr' properties window from start menu? and can I install it manualy by using regsvr32 madvr.ax? Why I have to use install.exe?
thank you.

[ImAhNoBoDy]

I was wondering if ffdshow is working as designed in this situation. When embedded vobsub files are used in a mkv container, any subtitles with any ending times of 00:00:00 are played, but it never goes to the next subtitle.

http://img.photobucket.com/albums/v395/SeX1eStAsaBa/0000000sub.jpg

[naoan]

I was wondering if ffdshow is working as designed in this situation. When embedded vobsub files are used in a mkv container, any subtitles with any ending times of 00:00:00 are played, but it never goes to the next subtitle.

Yes I get this problem as well (checking obey position in bluray/dvd tabs make it worse) but somehow found a workaround : extract the vobsub file from the mkv container and let ffdshow play it as an external sub, it will play it correctly, strangely enough.

[orkino]

Hi, the olders version of ffdshow (r33xx) the subtitles (fonts) had the same size in all resolution (if you had enable the Video Resize and in Sub/font the auto size), The newers version of ffdshow (r34xx) don't make this... I don't use dxva! Thanks for any help!

[Midzuki]

@haruhiko_yamagata

I think you forgot to put the back center speaker controls and meter in the volume filter (for something like 6.1 speakers), unless you did that on purpose with the intention of adding it later because like the description for rev.1549 says:
"Volume filter : add control for side channels".

Back center speaker is hidden there beforehand. Back left speaker can be used to configure back center speaker. They are rarely used together. Because there was no space to add one more control, I left it untouched. Though I cant test it.

It shouldn't be "incredibly-difficult" to draw a wider configuration window, I guess.

[fastplayer]

MPC (r2121) crashes in ffmpegmt.dll starting with rev3509. Can someone reproduce?

[rack04]

MPC (r2121) crashes in ffmpegmt.dll starting with rev3509. Can someone reproduce?

I can reproduce with ffdshow_rev3510_20100712_xhmikosr.

[fastplayer]

I can reproduce with ffdshow_rev3510_20100712_xhmikosr.
Thanks for the quick confirmation! :)

[clsid]

I am on it. Can you check which is the last working build? Last h264 specific change was in 3503.

[fastplayer]

^If I had a build of it, I would immediately.
rev3509 and 3510 both crash in ffmpegmt.dll.
rev3507 is fine, though.

Edit: My reply was in regard to rev3508, originally.
Anyway, I just checked rev3503 and it is OK.

[clsid]

Fixed in 3512

[fastplayer]

Fixed in 3512
Confirmed with xhmikosr's build. :)
:thanks:

[Atak_Snajpera]

@clsid
can you update http://sourceforge.net/projects/ffdshow-tryout/ page to r3512 ?

[Midzuki]

Uncheck "closed captions" in the subtitle options and the problem is solved.

[ revision 3507 ]

Uncheck ALL the subtitle options,

and

the

problem

REMAINS. :mad:


BTW,
what would the big horrible "sin" in removing the

subtype MEDIASUBTYPE_DVD_SUBPICTURE

from the filters "Raw Video" and "Subtitles" ???

[clsid]

You are correct. It does not work for the raw filter. It used to work if I remember correctly, so it might be a regression, possibly after the recent subtitle changes. Test some older builds as well.

But removing the mediatypes won't fix it! And even if it did, they won't be removed since in some cases we do want the filter to handle subtitles. Internally something goes wrong in the code that accepts/denies pin connection. MPC external filter settings allows you to edit/remove mediatypes of any filter. If you remove the subpictive and catch-all video mediatype you will see it still doesn't work.

[jhoff80]

So, I've been messing around with DXVA again for the first time in a long time, and have noticed that some (very old) x264 encodes apparently pass the compatibility checks (which are set to normal), but are constantly displaying small green squares and exhibit general blockiness throughout. Turning DXVA off plays them perfectly.

These are SD video encoded from DVD, so I really thought that there wouldn't be any problem.

All of the much more recently encoded files are playing perfectly, but this older stuff is showing issues. Is there any way to have even stricter checks to make sure that the video will play right? I mean, they're SD, so I really don't mind that much if they have to play without DXVA, I'd just really like them to be detected automatically so I don't have to switch back and forth.

I'm using an ATI 4850 with the newest 10.6 Catalyst drivers. I had similar issues when I first tried DXVA a long time ago with MPC-HC and an older (though still ATI - could that be part of it?) video card, but had hoped the issues were worked out by now.

[magic144]

just to report - this bug seems to have been cured since I installed build 3507 - thank you again!!

Hmmm, whilst clsid's build 3498 seems to allow h.264 DXVA content to work, apparently VC-1 content (via DXVA ONLY) causes an app-crash due to libavcodec.dll... only just noticed this whilst trying to play BBC's LIFE disc!

again, non-DXVA seems to be unaffected here

build 3483 seems immune to this problem

[Guest]

Rather than issue rule 4 strikes I removed some posts and edited others. Let's remain civil please. Thanks!

[nevcairiel]

These are SD video encoded from DVD, so I really thought that there wouldn't be any problem.


ATIs DXVA implementation is buggy with SD content. MPC-HC for example has a flag in its DXVA codec to disable it for SD content. Not sure if ffdshow has the same.

[davidsama]

How do i get svn 3512 since it is not on the ffdshow download page?

[Shark007]

How do i get svn 3512 since it is not on the ffdshow download page?

mediafire.com by xhmikosr (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca95e79d7d0540e1e1)

[Midzuki]

Another, uh, "interesting finding". :p IF mpeg-2 decoder == ArcSoft, AND player == WMP 9, THEN the subpicture stream is sent to ffdshow video decoder :mad: , AND this latter refuses connecting to VMR9. :eek:

N.B.: Unticking the checkbox "DVD decoding" in ffdshow blocks *only* the video input pin, *not* the "generic" one. http://forum.videohelp.com/attachments/2671-1279232225/uglylol.gif

[davidsama]

What is the difference between the icl 10 and icl 11 versions of ffdshow?

[jhoff80]

ATIs DXVA implementation is buggy with SD content. MPC-HC for example has a flag in its DXVA codec to disable it for SD content. Not sure if ffdshow has the same.

Thanks for the info, maybe something like that is necessary in ffdshow if not already present.

[fitbrit]

I'm posting on behalf of JimH at jriver dotcom from the J. River Media Center people:
===========================
Thanks to jmone, who pointed us here.

Thanks to the devs for great software.

We may have found a minor problem. Our developer, Yaobing talked about it in this thread.

ffdshow and J. River Media Center bug (http://yabb.jriver.com/interact/index.php?topic=58624.msg396632#msg396632)
===========================
Could one of you wizards comment or check it out, please?
J. River Media Center is great software, and I'd love to be able to use ffdshow with it flawlessly. It and MPC-HC are the only playback programs I've allowed on my HTPCs for years. Thanks again.

[leeperry]

I see a lot of work on subs lately, but it still seems impossible to ignore SSA styles/colors? I use a DLP pj, white subs are a RBE feast...ah well, I've always been forced to convert to SRT...KMPlayer's built-in subs engine can ignore SSA styling FWIW, too bad mVR isn't compatible due to the lack of subs pin.
I really need all my subs to look like this: http://thumbnails14.imagebam.com/8879/4c45ab88782199.jpg (http://www.imagebam.com/image/4c45ab88782199)

[jmone]

I'm posting on behalf of JimH at jriver dotcom from the J. River Media Center people:
===========================
Thanks to jmone, who pointed us here.

Thanks to the devs for great software.

We may have found a minor problem. Our developer, Yaobing talked about it in this thread.

ffdshow and J. River Media Center bug (http://yabb.jriver.com/interact/index.php?topic=58624.msg396632#msg396632)
===========================
Could one of you wizards comment or check it out, please?
J. River Media Center is great software, and I'd love to be able to use ffdshow with it flawlessly. It and MPC-HC are the only playback programs I've allowed on my HTPCs for years. Thanks again.

Here are some technical details from Yaobing (a J.River Dev):


We look for IAMStreamSelect interface so we can let user pick which stream to play. Normally, this interface is exposed by a source filter or a splitter filter. Haali Media Splitter does it well. When we can not find the interface on the source filter, we go to the next filter, which often is a splitter filter. If that still fails, we try looking for the interface on any filter by enumeration. FFDShow could be found in either the second stage or the third stage. It tells us that it supports IAMStreamSelect, and returns a pointer to it. When we call the interface function IAMStreamSelect::Count(), FFDShow crashes.

I too am a big J.River MC fan and am trying to use FFDSHOW for all Video and Audio decoding.

Thanks
Nathan

[oddball]

I have an issue when trying to deinterlace MPEG2 DVD's with mixed progressive and interlaced. I have them muxed into either MKV or .TS. All is well if just plain progressive obviously. But when I have interlaced mixed in I have to tick deinterlace and tick 'Process frames flagged as progressive' which leads to ugly artifacts when not wanted. I have a problem PAL source that does not seem to flag up the interlaced portions so even if deinterlace is ticked it does not deinterlace it until I tick the 'Process frames flagged as progressive' option. I don't suppose there is any way around this (Other than to leave in vobs instead of remuxing)?

[shaolin95]

Simple question guys...what do I select for DTS (like libdts, etc) for best audio quality and any other setting you can think off?
I play my ripped Blurays, some have True HD but others are DTS HD. Either way I decode them with my computer and send the analog output to my Harman Kardon receiver since it does not decode HD formats.
Thanks for any tips to get the most out of the audio experience
Regards

[fitbrit]

Simple question guys...what do I select for DTS (like libdts, etc) for best audio quality and any other setting you can think off?
I play my ripped Blurays, some have True HD but others are DTS HD. Either way I decode them with my computer and send the analog output to my Harman Kardon receiver since it does not decode HD formats.
Thanks for any tips to get the most out of the audio experience
Regards

I don't know the answer to your best audio quality question. However, for the second part, I believe that ffdshow doesn't currently decode DTS-HD. Rather it just decodes the core regular DTS track and sends that via LPCM. How are you connected to your HK receiver? Is it via multiple RCA connections, SPDIF or LPCM-only HDMI? Only the multiple analog connections or the LPCM over HDMI will give you the HD sound for TrueHD. SPDIF cannot transmit more than 2 channel LPCM.

[Snowknight26]

Any word on the broken Fraps (bgr24) decoding?

[LigH]

ffdshow rev.3488 2010-06-28 SSE ICL11 (xvidvideo.ru), AMD Athlon64 X2 3800+, Windows XP SP3, GeForce 6800 GS

When playing a 1080i video (either with the ffdshow internal AVC decoder - or with DiAVC, post-processing its YV12 output) and scaling down to fit in a 1600x1200 desktop, adding Noise results in especially heavy noise from about 60% of the width in the right half, with increasing strength towards the right border.

Already happened months and years ago, but eventually I tracked it down to a rather reliably reproducable example.

ColorBars_1080i.png (http://www.ligh.de/pics/ColorBars_1080i.png) | PoP-SoT.png (http://www.ligh.de/pics/PoP-SoT.png) | ffdshow_noise.png (http://www.ligh.de/pics/ffdshow_noise.png)

[mark0077]

Hi, Noticed a problem with build 3488 and mpc-hc 2099, using ffdshow audio and video. The audio and subtitle stream details are appearing under the ffdshow decoder menu. See screenshow. Is this a bug in mpc or ffdshow?

http://img62.imageshack.us/img62/1923/ffdshowbug.th.jpg (http://img62.imageshack.us/i/ffdshowbug.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

This is with a blu-ray, michael jackson this is it, m2ts file.

[shaolin95]

I don't know the answer to your best audio quality question. However, for the second part, I believe that ffdshow doesn't currently decode DTS-HD. Rather it just decodes the core regular DTS track and sends that via LPCM. How are you connected to your HK receiver? Is it via multiple RCA connections, SPDIF or LPCM-only HDMI? Only the multiple analog connections or the LPCM over HDMI will give you the HD sound for TrueHD. SPDIF cannot transmit more than 2 channel LPCM.

Thanks, so do you think it uses the DTS one to decode that Core DTS thus using libdts or the other should be make a difference?

[leeperry]

The audio and subtitle stream details are appearing under the ffdshow decoder menu. See screenshow. Is this a bug
it's a feature http://forum-images.hardware.fr/images/perso/poussahpensif.gif

[mark0077]

Lol audio and no video info under video section..... Not good

[STaRGaZeR]

Time for some testing :)

I've made a build with the following changes:

- Revert to the old autosize formula (before r3427). The new one matches VSFilter, but only takes into account video height for the calculation. The subs will look smaller after you update, set your preferred font size again. Letterbox and subs+resize will work like before r3427.
- Added options for overriding ASS styling. They're in the font section. They have tooltips, should be easy to understand what they do.
- Edited an option in the placement section, it allows you to override ASS positioning. The \pos(x,y) tags are always honored, this is because if you put \pos tags it means you want that sub in a specific position, not in the generic one.
- Cosmetics.

Enabling everything in the ASS override section plus the ASS positioning override should make ASS subs look like SRT. If there are more important things to override just tell me about them.

Please test and report any findings, bugs, whatever before I commit it. It works for everything I've thrown at it, but as always there are crazy scripts and situations out there.

ICL11 build: http://www.mediafire.com/?z8o8182a3yuafub

[davidsama]

Stargazer that 3512 build shows only a grey screen in media player classic 107 with no video or audio in ripbot 1.16.0. It also only outputs a video file the same way.

[fitbrit]

Thanks, so do you think it uses the DTS one to decode that Core DTS thus using libdts or the other should be make a difference?

I'm afraid I don't know the answer to that. Now that I bitstream everything, I'm averse to playing with settings to test this out.

[dann23]

Time for some testing :)

I've made a build with the following changes:

- Revert to the old autosize formula (before r3427). The new one matches VSFilter, but only takes into account video height for the calculation. The subs will look smaller after you update, set your preferred font size again. Letterbox and subs+resize will work like before r3427.
- Added options for overriding ASS styling. They're in the font section. They have tooltips, should be easy to understand what they do.
- Edited an option in the placement section, it allows you to override ASS positioning. The \pos(x,y) tags are always honored, this is because if you put \pos tags it means you want that sub in a specific position, not in the generic one.
- Cosmetics.

Enabling everything in the ASS override section plus the ASS positioning override should make ASS subs look like SRT. If there are more important things to override just tell me about them.

Please test and report any findings, bugs, whatever before I commit it. It works for everything I've thrown at it, but as always there are crazy scripts and situations out there.

ICL11 build: http://www.mediafire.com/?z8o8182a3yuafub

finally. right now I didn't found any problems. but I have a request. Now if the movie has internal subtitles and there is also an external subtitle present, than the external subtitle has priority. Please add an option to enable the old behaviour.
Thank you.

[leeperry]

I've made a build with the following changes: [..]

- Added options for overriding ASS styling. They're in the font section. They have tooltips, should be easy to understand what they do.
very nice feature, thank you! just two things, if I may:

1)-ffdshow allows you to choose the smoothing method for BD/DVD, but not for text subs...this is a tad too blurry for CRT/DLP: http://thumbnails29.imagebam.com/8924/88466d89239314.jpg (http://www.imagebam.com/image/88466d89239314)
KMP has many smoothing/AA methods to overcome this problem: http://thumbnails32.imagebam.com/8925/06f2cf89241025.jpg (http://www.imagebam.com/image/06f2cf89241025)

It's like Cleartype(which is essentially a LCD-only technology) there's no "one-size-fits-all" smoothing method that will work equally well on CRT/DLP/LCD. Blurry subs look even blurrier when projected on a large screen using a DLP pj. And I'd guess that glossy or antiglare LCD screens might also benefit from different smoothing settings.

It'd be nice to have a "smoothing" slider, so you could choose between GDI-like and gaussian blurry to finetune it depending on your taste and the gear you use...like it's apparently possible for BD/DVD subpictures.

2)- It'd be nice to be able to force italic/bold/underlined subs, I personally like them yellow/italic w/ the thinnest shadow possible.
KMP also allows you to enable either of those 3: http://thumbnails26.imagebam.com/8925/9056e689242175.jpg (http://www.imagebam.com/image/9056e689242175)

I know it iritates ppl when I point out how things work in KMP, but its subs support is almost perfect. :thanks:

[Sebastiii]

Time for some testing :)

I've made a build with the following changes:

- Revert to the old autosize formula (before r3427). The new one matches VSFilter, but only takes into account video height for the calculation. The subs will look smaller after you update, set your preferred font size again. Letterbox and subs+resize will work like before r3427.
- Added options for overriding ASS styling. They're in the font section. They have tooltips, should be easy to understand what they do.
- Edited an option in the placement section, it allows you to override ASS positioning. The \pos(x,y) tags are always honored, this is because if you put \pos tags it means you want that sub in a specific position, not in the generic one.
- Cosmetics.

Enabling everything in the ASS override section plus the ASS positioning override should make ASS subs look like SRT. If there are more important things to override just tell me about them.

Please test and report any findings, bugs, whatever before I commit it. It works for everything I've thrown at it, but as always there are crazy scripts and situations out there.

ICL11 build: http://www.mediafire.com/?z8o8182a3yuafub

Cool, i'm happy to test this release :)
Thanks,
Seb.

[STaRGaZeR]

Stargazer that 3512 build shows only a grey screen in media player classic 107 with no video or audio in ripbot 1.16.0. It also only outputs a video file the same way.

I haven't done anything that would cause such behaviour.

finally. right now I didn't found any problems. but I have a request. Now if the movie has internal subtitles and there is also an external subtitle present, than the external subtitle has priority. Please add an option to enable the old behaviour.
Thank you.

Try with the option "Subtitle files" in the tray, dialog & paths tab. albain changed that, I've not used it yet so I'm not sure what it does. However it should be in the subtitles section and not there IMO.

very nice feature, thank you! just two things, if I may:

1)-ffdshow allows you to choose the smoothing method for BD/DVD, but not for text subs...this is a tad too blurry for CRT/DLP: http://thumbnails29.imagebam.com/8924/88466d89239314.jpg (http://www.imagebam.com/image/88466d89239314)
KMP has many smoothing/AA methods to overcome this problem: http://thumbnails32.imagebam.com/8925/06f2cf89241025.jpg (http://www.imagebam.com/image/06f2cf89241025)

It's like Cleartype(which is essentially a LCD-only technology) there's no "one-size-fits-all" smoothing method that will work equally well on CRT/DLP/LCD. Blurry subs look even blurrier when projected on a large screen using a DLP pj. And I'd guess that glossy or antiglare LCD screens might also benefit from different smoothing settings.

It'd be nice to have a "smoothing" slider, so you could choose between GDI-like and gaussian blurry to finetune it depending on your taste and the gear you use...like it's apparently possible for BD/DVD subpictures.

2)- It'd be nice to be able to force italic/bold/underlined subs, I personally like them yellow/italic w/ the thinnest shadow possible.
KMP also allows you to enable either of those 3: http://thumbnails26.imagebam.com/8925/9056e689242175.jpg (http://www.imagebam.com/image/9056e689242175)

I know it iritates ppl when I point out how things work in KMP, but its subs support is almost perfect. :thanks:

I also hate how blur is done in ffdshow, but I haven't looked at it yet. And I don't know if I have the skills to do proper AA. I want to AA the subs, not blur them to death like the option does now. In fact, with white body and black outline, with blur the white is not white anymore, and that sucks. I can't imagine how bad it looks in a DLP, which is a blurry mess.
I'll add options for italic and underline, bold is already present (weight).

[leeperry]

I also hate how blur is done in ffdshow, but I haven't looked at it yet. And I don't know if I have the skills to do proper AA. I want to AA the subs, not blur them to death like the option does now. In fact, with white body and black outline, with blur the white is not white anymore, and that sucks. I can't imagine how bad it looks in a DLP, which is a blurry mess.
I'll add options for italic and underline, bold is already present (weight).
OK, cool! well I'd prefer a GDI option over blurry AA tbh...I don't think DLP is blurry per se, my HC3100 definitely doesn't look blurry(the pic was shot by Kazuya on his own HC3100): http://img708.imageshack.us/img708/4649/dsc3484resize.jpg

nor does my trusty LG F900B CRT...it's just that Cleartype-like AA really doesn't work on those technologies. One thing's for sure antiglare coatings on LCD's do blur the picture to death: http://www.hoobie7.com/Computer%20Mod%20Stuff/DIYPJ/DIYPJ2.html

but it's essentially due to the fact that there's 3 sub-pixels one on top of the other w/ some heavy post-processing that Cleartype does improve clarity I think(6/8bit dithering yada yada)..anyway I'd prefer getting edgy GDI fonts than the blurry mess it currently is if any possible :o

When it's blurry, it's harder to read and fatiguing because your brain constantly tries to focus...in vain :devil:

[obieobieobie]

Is the libavcodec Nellymoser implementation messed up?

[magic144]

Hi STaRGaZeR
just tried your new build 3512

problem I have reported with h.264 .mkv with embedded VobSub (bitmap) subs still persists, though I don't think you've specifically addressed it anyway.
http://sourceforge.net/tracker/?func=detail&aid=2981790&group_id=173941&atid=867360

1) If nobody talks for a while (no subs), subs don't reappear when dialogue finally continues
2) Placement (Letterbox) option to scale/maintain subs to e.g. 16:9 (no matter what the video/canvas size) seems very hit and miss (mostly miss, and almost always miss with DXVA variant) - this is possibly the same bug as reported here:-
http://sourceforge.net/tracker/?func=detail&aid=3029078&group_id=173941&atid=867360

thanks for continuing to look into this (all devs who have contributed!)

[STaRGaZeR]

Hi STaRGaZeR
just tried your new build 3512

problem I have reported with h.264 .mkv with embedded VobSub (bitmap) subs still persists, though I don't think you've specifically addressed it anyway.
http://sourceforge.net/tracker/?func=detail&aid=2981790&group_id=173941&atid=867360

1) If nobody talks for a while (no subs), subs don't reappear when dialogue finally continues
2) Placement (Letterbox) option to scale/maintain subs to e.g. 16:9 (no matter what the video/canvas size) seems very hit and miss (mostly miss, and almost always miss with DXVA variant) - this is possibly the same bug as reported here:-
http://sourceforge.net/tracker/?func=detail&aid=3029078&group_id=173941&atid=867360

thanks for continuing to look into this (all devs who have contributed!)

About the VobSub bug, it's normal, I didn't touch anything and never will, I know nothing about the format.

2. The letterbox bug you reported is not a bug: you can't use letterbox with DXVA. Why? Because it involves resizing, and you can't resize anything if you use DXVA. If you really want this you'll have to use software decoding.
I suppose you do have problems with letterbox if you use it with software decoding when you say "mostly miss"?

[Gleb Egorych]

Zoom Player and ffdshow video decoder b3507: when rightclick on ffdshow tray icon popup menu does not show up. Works in MPC-HC.

[dimitrik]

Using RGB32 output (colorspace conversion) seems to result in video delay especially in more demanding decoding e.g. x264 HD.

The strange thing is that CPU use is not that high, (between 40-70% per core - Athlon II x3 3GHz). I've seen this in other high spec CPU's (esp. AMD) - video delay without excessively high CPU use.


Does anyone know the reason for this? Is the colorspace conversion code very slow, does it use some specific part of the CPU that's bottlenecked or what?

Is there any chance that future revisions would address it?

[magic144]

@STaRGaZeR

thanks for the response - I figured you hadn't touched that stuff - is that albain's domain, or is nobody really looking at VobSub format subs?

As for "mostly miss", probably more to do with the "disappearing" issue. Certainly, Letterbox scaling of subs was seen to be working on the software-only decoder. Too bad about DXVA, but I can understand why I guess.

It's a shame, VobSub subs are *so* easy to generate from their BluRay parents (and significantly smaller) using e.g. BDSup2Sub, and require no torture in performing error-prone OCR! i.e. it's a brain-dead, turn-the-handle process... I guess I still need VSFilter in my toolbox... for now :-)

Thanks,
m

[dann23]

Try with the option "Subtitle files" in the tray, dialog & paths tab. albain changed that, I've not used it yet so I'm not sure what it does. However it should be in the subtitles section and not there IMO.


That option disables external subtitles. So it's not usefull. What I'm saying is that I want some option to choose the priority of subtitles. Right now ffdshow uses external subtitles if present and then embeded subtitles. So if I have a movie with embedded subtitles and there are present some external subtitles in the same folder, then the external subtitle is used, not the embedded one. And for me is very annoying.

[Keiyakusha]

So if I have a movie with embedded subtitles and there are present some external subtitles in the same folder, then the external subtitle is used, not the embedded one. And for me is very annoying.

Why do you have external subs if you not using them? Maybe move them to another (sub)folder and the problem is solved.
However adding option probably not bad idea.

[STaRGaZeR]

@STaRGaZeR

thanks for the response - I figured you hadn't touched that stuff - is that albain's domain, or is nobody really looking at VobSub format subs?

As for "mostly miss", probably more to do with the "disappearing" issue. Certainly, Letterbox scaling of subs was seen to be working on the software-only decoder. Too bad about DXVA, but I can understand why I guess.

It's a shame, VobSub subs are *so* easy to generate from their BluRay parents (and significantly smaller) using e.g. BDSup2Sub, and require no torture in performing error-prone OCR! i.e. it's a brain-dead, turn-the-handle process... I guess I still need VSFilter in my toolbox... for now :-)

Thanks,
m

Dunno about VobSub, but albain is the PGS guru. If I were you I'll just mux the BD subs directly now that mkvtoolnix supports them.
And if you have problems with letterbox and software decoding, report them :)

That option disables external subtitles. So it's not usefull. What I'm saying is that I want some option to choose the priority of subtitles. Right now ffdshow uses external subtitles if present and then embeded subtitles. So if I have a movie with embedded subtitles and there are present some external subtitles in the same folder, then the external subtitle is used, not the embedded one. And for me is very annoying.

I understood what you said, but I though that option was there for selecting the priority between external and embedded subs. Until the option is implemented you can revert r3472 and compile your own builds.

[magic144]

thanks again STaRGaZer

I will report any bugs I find!

As for PGS, if I mux the original PGS subs in with a non 16:9 encode in an .mkv container, will they still render properly, or will they need 16:9 scaling enabling? Again, does this then mean that this option is out for DXVA rendering??

Reason I ask is that most h.264 encodes are based on cropped pictures (for encoding efficiency, so I understand), so they are often wider than 16:9, and if original 16:9 AR subs are rendered within this wider canvas, they will appear squashed - they would need to be rendered crossing into the 'black bars' to appear normal. Does ffdshow's PGS subtitle rendering take this into account (Software AND DXVA variants?)

Thanks,
m

[STaRGaZeR]

thanks again STaRGaZer

I will report any bugs I find!

As for PGS, if I mux the original PGS subs in with a non 16:9 encode in an .mkv container, will they still render properly, or will they need 16:9 scaling enabling? Again, does this then mean that this option is out for DXVA rendering??

Reason I ask is that most h.264 encodes are based on cropped pictures (for encoding efficiency, so I understand), so they are often wider than 16:9, and if original 16:9 AR subs are rendered within this wider canvas, they will appear squashed - they would need to be rendered crossing into the 'black bars' to appear normal. Does ffdshow's PGS subtitle rendering take this into account (Software AND DXVA variants?)

Thanks,
m

Dunno, I don't encode, my MKVs are remuxed from the BD, so everything is as it was on the disc. Just do a small sample and test it. I'd guess that you'll need it, PGS subs are images, in this case 1920x1080, so if you crop to 1920x800 I don't know what will happen. Always keep in mind that, unless you resize, ffdshow subtitle filter can only work with the original video. And you can't resize if you use DXVA.

BTW, Keiyakusha, I've fixed the issue you reported (in Anira-san - Bad Apple!! (Touhou)_4.ass). As I though ffdshow had a maximum subtitle length of 2000, insufficient for the lines of such script. They were getting truncated, with the subsequent visual effect. The other differencies are because of missing features in ffdshow, like \t and rotate.

[Keiyakusha]

STaRGaZeR
Oh nice, thanks! I'll try it. Yes, I already know about missing features but at least if other garbage is absent - this is good.

[STaRGaZeR]

STaRGaZeR
Oh nice, thanks! I'll try it. Yes, I already know about missing features but at least if other garbage is absent - this is good.

I'll post a build with it after some other fixes, it's not present in the r3512 build I uploaded earlier.

[Sebastiii]

Hi, it seems working pretty good :)

I have see a thing and i don't know if it's normal.
On SRT sub with tag color, if i set option in SSA/ASS config : colors & alpha -> no color anymore.
But for the rest it's work :)
I need to made more test lol,
Seb.

[STaRGaZeR]

Hi, it seems working pretty good :)

I have see a thing and i don't know if it's normal.
On SRT sub with tag color, if i set option in SSA/ASS config : colors & alpha -> no color anymore.
But for the rest it's work :)
I need to made more test lol,
Seb.

I suppose no color means white, so yes, it's normal, that's the purpose of the option :p. If you check the "Colors & alpha" setting, any colors (caused by tags, styles, whatever) will be ignored and the ones set in the "Size, colors & alpha" section will be used instead. If you haven't changed them, the default one for the body is white.

Another build, this one includes:

- Fixes to the override SSA/ASS position option.
- Increase the maximum allowed length of the subtitle lines.
- Add italic and underline options to the GUI, for both OSD and subtitles. They're also applied to SSA/ASS subs if he option "Font style" is set.

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

[leeperry]

Another build, this one includes:

- Fixes to the override SSA/ASS position option.
- Increase the maximum allowed length of the subtitle lines.
- Add italic and underline options to the GUI, for both OSD and subtitles. They're also applied to SSA/ASS subs if he option "Font style" is set.
works perfectly on ASS :thanks:

http://thumbnails13.imagebam.com/8952/17058789519345.jpg (http://www.imagebam.com/image/17058789519345)

now if you could please allow to completely disable blurring as previously discussed, that'd be beyond words! no blurring/AA whatsoever would be really great, and hopefully this would be easier for you to implement than a variable "blur" slider.

[STaRGaZeR]

now if you could please allow to completely disable blurring as previously discussed, that'd be beyond words! no blurring/AA whatsoever would be really great, and hopefully this would be easier for you to implement than a variable "blur" slider.

Unchecking the "Blur" setting does exactly that.

[leeperry]

Hah, indeed! it's even blurrier if I check this option. I guess this is as sharp as it can get? fonts were much more edgy in KMP, I'll try to post a screenshot using HR.

My screenshot above had it disabled, and it still looks quite blurry to my eyes :o

[Sebastiii]

I suppose no color means white, so yes, it's normal, that's the purpose of the option :p. If you check the "Colors & alpha" setting, any colors (caused by tags, styles, whatever) will be ignored and the ones set in the "Size, colors & alpha" section will be used instead. If you haven't changed them, the default one for the body is white.

Another build, this one includes:

- Fixes to the override SSA/ASS position option.
- Increase the maximum allowed length of the subtitle lines.
- Add italic and underline options to the GUI, for both OSD and subtitles. They're also applied to SSA/ASS subs if he option "Font style" is set.

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

Thank you again for explanation :)
So it's perfect :)
Seb.

[Keiyakusha]

Another build, this one includes:

- Fixes to the override SSA/ASS position option.
- Increase the maximum allowed length of the subtitle lines.
- Add italic and underline options to the GUI, for both OSD and subtitles. They're also applied to SSA/ASS subs if he option "Font style" is set.

http://www.mediafire.com/?eolh8hll74g8ej6
Nice! However this text (http://imgur.com/IdlCr.png) which meant to be vertical... Maybe it is possible to move it somewhere away until it will be supported? :Р

leeperry
But you probably also want to compare with vsfilter because some other players (VLC I guess, don't remember...) also producing sharper subs but only vsfilter is a standard de facto.
EDIT: oops, now after STaRGaZeR's post I see that we probably talking about different things...


By the way, just now I noticed that VP8 decoder was added. This is a port from ffmpeg, isn't it? So can we expect AAC decoder?

[STaRGaZeR]

Hah, indeed! it's even blurrier if I check this option. I guess this is as sharp as it can get? fonts were much more edgy in KMP, I'll try to post a screenshot using HR.

My screenshot above had it disabled, and it still looks quite blurry to my eyes :o

That "blur" is because you're probably using YV12 as output or another chroma subsampled format. ffdshow creates an halo around the edges, dunno why. You can see it in your SS, yellow halo all over the place. Use RGB and you'll see it disappear, in fact subs look a lot better when RGB is used.

Nice! However this text (http://imgur.com/IdlCr.png) which meant to be vertical... Maybe it is possible to move it somewhere away until it will be supported? :Р

Short answer, no. Patches are welcome though :D

BTW, do you know if there's something like an "official" ASS specification?

[leeperry]

That "blur" is because you're probably using YV12 as output or another chroma subsampled format. ffdshow creates an halo around the edges, dunno why. You can see it in your SS, yellow halo all over the place. Use RGB and you'll see it disappear, in fact subs look a lot better when RGB is used.
good point, I do output YV12 to madVR.

anyway, here's a roundup of what I'm seeing(KMP using HR in RGB32HQ, and ffdshow using mVR in YV12).
that's KMP w/ GDI fonts and no AA whatsoever: http://thumbnails28.imagebam.com/8954/0b866889537940.jpg (http://www.imagebam.com/image/0b866889537940)http://thumbnails33.imagebam.com/8954/28990089537941.jpg (http://www.imagebam.com/image/28990089537941)http://thumbnails26.imagebam.com/8954/5e5c3989537938.jpg (http://www.imagebam.com/image/5e5c3989537938)

that's my favorite config tbh...my eyes don't search for inexistent edges, it prolly looks like **** on LCD.

KMP w/ GDI fonts + 2X AA: http://thumbnails15.imagebam.com/8954/6fdc3089537946.jpg (http://www.imagebam.com/image/6fdc3089537946)http://thumbnails32.imagebam.com/8954/ece6a189537944.jpg (http://www.imagebam.com/image/ece6a189537944)
KMP w/ GDI fonts + 3X AA: http://thumbnails9.imagebam.com/8954/e81b1c89537949.jpg (http://www.imagebam.com/image/e81b1c89537949)http://thumbnails27.imagebam.com/8954/ebba0689537948.jpg (http://www.imagebam.com/image/ebba0689537948)
KMP w/ rasterized fonts(can't add shadow for some reason, and I captured the wrong sub): http://thumbnails32.imagebam.com/8954/8a52d189537953.jpg (http://www.imagebam.com/image/8a52d189537953)http://thumbnails21.imagebam.com/8954/bcc0ec89537951.jpg (http://www.imagebam.com/image/bcc0ec89537951)

and now, the closest I seem to able to get to in your latest ffdshow beta: http://thumbnails32.imagebam.com/8954/effd9489537955.jpg (http://www.imagebam.com/image/effd9489537955)

first thing, the damn thing's not yellow anymore?!?! I'm colorblind on yellow/light green but figures don't lie...I ask for http://thumbnails30.imagebam.com/8954/3d928789537958.jpg (http://www.imagebam.com/image/3d928789537958) and I get http://thumbnails33.imagebam.com/8954/67b5f489537960.jpg (http://www.imagebam.com/image/67b5f489537960)

and there's some obvious AA being processed if you zoom up the picture...plus that nasty halo you're mentioning. good thing I hardly ever need subs :p

[hoborg]

Hi.

There is CTRL+ALT+O to show/hide OSD for FFDShow video decoder, but how can i show/hide OSD for Audio decoder from keyboard?
Keys&Remote is missing in FFDshow Audio decoder. Can it be added?

Thanks for all your work on FFDShow!

HOBORG

[Shinobu Maehara]

Since the old forum isn't being watched any more, I decided copy this two-message thread, since in all likelihood it just gathered dust there:
This setting appeared more than a year ago, and after a lot of testing, I absolutely recommend to uncheck it for smoother video playback. It really makes a difference, especially when CPU is not powerful enough to decode a video in real time. When disabled, the decoder instead of dropping frames, decodes as fast as possible, leading to audio desynchronization, but allowing to watch the video instead of what would be a kind of slideshow.
You can find this setting here:
ffdshow video decoder configuration > Decoder options > Drop frame on delayUnfortunately that makes dialogue impossible to follow as the lag slowly but surely accumulates. What I've found to sometimes help is setting it to some ridiculously high value, like 1 or 2 seconds.
But the basic problem is probably that it isn't implemented right. For example, when I set it to some really low value, it starts dropping frames like crazy, while the CPU load remains relatively low. So I have a hunch that the decoder instead of going straight to the next frame, waits for the next frame.
Now, as long as you're pumping out frames fast enough, waiting for the next frame makes sense. But if you're dropping frames that means you're running behind.
Of course, my diagnosis could be wrong, but if it isn't waiting, then we wouldn't expect this setting to affect the fps as much as it does. Maybe there is still another explanation, but I haven't thought of one. Perhaps it would be useful as a diagnostic to add two metrics to the OSD overlay, namely a dropped frames percentage and a time spent waiting percentage.

[dann23]

@STaRGaZeR
do you have a place where you upload nightly builds for ffdshow?

[doc_dvxm]

Hii there...

I am encoding HD movies. One week a go I was migrated to my new encoding machine. Specs are: Win 7 x64 Ultimate, i7 930 OC'ed to 3.6 Ghz, 6 Gb RAM, ATI HD5850 - Lastest Catalyst - MPC-HC x86, EVR Sync.

On my previous machine (Quad Core Q9850, 4 Gb RAM on Win 7 32 Bit Ult) I was so happy with K Lite Codec ver 6.0.0.

After migrating, I have too much codec problems. When with video everythng is fine, there is nothing heared from audio files integrated and/or not to mkv's. When I hear audio, video isn't presented. As a player, I am using MPC-HC. I've tried too many codecs, reinstalling the system 3 times.



When I select the ffdshow audio decoders as a prefered audio decoders, my system going to freez 3 sec after clicking to any audio files.

If I select from Codec package settings as a audio decoder AC3 filter, not ffdshow audio decoders, my system going to freeze again...

When I select AC3 filter from MPC-HC, it freezes again.

I've tried to install separated packages like ffdshow_rev3476_20100615_clsid_x64, ffdshow_rev3507_20100707_clsid_x64 + Later Matroska Splitter + MPC-HomeCinema.1.3.1249.0.(x64) and to run MeGUI x64 + Avisynth 64 bit. But result was only big crash - Video was full with blocking areas + no audio hearing. Also system going to freeze after clicking separated or integrated to mkv audio files.

I've tried also external player (like BSPlayer 2.5 Pro) + K Lite Codec 32/64 bit. But results were similair.

At the end, I decide that the most stable codec on my system is K Lite Mega Codec 5.9 Full (32 bit). I am running MeGUI + Avisynth 32 bit for now.
***On video configuration, I am setting ffmpeg-mt or libavcodec for H264, libavcodec for XviD, libmpeg2 for MPEG-2 and libavcodec for VC1 as video decoder.
***On audio configuration DTS - libdts, ac3 - liba52, mp3 - libmad.
***On MPC-HC Settings: ffdshow (dxva) for H264, ffdshow for VC-1, ffdshow for XviD & MPEG-2.
I've installed the .Net Framework 4.0 and Visual C++ 2010 64 bit.
When I click to any dts or ac3 audio file, my system going to blue screen (BSOD's) or freeze and don't responding to nothing except pushing 5 sec on On/Off button.

But there is no audio!

@stargazer, which codec package do you use? And which directx version do you use - 9 or 11?

What Can I do? All suggestions are wellcome.

[Konrad Klar]

@doc_dvxm

No codec (and in general no user mode program) can cause BSOD.
BSOD is symptom of error in kernel. So part of kernel (e.g. driver) is guilty, or its bottom layer (i.e. hardware; maybe incorrectly overclocked CPU) is guilty.
Applications (and any user mode component - that includes codecs) can only trigger BSOD by using erratic driver or hardware, but applications are never root cause of BSOD.

[doc_dvxm]

@doc_dvxm

No codec (and in general no user mode program) can cause BSOD.
BSOD is symptom of error in kernel. So part of kernel (e.g. driver) is guilty, or its bottom layer (i.e. hardware; maybe incorrectly overclocked CPU) is guilty.
Applications (and any user mode component - that includes codecs) can only trigger BSOD by using erratic driver or hardware, but applications are never root cause of BSOD.


Ok then... But why BSOD's appears when I am clicking on any AC3 or DTS files? Maybe you are right, but my machine working with 100% CPU load during encoding process ~ 28-30 hours per movie... Why BSOD's don't appears at this time? I'm going crazy... :devil:

I'll look for the updates of my graphic & mainboard drivers. After updating I'll look again...

[Konrad Klar]

@doc_dvxm

If you can preclude hardware as source of problem, then only other possibility is fault in kernel component. And it is only sure thing in this.
You did not specified your audio hardware.
.NET Framework does not contain kernel components.

[netwolf]

@doc_dvxm: sound card driver also sounds like a usual suspect in this case.

[doc_dvxm]

My mainboard is GIGABYTE GA-X58A-UD3R. On board Audio card is Realtek High Definition Audio, I guess. You are right I think. I'll update all drivers... I've installed previous drivers from the Manifacturers CD. If you say that my problem isn't user installed software, then I'll update my drivers to the latest versions....

Really appreciated. I'll post results soon.

Thanx Guys for your attention..

[Mixer73]

My mainboard is GIGABYTE GA-X58A-UD3R. On board Audio card is Realtek High Definition Audio, I guess. You are right I think. I'll update all drivers... I've installed previous drivers from the Manifacturers CD. If you say that my problem isn't user installed software, then I'll update my drivers to the latest versions....

I don't trust manfucturer CD as they are pretty old. is the BSOD number 124?

[oddball]

EDIT: Ignore. Was an issue with MPC HC.

[doc_dvxm]

I don't trust manfucturer CD as they are pretty old. is the BSOD number 124?

After updating of the mainboard drivers to the latest ones, I set my codecs according to the guides given HERE (http://forum.doom9.org/showthread.php?p=1349575#post1349575) and HERE (http://dbone1026.blogspot.com/2009/10/setting-up-codecs-for-7mc.html?success)

Now installed codecs & softwares are:
1. ffdshow_rev3488_20100628
2. MPC-Standalone Filters.1.3.1249.0.(x86)
3. MatroskaSplitter20052010
4. mpc-homecinema.1.3.2099.0.x86
5. Win7DSFilterTweaker_3.2
6. Graphstudio.

Now everythings looks fine. m2ts video files with VC-1 & AVC video tracks + TrueHD or DTS HD-MA audio streams playing fine.
MKV HD movies with DTS Audio tracks play fine...

Thanx to all of you guys for your hard work and for your attention. Now I can go to sleep :)

[Atak_Snajpera]

@clsid
Possible bug in AVC decoder (libavcodec and ffmpeg-mt)
http://img20.imageshack.us/img20/7715/1080isourcetssnapshot00.th.png (http://img20.imageshack.us/i/1080isourcetssnapshot00.png/)

sample: http://www.mediafire.com/?jlz64ah2vwkw19s

FFDshow r3507 (libavcodec/ffmpeg-mt) + Haali media splitter + MPC-HC (all filters disabled) = corrupted frame
FFDshow r3507 (DVXA acceleration enabled) + Haali media splitter + MPC-HC (all filters disabled) = no corruption!

[hwti]

I have a freeze with a corrupted H264 TS file :
ffdshow tryouts r3507 ffmpeg-mt NOK (with Haali Media Splitter, playing using MPC-HC, or Avisynth DirectShowSource)
ffdshow tryouts r3507 libavcodec OK (recovers after errors)
MPC-HC 1.3.2099 internal decoder OK (recovers after errors)

sample : http://www.mediafire.com/?6901m6x602d3276

[SamuriHL]

I think I may have seen this reported before but I'm not positive. After I've converted a ts (h.264/ac3) file to mkv using various methods, the resulting file has a green bar at the top when played using ffdshow dxva. Anyone know anything about this or have seen this issue at all? It plays the ts file fine. I've tried 3 different splitters with the same results. And I've created the MKV different ways. The MKV plays fine in VLC, as well.

MKV:


General
Complete name : C:\Users\Samuri\Videos\TrueBlood(6).720p.mkv
Format : Matroska
File size : 1.36 GiB
Duration : 57mn 53s
Overall bit rate : 3 364 Kbps
Encoded date : UTC 2010-07-27 01:46:14
Writing application : gdsmux
Writing library : Haali DirectShow Matroska Muxer 1.10.175.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 57mn 53s
Bit rate : 2 913 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.105
Stream size : 1.18 GiB (87%)
Title : PID 4113
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 57mn 53s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Video delay : 33ms
Stream size : 159 MiB (11%)
Title : PID 4352
Language : English


TS:


General
ID : 1
Complete name : C:\Users\Samuri\Videos\TrueBlood(6).720p.ts
Format : MPEG-TS
File size : 1.56 GiB
Duration : 57mn 54s
Overall bit rate : 3 852 Kbps

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 : 3 frames
Duration : 57mn 53s
Bit rate mode : Constant
Bit rate : 3 300 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.119
Stream size : 1.32 GiB (85%)
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Duration : 57mn 53s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Video delay : 33ms
Stream size : 159 MiB (10%)
Language : English


Thanks!!

[oddball]

Can anyone tell me how to get better IVTC? I use ffdshow for upscaling DVD MPEG2. However I sometimes get interlaced mixed with progressive sources but if I tick deinterlace I get so many artifacts it's not nice to watch. Even using Yadif which is meant to be the best. Animation is especially worse where fine lines looks like that are drawn with a graphite pencil (Missing bits of information between the lines). I would try DScaler5 with IVTC mod but I don't think there is a way to use it with ffdshow processing/resizing etc?

Basically for anything that is 29.97 with interlace, 3:2 pulldown or 23.976 with interlace ffdshow is not cutting it for me. Oh I also tried just using IVTC Avisynth in ffdshow but even on my OC'd E6600 it was too slow.

BTW could DScaler5 with IVTC mod not be integrated into ffdshow as one of the codec options? Or does their license not allow such a thing?

[roozhou]

@oddball
ffdshow does not have a plugin system. The only way to write a filter for ffdshow is to create a DScaler filter plug-in. Sadly it only supports YUY2 and allows neither adding/removing frames nor lookahead.

@ffdshow devs
Why not add an ivtc filter to ffdshow's filter system? A software adaptive IVTC filter is easier to implement compared to a deinterlacer. Look at ivtc and pullup filter in MPlayer. They work on most of telecined content and run very fast.

[oddball]

@oddball
ffdshow does not have a plugin system. The only way to write a filter for ffdshow is to create a DScaler filter plug-in. Sadly it only supports YUY2 and allows neither adding/removing frames nor lookahead.

@ffdshow devs
Why not add an ivtc filter to ffdshow's filter system? A software adaptive IVTC filter is easier to implement compared to a deinterlacer. Look at ivtc and pullup filter in MPlayer. They work on most of telecined content and run very fast.

Thanks. I am glad to read someone else agrees with me on this. :)

Devs any chance of putting it on your todo list?

[Mixer73]

Here's an interesting one, I just use FFDShow for decoding and processing my xvid files, now I recently upgraded to an I7-965 so I thought I could crank up my processing and make it even better.

Yesterday I had a build around 2800 odd and I found I was able to run my filters with no problems at all,

Running XviD codec, Blur/NR Soften 10, Denoise 3D luma 4, chroma 3, time 6, I was comfortably able to use Post Processing - SPP Deblocking/Soft threshold without any dropped frames, and I was encoding in another window so it was doing it pretty easy.

Fast forward today and I thought I'd upgrade to 3476 and it seems to drop about 1/4 of the frames with the same config, tried libavcodec as well as xvid codec, but I have to drop back to Fast SPP Deblocking...

Any suggestions? Is it right that the performance of this has gone away this much? I kinda find it hard to believe...

[doc_dvxm]

Any suggestions? Is it right that the performance of this has gone away this much? I kinda find it hard to believe...

Maybe, with these encoding speeds, something's going wrong... Who know?

I have same problems with fffdshow 3507, 3576 + various 34.. revisions.

@Mixer73,
Please try older versions of FFDShow. Yesterday after too many tryouts, I've switched to K Lite 5.9 Full - there is ffdshow rev 3156, I guess - now everything is fine...

Btw, is it possible that the source of this problem is Haali Splitter instead of ffdshow's ffmpeg-mt & libavcodecs?

[Mixer73]

Btw, is it possible that the source of this problem is Haali Splitter instead of ffdshow's ffmpeg-mt & libavcodecs?

My problem is with simple AVI files so no Haali splitter here.

System seems to want to drop about 10 frames every 100 or so all in one block, and isn't using any more than about 10% of my CPU. Something funny going on.

[stumped]

i was just wondering if anyone has gotten the highdef audio files working on the new hm55 intel IGP and new intel hd audio codec with hdmi? I'm looking at upgrading my laptop to this and would like ot know this owkrs before the upgrade. Thanks!

[Keiyakusha]

"report this exe anonymously" seems not to be working if you don't have IE installed.
Anyway please add potplayer to the whitelist.

[nevcairiel]

i was just wondering if anyone has gotten the highdef audio files working on the new hm55 intel IGP and new intel hd audio codec with hdmi? I'm looking at upgrading my laptop to this and would like ot know this owkrs before the upgrade. Thanks!

Assuming you mean bitstreaming..
It at least works on the desktop H55 boards with an i3 or i5 CPU, so i would hope it also works on Laptops. It might cause problems if your laptop has a hybrid GPU (like, coupled with an nvidia or ATI for better performance)

[fastplayer]

"report this exe anonymously" seems not to be working if you don't have IE installed.
Anyway please add potplayer to the whitelist.
When I implemented that feature, it was a safe bet that IE was installed in 10 out of 10 cases. Things have changed with Win7, obviously...
Unfortunately, there's no object model - at least one that I know of - that allows me to start the system's default web browser via VBScript and configure it to my liking.

[tetsuo55]

Ati Catalyst 10.7 lists support for VLC DXVA in the changelog.

Technically ATI improved the performance of the dxva2 memory->memory copy operation. This change should be very visable in ffdshow and open up posibilities for more post-processing.

[rpm7200]

libavcodec can't decode dts from dts ma. why not?

[Sebastiii]

Ati Catalyst 10.7 lists support for VLC DXVA in the changelog.

Technically ATI improved the performance of the dxva2 memory->memory copy operation. This change should be very visable in ffdshow and open up posibilities for more post-processing.

Great news :)
Seb.

[oddball]

I have a problem with auto profile loading. I can get them to load for DVD upscaling using the dimensions 720 x 480 and 720 x 576 on some files but a couple of divx .avi files it ignores them. These have a different resolution of 656x256 and 672x400 respectively. I have lots of other files with different resolutions that are still classed as standard definition.

How do I get ffdshow to auto load profiles for these odd resolutions that do not match the usual 720x criteria? Or is this some bug with divx in .avi and it should be working?

[hwti]

Ati Catalyst 10.7 lists support for VLC DXVA in the changelog.

Technically ATI improved the performance of the dxva2 memory->memory copy operation. This change should be very visable in ffdshow and open up posibilities for more post-processing.

It seems some changes were needed in VLC too :
http://git.videolan.org/?p=vlc.git;a=commit;h=10e9ceafd19c1a77ab23e775563233b2b26ca20a

I assume it's not done in ffdshow.

Is there a way to enable postprocessing ? I see only "surface overlay" as preprocessing, which is quite limited.

I suppose the DXVA decoder will only connect to a DXVA compliant renderer. Can we get the decoded video, for example to use in Avisynth ? I think we would need a second output pin.

[nevcairiel]

You can't do full post-processing with a DXVA decoder. Technical limitations. Once its in the GPU, you can't get it out again :d

[stumped]

Assuming you mean bitstreaming..
It at least works on the desktop H55 boards with an i3 or i5 CPU, so i would hope it also works on Laptops. It might cause problems if your laptop has a hybrid GPU (like, coupled with an nvidia or ATI for better performance)

thank you for the answer. Helps me make sure that when i get a laptop i get the right combo for what i'm trying to do.

[oddball]

Any help on getting profiles to load based on resolution = >720P?

[Keiyakusha]

oddball
As for me, it doesn't very clear what is your problem... set 720 height in left box and in right leave 2048

[oddball]

oddball
As for me, it doesn't very clear what is your problem... set 720 height in left box and in right leave 2048

Tried that. The profile does not auto load for the 672x400 video.

[Keiyakusha]

Tried that. The profile does not auto load for the 672x400 video.

Of course. It shouldn't. What you requested is for 1280x720 and higher. Then set 1px in left box and 720 in right. EDIT: also you probably can set width to 1 left and 1280 right and switch mode to "and"

[hoborg]

Hi.
Is there a plan to add DVB Subtitles support (decoding) in to FFDshow?

[soulkeeper]

any suggestions on what settings to use in ffdshow in order to get the below black and whiter than white information passed to my projector and then calibrate accordingly with a calibration disc to video levels?
I've tried many many combinations of settings in ffdshow(levels,input/output variations in rgb conversion tab with no luck..)...
Whenever i used ffdshow,either as a decoder or for post processing, i never managed to do it...Also,i realized that when ffdshow is active ,CCC settings(br./contrast) and rendering settings output in mpc-hc don't have any effect on the video playing...

I'm using ati 5670 with 10.7,mpc-hc rev.2099 with evr custom,ati pixel output format :full rgb,enable dynamic contrast in CCC disabled and HQ YV12->rgb conversion selected and rgb 32 selected output in ffdshow..
Thanks!

[kurkosdr]

Hi there, here is another question:

I just noticed ffmpeg has a -sameq switch, which according to their documentation (http://ffmpeg.org/ffmpeg-doc.html#SEC6), provides same video quality as source (their words not mine).

How is this possible on lossy formats like mpeg 2 and mpeg 4 asp? Does this mean I can get lossless conversion to mpeg 4 asp just by using the -sameq switch on ffmpeg?

If lossless is not the case, then what exactly "-sameq" means?

PS: I am asking here because you guys have the tryouts project, so you may know ffmpeg.

[Mr VacBob]

It copies qps from the source to the destination. I don't remember how well it works.

[dann23]

what happend to ff_acm.acm? is it usable with virtualdub?

[hoborg]

Hi.
Just noticed that HD MPEG-2 decoding is preaty slow comparing to Gabest/PDVD MPEG-2 decoders.

For example this 1080i MPEG-2sample (http://hobring.esero.net/saf/samples/mpeg-2+ac3.zip) is unplayable here on Intel Atom CPU using FFDShow (all postprocessing is turned off). Nearly 3/4 frames are droped.
If i play this sample using Gabest/PDVD10 decoder, it will play perfectly, no droped frames.

Using "MPC - Mpeg Source (Gabest)" as a splitter.

EDIT:
I am comparing software decoding only, DXVA is in PDVD is turned off.

This only happend if "set interlace flag in output media type" is on in FFDShow. Source is interlaced and i want to GPU do deinterlacing So maybe this is GPU problem? I have only crapy "Intel(R) 82945G" GPU here...

Here is graph: (droped frames)
http://hobring.esero.net/saf/samples/1080_ffdshow.png

[Mercury_22]

Weird, I always got a crash with some specific files with AC3 audio and only with the ICL11 ffdshow builds; generic builds are fine for me. With the debug ffdshow builds I get no crash. I still haven't found the cause.

Same here but with the x64 version in WMC (x64) which made me to stop using FFD
It will be nice if someone can fix this (AC3Filter x64 it's working fine)

[littleD]

Hi.
Just noticed that HD MPEG-2 decoding is preaty slow comparing to Gabest/PDVD MPEG-2 decoders.

For example this 1080i MPEG-2sample (http://hobring.esero.net/saf/samples/mpeg-2+ac3.zip) is unplayable here on Intel Atom CPU using FFDShow (all postprocessing is turned off). Nearly 1/2 frames are droped.
If i play this sample using Gabest/PDVD10 decoder, it will play perfectly, no droped frames...

Using "MPC - Mpeg Source (Gabest)" as a splitter.

Do you compare here dxva with cpu decoding? Because ffdshow might be pretty fast.

[hoborg]

Do you compare here dxva with cpu decoding? Because ffdshow might be pretty fast.

No, only software decoding of course (DXVA in PDVD is off).

[nevcairiel]

Are you using libmpeg2 or libavcodec in ffdshow?
Whichever you are using, try the other one. :)

[hoborg]

Are you using libmpeg2 or libavcodec in ffdshow?
Whichever you are using, try the other one. :)

Hi.
Already tryed - no diference.

EDIT
I think if there is problem in FFDshow it is in output not in decoder...

[littleD]

Hi.
Already tryed - no diference.

EDIT
I think if there is problem in FFDshow it is in output not in decoder...

Does video is deinterlaced using Cyberlink? If so, ffdshow could use gpu too. Try specific colorspace along with "set interlace flag in output media type".

[hoborg]

Does video is deinterlaced using Cyberlink? If so, ffdshow could use gpu too. Try specific colorspace along with "set interlace flag in output media type".

Yes, Cyberlink deinterlace always, but very badly (blury) if DXVA is off - like on second picture:
http://hobring.esero.net/saf/deinterlacing.jpg
Both Cyberlink and FFDshow using YUY2 output. YUY2 needs to be used, becouse picture is not deinterlaced at all if other colospaces are in use, NV12 is not supported by Intel GPU i have here (Graphstudio will crash).

[littleD]

Then drivers may be the cause. Does your chipset support VA deinterlacing at all? Try dxvachecker and show processor device tab.

[hoborg]

Then drivers may be the cause. Does your chipset support VA deinterlacing at all? Try dxvachecker and show processor device tab.

http://hobring.esero.net/saf/dxva_checker/dxva_checker_i945g0.png

I investigate the source of droped frames becouse acording some info i have, nvidia 9400 have similar problem - droped frames when playback FullHD MPEG-2 recordings/LiveTV.

There is no such problems on ATI 4550, 5450 or 5770.

[littleD]

You see now. Crappy intel cant any advanced deinterlacing for 1080. Some pixeladaptive, but only for DVD's. Not VA at all. Still have some hidden info under yuy2, but i wouldnt have any hope.
Ati 4550 is just enough For HDTV. I would recommend that card. 9400 has too low memory bandwidth for Full HD deinterlacing. You need at least 10 GB/s.

Edit. Hmm actually pixel adaptive may refer to vector adaptive, but if at all, its only for dvd resolution anyway.

[Porsche_fan]

Is there a current known issue with ffdshow resize crashing in Windows 7 x64? I tried my best to search the thread but there doesn’t seem to be a report of such.

I recently bought a HP with Windows 7 x64, i7 860 processor and nVidia 315 graphics card. I am using it as a HTPC connected to a plasma TV through a 1.4 compliant HDMI cable.

I have a 3 week trial period which ends today and during the last 3 weeks I have been struggling trying to resolve an infrequently occurring playback issue where the computer suddenly will display a black screen and stop responding.

It usually happens when I take some kind of action like display the time remaining on the autohide control bar but will often happen without anything being touched. Because it is so sporadic, it is hard to narrow down but I believe it may be related to the ffdshow resize filter.

I am using 32 bit MPC-HC in EVR-Custom with the following filters…Resize->Sharpen->Noise. I am also outputting RGB32 although I see the same error with YV12.

I have tried every combination I can think of including different renderers EVR, EVR-C and madVR. I have also tried a variety of ffdshow versions, including some rather old to the latest in both generic and icl10. It occurs both when ffdshow is decoding and in raw video only. Additionally, I have tried the 64 bit versions of MPC-HC and ffdshow.

Also tried installing nVidia’s drivers off their site but it failed to recognize the card. Finally, I have disabled all startup programs other than Windows services to rule out conflicts with other programs.

I’ve basically exhausted every option I can think of and as mentioned need to decide today if I want to return it. So any information or suggestions would be greatly welcomed.

[ranpha]

Is there a current known issue with ffdshow resize crashing in Windows 7 x64? I tried my best to search the thread but there doesn’t seem to be a report of such.



Start MPC-HC in Windows XP SP2 (not SP3) compatibility mode and see if your crashing problems can be reduced or not.

[leeperry]

I guess there really isn't any solution to the automatic profile problem when using 5.1 AC3 files tagged as stereo? It never loads the 5.1 profile, duh.

here's a sample: http://forum.doom9.org/showpost.php?p=1386984&postcount=11208

I could also use AC3Filter, but the "number of channel" condition doesn't work w/ it(duh again): http://sourceforge.net/tracker/index.php?func=detail&aid=2725991&group_id=173941&atid=867360

ah well, I can always force it manually...it's just annoying.

[Octo-puss]

What do I do to make subtitles muxed into a .mkv show up? I started experimenting with madVR renderer which doesn's support subtitles yet. Using MPC-HC as a player. Thanks for tips.
(in video decoder settings, checking subtitles didn't do anything)

[fastplayer]

@Stargazer

Regarding rev 3523:
Can you make the audio codec names for the tool tip uppercase?

[STaRGaZeR]

@Stargazer

Regarding rev 3523:
Can you make the audio codec names for the tool tip uppercase?

What tooltip?

[fastplayer]

What tooltip?
Then one you see when you move the mouse over the ffdshow audio tray icon. In rev 3523 you've made changes to the appearance of it, didn't you?

[leeperry]

talking about UI, I'd like to do bicubic 0.0 chroma resizing...but it simply isn't possible atm: http://thumbnails29.imagebam.com/9166/4c1dca91659501.jpg (http://www.imagebam.com/image/4c1dca91659501)

if I set "resizeBicubicChromaParam" to "0", it falls back to default...is the default "0.0"?

and when I suggested to add AR presets to Haruhiko, I should have said 2.39 (http://en.wikipedia.org/wiki/Anamorphic_format#2.35.2C_2.39.2C_or_2.40.3F) instead of 2.40 for unmolested cinemascope movies. It would also be nice if it were possible to maybe keep the right mouse button pushed when setting a custom AR to make it much slower and being able to reach ANY figure, w/o resorting to typing them in.

[STaRGaZeR]

Then one you see when you move the mouse over the ffdshow audio tray icon. In rev 3523 you've made changes to the appearance of it, didn't you?

When you see it lowercase, are you using liba52 or libdts? If that's the case don't worry, I forgot about them. Will change them in my next commit.

And yup, but that string appears in the Info&CPU tab and in the context menu of ffdshow audio, plus I don't use the tray icon, so I wasn't sure about what you meant with tooltip :p

if I set "resizeBicubicChromaParam" to "0", it falls back to default...is the default "0.0"?

Yup, so if you want to use 0.0 just set default.

[fastplayer]

When you see it lowercase, are you using liba52 or libdts? If that's the case don't worry, I forgot about them. Will change them in my next commit.

And yup, but that string appears in the Info&CPU tab and in the context menu of ffdshow audio, plus I don't use the tray icon, so I wasn't sure about what you meant with tooltip :p
Exactly. For example, for 5.1 AC-3 audio the tooltip looks like this:
Input: ac3, 5.1, 48000 Hz, 448 kbps (liba52)
Same applies to "dts".

:thanks:

[STaRGaZeR]

Exactly. For example, for 5.1 AC-3 audio the tooltip looks like this:
Input: ac3, 5.1, 48000 Hz, 448 kbps (liba52)
Same applies to "dts".

:thanks:

Done :)

[leeperry]

Yup, so if you want to use 0.0 just set default.
ok, thanks for the confirmation. BTW, I've kinda gotten used to the audio infos(don't have much choice anyway, as you guys refuse to allow disabling it http://forum-images.hardware.fr/images/perso/zytradance.gif): http://thumbnails33.imagebam.com/9176/9d2fcd91754300.jpg (http://www.imagebam.com/image/9d2fcd91754300)

It comes in handy as my current skin doesn't tell the audio format....but as mark0077 said, why does it also show up in ffdshow video? http://thumbnails8.imagebam.com/9176/c80e9b91754303.jpg (http://www.imagebam.com/image/c80e9b91754303)
I understand it seems to be a ditto of the HMS infos: http://thumbnails32.imagebam.com/9176/bd021d91755043.jpg (http://www.imagebam.com/image/bd021d91755043)

but what's the point to tell about audio streams in ffdshow video?

and sometimes it's pretty pointless: http://thumbnails22.imagebam.com/9177/c70ef591760022.jpg (http://www.imagebam.com/image/c70ef591760022)

it also doesn't show up on AVI I think.

[nevcairiel]

ffdshow video seems to forward the IAMStreamSelect interface thats being provided by the splitter, except it hides the video streams. Why it does that, i don't know. Having it on the splitter seems good enough for me. Maybe one of the ffdshow devs can provide the reasoning for this? :)

[STaRGaZeR]

Do not bring the same thing over and over again. albain was very clear about this, read his posts. And a very important step, understand them.

[leeperry]

his broken english makes my eyes bleed, and mark also doesn't see the point to show the audio infos in ffdshow VIDEO: http://forum.doom9.org/showpost.php?p=1418389&postcount=12121

but surely, we're not worthy ;)

[madshi]

@devs:

we're working on defining a new media type (GUID + structure), with the main purpose being to connect 3D splitters, decoders and renderers. If you're interested, please post your feedback here:

http://forum.doom9.org/showthread.php?t=156051

[leeperry]

That "blur" is because you're probably using YV12
the blur is fine, subs look great right now...a nice in-between blurry and edgy: http://thumbnails23.imagebam.com/9217/3db78692160427.jpg (http://www.imagebam.com/image/3db78692160427)
I just wish I could have them in the exact yellow tint I want: http://thumbnails30.imagebam.com/8954/3d928789537958.jpg (http://www.imagebam.com/image/3d928789537958)

I've tried to change the hue/saturation/RGB levels blindly, to no available http://forum-images.hardware.fr/images/perso/tt%20tt%20dago%20tt.gif

[hoborg]

Hi.
I noticed in "ffdshow_rev3517_20100731_clsid.exe" that DTS is not decoded correctly when use libavcodec, libdts working fine (i am not using passthrough).

EDIT:
Seems to be already fixed in "ffdshow_rev3527_20100808_xhmikosr.exe".

[27049215]

Hi, when using 'libsamplerate high quality' as resampler it crashes mpc-hc.
'ff_samplerate.dll' is the problem said by OS crash report

This is reproducible on my computer, here is the steps:
1. open any movie file
2. randomly click on the seek bar
3. after 10~20 clicks, there is a chance that mpc-hc will crash

when using libavcodec as resamper, everything is fine

my computer spec:
win xp sp3
mpc-hc svn.2212
ffdshow_rev3527_20100808_xhmikosr_icl11

[STaRGaZeR]

Try with the VS2008 build instead.

[27049215]

Try with the VS2008 build instead.

tried ffdshow_rev3528_20100810_xhmikosr, still crashes mpc-hc

after more investigation, the crash always happens when playing avi video files
I remux avi into mkv, and the problem is gone, quite weird...

[STaRGaZeR]

I'm out of ideas then.

[_xxl]

Hi, when using 'libsamplerate high quality' as resampler it crashes mpc-hc.
'ff_samplerate.dll' is the problem said by OS crash report

This is reproducible on my computer, here is the steps:
1. open any movie file
2. randomly click on the seek bar
3. after 10~20 clicks, there is a chance that mpc-hc will crash

when using libavcodec as resamper, everything is fine

my computer spec:
win xp sp3
mpc-hc svn.2212
ffdshow_rev3527_20100808_xhmikosr_icl11

ff_samplerate.dll was updated some time ago. Please check if older builds work fine. If so I''ll revert it.

[27049215]

ff_samplerate.dll was updated some time ago. Please check if older builds work fine. If so I''ll revert it.

You are referring to svn.3421, right?
however, i tried ffdshow_rev3425_20100508, no problem with this version

I think it's something else that trigger this crash, I will try more svn builds later

Update: I have located the problem is between 3498 and 3507

[STaRGaZeR]

There are builds between r3498 and r3507 here (http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdy9vbGQvaWNsMTE=), can you try those?

[27049215]

There are builds between r3498 and r3507 here (http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdy9vbGQvaWNsMTE=), can you try those?

OK, more test performed, the problem is between r3500 and r3503

[Momber]

http://img.pixs.ru/storage/5/0/5/ffdshowjpg_1810279_744505.jpg

This happens every time I run the video decoder configuration.
It still happens every time, including rev3516.
I have tried uninstalling and re-installing (enabled resetting of all ffdshow options) multiple times.
Win XP SP3, DX as of June 2010

[NiFa]

Just updated from vista to 7, now I have problems with FFDshow, I can't get DXVA to work with Win 7 32-bit, in vista it worked perfectly.

My system is:
Win 7
HD4200 with cat. 10.1
MPC-HC rev.2223 output EVR Sync
FFDshow rev.3488

Edit: Seems that UAC needs to be enabled or FFDshow DXVA won't load.

[Alexander01]

Can anybody please fix this bug with the DXVA part of ffdshow: http://sourceforge.net/tracker/?func=detail&aid=3029078&group_id=173941&atid=867360

I also made a topic about this in th ffdshow forum, but no one is responding. See here: http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=1560

This bug is really annoying because some movies are really small (cinema format). Placing those subtitles into an already small picture is not really comfortable to watch :P

[STaRGaZeR]

It's not a bug, it's a limitation. Letterboxing involves resizing, and you can't resize if you use DXVA. The option should be greyed out in the DXVA config.

[janos666]

I have some questions which I can't find in the FAQ. I am confused about the Audio Decoder settings.

I have an Audigy 4 sound card with an analogue amplifier and relatively cheap (but not too bad) speakers. The card is theoretically 24/96 capable but it doesn't support any HDCP encryption.
I used to leave the Windows 7 output settings on 16/48. (Can it theoretically hurt the 16/48 sources if I set it to 24/96? Just to make sure that it will be able to handle a 24/96 signal if I will have any...?)

I use MPC-HC (latest SVN right now) with madVR video (FS exclusive) and ReClock (WASAPI exclusive) audio renders. I use the internal Source Filters but I disabled every internal Transform Filters to use the external FFDShow codec (it gives me more control over the settings and it is more compatible with madRV).
I try to avoid any unnecessary data manipulations. So, I don't use any FFDShow filters/plugins except the Subtitles and Mixer. (I don't really need the mixer because most of the sources match with my 5.1 speaker configuration. But the Subtitle renderer let me use madVR. It is a very nice feature. :))

I used to watch movies with 16/48 DTS-1536 or AC3-640 tracks (or the "cores").
I fairly sure that I can't decode the full TrueHD or DTS-HD MA 24/96 tracks with a simple software codec and send it to a non-HDCP compliant soundcard in full resolution (and enjoy a very little bit of the extra quality).

And I think I should disable the jitter correction with ReClock.

But I am not sure anymore because the Info & CPU tab says this (with TrueHD track):
Input description: 48000Hz, 6 channels truehd (libavcoced)
Current bitrate: 5376 kbps
Juitter: -11ms

Does it really work with the full bitrate? Will it work with 24 bit if I insert a disc with 24 bit track? (I don't have any of them yet. -> Or I don't know, may be I see them as 16 bit because the softwares can't recognize the full track...)

And it says this with another disc (with DTS-HD MA track):
Input description: 48000Hz, 6 channels dts (libavcoced)
Current bitrate: 1536 kbps
Juitter: -11ms


And here is the Processing tab with the allowed sample formats. How should I configure it with 16 bit sources, 16(/24) bit soundcard and none known additional sound processing?
Or does FFDShow need to do some kind of processing anyway?
So, if I don't care about the CPU utilization, then should I set it to 32 bit FP + dithering with light noise shaping (to minimize the rounding errors) or should I set it to 16 bit only without dithering (to avoid the unnecessary resample steps with additional dithering noise)?
Does it even matter when I don't use any signal manipulation plugins? I have no idea...

If there is some proessing (even without additional filters/plugins), then how should I set the output format? Should I enable the 32 bit FP processing only and set the output format to 24 bit (to minimize the rounding errors)?


A last (and little) thing:
Is there a chance to support ASIO (or may be OpenAL) outputs? This software Dsound is weird with Vista+ (after 2006...!). This is why I choose the ReClock WASAPI output. (But it is not as convincing as the ASIO or OpenAL plugins for Winamp.) I don't apply 23.976->24 fps speedup with it (I enabled the PAL speedup but I don't watch DVDs anymore.), so I use it only as a smarter audio renderer.

[Alexander01]

It's not a bug, it's a limitation. Letterboxing involves resizing, and you can't resize if you use DXVA. The option should be greyed out in the DXVA config.

So is there any other technique that can be used to get the subtitles on the bottom of the screen when using DXVA? In MPC-HC this is possible, but as this is a standalone player, it's not really fair to compare. Is it possible to use the same technique for this as MPC-HC does? Or is this not possible with a standalone directshow codec?

[STaRGaZeR]

So is there any other technique that can be used to get the subtitles on the bottom of the screen when using DXVA? In MPC-HC this is possible, but as this is a standalone player, it's not really fair to compare. Is it possible to use the same technique for this as MPC-HC does? Or is this not possible with a standalone directshow codec?

Not really, because at the moment ffdshow can only print stuff to the video, and your video is 1920x800, without the black bars. The black bars are added in the video renderer, and ffdshow has no control over them. MPC can do it because it has direct control over its custom renderers. When you activate letterbox when using software decoding what ffdshow does is resize to match your desired aspect ratio, in your case if the monitor is 16:9 to 1920x1080, adding black bars. Now that the subtitle filter has the bars to work on, it can print the subs there.

I say at the moment because some time ago tal.aloni talked about DXVA substreams or something like that, not sure if it could be used for this or not. Either way tal is missing, so you should forget about it. Just use software decoding.

[tal.aloni]

I'm still around, PM if you need anything.
DXVA substreams has the same limitations as our software overlay method when it comes to where we can place subtitles, so it's not going to help here.

p.s.
it's not possible to use the same technique as MPC-HC does, because MPC-HC has control over the renderer.

[Gleb Egorych]

Many modern ffdshow revisions crash on scrolling FLV files on my setup. As I found out the faulty module is ffsamplerate.dll. Crash log of rev.3529
Problem signature:
Problem Event Name: APPCRASH
Application Name: zplayer.exe
Application Version: 7.0.0.0
Application Timestamp: 2a425e19
Fault Module Name: ff_samplerate.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4be8758d
Exception Code: c0000005
Exception Offset: 00003933
OS Version: 6.0.6002.2.2.0.256.1
Locale ID: 1049
Additional Information 1: fd00
Additional Information 2: ea6f5fe8924aaa756324d57f87834160
Additional Information 3: fd00
Additional Information 4: ea6f5fe8924aaa756324d57f87834160

I setup ffdshow to resamle to 48KHz when freq<48KHz using libsamplerate sinc high quality. I assume the problem is not just FLV files, simply audiostreams in such files often satisfy the condition.

Can't say the last good revision but suspect it is related to rev.3421.

[leeperry]

As I found out the faulty module is ffsamplerate.dll.
did you try to use libavcodec for resampling? it sounds better to my ears, and doesn't crash while seeking for me.

[Gleb Egorych]

did you try to use libavcodec for resampling?
Use it now. Don't think there is a big difference from libsamplerate for internet video files :)

[hoborg]

Hi.
Anybody was able to play FLAC files using "MPC - Flac Source" + "ffdshow Audio Decoder"? This two filters seems to be incopatible :/
"MPC - Flac Source" + "MPC - MPA Decoder Filter" working fine.

[leeperry]

Anybody was able to play FLAC files using "MPC - Flac Source" + "ffdshow Audio Decoder"? This two filters seems to be incopatible :/
"MPC - Flac Source" + "MPC - MPA Decoder Filter" working fine.
whatever madFlac or MPC don't allow to use their source filter using another decoder AFAIK...and I don't think it's ever been officially cleared up whether ffdshow FLAC decoder was stuck to 16int.

[27049215]

Many modern ffdshow revisions crash on scrolling FLV files on my setup. As I found out the faulty module is ffsamplerate.dll. Crash log of rev.3529

I setup ffdshow to resamle to 48KHz when freq<48KHz using libsamplerate sinc high quality. I assume the problem is not just FLV files, simply audiostreams in such files often satisfy the condition.

Can't say the last good revision but suspect it is related to rev.3421.

I have encounter similiar crash, but i don't think r3421 is causing the crash

Based on my own testing, I suspect r3501
maybe you could try r3500 and r3503, from this link (http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdy9vbGQvaWNsMTE=)

[Tom Keller]

Is there any chance for ffdshow supporting forced subs and subtitles with fade-in/-out effect for dvd decoding in the not so distant future? Cause all ffdshow revisions of the last months i could find simply won't show any as 'forced' tagged subtitles inside a subtitle stream and neither any subs with fade effects. I've read a some older postings in here and in some other threads (just to find out, if it's a setting i did miss... which i apparently didn't do) just to find out, that it's a known but yet unregarded "problem" :( .

[Gleb Egorych]

Based on my own testing, I suspect r3501
maybe you could try r3500 and r3503, from this link (http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdy9vbGQvaWNsMTE=)
Seems you're right, I tried rev.3495 by clsid from my archive and it works.

[STaRGaZeR]

Is there any chance for ffdshow supporting forced subs and subtitles with fade-in/-out effect for dvd decoding in the not so distant future? Cause all ffdshow revisions of the last months i could find simply won't show any as 'forced' tagged subtitles inside a subtitle stream and neither any subs with fade effects. I've read a some older postings in here and in some other threads (just to find out, if it's a setting i did miss... which i apparently didn't do) just to find out, that it's a known but yet unregarded "problem" :( .

DVD subtitles with fade effects? I'm missing something?

[Tom Keller]

You actually do. For example: the HK-Legends UK DVD of "Fist of Fury" has subtitles, which fade in and out... and the german DVD of "Pan's Labyrinth" has this nice effect for subtitles too. For realizing this, one subpic exists multiple times (seamlessly arranged) with different transparency. So you'll see the subpic with the highest transparency for one frame, a subpic with lower transperency the following frame and so on, till you get to the subpic with no transparency at all, which (of course) will be shown for a couple of frames (like any "normal" subtitle)... and then it will be repeated vice versa for the fade-out effect.

I did some tests with different MPEG2 decoders (Nero DVD decoder, Elecard MPEG2 decoder, MPC-HC's internal MPEG2 decoder, DScaler5) inside MPC-HC - none of them had any problems with this kind of subtitles. Even forced subs were no problem. Only ffdshow won't show any of this subtitles... "normal" DVD subtitles work though.

[Alexander01]

Is there any difference in H.264 videoquality between the ffdshow DXVA decoder and the normal ffdshow (ffmpeg-mt) software decoder? I switched back to the software decoder but it seems there is not much difference between videoquality. With the DXVA decoder there was some extra noise filtering (this was configured in in ATI Catalyst, when unchecked there was no filtering anymore) and the picture seems a little bit smoother (less stuttering). Apart form that, the PQ seems the same. So the only advantage of the ffdshow DXVA decoder is the low CPU load?

[STaRGaZeR]

You actually do. For example: the HK-Legends UK DVD of "Fist of Fury" has subtitles, which fade in and out... and the german DVD of "Pan's Labyrinth" has this nice effect for subtitles too. For realizing this, one subpic exists multiple times (seamlessly arranged) with different transparency. So you'll see the subpic with the highest transparency for one frame, a subpic with lower transperency the following frame and so on, till you get to the subpic with no transparency at all, which (of course) will be shown for a couple of frames (like any "normal" subtitle)... and then it will be repeated vice versa for the fade-out effect.

I did some tests with different MPEG2 decoders (Nero DVD decoder, Elecard MPEG2 decoder, MPC-HC's internal MPEG2 decoder, DScaler5) inside MPC-HC - none of them had any problems with this kind of subtitles. Even forced subs were no problem. Only ffdshow won't show any of this subtitles... "normal" DVD subtitles work though.

I can't do anything since I don't know the format, but I'm interested in a sample, just to see the effect.

Also DVD (Vobsub) subtitles support is incomplete, so these issues are normal.

So the only advantage of the ffdshow DXVA decoder is the low CPU load?

Yes.

[dann23]

if tal is alive :) when will see improvements in dxva? last time I know that tal was working on improving subtitles and performance in dxva mode.

[Tom Keller]

I can't do anything since I don't know the format, but I'm interested in a sample, just to see the effect.
I've made a small sample in the form of a normal DVD video structure, so that you could have a better idea of how those fade-in/out effects on subtitles work and look like:

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

[Alexander01]

When I use the Letterbox 16:9 option in ffdshow software decoder, the colorspace is being altered (for example: skin tones look more yelllow). Is this normal?

[STaRGaZeR]

I've made a small sample in the form of a normal DVD video structure, so that you could have a better idea of how those fade-in/out effects on subtitles work and look like:

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

Thanks :)

When I use the Letterbox 16:9 option in ffdshow software decoder, the colorspace is being altered (for example: skin tones look more yelllow). Is this normal?

I assume you're not outputting RGB32. The YCbCr --> RGB32 conversion is done by your graphics card. The drivers use the video resolution to determine if the video should be converted using BT.601 or BT.709. When you letterbox, you're changing video resolution, and this can force the drivers to change between the two. You can't avoid this unless you output RGB32 from ffdshow.

[Alexander01]

I just unchecked all Planar YUV, all Packed YUV and all RGB except 'RGB32' and 'High YV12 to RGB conversion', but it didn't solved the issue.

[STaRGaZeR]

Post a sample and your letterbox settings then.

[Alexander01]

I found out it only happens with the following scenarios:


- When external subtitles are loaded
- When internal subtitles are loaded (Embedded subtitles checkbox ticked).


There's also another bug with the embedded subtitles (which also applies to the ffdshow DXVA decoder): When I uncheck the 'Embedded subtitles' box, ffdshow still loads the embedded subtitles, but this time they are not displayed in the bottom black bar (so no Letterbox 16:9 is used) and the colors are correct. Don't now if this is related to the splitter, but I am using MatroskaSplitter.ax from the latest MPC-HC build.


Sample: http://www.megaupload.com/?d=ASY575F5

Subtitles checked/Embedded subtitles unchecked/16:9 Letterbox unchecked: http://j.imagehost.org/0292/1_104.jpg
Subtitles checked/Embedded subtitles checked/16:9 Letterbox checked: http://j.imagehost.org/0731/2_25.jpg

[STaRGaZeR]

That looks a lot like a BT.601 vs BT.709 issue. Your sample is 1280x544, with letterboxing to 16:9 it's 1280x720.

When outputting RGB32 I get the exact same output on both. Graphics card drivers usually use BT.601 for height<720 and BT.709 for height>=720, and that's probably the case here. So please recheck in the Info & CPU tab that you're outputting RGB32 when this thing happens, because this can only happen if you're not outputting RGB32.

[Alexander01]

Correct color: Letterbox 16:9 unchecked and default output colorspaces settings checked. FFdshow output says YUY2
Bad color (too yellow): Letterbox 16:9 checked and default output colorspaces settings checked. FFdshow output says YUY2
Bad color (too yellow): Letterbox 16:9 checked and all output colorspaces unchecked except 'RGB32' and 'High YV12 to RGB conversion'. FFdshow output says RGB32
Bad color (too yellow): Letterbox 16:9 unchecked and all output colorspaces unchecked except 'RGB32' and 'High YV12 to RGB conversion'. FFdshow output says RGB32

Changing 'YCbCr' specification to 'ITU-R BT.709' also didn't help to get correct color with the last 3.

I'm using ffdshow 3533 and the Latest ATI Catalyst 10.7 with default settings. I had installed a previous of Catalyst before. I uninstalled it completely, then installed the newest one made sure all settings were set to default (I only unchecked the noise filtering).

[nevcairiel]

Hey,

while developing my new media splitter, i noticed that the ffdshow subtitle renderer doesn't properly deal with subs that are UTF-8 encoded.
I have a sample here thats a UTF-8 encoded ASS sub, and it shows broken characters for the unicode chars. It works fine with DirectVobSub.

I can provide the sample if required, but any non-english subs should eventually show the problem.

How does ffdshow expect the character data? I realize it works with other splitters, so i'm mostly wondering if you could fix that more easily then i can.
Any feedback on how to resolve this issue would be appreciated. Thanks!

[STaRGaZeR]

Correct color: Letterbox 16:9 unchecked and default output colorspaces settings checked. FFdshow output says YUY2
Bad color (too yellow): Letterbox 16:9 checked and default output colorspaces settings checked. FFdshow output says YUY2
Bad color (too yellow): Letterbox 16:9 checked and all output colorspaces unchecked except 'RGB32' and 'High YV12 to RGB conversion'. FFdshow output says RGB32
Bad color (too yellow): Letterbox 16:9 unchecked and all output colorspaces unchecked except 'RGB32' and 'High YV12 to RGB conversion'. FFdshow output says RGB32

Changing 'YCbCr' specification to 'ITU-R BT.709' also didn't help to get correct color with the last 3.

I'm using ffdshow 3533 and the Latest ATI Catalyst 10.7 with default settings. I had installed a previous of Catalyst before. I uninstalled it completely, then installed the newest one made sure all settings were set to default (I only unchecked the noise filtering).

I can't reproduce, if you output RGB32 the ATI drivers don't touch the image (at least not for this). And ffdshow does the conversion based on the original video resolution, not after the resizing, so I always get the same output. Do you have Auto checked in the YCbCr spec?

Hey,

while developing my new media splitter, i noticed that the ffdshow subtitle renderer doesn't properly deal with subs that are UTF-8 encoded.
I have a sample here thats a UTF-8 encoded ASS sub, and it shows broken characters for the unicode chars. It works fine with DirectVobSub.

I can provide the sample if required, but any non-english subs should eventually show the problem.

How does ffdshow expect the character data? I realize it works with other splitters, so i'm mostly wondering if you could fix that more easily then i can.
Any feedback on how to resolve this issue would be appreciated. Thanks!

I have loads of MKVs with non english UTF-8 plain text subs (SRT) that work fine, can you post that sample?

[Sebastiii]

Hi :)

You can find it here :

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

Cheers,
Seb.

[nevcairiel]

I also sent you a pm with the sample, but yeah, thats the one.

Using LAVFSplitter i get corrupted glyphs in the first sub (Sub für Jap-dub [ger]). It works with DirectVobSub, but it also works with other splitters and ffdshow. So i guess it could be fixed on either end.
I would just need some insight on how to fix it, as i don't really have the time to dive into the ffdshow or directvobsub code.

[Alexander01]

Do you have Auto checked in the YCbCr spec?

Yes. And I also tryed to set it to ITU-R BT.709, but it didn't helped.

[STaRGaZeR]

I also sent you a pm with the sample, but yeah, thats the one.

Using LAVFSplitter i get corrupted glyphs in the first sub (Sub für Jap-dub [ger]). It works with DirectVobSub, but it also works with other splitters and ffdshow. So i guess it could be fixed on either end.
I would just need some insight on how to fix it, as i don't really have the time to dive into the ffdshow or directvobsub code.

Successful debug session, ffdshow enables its "utf8" flag when it detects MEDIASUBTYPE_SSA and another flag called "ismatroska" is set. "ismatroska" is set when one of these 3 filters are detected: Haali, MPC's internal MKV splitter or MPC's standalone MKV splitter. Just adding LAVFSplitter to the list fixes the issue, as utf8 is now true :)

Build: http://www.mediafire.com/?41clo6a849c3bld

BTW I've found something that may help you with the SSA fonts issue. Go to "SetMediaType" in TtextInputPin.cpp, line 78. What's this "extradata" stuff about?

Yes. And I also tryed to set it to ITU-R BT.709, but it didn't helped.

Setting it to 601 or 709 will just force one or another, your problem is that without lettebox it's using 601, and with letterbox 709 because of the new resolution. Either way I can't fix it since I can't reproduce it :(

[nevcairiel]

BTW I've found something that may help you with the SSA fonts issue. Go to "SetMediaType" in TtextInputPin.cpp, line 78. What's this "extradata" stuff about?

The extradata in SSA/ASS holds the style definition. But i believe i figured out how to do embedded fonts, i just need to work on extracting it from the mkv =)

Thanks for the quick fix!

[Sebastiii]

Really great guys :)
Thanks.

[Alexander01]

Setting it to 601 or 709 will just force one or another, your problem is that without lettebox it's using 601, and with letterbox 709 because of the new resolution. Either way I can't fix it since I can't reproduce it :(

This week Catalyst 10.8 will be released, so i hope it will fix my issue. If not, my last chance would be a complete format/reinstall.

[rack04]

Has anyone noticed that installing ffdshow tryouts over an existing installation on Windows7 64bit Ultimate that the installer occasionally doesn't enable subtitles which was active in the existing installation?

[Blight]

Hi,
I have a bug to report:

When calling QueryInterface for "IID_IAMStreamSelect" on FFDShow's video decoder, subsequent calls to "IStreamSelect.Count(DWord variable)" raises an "EStackOverflow" exception. Tested with subtitles and without, makes no difference.
Tested with 32bit clsid build #3529

[STaRGaZeR]

Does anybody have a sample with closed captions?

[Tom Keller]

I can provide a DVD sample with closed captions:

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

[STaRGaZeR]

Thanks Tom, in this sample CCs can be turned on and off with the CCs option in the subs section. People reported that CCs were always shown regardless of the option, so I thought it happened on all sources. Any CC samples that have this bug?

[clsid]

The CC option itself works ok as far as I can remember. The problem/confusion was that it functions independently from the state of the global subtitle filter option.

[STaRGaZeR]

The global subtitle filter option also works with this one, do you have any of the problematic ones?

[albain]

Hi all,

I am back from holidays

I have just added support for cook audio decoding, let me know if there are issues. The decoder might not be as good as the one used by MPC : FFDshow uses ffmpeg, MPC uses Real's dlls

Hi,
I have a bug to report:

When calling QueryInterface for "IID_IAMStreamSelect" on FFDShow's video decoder, subsequent calls to "IStreamSelect.Count(DWord variable)" raises an "EStackOverflow" exception. Tested with subtitles and without, makes no difference.
Tested with 32bit clsid build #3529

Have you enabled internal filters to appear in the tray icon menu (in FFDShow video config / "tray,dialogs..." section, Add internal filters... checked ?) ?

For now I can't see how we would fall on an overflow

[XhmikosR]

@albain: thanks for adding support for COOK audio. Here (http://www.mediafire.com/?57c26hgcb1uqc) are a few samples which don't play with the latest rev. Note that "pareme.rm" crashes mpc-hc pointing to libavcodec.dll.

[clsid]

Great work Albain!

I have noticed one problem. The audio is messed up after seeking in a RealMedia video. It sounds like the audio samples are decoded in the wrong order. Without performing a seek the audio plays fine.

[Gleb Egorych]

Hi albain.

There is crash in ff_samplerate.dll possibly related to revision 3501. See page 613, posts by me and 27049215: http://forum.doom9.org/showthread.php?p=1426231#post1426231

[Hyper Shinchan]

Is it possible to add MPEG-4 ALS support in FFDShow? Since revision 20517 ffmpeg can decode it. There's also the issue of a splitter capable of demuxing and feeding the audio stream correctly, so actually adding support in FFDShow isn't enough I suppose but it would be nice to have ALS under directshow.

[albain]

Hi albain.

There is crash in ff_samplerate.dll possibly related to revision 3501. See page 613, posts by me and 27049215: http://forum.doom9.org/showthread.php?p=1426231#post1426231


Hi,

I can't reproduce the problem. Do you have a sample file ? Which splitters are you using ? which player ?

[fastplayer]

@albain:
In rev3551 you moved a statement next to the condition. Where's the fix in that?
I'm probably missing something big here, right? :o

[Blight]

Albain:
I've had it set to not show the tray icon at all and the option to show internal filter in the tray icon was not enabled.

I tried enabling the tray icon and then when playing a media file, right clicking the tray icon threw this error:

---------------------------
Debugger Fault Notification
---------------------------
Project Z:\zplayer.exe faulted with message: 'application-defined exception (code 0xc00000fd) at 0x1026ac27'. Process Stopped. Use Step or Run to continue.
---------------------------


Enabling the tray icon or enabling the show internal filters feature had no affect on the StackOverflow error.
I'm calling QueryInterface before the graph is running (filters are added to the graph and connected), does this make a difference?

I'm on Windows 7 Pro 32bit and set the ffdshow tray icon to always show in the tray. Still using the same CLSID build.

[Gleb Egorych]

Hi,

I can't reproduce the problem. Do you have a sample file ? Which splitters are you using ? which player ?

Here is a sample: http://www.mediafire.com/?9maeuon2vgbza6u
I watch using Zoom Player, navigate file using mouse wheel.
Audio is resampled from 44.1Khz to 48KHz using libsamplerate high.

FLV splitter 1.3.2099 from MPC-HC project.

[hoborg]

Hi.
Since LAVF splitter introduced very good MOV splitting, all my *.MOV samples plays using FFDshow except one with "twos" audio inside. Sample is here (http://hobring.esero.net/saf/samples/p1010337.zip).

Here is what MediaInfo say:
Audio
ID : 2
Format : PCM
Format settings, Endianness : Big
Format settings, Sign : Signed
Codec ID : twos
Duration : 2s 0ms
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 1 channel
Sampling rate : 16.0 KHz
Bit depth : 16 bits
Stream size : 62.5 KiB (1%)
Language : English
Encoded date : UTC 2010-03-17 22:55:13
Tagged date : UTC 2010-03-17 22:55:13

[LigH]

hoborg's post reminds me on a similar issue we have discussed in the german doom9/Gleitz board: MOVs with "twos" audio don't play in MPC-HC. Because MediaInfo reports them as PCM, I wondered if it was possible to hex-patch the Codec ID to something more compatible, but I had no idea which alternative FourCCs for PCM audio might exist in QuickTime... "Simply" recognising it as compatible PCM format would of course be a more convenient solution.

[XhmikosR]

You should try the latest MPC-HC build.

[LigH]

mpc-homecinema.2397_(x86)_msvc2010 + ffdshow_rev3550_20100829_sse_icl11 from XvidVideo.RU => Sample ^ (p1010337) plays without error message.

[hoborg]

mpc-homecinema.2397_(x86)_msvc2010 + ffdshow_rev3550_20100829_sse_icl11 from XvidVideo.RU => Sample ^ (p1010337) plays without error message.

Yes, MPC-HC will use Quicktime frameworks to play MOV file. Open it in Graphstudio and LAVF as splitter - FFDShow audio decoder refuse to connect.

[STaRGaZeR]

Yes, MPC-HC will use Quicktime frameworks to play MOV file. Open it in Graphstudio and LAVF as splitter - FFDShow audio decoder refuse to connect.

It plays fine with MPC's internal MP4 splitter here, so I take it's a problem with LAVFSplitter only?

[hoborg]

It plays fine with MPC's internal MP4 splitter here, so I take it's a problem with LAVFSplitter only?

Looks like you are right, it is working with MP4 splitter.
The problem is that MP4 splitter failed to split some MOV samples (http://hobring.esero.net/saf/samples/03_100_0435.zip) i have - there is no audio output PIN, but working fine with LAVF as splitter :/

[albain]

@albain:
In rev3551 you moved a statement next to the condition. Where's the fix in that?
I'm probably missing something big here, right? :o

You're right, my mistake. I changed CoTaskMemFree by free() and I had a corrrupted heap but the change was done only locally, so a commit for nothing

[albain]

Albain:
I've had it set to not show the tray icon at all and the option to show internal filter in the tray icon was not enabled.

I tried enabling the tray icon and then when playing a media file, right clicking the tray icon threw this error:


Enabling the tray icon or enabling the show internal filters feature had no affect on the StackOverflow error.
I'm calling QueryInterface before the graph is running (filters are added to the graph and connected), does this make a difference?

I'm on Windows 7 Pro 32bit and set the ffdshow tray icon to always show in the tray. Still using the same CLSID build.

Ok, I guess that you release the pointer after each call of QueryInterface ?
The fact that the graph is not running shouldn't have any effect

[STaRGaZeR]

Looks like you are right, it is working with MP4 splitter.
The problem is that MP4 splitter failed to split some MOV samples (http://hobring.esero.net/saf/samples/03_100_0435.zip) i have - there is no audio output PIN, but working fine with LAVF as splitter :/

The problem seems to be in LAVFSplitter, it's sending 00000000-0000-0010-8000-00AA00389B71 as subtype (WMMEDIASUBTYPE_Base???), while MPC's splitter is using 736F7774-0000-0010-8000-00AA00389B71 as subtype. Dunno if this is the official guid of twos, but here (http://www.codecguide.com/faq_mpc.htm) it says it is. Report this to nevcairiel, it should be easy to fix.

[XhmikosR]

@albain it seem you missed my previous post.

@albain: thanks for adding support for COOK audio. Here (http://www.mediafire.com/?57c26hgcb1uqc) are a few samples which don't play with the latest rev. Note that "pareme.rm" crashes mpc-hc pointing to libavcodec.dll.

I also tried this (http://samples.mplayerhq.hu/real/tv_watching_t1.rm) sample which has 1 channel 22.05Khz COOK audio and still the same. The latest ffplay has no problem with this.

[Tinkerer2]

The default matrices in mixer do not seem to be correct.
For example for 5.1 to 2.0 it uses 0.707 for both center and LFE. However, the LFE channel is supposed to be played 10dB louder than other channels. Is it a bug or does ffdshow compensate for this somewhere else?

[Blight]

Small feature request:
Accept video decoder pin connections for the "{72707A61-0000-0010-8000-00AA00389B71}" sub-type exposed by the microsoft AVI splitter. You already support decoding this video format when the "QTRpza" sub-type is used for connection (exposed by 'haali media splitter' for the same file).

Here are some sample files:
http://samples.mplayerhq.hu/V-codecs/RPZA/
(i couldn't find a splitter for the MOV files, but the jumping.avi file can be used as a test case)


Albain:
Here's my entire process for getting the stream info:

1) I enum all the filters in the graph.

2) For each filter in the graph, I call:

// dsStreamFilter is an IBaseFilter class
If dsStreamFilter.QueryInterface(IID_IAMStreamSelect, dsStreamSelect) = S_OK then // dsStreamSelect is an IAMStreamSelect class
Begin
dsStreamFilter.GetClassID(dsFilterGUID);
If (IsEqualGUID(dsFilterGUID,CLSID_FFDShow) = True) then
Begin
If dsStreamSelect.Count(StreamCount) = S_OK then // This call throws the StackOverflow exception, StreamCount is a DWord.
Begin
End;
End;
dsStreamSelect := nil; // removes the reference count and frees the object
End;


This works for every other filter supporting the IAMStreamSelect interface...
Am I doing something wrong?

[STaRGaZeR]

Small feature request:
Accept video decoder pin connections for the "{72707A61-0000-0010-8000-00AA00389B71}" sub-type exposed by the microsoft AVI splitter. You already support decoding this video format when the "QTRpza" sub-type is used for connection (exposed by 'haali media splitter' for the same file).

Here are some sample files:
http://samples.mplayerhq.hu/V-codecs/RPZA/
(i couldn't find a splitter for the MOV files, but the jumping.avi file can be used as a test case)

MEDIASUBTYPE_QTRpza is {617a7072-0000-0010-8000-00AA00389B71}, I couldn't find any info about {72707A61-0000-0010-8000-00AA00389B71}. Is there a know MEDIASUBTYPE_xxx for this guid?

[clsid]

72707A61 = "rpza" = FourCC "azpr"
617a7072 = "azpr" = FourCC "rpza"

[STaRGaZeR]

Added in r3555. jumping.avi now works with Microsoft's AVI splitter.

[madshi]

@ffdshow developers:

Graph:
MPC HC -> Haali MKV Splitter -> any video decoder -> ffdshow raw video filter (rev. 3529) -> any video renderer

Video:
MKV, 1 video track, 1 audio track, many subtitle tracks

In this situation there's a serious bug in the ffdshow IAMStreamSelect implementation: The media type for all streams (video, audio and subtitles) is reported as "MEDIATYPE_Video". Haali's IAMStreamSelect implementation properly reports the correct media types for all the streams.

[XhmikosR]

@devs: I did a comparison between O2 and O3 with GCC 4.5.1 and there's no difference in the performance at all. And the installer's size is decreased a lot.

Installer size msvc2008 O3: 5.09MB
Installer size msvc2008 O2: 4.85MB

Maybe someone else should measure the performance and if the results are the same then change the O3 to O2.

[hoborg]

Hi.
This sample (http://www.volny.cz/hoborg/test.zip) will freeze durning playback if FFDshow DXVA decoder is in use.
It play fine using MPC-HC DXVA, MS VIDEO decoder or standard FFDShow h.264 decoder.

[albain]

Small feature request:
Accept video decoder pin connections for the "{72707A61-0000-0010-8000-00AA00389B71}" sub-type exposed by the microsoft AVI splitter. You already support decoding this video format when the "QTRpza" sub-type is used for connection (exposed by 'haali media splitter' for the same file).

Here are some sample files:
http://samples.mplayerhq.hu/V-codecs/RPZA/
(i couldn't find a splitter for the MOV files, but the jumping.avi file can be used as a test case)


Albain:
Here's my entire process for getting the stream info:

1) I enum all the filters in the graph.

2) For each filter in the graph, I call:

// dsStreamFilter is an IBaseFilter class
If dsStreamFilter.QueryInterface(IID_IAMStreamSelect, dsStreamSelect) = S_OK then // dsStreamSelect is an IAMStreamSelect class
Begin
dsStreamFilter.GetClassID(dsFilterGUID);
If (IsEqualGUID(dsFilterGUID,CLSID_FFDShow) = True) then
Begin
If dsStreamSelect.Count(StreamCount) = S_OK then // This call throws the StackOverflow exception, StreamCount is a DWord.
Begin
End;
End;
dsStreamSelect := nil; // removes the reference count and frees the object
End;


This works for every other filter supporting the IAMStreamSelect interface...
Am I doing something wrong?


I am not very aware of delphi coding but if setting to null a variable corresponds to a Release call in CPP this should be ok.
Although, there shouldn't be any stack overflow if you call it once.

But the problem may come from this : this method will also scan the graph for IAMStreamSelect interface in the other filters. So if another filter does the same there (and calls Count method), there will be an infinite loop then a stack overflow.

I added a security for that in revision 3557


@XhmikosR No I didn't miss your post, I just didn't have the time to look after this

@Madshi I don't understand what's wrong with the behaviour you describe ?
IAMStreamSelect does not report any media type but a group number which is 1=video track, 2=audio track...

[madshi]

I am not very aware of delphi coding but if setting to null a variable corresponds to a Release call in CPP this should be ok.
Yes, in Delphi setting an interface to "nil" ends up in a "Release" call.

Although, there shouldn't be any stack overflow if you call it once.

But the problem may come from this : this method will also scan the graph for IAMStreamSelect interface in the other filters. So if another filter does the same there (and calls Count method), there will be an infinite loop then a stack overflow
FWIW, in the latest madVR version I'm also calling IAmStreamSelect, and inside of ZoomPlayer that also causes a stack overflow, if ffdshow is in the graph. But strangely inside of MPC HC there doesn't seem to be a stack overflow. Weird... I've worked around it by putting the "IAmStreamSelect.Count" call into a try..except block.

@Madshi I don't understand what's wrong with the behaviour you describe ?
IAMStreamSelect does not report any media type but a group number which is 1=video track, 2=audio track...
The problem is that the group numbers are not defined anywhere. Microsoft does not say anywhere that group 1 = video, or am I wrong? As far as I can see, some splitter might also have video tracks in group 2 and audio tracks in group 1.

Anyway, look at the documentation of "IAMStreamSelect::Info". The 2nd parameter is a media type. And ffdshow *DOES* return media type information for every stream, in the 2nd parameter of the "Info" method. The problem is that ffdshow always returns a video media type, even for audio and subtitle streams. I'm using the media type to find out which group is video, audio and subtitles.

[STaRGaZeR]

@devs: I did a comparison between O2 and O3 with GCC 4.5.1 and there's no difference in the performance at all. And the installer's size is decreased a lot.

Installer size msvc2008 O3: 5.09MB
Installer size msvc2008 O2: 4.85MB

Maybe someone else should measure the performance and if the results are the same then change the O3 to O2.

I've tested both with constant 35mbps H.264 Blu-ray content and I got ~155,5fps with O2 vs ~158fps with O3 in timecodec using ffmpeg-mt. GCC 4.5.1 too. I don't care about the difference nor the installer size, so you guys decide.

Specs in sig.

[albain]

Madshi, you're right, there is indeed a media type information. However every players I know use the group ID with the same mapping rules even if there are no mapping rules AFAIK

This is fixed in revision 3558

@XhmikosR : the RM samples you provided won't read because of ffmpeg

codecdata_length=8
subpacket[0].cookversion=1000001
MONO
js_vlc_bits = 43947, only >= 0 and <= 6 allowed!

You can report these samples to ffmpeg team, thanks

[madshi]

Madshi, you're right, there is indeed a media type information

This is fixed in revision 3558
Great - thanks!

[Midzuki]

Q.: Any possibility of finally fixing this issue (http://forum.doom9.org/showthread.php?p=1431370#post1431370) ???

A.: Only after the Third Impact (if ever).

[XhmikosR]

Madshi, you're right, there is indeed a media type information. However every players I know use the group ID with the same mapping rules even if there are no mapping rules AFAIK

This is fixed in revision 3558

@XhmikosR : the RM samples you provided won't read because of ffmpeg

codecdata_length=8
subpacket[0].cookversion=1000001
MONO
js_vlc_bits = 43947, only >= 0 and <= 6 allowed!

You can report these samples to ffmpeg team, thanks

All the samples play fine with the latest ffplay build so I cannot report anything to them. Only ffdshow has problems.

[STaRGaZeR]

I've come across a similar problem when enabling libavcodec AAC. DebugView is full of:

[7720] More than one AAC RDB per ADTS frame is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs,
it means that your file has a feature which has not been implemented.
[7720] Error decoding AAC frame header.

And all I get is silence, with a clear Info&CPU tab with all AAC files I have. The AAC parser never parses anything. FFmpeg is updated. The same files play fine with ffplay. Ideas are welcomed :(

[albain]

All the samples play fine with the latest ffplay build so I cannot report anything to them. Only ffdshow has problems.

This is odd then, I'll check after this, maybe the ffmpeg cook decoder inside ffdshow is not up to date but I doubt it

[clsid]

The decoder code should be fully up-to-date. Perhaps it is a bug in the realmedia splitter?

[jhoff80]

Can we please get a "Disable DXVA in SD" option like in MPC-HC? As mentioned a little ways back, my ATI HD4850 doesn't like SD content when using DXVA acceleration, and the output is very blocky. At the moment, I have to manually switch between DXVA enabled for h.264 and disabled when I switch between files, and since MPC-HC does this automatically, I'd love if the same worked for ffdshow.

[clsid]

Use the presets functionality.

[XhmikosR]

The decoder code should be fully up-to-date. Perhaps it is a bug in the realmedia splitter?

It might be a bug in the MPC RealMediaSplitter indeed.

[jhoff80]

Use the presets functionality.

:o Wow, I can't believe I completely missed that before, thanks / sorry.

[vince100]

I was trying to play some TV recordings with cyberlink mpeg2 decoder and ffdshow as post-processor and VMR9 as renderer.

When used alone without ffdshow, the cyberlink mpeg2 decoder has the capability to decode closed captions and connect to a MS line 21 decoder for closed caption display.

When ffdshow is used, if the ffdshow internal mpeg2 codec was disabled, the video can be decoded by cyberlink codec (system-default) and post-processed. But closed captions would not display.

If I use ffdshow's internal mpeg2 decoder instead of commercial ones, closed captions can be displayed in ffdshow-style, but the video quality leaves a lot to be desired and cpu usage was too high.

Because closed captioning is essential for me, my question is:
Is there anyway to get closed captions displayed and also have the video decoded by a non-ffdshow mpeg2 decoder and post-processed by ffdshow's special filters?
What configuration is required in ffdshow and which player can implement this setup?


Thanks.

[Midzuki]

Is there anyway to get closed captions displayed and also have the video decoded by a non-ffdshow mpeg2 decoder and post-processed by ffdshow's special filters?

No.

What configuration is required in ffdshow and which player can implement this setup?

Post a "proper" bug report on the "official channels"
(this thread is not an "official" channel)
and PRAY.

:-\

[jmartinr]

Concerning this bug, giving problems in new builds of MPC-HC: http://forum.doom9.org/showthread.php?p=1430936#post1430936

It's enough to make a small adjustment to the contents of ffavisynth.avsi that's installed by ffdshow. A simple try... catch... will do.

try { Load_Stdcall_Plugin("ffavisynth.dll") }
catch(err_msg) { NOP() }

[djcla]

ANy idea why any AVI's i have with a DTS track in them stutter at the start of the video everytime when using FFDSHow? I do not get this issue bitstreaming with MS audio decoder or MPC-HC own decoders.. I have FFDSHow audio decoder setup as an external filter in MPC-HC.

I do not get this issue with DD 5.1 or HD audio i use a an ATI 5670 via HDMI out to SOny 2400ES reciever.

Next issue i have always had is when i configure FFDShow and mediaplayer or 7MC to decode H264 MKV's they always play with a green bars through them VC1 stuff is fine.

I tried using MPC-HC and FFDshow DXVA yesterday and seemed to have mroe success but need to investigate that further .

Any one else get these issues?

[Snowknight26]

You don't get the issue with Microsoft's audio decoder because it doesn't decode DTS.

[louisnet]

In recent version, the "Flip" option in context menu has been deleted,

I set the mirror in "Offset & flip" to Enable,
When I want to flip the screen horizontally, I just do to select the "Offset & flip" in Context Menu
if I want to flip the screen vertically, I just do to select the "Flip" in Context Menu.
Both function can be done thru the Context menu.

So the "Flip" option in Context Menu is very important.

Please....consider to make it appear again.
Thanks

[djcla]

You don't get the issue with Microsoft's audio decoder because it doesn't decode DTS.

i meant bitstreaming and the MS one works fine for that

[magic144]

Hooray, the ffdshow FFv tray icon right-click no longer makes ZP go boom! (build 3562) - thanks to all concerned for addressing this one!

[vince100]

Is there anyway to get closed captions displayed and also have the video decoded by a non-ffdshow mpeg2 decoder and post-processed by ffdshow's special filters?
What configuration is required in ffdshow and which player can implement this setup?

Thanks.

Is it possible to achieve this by using Avisynth within ffdshow?

[tschi]

Concerning this bug, giving problems in new builds of MPC-HC: http://forum.doom9.org/showthread.php?p=1430936#post1430936

It's enough to make a small adjustment to the contents of ffavisynth.avsi that's installed by ffdshow. A simple try... catch... will do.

try { Load_Stdcall_Plugin("ffavisynth.dll") }
catch(err_msg) { NOP() }
What do you means exactly by "enough ??" :confused:
I tried but MPC-HC still crash when I use avisynth with ffdshow :mad:
The only working solution I found is to not use MPC-HC :devil:

[jmartinr]

@Tschi

You might have another avsi-file in your avisynth plugin directory that loads a dll. Delete it, move it or edit it. ;)

[dansrfe]

Slight n00b question. I have made a script which resizes to 1080p depending on the source A/R in ffdshow and I am not quite sure if ffdshow's "Output" tab picks up the original video resolution from the initial video input before AviSynth or after AviSynth for the purpose of determining YCbCr Specification being ITU-R BT.601 or ITU-R BT.709. I hope it picks it up before AviSynth. Another probably more important question I have is that does YCbCr Specification matter if I am outputting only YV12 for madVR? In this case does madVR determine the colorspace by itself? If so then that is probably messing up due to my AviSynth resize script. Any explanation for this whole situation would be great. Thanks.

[STaRGaZeR]

Slight n00b question. I have made a script which resizes to 1080p depending on the source A/R in ffdshow and I am not quite sure if ffdshow's "Output" tab picks up the original video resolution from the initial video input before AviSynth or after AviSynth for the purpose of determining YCbCr Specification being ITU-R BT.601 or ITU-R BT.709. I hope it picks it up before AviSynth.

It picks the initial video input dimensions, so it guarantees that the correct matrix is used. You can check it by changing between the two to see which one is actually used.

Another probably more important question I have is that does YCbCr Specification matter if I am outputting only YV12 for madVR? In this case does madVR determine the colorspace by itself? If so then that is probably messing up due to my AviSynth resize script. Any explanation for this whole situation would be great. Thanks.

The whole "RGB conversion" tab affects things only when you're outputting RGB from ffdshow (obviously :p). If you're outputting YV12 no conversion is done in ffdshow, the video renderer (madVR in this case) does all the stuff. You should ask madshi when madVR uses each one. However, if it uses one or another based on the video dimensions that it receives from the previous filter the whole thing will be incorrect if you resize before madVR, since the resized image may toggle 709 when the video is 601 and viceversa.

Any kind of postprocessing is yet another situation where RGB32 input would make perfect sense in madVR, but madshi didn't want to add it the last time I asked for it, not even with an option to disable it.

[Keiyakusha]

It picks the initial video input dimensions, so it guarantees that the correct matrix is used. You can check it by changing between the two to see which one is actually used.

If we talking about avisynth script, then output colors will be wrong. What you said is valid for internal resizer only. However I'm not sure, maybe this was fixed in some of the recent revisions.
EDIT: also SD -> 1080p using internal resizing AND keeping it YV12 -> wrong colors.

[STaRGaZeR]

If we talking about avisynth script, then output colors will be wrong. What you said is valid for internal resizer only. However I'm not sure, maybe this was fixed in some of the recent revisions.
EDIT: also SD -> 1080p using internal resizing AND keeping it YV12 -> wrong colors.

If you're not outputting RGB ffdshow doesn't do anything. You have to convert whatever you have to RGB somewhere in the filter chain. These settings are only used when the YCbCr-->RGB conversion is done inside ffdshow. If you resize, with avisynth or the resize filter, and output YV12 or any other non-RGB colorspace, colors will be wrong if your video was mastered using 601 and the filter doing the conversion uses 709 because of the new resolution. This is not a bug in ffdshow, nor in the renderer. The selection 601 vs 709 is done assuming that certain resolutions are 601 and 709.

Example: you have SD video, ffdshow and renderer assume 601. If you resize to 1080p within ffdshow AND you output RGB, the RGB conversion will be done inside ffdshow with 601, as it should, because ffdshow knows that the source is SD. If you're NOT outputting RGB no conversion is done in ffdshow, but in the renderer. Now, the renderer sees 1080p YV12 video, it doesn't know what the original dimensions were, so it assumes 709 --> wrong colors. Again, this is not a bug, is a limitation.

[Midzuki]

Bug in ffdshow r3529 Audio Processor:

when a 4.0 FLAC is decoded by the latest madFlac and then sent to ffdshow audio processor, this produces a 3.1 output. :rolleyes: No problem when madFlac connects to AC3Filter, OTOH.

[madshi]

Bug in ffdshow r3529 Audio Processor:

when a 4.0 FLAC is decoded by the latest madFlac and then sent to ffdshow audio processor, this produces a 3.1 output. :rolleyes: No problem when madFlac connects to AC3Filter, OTOH.
FWIW, the latest madFlac version outputs a correct dwChannelMask value in the media type information. So if Midzuki's bug report is true (haven't checked), then ffdshow probably doesn't properly handle a 4.0 dwChannelMask.

[Midzuki]

@ madshi: the audio processor works fine when connected to the audio decoder of ffdshow, so it seems there is a "language barrier" :) between the audio processor and madFlac's decoder filter.

[madshi]

Can you please post the dwChannelMask information for both cases? Don't need the whole media type, just the channel mask for comparison.

[Midzuki]

I'm afraid I spoke too early :o ... I will have to re-create the test .WAVs and .FLACs, not only because I've already deleted them :p , but principally because, now that I think it all over, it's quite possible that they were VERY "non-standard" :( ... Just out of curiosity, does madFlac (or/and eac3to) support ALL "weird" channel masks --- let's say, 0x003C (FC, LFE, BL, BR) --- :confused:

[madshi]

madFlac (at least in theory) supports all channel mask combinations that can be expressed with the MS flags.

[Snowknight26]

Now that MPC-HC checks for the profile level of the video (so that High 4:4:4 Predictive H.264 isn't decoded with DXVA), any chance of implementing this in ffdshow? And while we're at it, perhaps fixing the broken colorspace output?

[Alexander01]

Can I use madVR with ffdshow?

[SamuriHL]

That's a question I've been tackling today. I'm told yes. My problem is that madVR appears to be 32 bit only.

[nevcairiel]

I can confirm that it works fine. Why wouldn't it? As long as a renderer ouputs YV12, it should work fine with madVR

[SamuriHL]

Yup, not only does it work, but, WOW. Just wow. It's now the setup I intend to use. And because I'm an idiot, they got me set up in 32 bit land so that Haali and MPC splitters co-exist without stepping on each other in MPC-HC. Quite frankly, madVR rocks.

P.S. I will be switching to LAVF at some point. :)

[SamuriHL]

Hey, can someone using 3569 tell me if subtitles are working with DXVA? They seem to have stopped working for me in both 32 bit and 64. I've tried 2 different splitters to make sure it wasn't a splitter issue. I've also tried in 2 different players. In 64 bit land I've not touched my config so this doesn't seem good. In 32 bit land I've switched to using madVR, but, even switching back to EVR CP subtitles are not showing for me. Help?

[clsid]

@Snowknight26
I have updated the DXVA check

[magic144]

@SamuriHL - have you tried changing the "Smoothing method" - I've seen before where subs appear to have stopped working between one version of ffdshow and the next, but changing to a different Smoothing method makes them reappear - dunno if that means one of the methods is no longer working of course, but that's what worked for me in the past.

[SamuriHL]

Yea, I had looked at that to make sure it was set right. I'll take another look when I get home. I'll report back what I find in a few hours. Thanks!

[Alexander01]

Is it possible to implement this in ffdshow: http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=1000

Would be great if a start videofile with xx fps in WMC , ffdshow changes the refresh rate to xx hz. If I stop the video ffdshow should change the refresh rate back.

[nevcairiel]

This isn't really something the decoder should do. Either the player, or possibly the renderer should take care of this. Not the decoder.

[Alexander01]

Yes, but the player/renderer can't do it (WMC), so it would be nice if ffdshow can send a command to change the refesh rate.

[noee]

You're particular player cannot, but MPC-HC can do it (as well as others) and madshi has committed to adding a refresh rate "changer" to madVR. This feature makes no sense to be at the decoder layer.

[clsid]

Use MPC-HC, madVR, or ReClock.

[SamuriHL]

@SamuriHL - have you tried changing the "Smoothing method" - I've seen before where subs appear to have stopped working between one version of ffdshow and the next, but changing to a different Smoothing method makes them reappear - dunno if that means one of the methods is no longer working of course, but that's what worked for me in the past.

Work got in the way, but, I checked and it's as I had it set before when it was working. I haven't touched the 64 bit config other than to update to a new ffdshow version. For me, subtitles are no longer working at all. :( I'm surprised no one else has seen this issue? sigh.

[clsid]

Obvious thing to check is if post processing is enabled in the DXVA decoder.
Otherwise delete HKEY_CURRENT_USER\Software\GNU\ffdshow_dxva and start with a fresh set of settings.

[SamuriHL]

Yup. I may have to whack the settings. What's odd is that it's happening on both 32 and 64 bit. I haven't tried it on my other machine yet.

[Alexander01]

You're particular player cannot, but MPC-HC can do it (as well as others) and madshi has committed to adding a refresh rate "changer" to madVR. This feature makes no sense to be at the decoder layer.

I know MPC-HC does have an option to change the refresh rate based on the video file's fps. But the problem is I use WMC because I can use a remote control, watch TV, timeshift, etc. So if I use MPC-HC the remote control gets useless (need to start every video file from Windows Explorer with the mouse), I can't watch Live TV, and I can't timeshift. Is it impossible to let the ffdshow decoder do a Windows-command to change the refresh rate when the video file gets initialized by the decoder? And then change back to refresh rate when the decoding process is stopped (decoder quits)?

[nevcairiel]

You could use reclock. It offers a scripting interface to change refresh rates and even works in WMP (as long as you use DirectShow and not MF)

[hoborg]

Feature request:

MPC-HC MP4 splitter (MP4Splitter.ax) now support old QT *.mov files.
Can be QT PCM audio (subtype {454E4F4E-0000-0010-8000-00AA00389B71}) added to FFDshow audio decoder? MPC MPA decoder already support this, but FFDshow dont connect to MP4Splitter.ax

Here are two samples (http://hobring.esero.net/saf/samples/qt_pcm.zip).

BTW, make sure you have at last MP4Splitter.ax rev. 2551 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2551).

With QT PCM, it should be now possible to play all old *.MOV files without QT frameworks and QT source filter...
Thanks.

[SamuriHL]

I'm back with subtitle issues I'm afraid. I've completely cleaned the settings for both 32 and 64 bit, reinstalled with the latest build, and I still get no subtitles in either WMP or MPC-HC. I'm quite well aware of how to configure it to work having helped Damian with his guide on doing exactly that, so, something is not right. These are MKV's created by MakeMKV with PGS subs. As I said previously, they all worked fine until I upgrade ffdshow. I don't have the old installs handy nor do I have time to go try and track down what version it broke in right now. This is frustrating because I know it was working fine before with no changes to the setup other than upgrading to a newer version, and no one else seems to be having problems. sigh.

[STaRGaZeR]

The problem is on your side, the lastest version works just fine with PGS in MKV.

[SamuriHL]

Awesome. Well, given that I cleaned the ffdshow settings completely and reinstalled it from scratch, I have no idea at all what the issue is.

[SamuriHL]

I'm kind of worried now. I output the settings from a machine that is working, import them on my main HTPC that is NOT working, and it still doesn't give me subtitles. WTH could be wrong? :( This was working FINE just a few weeks ago. I'm seriously not happy right now.

EDIT: I take it back. It's not working on this machine, either. I had forgotten to uncheck auto-load subtitles in MPC-HC so it was using the internal subtitle display. SIGH. So that's two machines that it's not working on now. HELP

[DJ_Phatic]

I have never been able to get the subs working with ffdshow DXVA. I have just done a fresh install of Win7 64-bit and installed r3574 (tried on my previous install with various other revisions).

PGS subs inside MKV created by MakeMKV. Surface overlay enabled, subtitles on using MPC Matroska Splitter.

Subs work fine with MPC-HC Subtitle Engine. Using Catalyst 10.9 hotfix.

[SamuriHL]

Oh that's SO not what I want to hear. :D I had this working at one point. Something has broken it on both my laptop and my HTPC. Yes, subs work with MPC-HC, but, that's not the only player I use so this is very frustrating. I'm trying to lock it down and figure out what is causing this. So far, no luck at all.

[SamuriHL]

Yea, none of my machines have it working anymore. I have no idea what broke, but, if the ffdshow developers tell me it's working for them I have to take that as fact. It is NOT working for me at all anymore. I'm very very frustrated at this point.

[DJ_Phatic]

Same here, trying to get it setup nicely for MediaPortal.

Any ideas how I get LPCM in a mkv to work?

[SamuriHL]

I've not tried yet. I suppose I can work on that, but, this subtitle thing is really upsetting me now. :( I'll try Kill Bill when I get a chance and see what happens.

[rica]

Guys please.

What i need is somebody makes PCM bithdepth automatically selected.

_ _ _ _ _

[STaRGaZeR]

ffdshow r3574:

http://thumbnails26.imagebam.com/9801/bc702a98008540.jpg (http://www.imagebam.com/image/bc702a98008540)

EDIT: DXVA now:

http://thumbnails28.imagebam.com/9801/d77d8a98009395.jpg (http://www.imagebam.com/image/d77d8a98009395)

BTW, the logical first step when you break something is undo what broke it in the first place. Just sayin' :p

[SamuriHL]

Believe me, I wish I could! :D The only thing I've done to those machines is update FFDSHOW, MPC-HC, and the ATI drivers. I don't use subs very often, but, for forced subs they're, uh, kinda nice to have. :) I just want to be clear here, and I know you're a dev so this is stupid on my part to even ask, but, you have auto-load subtitles unchecked in MPC-HC....right? :)

[SamuriHL]

So yea, I created an MKV with LPCM from Kill Bill using MakeMKV and I get no audio, either. It looks like a splitter issue to me. The audio's simply not getting sent to ffdshow. I tried with SMM and MPC-HC splitters and nada. I didn't try with LAVF or Haali.

[SamuriHL]

So, I've just gone through about everything I can find. Stargazer, I even set up my 32 bit environment to match yours...ReClock audio renderer, EVR Sync, Haali....the *ONLY* way to get subs to show for me is if the auto-load subtitles checkbox is checked in MPC-HC which is not using ffdshow dxva subtitle rendering...instead it's using MPC-HC's internal sub renderer. So, I would ask you to look and see what you have set in MPC-HC just to see if maybe I'm going crazy. Thanks!!

[SamuriHL]

Ok, my last post on this because....drumroll....I've tracked down the damn build that broke it! :p So there, I wasn't crazy. ROFLMAO! It stops working for me in 3540. 3536 and previous work perfectly. Does this help at all? Do I need to log a bug? (Not sure how for ffdshow project). At least I know I'm not nuts! And Stargazer, that means you've been using MPC-HC subtitle support. ;)

[STaRGaZeR]

Believe me, I wish I could! :D The only thing I've done to those machines is update FFDSHOW, MPC-HC, and the ATI drivers. I don't use subs very often, but, for forced subs they're, uh, kinda nice to have. :) I just want to be clear here, and I know you're a dev so this is stupid on my part to even ask, but, you have auto-load subtitles unchecked in MPC-HC....right? :)

Yes, everything you see is done by ffdshow. However I've found something, try with r3537 and then with r3540 from here (http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdy9vbGQvaWNsMTE=) and report your findings.

EDIT: ninja'd. And no, I'm not using MPC's renderer ;). The problem is that in r3537 libswscale was updated, adding sanity checks. These checks fail if you use a chroma subsampled format and swscaler gaussian or bilinear smoothing methods. I always use RGB32, so it didn't affect me. There's a bug in ffdshow, that now causes an error in libswscale. albain to the rescue! You can use another smoothing method until this is fixed. We can also partially revert that revision until albain has time to look at it, what do you say clsid?

[SamuriHL]

Yes, everything you see is done by ffdshow. However I've found something, try with r3537 and then with r3540 from here (http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdy9vbGQvaWNsMTE=) and report your findings.

EDIT: ninja'd. And no, I'm not using MPC's renderer ;). The problem is that in r3537 libswscale was updated, adding sanity checks. These checks fail if you use a chroma subsampled format and swscaler gaussian or bilinear smoothing methods. I always use RGB32, so it didn't affect me. There's a bug in ffdshow, that now causes an error in libswscale. albain to the rescue! You can use another smoothing method until this is fixed.

You ROCK! Thank you for that. I thought I had changed that but I went back to defaults. Lemme go mess with that and see what happens. Most excellent!!

[SamuriHL]

I have a stupid question now. So I got RGB32 setup when using madVR and it's pretty damn stunning. However, for my other machine I have to use DXVA as we determined my CPU isn't fast enough to handle madVR (a shame). When I look at the icon for ffdshow dxva it's showing nv12 output. I set the regular ffdshow video settings to use only rgb32 with conversion but it doesn't seem to apply when doing dxva. Is this normal or am I missing a setting?

[STaRGaZeR]

madVR doesn't accept RGB32, so it's impossible you're using it. If you're actually using RGB32 and you think the quality is stunning, you will get that quality in any renderer that accepts RGB32 (basically everything except madVR).

DXVA is NV12 only, yes. Your GPU is doing thedecoding and the YCbCr-->RGB conversion. You should try outputting RGB32 from ffdshow in your other machine with your renderer of choice if your CPU is fast enough, you'll get madVR like quality instead of crappy DXVA. Don't forget checking "High quality YV12 to RGB conversion" ;)

[NiFa]

Is it possible to add "don't use DXVA if scan type is PAFF or MBAFF" or "use DXVA only if scan type is progressive" checkbox in DXVA settings so it doesn't decode interlaced videos at all?

[Underground78]

Is it possible to add "don't use DXVA if scan type is PAFF or MBAFF" or "use DXVA only if scan type is progressive" checkbox in DXVA settings so it doesn't decode interlaced videos at all?

Why ? Can't DXVA decode interlaced videos ?

[hoborg]

Why ? Can't DXVA decode interlaced videos ?

I would like to have this option, but only for VC-1i - not supported by FFMpeg, but FFDshow DXVA load to decode it = black screen.
But i didnt see reason why to disable interlaced h.264...

[NiFa]

Why ? Can't DXVA decode interlaced videos ?
DXVA can decode interlaced material but it causes artifacs at least ATI's low-end cards, so it would be nice to have some option that interlaced material would not be decoded using DXVA.
I would like to have this option, but only for VC-1i - not supported by FFMpeg, but FFDshow DXVA load to decode it = black screen.
But i didnt see reason why to disable interlaced h.264...
I'm not sure which one AVC1 is, but my problems occur when video is interlaced and encoded using AVC1, I don't have any interlaced h.264 videos in my computer so I can't test does it cause same problems.

[albain]

Guys please.

What i need is somebody makes PCM bithdepth automatically selected.

_ _ _ _ _

Hi Rica,

what's the deal with PCM bitdepth ?

This part is still a little messy in my head

@Nifa : does MPC-HC decodes interlaced VC1 correclty with DXVA decoder ?

[hoborg]

I'm not sure which one AVC1 is, but my problems occur when video is interlaced and encoded using AVC1, I don't have any interlaced h.264 videos in my computer so I can't test does it cause same problems.

AVC (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC) is not VC-1 (http://en.wikipedia.org/wiki/VC-1) :)

[NiFa]

@Nifa : does MPC-HC decodes interlaced VC1 correclty with DXVA decoder ?
Same problem occurs when I tried with MPC-HC internal DXVA decoder, But I'm not sure is it VC-1 or h.264 which I have problems.

Here is video info:
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=2, N=32
Duration : 1h 7mn
Bit rate mode : Variable
Bit rate : 36.4 Mbps
Maximum bit rate : 39.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Scan type : MBAFF

Is that encoded with h.264/AVC?

@hoborg: thanks I wasn't sure which one it was, but that made it clearer.

[Underground78]

DXVA can decode interlaced material but it causes artifacs at least ATI's low-end cards, so it would be nice to have some option that interlaced material would not be decoded using DXVA.

This sample : beyonce.at.the.bbc.1080mbaff.sample.ts (http://mirror05.x264.nl/public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts) seems to be work fine here with my HD2600XT. Can you try it ?

[NiFa]

This sample : beyonce.at.the.bbc.1080mbaff.sample.ts (http://mirror05.x264.nl/public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts) seems to be work fine here with my HD2600XT. Can you try it ?
That sample played just fine without any problems.

[Underground78]

So maybe you can sample a short sample so that we can test the problematic file ?

[NiFa]

I'm just making sample and will put link here when I get it uploaded.

[SamuriHL]

madVR doesn't accept RGB32, so it's impossible you're using it. If you're actually using RGB32 and you think the quality is stunning, you will get that quality in any renderer that accepts RGB32 (basically everything except madVR).

DXVA is NV12 only, yes. Your GPU is doing thedecoding and the YCbCr-->RGB conversion. You should try outputting RGB32 from ffdshow in your other machine with your renderer of choice if your CPU is fast enough, you'll get madVR like quality instead of crappy DXVA. Don't forget checking "High quality YV12 to RGB conversion" ;)

Yea I'm an idiot. sigh. :) This is what I get for messing with things so much. It wasn't set to madVR when I was using RGB32. I had it set to EVR Sync at that point. However, that does go to show that EVR Sync + RGB32 looks pretty damn good!! Thanks for all your help. I've been learning a lot. This is not an area that I'm really all that good at yet. I'll try it on my other machine later and see what happens.

[SamuriHL]

Hi Rica,

what's the deal with PCM bitdepth ?

This part is still a little messy in my head



For PCM blu-ray discs, it's not sending it out through exclusive mode, so, you get whatever Windows audio is set to. (For example, my default is 7.1 96/24). That means a track like Kill Bill, for example, will play 7.1 96/24 even though in reality it's only 5.1 48/16. That's for Blu-rays. For MKV, I can't get any PCM audio at all. I believe that to be a splitter issue perhaps? Anyway, that's what I think Rica's referring to.

[NiFa]

Here are 2 samples from the video which I get some artifact to picture they are not huge but you can see them.

Sample (http://www.mediafire.com/?fxw3t8oyco0e618)
Sample 2 (http://www.mediafire.com/?c09h1901rkqiddx)

My graphigcard is HD4200, so I'm using really low-end card which shouldn't have power to handle interleced full-hd material as far as I know.

[nevcairiel]

For PCM blu-ray discs, it's not sending it out through exclusive mode, so, you get whatever Windows audio is set to. (For example, my default is 7.1 96/24). That means a track like Kill Bill, for example, will play 7.1 96/24 even though in reality it's only 5.1 48/16. That's for Blu-rays. For MKV, I can't get any PCM audio at all. I believe that to be a splitter issue perhaps? Anyway, that's what I think Rica's referring to.

What codec tag does it use in MKV?
Sample? :)

On the general issue that Rica is referring to, people want bit exact output.
This is not a problem for lossy formats, they should be decoded and output with the highest bit-depth possible, if the audio renderer supports it 32-bit int or even 64-bit float - the renderer should then dither it to 24-bit (or 16 on hardware that doesn't like 24)
However with lossless formats, they should preferably not be touched at all. So a 16-bit PCM Stream should be send as 16bit to the audio renderer, or a 24bit FLAC send as 24-bit, you get the idea.

This however does not work with ffdshow. When you tic multiple bit-depths on the output page, it'll always try to use the highest, in my experience.

A similar discussion started on the MPC-HC thread a while back, for reference the conclusion:
http://forum.doom9.org/showthread.php?p=1427095#post1427095

[SamuriHL]

What codec tag does it use in MKV?
Sample? :)

Sorry, I know better. Still not fully awake yet. :)


Audio
ID : 2
Format : PCM
Codec ID : 00001000-0000-0100-8000-00AA00389B71
Codec ID/Hint : Microsoft
Duration : 1h 50mn
Bit rate mode : Constant
Bit rate : 4 608 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 3.56 GiB (13%)
Title : 3/2+1
Language : English


That's the media info for the PCM track inside the MKV. I don't have a small sample yet. Is there an easy way to cut 30 seconds to a minute from an MKV? For m2ts/ts files I can use tsMuxer, but, not for MKV's.

[nevcairiel]

I was hoping for the actual MKV tag, probably something like "A_PCM/....". Something like mkvinfo (from mkvtoolnix) should tell you.

mkvmerge can also split files based on time code. Somethnig like this will split the first 30s

mkvmerge -o sample.mkv --split 30s source.mkv

Note that --split will split after all 30s, so it'll create alot of small chunks. But its the easiest way i know from the top of my head to get a sample out of it. Just stop it after ti created a chunk :p

[Underground78]

Here are 2 samples from the video which I get some artifact to picture they are not huge but you can see them.

Sample (http://www.mediafire.com/?fxw3t8oyco0e618)
Sample 2 (http://www.mediafire.com/?c09h1901rkqiddx)

My graphigcard is HD4200, so I'm using really low-end card which shouldn't have power to handle interleced full-hd material as far as I know.

Hum I don't get artifacts but playback is jerky with those samples. I am not sure it is because of the fact they are interlaced.

[SamuriHL]

I was hoping for the actual MKV tag, probably something like "A_PCM/....". Something like mkvinfo (from mkvtoolnix) should tell you.

mkvmerge can also split files based on time code. Somethnig like this will split the first 30s

mkvmerge -o sample.mkv --split 30s source.mkv

You can also specify an absolute position using "--split timecodes:00:45:00.000,00:45:30.000"


(MKVInfo) | + Track number: 2
(MKVInfo) | + Track UID: 2
(MKVInfo) | + Track type: audio
(MKVInfo) | + Enabled: 1
(MKVInfo) | + Default flag: 1
(MKVInfo) | + Forced flag: 0
(MKVInfo) | + Lacing flag: 1
(MKVInfo) | + MinCache: 0
(MKVInfo) | + Timecode scale: 1
(MKVInfo) | + Max BlockAddition ID: 0
(MKVInfo) | + Codec ID: A_MS/ACM
(MKVInfo) | + Codec decode all: 1
(MKVInfo) | + Language: eng
(MKVInfo) | + CodecPrivate, length 40 (format tag: 0xfffe)
(MKVInfo) | + Default duration: 5.000ms (200.000 fps for a video track)
(MKVInfo) | + Name: 3/2+1
(MKVInfo) | + Audio track
(MKVInfo) | + Sampling frequency: 48000
(MKVInfo) | + Channels: 6
(MKVInfo) | + Bit depth: 16


http://www.mediafire.com/?8f37sc3mgcyxh2p

I hope this helps!

[SamuriHL]

Just an FYI, the original MKV was made with MakeMKV 1.5.8. I don't know if that's relevant or not but I just thought I'd mention it.

[clsid]

Yes, everything you see is done by ffdshow. However I've found something, try with r3537 and then with r3540 from here (http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdy9vbGQvaWNsMTE=) and report your findings.

EDIT: ninja'd. And no, I'm not using MPC's renderer ;). The problem is that in r3537 libswscale was updated, adding sanity checks. These checks fail if you use a chroma subsampled format and swscaler gaussian or bilinear smoothing methods. I always use RGB32, so it didn't affect me. There's a bug in ffdshow, that now causes an error in libswscale. albain to the rescue! You can use another smoothing method until this is fixed. We can also partially revert that revision until albain has time to look at it, what do you say clsid?
Do you mean these checks (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/libswscale/swscale.c?r1=3538&r2=3537&pathrev=3538) in r3538? If so, go ahead and disable them. Please also add a comment that describes the bug in ffdshow.

@Albain, could you have a look at this bug?

[NiFa]

Here are some pics from sample 2 when I play it using DXVA.

http://img843.imageshack.us/img843/9440/sakura2m2tssnapshot0000.th.png (http://img843.imageshack.us/i/sakura2m2tssnapshot0000.png/)

http://img651.imageshack.us/img651/3526/sakura2m2tssnapshot0003.th.png (http://img651.imageshack.us/i/sakura2m2tssnapshot0003.png/)

http://i9.aijaa.com/t/00837/6731124.t.png (http://www.aijaa.com/v.php?i=6731124.png)

http://i10.aijaa.com/t/00835/6731125.t.png (http://www.aijaa.com/v.php?i=6731125.png)

http://i3.aijaa.com/t/00160/6731126.t.png (http://www.aijaa.com/v.php?i=6731126.png)

http://i9.aijaa.com/t/00257/6731127.t.png (http://www.aijaa.com/v.php?i=6731127.png)

I have marked the artefacts in pictures.

When I play it using software decoding there are no artefact at all, I think that problem is that my HD4200 just doesn't have enough power to decode 1080i material, this one is my first and only interlaced video at moment.

[STaRGaZeR]

However, that does go to show that EVR Sync + RGB32 looks pretty damn good!!

Try other renderers if you want, they'll look the same ;)

Do you mean these checks (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/libswscale/swscale.c?r1=3538&r2=3537&pathrev=3538) in r3538? If so, go ahead and disable them. Please also add a comment that describes the bug in ffdshow.

@Albain, could you have a look at this bug?

Yeah, I meant r3538 not r3537. I've disabled them in r3576.

[nevcairiel]

I hope this helps!

It did, next version of LAVFSplitter will support multi-channel raw PCM tracks, thanks!
Doesn't even need a audio decoder when your hardware directly supports the format. Needs a filter when you, for example, want to play a 5.1 track on stereo hardware. But ffdshow with raw audio input enabled can do the job of down-mixing it. :)

Edit:
Actually, i lied. I just found a 7.1 PCM track, and my dev system is only setup for 5.1 through a AC3 encoded SPDIF link, and it still plays just fine without any filter.
Although i'm not sure if the DD-Live encoding didn't somehow accept 7.1 while a standard sound renderer wouldn't, oh well.

[SamuriHL]

Try other renderers if you want, they'll look the same ;)


I shall indeed. Before I started playing with madVR I was using EVR CP. I was playing with EVR Sync trying to match your config to get subs working before you told me what the issue was and forgot to set it back. It does look really good. I'm gonna have to sit and do some comparisons when I get a chance.


Yeah, I meant r3538 not r3537. I've disabled them in r3576.

Sweet. I'm surprised I'm the first one to run into this issue.

[SamuriHL]

It did, next version of LAVFSplitter will support multi-channel raw PCM tracks, thanks!
Doesn't even need a audio decoder when your hardware directly supports the format. Needs a filter when you, for example, want to play a 5.1 track on stereo hardware. But ffdshow with raw audio input enabled can do the job of down-mixing it. :)

Edit:
Actually, i lied. I just found a 7.1 PCM track, and my dev system is only setup for 5.1 through a AC3 encoded SPDIF link, and it still plays just fine without any filter.
Although i'm not sure if the DD-Live encoding didn't somehow accept 7.1 while a standard sound renderer wouldn't, oh well.

Awesome! I guess this means I'm gonna have to finally get LAVF installed. I've been lazy! :) Thanks for adding this!

[Juaneeto]

Hi guys,

would somebody please comment on this issue I've posted a few days ago? http://sourceforge.net/tracker/?func=detail&aid=3064948&group_id=173941&atid=867360 I would like to know whether it's really ffdshow bug, or whether it's just a mistake on my side that can be fixed?

Thanks a lot.

[Midzuki]

@haruhiko_yamagata

I think you forgot to put the back center speaker controls and meter in the volume filter (for something like 6.1 speakers), unless you did that on purpose with the intention of adding it later because like the description for rev.1549 says:
"Volume filter : add control for side channels".

Back center speaker is hidden there beforehand. Back left speaker can be used to configure back center speaker. They are rarely used together. Because there was no space to add one more control, I left it untouched. Though I cant test it.

It shouldn't be "incredibly-difficult" to draw a wider configuration window, I guess.


OK, so the ffdshow configuration applets are made of adamantium and cannot be enlarged, but what about doing something like this:

http://forum.videohelp.com/attachments/3508-1284773942/audio-processor-wise.png

[STaRGaZeR]

@devs

Have you considered removing some deinterlacers, more specifically kernelDeint, DGBob and TomsMoComp? These are barely faster than Yadif (at least on my system), provide less quality (IMO) and I don't know of anybody that actually uses them inside ffdshow. Same with realaac, it's not even listed as an available filter.

[_xxl]

realaac - yes, the rest no.

[DJ_Phatic]

ffdshow doesn't seem to like a 6.1 FLAC stream I have in one of my mkv's, using ffdshow to decode and when using madFlac.

Sample: http://www.mediafire.com/?1dpylzi343f3otc

ffdshow revision 3357.

[war59312]

ffdshow build 3576 (x86 and x64) is refusing to save its directshow merit level. :(

I cant get WMP to use ffdshow for x264 .avi files for the life of me. :(

Update: ok have to run config as admin, always been the case ?

OK but on very high and wmp still is not using ffdshow..

Ok got that working using Win7DSFilterTweaker by disabling media foundation, too bad that breaks thumbnails though...

[Gleb Egorych]

Here is a sample: http://www.mediafire.com/?9maeuon2vgbza6u
I watch using Zoom Player, navigate file using mouse wheel.
Audio is resampled from 44.1Khz to 48KHz using libsamplerate high.

FLV splitter 1.3.2099 from MPC-HC project.
Теsted revisions 3500 and 3503. Rev 3500 does not crash, rev 3503 does crash as well as rev 3574. It crashes in ZP and MPC-HC.

Revision 3503 - Directory Listing
Modified Tue Jul 6 16:07:13 2010 UTC (2 months, 2 weeks ago) by clsid2

Updated FFmpeg

Revision 3502 - Directory Listing
Modified Tue Jul 6 13:08:33 2010 UTC (2 months, 2 weeks ago) by albain

Revision 3501 fix : missing file

Revision 3501 - Directory Listing
Modified Tue Jul 6 09:44:20 2010 UTC (2 months, 2 weeks ago) by albain

Revision 3499 fix : deadlocks fixed when using an external audio file. MPC splitter + MPC AC3/DTS filter => OK. But Haali + MPC AC3/DTS filter won't work because Haali's pins are monothreaded and MPC AC3/DTS filter needs a blocking mode (which requires multithreaded pins).

[STaRGaZeR]

realaac - yes, the rest no.

Done.

To all, I've successfully enabled libavcodec's AAC decoder again. It has decoded everything I've thrown at it, LC, HE v1 and HE v2. Please test and report any issues!

Build: http://www.mediafire.com/?z83xtyw4xay6l7f

[XhmikosR]

I can confirm it plays back all of my samples, and those which are unsupported by libfaad2! What are the downsides of ffmpeg's aac decoder? If there aren't any maybe libfaad should be removed.

[STaRGaZeR]

16-bit integer output instead of 32-bit floating point in libfaad2. I guess some audio purists will be against removing it even if it plays things libfaad2 can't play.

Oh I've found something it doesn't decode, AAC-LTP. Nobody uses this, but still.

[fastplayer]

Why are we so eager to remove things? Choice is a good thing.
Is libfaad holding ffdshow development in any way back? Does it take too long to compile, does it need hacks to get it working etc.?
FYI, there's a feature list (http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/aacdec.c;h=6138dac05e79e1540cc4d89be6e89474d7e3025a;hb=HEAD) of ffmpeg's AAC decoder in aacdec.c.

[STaRGaZeR]

Why keep two decoders when one of them does at least the same as the other? Useless waste of time, space, etc. This isn't the case here, but that's the reason.

I see LTP is a SoC project, good to know :)

[xergon]

well.
put it like this:
I play interlaced material with ffdshow maybe four times a year. In case i do, i want highest possible quality.

Activating deinterlacing is the one thing, CHOOSING a proper Deinterlacer is another.

YOU HAVE TWELVE DIFFERENT DEINTERLACING OPTIONS IN THERE.

That´s the first time I get an advice which Deinterlacer to use (Yadif). Actually, two Deinterlacers are enough:
one which fits most users - giving best quality. And maybe one with special options, for example the one which is allowing 50fps output.
Well, you know, maybe just give some sort of speed/quality ranking in the help annotations might be enough. Like the ones for the sharpening algorithms.
They are perfectly, even if the best methods like asharpen are not explained at all ... *roll eyes*

Would be perfect if a deinterlace insider writes some descriptions explaining what is the difference between these Deinterlacers.


So, MANY users will just select a deinterlacer by chance. makes no sense.


Mabye ask the authors of the deinterlacers to write a short description. If they don´t react, maybe hide these deinterlacers in some sort of special/advanced option field.

So, yeah, I don´t know every deinterlacer. so just remove the ones which are "bad"/"not so good", or at least mark the recommended deinterlacers and explain why they are recommended.

this would make ... sense :-)

:)
Xergon

[fastplayer]

Why keep two decoders when one of them does at least the same as the other? Useless waste of time, space, etc. This isn't the case here, but that's the reason.

I see LTP is a SoC project, good to know :)
Choice is really helpful when troubleshooting...
If our goal is to be as close to the ffmpeg source as possible, then there's a lot more to strip out of ffdshow than libfaad. :D
We should wait for more input on this matter from the other devs.

By the way, nice work with the AAC integration! :)
Now give deband to the 64-bit folks :D

[Midzuki]

O.T.Same.H., libavcodec's mpeg-2 decoder && libmpeg2 are inferior to DScaler 5, so why not get rid of them both as well? :devil: :D

[tetsuo55]

O.T.Same.H., libavcodec's mpeg-2 decoder && libmpeg2 are inferior to DScaler 5, so why not get rid of them both as well? :devil: :DDo you have any scientific evidence for this? (not interlacing related)

[Midzuki]

Do you have any scientific evidence for this? (not interlacing related)

It depends on what you mean by "scientific". :)
Anyway, here goes a thing that DScaler 5 does not do:

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

[Anima123]

I can confirm it plays back all of my samples, and those which are unsupported by libfaad2! What are the downsides of ffmpeg's aac decoder? If there aren't any maybe libfaad should be removed.

XhmikosR, have you enabled ffmpeg's aac decoder in your recent builds, like rev. 3577?

[NiFa]

Here are some pics from sample 2 when I play it using DXVA.

http://img843.imageshack.us/img843/9440/sakura2m2tssnapshot0000.th.png (http://img843.imageshack.us/i/sakura2m2tssnapshot0000.png/)

http://img651.imageshack.us/img651/3526/sakura2m2tssnapshot0003.th.png (http://img651.imageshack.us/i/sakura2m2tssnapshot0003.png/)

http://i9.aijaa.com/t/00837/6731124.t.png (http://www.aijaa.com/v.php?i=6731124.png)

http://i10.aijaa.com/t/00835/6731125.t.png (http://www.aijaa.com/v.php?i=6731125.png)

http://i3.aijaa.com/t/00160/6731126.t.png (http://www.aijaa.com/v.php?i=6731126.png)

http://i9.aijaa.com/t/00257/6731127.t.png (http://www.aijaa.com/v.php?i=6731127.png)

I have marked the artefacts in pictures.

When I play it using software decoding there are no artefact at all, I think that problem is that my HD4200 just doesn't have enough power to decode 1080i material, this one is my first and only interlaced video at moment.
Any changes to get possibility to disable DXVA with interlaced material?

I would but it in code by myself, but I don't have any idea how to do it.

[nevcairiel]

16-bit integer output instead of 32-bit floating point in libfaad2.
Sadly this is a overall problem with libavcodec. They do decoding internally at full floating point precision, and then cut it to 16bit int for output. <.<

[hoborg]

Feature request:

MPC-HC MP4 splitter (MP4Splitter.ax) now support old QT *.mov files.
Can be QT PCM audio (subtype {454E4F4E-0000-0010-8000-00AA00389B71}) added to FFDshow audio decoder? MPC MPA decoder already support this, but FFDshow dont connect to MP4Splitter.ax

Here are two samples (http://hobring.esero.net/saf/samples/qt_pcm.zip).

BTW, make sure you have at last MP4Splitter.ax rev. 2551 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2551).

With QT PCM, it should be now possible to play all old *.MOV files without QT frameworks and QT source filter...
Thanks.

Ticket (https://sourceforge.net/tracker/?func=detail&aid=3071690&group_id=173941&atid=867363)

[fastplayer]

XhmikosR, have you enabled ffmpeg's aac decoder in your recent builds, like rev. 3577?
No, he hasn't.

[tetsuo55]

Sadly this is a overall problem with libavcodec. They do decoding internally at full floating point precision, and then cut it to 16bit int for output. <.<madshi's 1 line patch changes that.

[nevcairiel]

1 line in every format that it decodes, maybe. Sounds like it would be more. At least changing the definition of the output sample format, changing the data type of the buffers, and disabling the function that cuts down the sample to 16bit int. Maybe 5 lines, yet still in every decoder.

[tetsuo55]

maybe, send a pm to madshi and he will give you the patch for formats supported by eac3to

[albain]

ffdshow build 3576 (x86 and x64) is refusing to save its directshow merit level. :(

I cant get WMP to use ffdshow for x264 .avi files for the life of me. :(

Update: ok have to run config as admin, always been the case ?

OK but on very high and wmp still is not using ffdshow..

Ok got that working using Win7DSFilterTweaker by disabling media foundation, too bad that breaks thumbnails though...

This is not related to ffdshow build but to your OS : Vista/7 introduce UAC, and the registry portion which stores the merit is exposed to UAC.

I didn't find a simple way to fix this : ffdshow configuration cannot be run in admin mode, so a separate executable should be done for this with parameters (filter clsid, merit to set)

[albain]

Do you mean these checks (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/libswscale/swscale.c?r1=3538&r2=3537&pathrev=3538) in r3538? If so, go ahead and disable them. Please also add a comment that describes the bug in ffdshow.

@Albain, could you have a look at this bug?

Hi,

I don't know what happened exactly : this check was included into the libswscale upgrade process

Also PGS subtitles are extracted in RGB32 mode whereas all the other subtitles formats are extracted in YUV colorspace.
In all cases they are planar into the first plane so this is normal that the planes 2,3,4 are empty when calling ffmpeg scaling methods

[SamuriHL]

Hi,

I don't know what happened exactly : this check was included into the libswscale upgrade process

Also PGS subtitles are extracted in RGB32 mode whereas all the other subtitles formats are extracted in YUV colorspace.
In all cases they are planar into the first plane so this is normal that the planes 2,3,4 are empty when calling ffmpeg scaling methods

Have you tried PGS subs with ffdshow defaults lately? Cause I got no subs at all until I changed the smoothing method to something other than swscaler gaussian.

[allak]

maybe, send a pm to madshi and he will give you the patch for formats supported by eac3to

The patch is actually included in the eac3to.zip distribution, in this path:

/legal stuff/ffmpeg/compiling

[Anima123]

Done.

To all, I've successfully enabled libavcodec's AAC decoder again. It has decoded everything I've thrown at it, LC, HE v1 and HE v2. Please test and report any issues!

Build: http://www.mediafire.com/?z83xtyw4xay6l7f

I have tried this build with some video with Real's cook audio, and it decode the cook with no problem. Thank you STaRGaZeR!

[nevcairiel]

The patch is actually included in the eac3to.zip distribution, in this path:

/legal stuff/ffmpeg/compiling

Indeed it is. This should be useful for future endavours, but its exactly like i predicted it would be, fwiw =)

[tetsuo55]

nevcairiel > thanks for the lesson :P

[XhmikosR]

I did another benchmark, regarding KernelDeint this time:

ffdshow r3680, libmpeg2
Compiler Average fps
========= ===========
MSVC 2008 341
ICL 11.1.0.67 356
GCC 4.5.1 372

KernelDeint GCC 4.5.1 (http://xhmikosr.1f0.de/patches/ffdshow/ff_kernelDeint.dll_gcc451.7z)
KernelDeint ICL 11 (http://xhmikosr.1f0.de/patches/ffdshow/ff_kernelDeint.dll_ICL11.7z)
KernelDeint MSVC 2008 (http://xhmikosr.1f0.de/patches/ffdshow/ff_kernelDeint.dll_MSVC2008.7z)

Can someone else confirm these results and if yes should we remove the KernelDeint from the VS2008 solution file and perhaps the ICL11 solution file too?

I've also added the compiler info for Xvidcore (patch (http://xhmikosr.1f0.de/patches/ffdshow/ffdshow_xvidcore_compiler_info.patch)), does anybody have any problem committing that?

Lastly, what was the decision regarding O3 vs O2?

[DJ_Phatic]

Have you tried PGS subs with ffdshow defaults lately? Cause I got no subs at all until I changed the smoothing method to something other than swscaler gaussian.

PGS subs appear to be working again with DXVA in rev3577.

Though think I will stick with MPC-HC decoders in Mediaportal for DXVA/subtitles for the time being.

[SamuriHL]

PGS subs appear to be working again with DXVA in rev3577.

Though think I will stick with MPC-HC decoders in Mediaportal for DXVA/subtitles for the time being.

Right, cause I think the checks were disabled.

[STaRGaZeR]

Choice is really helpful when troubleshooting...
If our goal is to be as close to the ffmpeg source as possible, then there's a lot more to strip out of ffdshow than libfaad. :D
We should wait for more input on this matter from the other devs.

By the way, nice work with the AAC integration! :)
Now give deband to the 64-bit folks :D

Fully agree. However who said our goal is to be as close to ffmpeg as possible? It's easier since we only have to update ffmpeg to add/fix/whatever stuff, but it's not the only thing in the world, too much ffmpeg drama is bad :D

Deband x64 is still waiting JoshyD's source code, without it I can't do jack, unless someone here rewrites those mmx functions :eek:

I have tried this build with some video with Real's cook audio, and it decode the cook with no problem. Thank you STaRGaZeR!

That build doesn't do anything about Cook, you should thank albain, he's the one who did it ;)

I did another benchmark, regarding KernelDeint this time:

ffdshow r3680, libmpeg2
Compiler Average fps
========= ===========
MSVC 2008 341
ICL 11.1.0.67 356
GCC 4.5.1 372

KernelDeint GCC 4.5.1 (http://xhmikosr.1f0.de/patches/ffdshow/ff_kernelDeint.dll_gcc451.7z)
KernelDeint ICL 11 (http://xhmikosr.1f0.de/patches/ffdshow/ff_kernelDeint.dll_ICL11.7z)
KernelDeint MSVC 2008 (http://xhmikosr.1f0.de/patches/ffdshow/ff_kernelDeint.dll_MSVC2008.7z)

Can someone else confirm these results and if yes should we remove the KernelDeint from the VS2008 solution file and perhaps the ICL11 solution file too?

I've also added the compiler info for Xvidcore (patch (http://xhmikosr.1f0.de/patches/ffdshow/ffdshow_xvidcore_compiler_info.patch)), does anybody have any problem committing that?

Lastly, what was the decision regarding O3 vs O2?

I'd remove it and use GCC instead, because of your results and because x64 can't be compiled with ICL11.

Don't commit the xvid change, I've done it in a better way plus organizing the versions window a bit.

And I'll asnwer your PM now, too much stuff yesterday :p

[_xxl]

I've also added the compiler info for Xvidcore (patch (http://xhmikosr.1f0.de/patches/ffdshow/ffdshow_xvidcore_compiler_info.patch)), does anybody have any problem committing that?

Lastly, what was the decision regarding O3 vs O2?

Xvidcore, yes commit. xvidcore, x264, ffmpeg and mplayer should only be compiled by GCC.

[_xxl]

Maybe all ffdshow's libs could be integrated inside ffdshow.ax. No more a lot of dll's. Why not?

[nevcairiel]

Statically linking ffmpeg on windows is not a good idea, and not supported upstream.

Why do the number of dlls matter anyway? You have an installer to take care of this. :)

[Midzuki]

^ BTW, why there is no ff_theora.dll since revision 30** ?

[clsid]

KernelDeint -> Removing MSVC/ICL is OK with me. Perhaps just disable building of it in the solution file. Optional compiling with MSVC may be useful for easier debugging if ever needed.

Deband x64 -> I think we should disable the option on x64 until the performance can be fixed. That should avoid the constant complaints about it now working.

[fastplayer]

Deband x64 is still waiting JoshyD's source code, without it I can't do jack, unless someone here rewrites those mmx functions :eek:
Yep, __m64 is a no-go for 64-bit CPUs... :(
While "researching", I noticed that the VLC guys recently committed gradfun to the 1.2.0-trunk. Here are the files:
gradfun.h (http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_filter/gradfun.h;h=4b30748b5178c2a8d1b6c2e6436ba2eb14936361;hb=HEAD)
gradfun.c (http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_filter/gradfun.c;h=761f69ba4db1d39de49fa22c14dc26da93ecb10b;hb=HEAD)
Maybe you could forward this to JoshyD, if you're in contact with him.

[STaRGaZeR]

KernelDeint -> Removing MSVC/ICL is OK with me. Perhaps just disable building of it in the solution file. Optional compiling with MSVC may be useful for easier debugging if ever needed.

Deband x64 -> I think we should disable the option on x64 until the performance can be fixed. That should avoid the constant complaints about it now working.

What about mp3lib, skal, tremor and theora? VP8 enabled by default?

On deband, I've hidden it from view in r3586.

Yep, __m64 is a no-go for 64-bit CPUs... :(
While "researching", I noticed that the VLC guys recently committed gradfun to the 1.2.0-trunk. Here are the files:
gradfun.h (http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_filter/gradfun.h;h=4b30748b5178c2a8d1b6c2e6436ba2eb14936361;hb=HEAD)
gradfun.c (http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_filter/gradfun.c;h=761f69ba4db1d39de49fa22c14dc26da93ecb10b;hb=HEAD)
Maybe you could forward this to JoshyD, if you're in contact with him.

In contact? I just asked for the code of one of his filters :D He has a x64 port of Gradfun2DB posted in his Avisynth x64 thread, the problem is that it comes without the source code and he's been MIA for several months and who knows if he's ever going to post it :(

[STaRGaZeR]

Ticket (https://sourceforge.net/tracker/?func=detail&aid=3071690&group_id=173941&atid=867363)

Added :)

[Sebastiii]

Added :)

Thanks for all improvements :)
Seb.

Ps: You didn't sleep ? :)

[hoborg]

Added :)

Thanks!

[fastplayer]

In contact? I just asked for the code of one of his filters :D He has a x64 port of Gradfun2DB posted in his Avisynth x64 thread, the problem is that it comes without the source code and he's been MIA for several months and who knows if he's ever going to post it :(
Argh. GPS implants should be mandatory...

[hoborg]

Hi.
This sample (http://www.volny.cz/hoborg/test.zip) will freeze durning playback if FFDshow DXVA decoder is in use.
It play fine using MPC-HC DXVA, MS VIDEO decoder or standard FFDShow h.264 decoder.

Anybody already try it?
I can report i have similar problem with well known killer sample - picture freeze after few secs, but audio continue.

Tested on Win7 + ATI 5770 + Cat. 10.8.

[NiFa]

Tested it and I can reproduce to problem.

Win7 + ATI HD4200 + Cat. 10.9

[STaRGaZeR]

Thanks for all improvements :)
Seb.

Ps: You didn't sleep ? :)

I did, I just wake up :p

Argh. GPS implants should be mandatory...

:D

[SamuriHL]

I need some help. A quick background and then my question. I just upgraded my AMD 4850 to a shiny new nVidia 450 (ASUS overclocked :D) on my AMD X2 4200 machine. W7 64 as always for me. Not an especially powerful machine but with DXVA she's all good for video playback. I've got the desktop set to 1080p/24. With the AMD 4850, everything was smooth as butter.

Now, with the 450, I opened up MPC-HC 64 bit with ffdshow configured for dxva and bitstreaming, and loaded up one of my MKV's. CPU usage spiked to max immediately and video was badly stuttering. After a *LOT* of troubleshooting, I have determined the exact cause. This is where I need some help. If ffdshow dxva has surface overlay enabled (which is needed for subtitles), that's when the CPU spikes and video stutters. If I turn that off, CPU usage is back down to a realistic 25-30%. This did NOT happen with the 4850. Does anyone have any ideas? Help?! :)

[STaRGaZeR]

nvidia drivers suck? :D

To all, testing time again! I've enabled libavcodec's floating point MP1,2,3 decoder instead of the integer one. It should play everything the old one des, but test it and report your findings.

Build: http://www.mediafire.com/?k8y1fakk2ayqoie

[SamuriHL]

Hey that wasn't very helpful! :p LOL! I know your feelings on DXVA in general but on that machine I don't have a lot of choice. Although CUDA decoding has been suggested as a possibility. Nonetheless, doesn't this surface overlay issue seem, I don't know, like an issue?? :D

[STaRGaZeR]

Dunno, you're the first one to report this. Also I don't know anything about DXVA, so meh.

[SamuriHL]

Yea, I'm just lucky that way these past 2 weeks I guess. :)

[SamuriHL]

I was able to setup RGB32 on that machine using CoreAVC to decode using CUDA. It doesn't help with VC-1 but at least I can get rid of DXVA on AVC now. That's something at least.

[STaRGaZeR]

Why did you change your card? You should have spent that money in a faster CPU IMO. Slow CPU = you need DXVA or CUDA = limitations and problems.

[SamuriHL]

Several reasons. The 4850 was not a good fit for the case it was in. It was enormously hot and loud. Plus I wanted bitstreaming on MKV's because there's no open source DTS-HD MA decoder. And PhysX for the casual gaming I do on that machine. Yes, a better CPU would be nice, but, I refuse to go AMD again so I'd want to replace the mobo and get an i5 minimum. I'm not ready to deal with all that at the moment. The way it's setup right now works quite well. I was just playing around with it. Video is smooth, bitstreaming works, and the machine is whisper quiet. No real complaints. At some point, yes, the mobo and cpu will get upgraded.

[XhmikosR]

@STaRGaZeR: thanks a lot for fixing the crash with the ICL11 builds! It was a crash I hit a lot of times.

[NiFa]

Could some one tell me how can I compile my own ffdshow? I would like to add checkbox to disable DXVA for interlaced material in DXVA settings, how do I do this?

[fastplayer]

Could some one tell me how can I compile my own ffdshow?
http://ffdshow-tryout.sourceforge.net/wiki/devel:building

[NiFa]

Can't someone make a pack which contais all needed softwares? I have no idea what softwares I need, because some parts of wiki seems to be outdated, and I can't find some of the mentioned softwares or then I'm just blind.

[XhmikosR]

The wiki is up to date, but its goal is not to teach you how to set up MSYS/MinGW. Maybe this (https://sourceforge.net/apps/trac/mpc-hc/wiki/How_to_compile_the_MPC#PartB:PreparingtheGCCenvironment) helps (it includes all the needed components regarding MSYS/MinGW).

[NiFa]

Do I need to use DirectX SDK feb 2010 or can I use newer? Also do I need to use Visualstudio 2008 or can I use 2010 version?

[Gleb Egorych]

I've enabled libavcodec's floating point MP1,2,3 decoder instead of the integer one. It should play everything the old one des, but test it and report your findings.

Haven't faced any problem, CPU usage seems to be the same. Removing forced 16-bit downconversion of decoded stream would be great.

[XhmikosR]

Do I need to use DirectX SDK feb 2010 or can I use newer? Also do I need to use Visualstudio 2008 or can I use 2010 version?

1) Yes you can
2) I don't see the ffdshow wiki mentioning Visual Studio 2010 somewhere so I don't know where you got that. ffdshow cannot be built with VS2010, at least not at the time of writing this post.

[NiFa]

So I need to use visual c++ 2008? Can I use express version?

[_xxl]

So I need to use visual c++ 2008? Can I use express version?

Yes, you can. Please read instruction how to compile ffdshow.

Don't forget that some parts are compiled by gcc and yasm.

[_xxl]

@stargazer69

/*.init = */decode_init,
/*.encode = */NULL,
/*.close = */NULL,
/*.decode = */decode_frame,
/*.capabilities = */CODEC_CAP_PARSE_ONLY,
/*.next = */NULL,
/*.flush = */flush,
/*.supported_framerates = */NULL,
/*.pix_fmts = */NULL,
/*.long_name = */NULL_IF_CONFIG_SMALL("MP1 (MPEG audio layer 1)")


decode_init,
NULL,
NULL,
decode_frame,
CODEC_CAP_PARSE_ONLY,
.flush= flush,
.long_name= NULL_IF_CONFIG_SMALL("MP1 (MPEG audio layer 1)")

If I remember correctly those modifications are required to build MSVC 2008 debug build. Can you please check it? :)

[NiFa]

I only want to add two features to DXVA.
-Possibility to disable DXVA with interlaced material
-AR correction when video resolution is 4:3, but PAR is 16:9

I'm trying really hard to learn how to do those changes, but it seems that I need to find out is scan type MBAFF or PAFF, how do I get this info and how I link it to so that if scan type MBAFF or PAFF it won't be decoded using DXVA? AR correction is another feature which I would like to put in ffdshow DXVA.

None of the tutorials I have read mention anything about DXVA, so I'm little lost at moment.

If someone wants help please post it here (http://forum.doom9.org/showthread.php?t=156977).

[STaRGaZeR]

If I remember correctly those modifications are required to build MSVC 2008 debug build. Can you please check it? :)

Will do. However, the last time I tried to build libavcodec with MSVC (debug or release) I couldn't because of errors, way before my changes.

EDIT: You're correct. MSVC needs that. But now there is a bigger problem. Line 935, aacdec.c

union float754 s = { .f = *scale };

error C2059: syntax error : '.'

Any ideas?

[fastplayer]

union float754 s = { .f = *scale };

error C2059: syntax error : '.'

Any ideas?
You probably tried it already but I still gotta ask:
What does the compiler say when you put an s in front of .f?
Like this:
union float754 s = { s.f = *scale };

[STaRGaZeR]

You probably tried it already but I still gotta ask:
What does the compiler say when you put an s in front of .f?
Like this:
union float754 s = { s.f = *scale };

Yep, that works. Only to find one more in g726, line 329 (error C2059: syntax error : '{'):

avctx->frame_size = ((int[]){ 4096, 2736, 2048, 1640 })[index];


This one can be fixed too, but it's ok to add this kind of custom code? I don't like it, well I don't like custom code at all, makes it more difficult to update ffmpeg and it's ugly :p

[fastplayer]

This one can be fixed too, but it's ok to add this kind of custom code? I don't like it, well I don't like custom code at all, makes it more difficult to update ffmpeg and it's ugly :p
Wait a sec. This custom code is only to make libavcodec "compatible" for MSVC, right? If yes, au revoir "custom code"!
If somebody needs a MSVC debug/release version of libavcodec, he or she can figure out how to circumvent those compile errors temporarily, IMO.

As for the 2nd error, I'd change it to (if I had to):
int tmp_array[] = { 4096, 2736, 2048, 1640 };
avctx->frame_size = tmp_array[index];
There's probably a more elegant solution but as I said, "custom code" turns me personally into an angry Bruce Banner... :D

[tetsuo55]

Maybe you could add the MSVC patches as IFDEF, and clearly mark it as ffdshow custom code for msvc.

That way it should be easier to keep in sync.

That said, changes like these might be accepted upstream if they make sense on GCC too.

[clsid]

In other places this is used for C99 code that MSVC doesn't like:
#if __STDC_VERSION__ >= 199901L
// original code
#else
// MSVC code
#endif

[STaRGaZeR]

Wait a sec. This custom code is only to make libavcodec "compatible" for MSVC, right? If yes, au revoir "custom code"!
If somebody needs a MSVC debug/release version of libavcodec, he or she can figure out how to circumvent those compile errors temporarily, IMO.

Yep. But this custom code (the .something stuff MSVC doesn't support like in here (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/libavcodec/aacdec.c?r1=3585&r2=3584&pathrev=3585)) is already in basically all decoders, making copy/paste updates impossible aka making ffmpeg updates a pain in the ass. I think nobody has compiled libavcodec with MSVC in a loooong time, otherwise this would be fixed. What to do?

[tetsuo55]

We compile libavcodec with msvc all the time over at MPC-HC, maybe you could take a look at the code?

[clsid]

The errors are only in the recently added AAC decoder. I don't mind any extra custom code to allow MSVC compilation.

[STaRGaZeR]

There are also unresolved externals because libavutil (cpu.c) is outdated, because it can't find log2f and exp2f, etc. Have you considered creating a new folder (like libavcodec_msvc or something like that) with all these changes to compile libavcodec with MSVC and keep the normal one clear?

[clsid]

That would mean extra work. Getting it to compile with MSVC is not a high priority right now. It will get fixed eventually.

[STaRGaZeR]

Yeah, also it wouldn't make much sense. Now that I've taken a closer look at it there's custom code everywhere, not related to MSVC compilation.

[_xxl]

Yeah, also it wouldn't make much sense. Now that I've taken a closer look at it there's custom code everywhere, not related to MSVC compilation.
That is true. FFdshow has a lot of custom code...:)

[Sebastiii]

hi STaRGaZeR,

I try to compil 3600 but i have an error, i build with the .bat (build_x86.bat), i go to try with the sln.
Thanks,
Seb.

Ps: i didn't know if it's 3600 that break the compil.
It's the innosetup, if i compil the .exe with .iss it's ok :)

Ok found it lol : in batch @cd bin\distrib\innosetup but for me it's @cd bin\distrib

Edit : Thanks for the fix :)

[STaRGaZeR]

Fixed :)

[rica]

Guys, i must have missed something.
ffdshow 3574 decodes DTSHD-MA; downsamples 96 to 48 but not 24 to 16 with libdts.
Is it correct?

[nevcairiel]

All it decodes is dts core, which only contains 48Khz samples. But at least it provides full bit depth in decoding, afaik (remember, lossy formats don't have a pre-defined bit depth, you should decode with as much precision as you can)

[rica]

Yes, that is still what it's doing. Thx.

[Ap3 n1nja]

Hi, I not sure if this goes here but there seems to be a certain problem getting ffdshow's AAC libavcodec to work with the KMPlayer. I think the problem might be with the internal KMP MKV Splitter since I tested it with MatroskaSplitter.ax and its internal MOV/MP4 splitter and it worked fine.

Versions Used:
KMPlayer 3.0.0.1438
ffdshow rev3600 20100925 xhmikosr icl11

[dann23]

I have a problem when using LAVFSplitter. External subtitles don't work when using ffdshow dxva and when I use normal ffdshow I can't choose beetwen external subtitles present in the same folder as the movie(one subtitles is choosen but I can't choose another one. I have no context menu present). I also posted in LAVFSplitter's thread but nevcairiel said that it's possible that ffdshows is the culprit.
Also is good to know that I'm using wmp11.

[dansrfe]

I'm still having major problems with .ASS or .SSA karoke subtitle tags showing up all over the place.

[Mr. Monte]

I just recently installed FFDSHOW 3572_20100913_clsid. I was using AVStoDVD for converting my MKV's to DVD5's. All of a sudden I was getting AVS script errors. Using graphedit, I was able to determine that FFDSHOW was no longer decoding DTS or AC3 audio. I looked at the configuration and libdts and liba52 is selected. Installing AC3Filter fixed the isues.

Is there anyway to determine why FFDSHOW stopped working with DTS & AC3 (works fine with AAC). Moreover, how to restore it?

TIA

[leeperry]

To all, testing time again! I've enabled libavcodec's floating point MP1,2,3 decoder instead of the integer one. It should play everything the old one des, but test it and report your findings.

Build: http://www.mediafire.com/?k8y1fakk2ayqoie
cool! if you could do the same for AC3/DTS, this would be really fantastic :)

[Keiyakusha]

STaRGaZeR
Just a little suggestion. I never saw floating-point build yet but if it will work, could you please keep both variants (16 and 32 bit) if 32bit any slower? Maybe it will be possible to add switch "libavcodec (16bit)" and "libavcodec (32bit)" like it is done for h264 in case of libavcodec and ffmpeg-mt. Also if you know better solution - just skip this post. Thanks.

[leeperry]

I never saw floating-point build yet but if it will work
the only reason to go 32fp for lossy audio is this: http://mp3decoders.mp3-tech.org/24bit.html

it provides a more accurate decoding w/ less rounding errors, very important if you down-upmix/resample/post-process/use Reclock. There isn't a single good reason to decode lossy audio to 16int.

[kieranrk]

the only reason to go 32fp for lossy audio is this: http://mp3decoders.mp3-tech.org/24bit.html

it provides a more accurate decoding w/ less rounding errors, very important if you down-upmix/resample/post-process/use Reclock. There isn't a single good reason to decode lossy audio to 16int.

Here there be audiophiles...

[dansrfe]

Don't most soundcards handle only 16 bit? I can definitely handle decoding to 32 bit fp but I was under the impression that windows or the soundcard automatically discards all that extra information or "downsizes" to 16 bit upon outputting to the speakers?

[SamuriHL]

No, I don't think so. Commercial Blu-ray players will do that if they don't detect PAP hardware that they support, but, Windows won't downsample by itself.

[leeperry]

Don't most soundcards handle only 16 bit? I can definitely handle decoding to 32 bit fp but I was under the impression that windows or the soundcard automatically discards all that extra information or "downsizes" to 16 bit upon outputting to the speakers?
DirectSound on Vista/W7 works in 32fp, so even w/o Reclock there'll be a SQ improvement...and madshi would explain it better, but it's better to decode lossy audio to 32fp and then use noiseshaping/dithering to 24int than decoding to 16int in the first place.
Here there be audiophiles
any kind of audio post-processing requires 32/64fp to avoid rounding errors(that's how accurate VST plugins are). I personally do a lot of post-processing on AC3/DTS in ffdshow in order to get a binaural stereo downmix.

[Midzuki]

Don't most soundcards handle only 16 bit?

That's a BIG "perhaps". :) OK, I myself do not have reliable statistics on that, but it's a fact that even an outdated frAudigy-2 can accept a 24-bit+96kHz input and transmit this directly to its Digital2Analog Converter. :cool:

[nevcairiel]

Yeah, quite alot of sound cards actually do support 24-bit these days.
And even if they don't, decoding to 32fp and then dithering down to 16bit is far superior to just decoding in 16bit directly.

Not everyone may notice the difference, but there certainly are people that do. And especially when you do alot of post-processing, a 16bit signal can be degraded quite heavily, and you might even hear it yourself.

[Reimar]

the only reason to go 32fp for lossy audio is this: http://mp3decoders.mp3-tech.org/24bit.html

it provides a more accurate decoding w/ less rounding errors, very important if you down-upmix/resample/post-process/use Reclock. There isn't a single good reason to decode lossy audio to 16int.

Are you really sure you understand that linked page? Because that will only work if someone used a MP3 encoder that takes > 16 bit as input and the decoder is somewhat matching. How many people do you think will have such files? Everyone else as soon as they use e.g. dithering to reduce the supposedly 24-bit output to 16 bit will actually reduce the accuracy from 16 to 15 bit (the lowest bit will be replaced by dithering, and the dithering will be based on pure noise, since the encoder did not have more than 16 bit input, anything beyond 16 bit the decoder produces can only be noise).
If someone wanted to do this, they'd have to add a flag indicating the number of bits the MP3 encoder used and then the decoder/ditherer would behave based on that - like this you'd always win, otherwise the loss from 16 -> 15 bit seems more critical to me than the potential e.g. 16 -> 18 bit win.

[madshi]

Here there be audiophiles...
You seem to miss the fact that libav decodes internally to floating point and then ROUNDS the decoded data down to int16. This is a very clear violation of digital processing laws and results in relatively high quantization errors. If libav would dither the floating point decoding results down to int16, you could argue about audiophiles bla bla. But what libav currently does is a middle sized catastrophe for audio quality.

[madshi]

Everyone else as soon as they use e.g. dithering to reduce the supposedly 24-bit output to 16 bit will actually reduce the accuracy from 16 to 15 bit (the lowest bit will be replaced by dithering, and the dithering will be based on pure noise
Incorrect. Dithering does not *replace* the lowest bit. You clearly don't understand how dithering works.

[Gleb Egorych]

I assume it's a known problem: bitrate calculation does not work with libav AAC decoder.

[nevcairiel]

Are you really sure you understand that linked page?

You clearly do not understand how decoding lossy audio works (nor the linked page, which clearly specifys how it works). The decoding process should produce as many bits of data as it can, and that does not depend on the bitdepth of the original source!

You seem to miss the fact that libav decodes internally to floating point and then ROUNDS the decoded data down to int16. This is a very clear violation of digital processing laws and results in relatively high quantization errors. If libav would dither the floating point decoding results down to int16, you could argue about audiophiles bla bla. But what libav currently does is a middle sized catastrophe for audio quality.

Actually i think the default internal MP3 decoder in libav is pure integer (and int16 at that), but yes, thats true for most other formats.

[leeperry]

Are you really sure you understand that linked page? Because that will only work if someone used a MP3 encoder that takes > 16 bit as input and the decoder is somewhat matching.
There's no bitdepth in lossy audio, and the higher it is at the decoding stage the closer you will be to the lossless integer source.

There's no point in decoding lossy audio in anything else than 32fp. You're making a truckload of rounding errors in 16int...There's a good reason if all the audio software always post-process in 32/64fp: avoiding useless rounding errors. Even media players such as foobar decode mp3 in 32fp, and so do liba52 and libdts...why not libavcodec? :(

I've been whining about it since forever, but apparently the libavcodec ppl don't care...maybe STaRGaZeR could hook us up w/ 32fp DTS, I don't care much for AC3 as liba52 sounds great(in 32fp at that) but I really don't like libdts...it sounds metallic, I very much prefer libavcodec.

[Keiyakusha]

the only reason to go 32fp for lossy audio is this: http://mp3decoders.mp3-tech.org/24bit.html

it provides a more accurate decoding w/ less rounding errors, very important if you down-upmix/resample/post-process/use Reclock. There isn't a single good reason to decode lossy audio to 16int.

Well if 32bit will be slower - I will be able to measure this. But speaking of quality, I'm sure me and all of my friends with different kind of hardware from cheaper to more expensive won't notice any difference between rounded 16bit and 32bit. In other words, all I care about is speed, everything else comes after that.

[leeperry]

if 32bit will be slower - I will be able to measure this. But speaking of quality, I'm sure me and all of my friends with different kind of hardware from cheaper to more expensive won't notice any difference between rounded 16bit and 32bit.
it wouldn't make a difference, even on a Pentium IV...actually, 32fp should be faster I think.

Don't be so sure that 32fp doesn't many an audible diff over 16int...especially if you're using DirectSound or Reclock resampling.

Anyway, STaRGaZeR didn't confirm whether he could fix DTS in libavcodec...libmad already does 32fp MP3 and liba52 32fp AC3.

I also wish the winamp2 DSP plugins in ffdshow were not converted to 16int both ways(I use a VST plugins wrapper), as 24int is entirely possible :/

[rack04]

How does ffdshow determine which output format, i.e. 16 bit int, 24 bit int, 32 bit int, or 32 bit fp if all the boxes on the output tab are checked?

[leeperry]

How does ffdshow determine which output format, i.e. 16 bit int, 24 bit int, 32 bit int, or 32 bit fp if all the boxes on the output tab are checked?
if the decoder outputs 32fp natively and if you have 32fp checked in ffdshow's output, it will be automatically picked over the others.

[STaRGaZeR]

STaRGaZeR
Just a little suggestion. I never saw floating-point build yet but if it will work, could you please keep both variants (16 and 32 bit) if 32bit any slower? Maybe it will be possible to add switch "libavcodec (16bit)" and "libavcodec (32bit)" like it is done for h264 in case of libavcodec and ffmpeg-mt. Also if you know better solution - just skip this post. Thanks.

Do you have a Pentium II or similar? If not, you should forget about the speed argument.

maybe STaRGaZeR could hook us up w/ 32fp DTS, I don't care much for AC3 as liba52 sounds great(in 32fp at that) but I really don't like libdts...it sounds metallic, I very much prefer libavcodec.

Nope, unless there is a strong negative from ffmpeg against this, in that case I'll consider it. Custom code sucks.

Reimar, since you're a ffmpeg developer, could you consider adding an option to bypass the float to int16 conversion you have at the end of your decoders? Easy, cheap and everybody is happy.

[nevcairiel]

Custom code only sucks when you use subversion trying to manage it .. what you do .. :P
Don't blame code for your version control shortcomings, imho :D

Anyhow, the patch to enable 32fp decoding of DTS is pretty short, but its more then a one line change to disable the downconversion.
Maybe one of the ffmpeg guys could shed some light on the reasons why its downconverting everything to int16 anyway

[madshi]

Maybe one of the ffmpeg guys could shed some light on the reasons why its downconverting everything to int16 anyway
An eternity ago I had asked both Benjamin Larsson (DTS) and Justin Ruggles (AC3 + E-AC3) about that and IIRC both said that native bitdepth output was planned for a future libav version. But that was ages ago. I had sent my eac3to patches to both of them, but neither was willing to apply them. So I keep on patching libav, year after year... :(

[Gleb Egorych]

Does Vista/7 mixer dither audio stream?

[STaRGaZeR]

Custom code only sucks when you use subversion trying to manage it .. what you do .. :P
Don't blame code for your version control shortcomings, imho :D

Custom code sucks the same on git, IMHO :D

[nevcairiel]

But keeping in sync with the upstream repository is trivial! :)

[STaRGaZeR]

I don't know git, but it can't be worse than svn :D

To all, please test r3602. Things to test:

a) Audio channel mapping is fine for 5.1 streams and above. Fine means the same as in previous revisions.
b) Yadif works fine. Please test on CPUs without SSSE3, SSE2 and MMX2, or any combination of them. If your CPU has SSE2 but no SSSE3 for example, test it. Fine means it doesn't crash and the speed is the same as before or within margin of error.

Build: http://www.mediafire.com/?l90nft4ccgam2o4

And to the devs, mplayer now only contains mp3lib, which is IMO not needed at all, with libavcodec and libmad. We can remove it and libmplayer will be gone.

[leeperry]

unless there is a strong negative from ffmpeg against this, in that case I'll consider it.
Put simply, they don't seem to care :o

And sorry to beat a dead horse(I know, that's my speciality :D), but would you have any idea how to enable PCM24/32 for winamp DSP plugins? the input/output is currently downconverted to 16int, which is a major bummer as there's many DX/VST plugins wrappers...and ffdshow is the perfect place for this kind of job :devil:

You can see tons of "int16_t"/"SF_PCM16" in those sections:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/audioFilters/winamp2/Twinamp2.cpp?view=markup&pathrev=1928
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/audioFilters/TaudioFilterWinamp2.h?revision=1609&view=markup&pathrev=1928

winamp2 DSP plugins work in PCM24/32 using the foobar wrapper: http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/Winamp_DSP_Bridge_(foo_dsp_winamp)
16-bit: low quality, failsafe. Choose this setting, if you encounter a problem while playback;
24-bit: hi-quality;
32-bit: highest quality.

I asked its author for help but he told me that the ffdshow code was quite messy and that he had no time to work on it :(

Christian Budde(a professional VST plugin coder) helped Haruhiko to iron out a few bugs in the winamp DSP plugins host code of ffdshow, and confirmed that PCM24/32 were entirely possible w/ winamp2 DSP plugins.

If anyone's interested, I could make a complete tutorial to VST awesomeness in ffdshow...including upmix/downmix matrixes based on Lexicon's Logic7 routines. The key is to calibrate their coefficients to your gear/brain. Its author, David Griesinger, is the living god of audio DSP for hometheater use.

After a bit of work, you can make very convincing stereo downmixes(very short FLAC samples):
http://www.mediafire.com/download.php?hzgj3fsco1gqsbf
http://www.mediafire.com/download.php?xrfcj9rm2od453k

b) Yadif works fine. Please test on CPUs without SSSE3, SSE2 and MMX2, or any combination of them. If your CPU has SSE2 but no SSSE3 for example, test it. Fine means it doesn't crash and the speed is the same as before or within margin of error.
I'm a noob at deinterlacing, but YADIF always gives me tons of combing...I was trying it on a 29.97fps NTSC source yesterday, and bingo still a combo feast. It works wonderfully in double frame rate mode, though...but it's not too handy in 89.91Hz.

One thing I've never understood about double frame rate deinterlacing is that it looks like frame interpolation...It really looks as if I were watching a 59.94fps source, when it should actually be 29.97*2 :confused:

A friend of mine is completely hooked to 1080i*2 on his projector, he finds the picture WAY smoother.

[kieranrk]

One thing I've never understood about double frame rate deinterlacing is that it looks like frame interpolation...It really looks as if I were watching a 59.94fps source, when it should actually be 29.97*2 :confused:

A friend of mine is completely hooked to 1080i*2 on his projector, he finds the picture WAY smoother.

Double frame rate is the *right* way to do it. That's what true interlaced looks like if you were watching it on a CRT. Just because there's a lot of 24/25/30p misuse out there and that many people are used to watching web video (or pirated video) at a max of 30p doesn't suddenly mean it's right.

[kieranrk]

There's no point in decoding lossy audio in anything else than 32fp.

Why not use 64fp (doubles); in fact why not use 128fp (long double); don't forget you're losing quality at each stage...

[leeperry]

Double frame rate is the *right* way to do it. That's what true interlaced looks like if you were watching it on a CRT. Just because there's a lot of 24/25/30p misuse out there and that many people are used to watching web video (or pirated video) at a max of 30p doesn't suddenly mean it's right.
I know what 24fps looks like, same goes for 25 and 29.97....29.97 double frame rate deinterlace looks like 29.97 interpolated to 59.94 to my eyes. Trimension DNM all the way.
Why not use 64fp (doubles); in fact why not use 128fp (long double); don't forget you're losing quality at each stage...
my favorite audio player(Lilith) decodes all lossy audio in 64fp, and so are its volume attenuator and VST plugins pipeline. SQ is amazing.

http://thumbnails22.imagebam.com/6979/c05f0669780253.gif (http://www.imagebam.com/image/c05f0669780253)

But right now, libavcodec DTS and VST plugins are stuck to 16int in ffdshow :(

[kieranrk]

I know what 24fps looks like, same goes for 25 and 29.97....29.97 double frame rate deinterlace looks like 29.97 interpolated to 59.94 to my eyes. Trimension DNM all the way.

my favorite audio player(Lilith) decodes all lossy audio in 64fp, and so are its volume attenuator and VST plugins pipeline. SQ is amazing.

http://thumbnails22.imagebam.com/6979/c05f0669780253.gif (http://www.imagebam.com/image/c05f0669780253)

But right now, libavcodec DTS and VST plugins are stuck to 16int in ffdshow :(

Clearly you don't understand the difference between interlace and progressive then....

I'm glad you enjoy your 64-bit double placebo. The rest of us live in reality.

[leeperry]

they took a 29.97fps progressive source, once properly deinterlaced it should be reconstructed to 29.97 progressive...no need for frame interpolation. anyway, I don't care for interlaced stuff...I have a bunch of poorly authored DVD's using it, that's all.

oh yes, placebo...good thing I didn't tell you about software induced jitter (http://www.cicsmemoryplayer.com/index.php?n=CMP.03Jitter), I don't think you'd be ready for that just yet.

and in case you were wondering, you can measure it (http://www.phasure.com/index.php?topic=692.0) too...so much for placebo.

even a 11yo girl can hear the difference (http://www.audioasylum.com/forums/pcaudio/messages/2/21586.html), but she has better hearing than you and I.

foobar's volume attenuator also works in 64fp, just like all the pro-audio software....anyway, my original point was that 16int for lossy audio decoding and post-processing butchers the SQ.

[_xxl]

And to the devs, mplayer now only contains mp3lib, which is IMO not needed at all, with libavcodec and libmad. We can remove it and libmplayer will be gone.
Remove it. It is hard to maintain.

[STaRGaZeR]

I'm a noob at deinterlacing, but YADIF always gives me tons of combing...I was trying it on a 29.97fps NTSC source yesterday, and bingo still a combo feast. It works wonderfully in double frame rate mode, though...but it's not too handy in 89.91Hz.

One thing I've never understood about double frame rate deinterlacing is that it looks like frame interpolation...It really looks as if I were watching a 59.94fps source, when it should actually be 29.97*2 :confused:

A friend of mine is completely hooked to 1080i*2 on his projector, he finds the picture WAY smoother.

First, please do not parrot your feature request/bug fixes/whatever each time you have the chance. It's annoying, and this is not the first time I tell you this.

Second, you should really learn what interlaced video is. If you have 29,97fps pure interlaced content you have 59,94fps of temporal information there. Outputting 29,97fps is an abortion, but needed in some cases. That's why deinterlacers have that option.

Remove it. It is hard to maintain.

OK. What about theora? It hasn't been included in the installer for quite some time, why is still there?

[Astrophizz]

That XXHighEnd developer and the people that buy into his overpriced software sound a bit loony to me. You can still measure something with a sensitive device and yet not be able to sense a difference and so you would be subject to a placebo effect. I could point out the differences in spectral patterns of two stars to determine that one is of slightly different composition, but I could never see the difference with my eyes.

[leeperry]

You can still measure something with a sensitive device and yet not be able to sense a difference and so you would be subject to a placebo effect. I could point out the differences in spectral patterns of two stars to determine that one is of slightly different composition, but I could never see the difference with my eyes.
Of course, many FREE audio engines provide the same sort of low jitter(cMP/Reclock/Lilith)...I couldn't care less about XXHighEnd myself. Did you compare all the media players, do they sound the same to you? Jitter is real, and far from placebo.
this is not the first time I tell you this.
If you had a bugtracker anyone cared about, this wouldn't be happening...bumping bugfixes requests is the only chance to see anything happening(just like MPC).

I've asked three very skilled audio plugins coders for help and they've all told me that the ffdshow audio code was a bug feast(full of syntax errors and beginners mistakes) and a huge mess...so I guess this is not going to change anytime soon. They were even wondering how it could be working at all :confused:

ffdshow is a lost cause for studio grade audio, atm it's just a toy to watch movies in WMP...sorry for rubbing it in http://t0.gstatic.com/images?q=tbn:0qtMKZwl3EPf5M

[fastplayer]

OK. What about theora? It hasn't been included in the installer for quite some time, why is still there?
clsid disabled it some time ago in the hope that someone would update it. IIRC the current version in the trunk is hopelessly outdated.

[nm]

I'm a noob at deinterlacing, but YADIF always gives me tons of combing...I was trying it on a 29.97fps NTSC source yesterday, and bingo still a combo feast. It works wonderfully in double frame rate mode, though...

I haven't seen yadif leaving residual combing in neither single nor double-rate mode if the spatial deinterlacing check is enabled (not skipped, modes 0 and 1 in the MPlayer implementation). Do you have a sample clip?

[leeperry]

I haven't seen yadif leaving residual combing in neither single nor double-rate mode if the spatial deinterlacing check is enabled (not skipped, modes 0 and 1 in the MPlayer implementation). Do you have a sample clip?
I didn't have it disabled, I'll try to come up w/ a sample.

so videos shot interlaced actually have 59.94fps, great! that would explain why my friend is so hooked to 1080i concerts on his projector...but I believe he also likes 1080i movies, that can't possibly have more than 24fps AFAIK(IVTC put aside).

[_xxl]

OK. What about theora? It hasn't been included in the installer for quite some time, why is still there?

If you can update it ok. If not remove it.

x264 should be updated to latest, I can t update it anymore....

[Reimar]

An eternity ago I had asked both Benjamin Larsson (DTS) and Justin Ruggles (AC3 + E-AC3) about that and IIRC both said that native bitdepth output was planned for a future libav version. But that was ages ago. I had sent my eac3to patches to both of them, but neither was willing to apply them. So I keep on patching libav, year after year... :(

I think some were changed. The biggest issue is that the format conversion inside the codec uses some tricks to be a lot faster, particularly on systems with slow FPU like ARM. Just removing them would mean that FFmpeg would get a lot slower on these systems.
And for FFmpeg speed (even on non-mainstream platforms) is most important than output resolution.
But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.

[madshi]

I think some were changed. The biggest issue is that the format conversion inside the codec uses some tricks to be a lot faster, particularly on systems with slow FPU like ARM. Just removing them would mean that FFmpeg would get a lot slower on these systems.
And for FFmpeg speed (even on non-mainstream platforms) is most important than output resolution.
I understand. I'm just wondering why there isn't a simple (compile time) configuration switch for activating "native" output. I did try to get such a switch added to the (E-)AC3 and DTS decoders, but my patches were declined.

[Reimar]

Everyone else as soon as they use e.g. dithering to reduce the supposedly 24-bit output to 16 bit will actually reduce the accuracy from 16 to 15 bit (the lowest bit will be replaced by dithering, and the dithering will be based on pure noise
Incorrect. Dithering does not *replace* the lowest bit. You clearly don't understand how dithering works.

Bad choice of words maybe. But to clarify: If you take a 16 bit input, add random bits to expand it to 24 bit and then dither that to 16 bit the dithering will have added noise. If the encoder never had more than 16 bit to start with, anything more than 16 bit in the decoded output can't be much more than noise (I guess this is not 100% true since the encoder can "expand" the input data to more than 16 bit by knowing how audio data is "supposed" to look).

[madshi]

If you take a 16 bit input, add random bits to expand it to 24 bit
What are you talking about? I don't think anybody is doing that.

If the encoder never had more than 16 bit to start with, anything more than 16 bit in the decoded output can't be much more than noise
I'm not really sure if you understand how lossy encoding/decoding works. Look, the encoder gets samples in the time domain, but encoding is done in the frequency domain (for lossy formats). After conversion to frequency domain, you end up with floating point data with full precision. The precision is not limited to 16bit here, because the conversion to frequency domain is a complex mathematical process. In the next step the encoder compresses the frequency domain audio data. Later, when you decode that, you again get floating point frequency data back. This will not be identical to the input data, of course, since the encoder is lossy. The decoder converts the frequency data back to time domain, which means that you end up with *full precision* floating point time domain data. Because of that you cannot say that only 16bit contain data and the rest is noise. That doesn't make any sense. The native output of a lossy decoder is usually *full precision* floating point. This data will only be an approximation of the original input data, but still it is full precision. You can't say that the data is only 16bit and the rest is noise. That's not true. After decoding, the data is floating point, not 16bit. The decoder doesn't even *try* to reproduce the original 16bit PCM data. Instead the decoder tries to reproduce an approximation of the original frequencies. And it does so in full floating point precision. Of course the decoding result will never sound better than the 16bit original, though, because it's only an approximation.

[clsid]

I am OK with removing Theora and mp3lib.

[kieranrk]

But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.

I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).

[nevcairiel]

I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).

You realize that it already decodes in full floating point? All we basically ask for is to move the conversion to int16 from the decoder to ffdshow. If you're happy with int16, it wouldn't change much for you at all, but if you're not, you can select another bitdepth for output, and you get higher quality.

No downsides, just added value. Why are you arguing?

[leeperry]

I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).
A troll is a troll, but troll feeding can be fun sometimes.

madVR brings world class PQ, and ffdshow sub-par consumer SQ...you're watching your videos in YV12 OVERLAY point resize on an ATi I presume http://forum-images.hardware.fr/images/perso/smoking.gif

All it needs is a few fixes, it will not worsen the SQ...at worst, it'll sound the same to your ears. Point of the matter is that either the few active coders don't care(libavcodec) or can't fix it due to an unmanageably messy code(ffdshow audio) so it's a lost cause. WYSIWYG.

[madshi]

Why are you arguing?
Because he evidently does not understand the basic laws of digital audio processing.

[kieranrk]

Because he evidently does not understand the basic laws of digital audio processing.

Having written a decoder for a perceptual audio format (with floating point transforms) I can tell you that's not the case.

All I'm saying is that the people arguing for float output because of "higher quality" are wrong. It is also laughable to see leeperry's talk of 64bit float - I can guarantee the decoder from the audio codec is 16-bit int or possibly 32-bit float at most. As reimar said the encoder had most likely 16-bit input in the first place so insisting on float producing a higher quality is an invalid argument. The LSBs of audio are generally noise anyway.

Feel free to also add the slowest but "highest quality" DCTs for mpeg-2 video and other codecs while you're at it. Also rewrite ffmpeg's MDCT to use 64-bit float since it "only" uses 32-bit float.

[madshi]

Having written a decoder for a perceptual audio format (with floating point transforms) I can tell you that's not the case.
Then you do know that every time you reduce audio bitdepth, you have to apply dithering, if you don't want to introduce quantization noise. Do you know that, or do you not? Are you aware that libav violates this basic processing law, or are you not aware of that?

All I'm saying is that the people arguing for float output because of "higher quality" are wrong.
No, they are right. Because of the simple reason that libav currently does not *dither* down to 16bit, but they *round* down the internal float32 decoding data to 16bit int. Which is a violation of audio processing laws and adds quantization noise. If libav correctly dithered down to 16bit, there would be little point to ask for floating point output. Not for ffdshow, at least.

[kieranrk]

...

Read what Reimar said.

[leeperry]

It is also laughable to see leeperry's talk of 64bit float - I can guarantee the decoder from the audio codec is 16-bit int or possibly 32-bit float at most.
http://www.sonicspot.com/lame/history.html
found bugs in some sections when using 32 bit floating point. Default is now back to 64bit floating point.
Lilith decodes MP3 in 64fp and processes attenuation/VST plugins in 64fp as well...just like any serious pro-audio app. The higher the resolution, the less distorted the tiny details and phase coherence will be.

Reclock provides 53bit volume attenuation and bit-perfect float/integer conversions(they all pass the HDCD flag and were looked over by WingFeather -a pro VST plugin coder from diyaudio.com-, James and yesgrey).

I use a low jitter 24/96 transport w/ Reclock via a bit-perfect audio renderer, and my two bottlenecks are libavcodec for DTS and the VST plugins processed in 16int...Some call it parroting, I call it uncalled for and a damn shame as the chain is only as strong as its weakest link. But nothing ever works the way it should thanks to Murphy's Law, so that's no big deal.

[STaRGaZeR]

If you can update it ok. If not remove it.

x264 should be updated to latest, I can t update it anymore....

clsid disabled it some time ago in the hope that someone would update it. IIRC the current version in the trunk is hopelessly outdated.

I don't care about Theora really, the best thing is to remove it IMO. libavcodec handles it just fine. I'll do it. clsid, I can't update ICL10 project files, sorry about that.

I think some were changed. The biggest issue is that the format conversion inside the codec uses some tricks to be a lot faster, particularly on systems with slow FPU like ARM. Just removing them would mean that FFmpeg would get a lot slower on these systems.
And for FFmpeg speed (even on non-mainstream platforms) is most important than output resolution.
But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.

I agree with madshi, the best solution would be a compile time option. Very few lines of code to make everyone happy. Can you make those patches and send them, madshi?

[STaRGaZeR]

If you had a bugtracker anyone cared about, this wouldn't be happening...bumping bugfixes requests is the only chance to see anything happening(just like MPC).

I've asked three very skilled audio plugins coders for help and they've all told me that the ffdshow audio code was a bug feast(full of syntax errors and beginners mistakes) and a huge mess...so I guess this is not going to change anytime soon. They were even wondering how it could be working at all :confused:

ffdshow is a lost cause for studio grade audio, atm it's just a toy to watch movies in WMP...sorry for rubbing it in

Stop the presses, a freak wants studio grade stuff for free ASAP!!! :D

lol, you talk like if it were my responsability or something. I was going to fix it, but now I don't feel like it. Enjoy the wonderful 16-bit integer output, troll :)

[fastplayer]

libavcodec handles it just fine.
Yep, libavcodec seems to be the solution for every "problem" lately :D

[leeperry]

Stop the presses, a freak wants studio grade stuff for free ASAP!!! :D

lol, you talk like if it were my responsability or something. I was going to fix it, but now I don't feel like it. Enjoy the wonderful 16-bit integer output, troll :)
hehe, yeah exactly...can you please make libavcodec and the winamp2 plugins output 8int? that'd be the shiznit, and that'd make kieranrk happy too :)

I don't think I'm the troll here, but the french and british have never managed to get along nicely...that's what hundred years of history are teaching us.

3 highly skilled coders(Vincent Burel, Wingfeather and Christian Budde) said that ffdshow shouldn't even work as is...but surely you could fix it, I believe you. I really do.

[Midzuki]

I was going to fix it,

I seriously doubt that. :devil:

[STaRGaZeR]

Cool, I can own our two resident trolls in one shot :D

http://thumbnails4.imagebam.com/9980/0d2e8d99792836.jpg (http://www.imagebam.com/image/0d2e8d99792836)

Winamp works with 32-bit integer max, and there you have it working with a simple equalizer. If you want a video of it working, just let me know :)

[avih]

hehe, yeah exactly...can you please make libavcodec and the winamp2 plugins output 8int? that'd be the shiznit, and that'd make kieranrk happy too :)

I don't think I'm the troll here, but the french and british have never managed to get along nicely...that's what hundred years of history are teaching us.

3 highly skilled coders(Vincent Burel, Wingfeather and Christian Budde) said that ffdshow shouldn't even work as is...but surely you could fix it, I believe you. I really do.
Dude, take it easy, you've made your point. Please try to lower the volume of your posts and stay closer to the topic.

Thanks.

[leeperry]

Cool, I can own our two resident trolls in one shot [..]
Winamp works with 32-bit integer max, and there you have it working with a simple equalizer. If you want a video of it working, just let me know :)
What are you trying to prove exactly? You obviously set the ffdshow sound processing bitdepth higher than 16int, and the 16int off the decoder and winamp2 DSP plugin are being resampled to 32int/32fp(depending on what you chose).

I've inserted the Ozone4 bitmeter in MPC Classic between ffdshow and Reclock, and set ffdshow to 32fp:
DTS in ffdshow/libavcodec: http://thumbnails27.imagebam.com/9980/63349e99798776.jpg (http://www.imagebam.com/image/63349e99798776)
DTS in ffdshow/libdts: http://thumbnails24.imagebam.com/9980/e09c2499798781.jpg (http://www.imagebam.com/image/e09c2499798781)
DTS in ffdshow/libdts + a winamp2 DSP wrapper>VST plugin in ffdshow: http://thumbnails15.imagebam.com/9980/673bdf99798778.jpg (http://www.imagebam.com/image/673bdf99798778)

both libavcodec and the winamp2 DSP plugins are processed in 16int and trim the 8 least significant bits...but nice try.
Dude, take it easy, you've made your point. Please try to lower the volume of your posts and stay closer to the topic.

Thanks.
Sorry for that, I know that posting in the ffdshow thread is a waste of time. Won't happen againhttp://forum-images.hardware.fr/images/perso/the%20bloodhound%20gang.gif

[Astrophizz]

So, if I understand correctly, there is no intent to have libav dither to 16 bit?

[diizzy]

While this 16-bit int vs * float seems to get people a bit defensive I would like to ask how "inaccurate" is it really? Given that many formats except HD formats are 16-bit or even lower the degradation should be minimal or none at all nor do you really know if the encoder used a higher precision during encoding right? As far as I know most people use analogue cabling at least to the speakers you would also introduce further degradation since there's no digital correction of any kind. Also having in mind that speakers or headphones usually don't have a flat frequency curve this would sound degrade even further. While I do agree that precision is a good thing in general and that it may / may not make a huge performance impact I also understand if some say that rounding doesn't matter since the sound will get dirty on the way to your ears. Fine, audio processing should be lossless but interpolating which might happen since you have more precision (and then at some point round it) than during encode time might not be a great solution either.
Am I missing something here?

[STaRGaZeR]

What are you trying to prove exactly? You obviously set the ffdshow sound processing bitdepth higher than 16int, and the 16int off the decoder and winamp2 DSP plugin are being resampled to 32int/32fp(depending on what you chose).

http://i296.photobucket.com/albums/mm179/moistmuffin/picard-facepalm.jpg

Every option in sound processing was checked. Every option in the output section was checked. It seems you don't get that I've modified ffdshow to process winamp plugins in 24-bit (output is zeroed to 32-bit) instead of 16-bit here in my system, by changing "tons of "int16_t"/"SF_PCM16" in those sections" into something else following your own words. Too bad I couln't get 32-bit to work, everything was fine but the audio returned from the plugin was untouched. Just a FYI:

int (*ModifySamples)(struct winampDSPModule *this_mod, int16_t *samples, int numsamples, int bps, int nch, int srate)

Notice that little int bps? 16, 24, etc. etc. ;)

Sorry for that, I know that posting in the ffdshow thread is a waste of time. Won't happen again

Someone wanna bet on this? :D

[Midzuki]

Cool, I can own our two resident trolls in one shot

As Palpatine surely would say,

"Troll is a point of view".

Also, you cannot deny that many devilopers can be scientifically :) defined as "the trolls who got there first". :rolleyes:

[tetsuo55]

While this 16-bit int vs * float seems to get people a bit defensive I would like to ask how "inaccurate" is it really? Given that many formats except HD formats are 16-bit or even lower the degradation should be minimal or none at all nor do you really know if the encoder used a higher precision during encoding right? As far as I know most people use analogue cabling at least to the speakers you would also introduce further degradation since there's no digital correction of any kind. Also having in mind that speakers or headphones usually don't have a flat frequency curve this would sound degrade even further. While I do agree that precision is a good thing in general and that it may / may not make a huge performance impact I also understand if some say that rounding doesn't matter since the sound will get dirty on the way to your ears. Fine, audio processing should be lossless but interpolating which might happen since you have more precision (and then at some point round it) than during encode time might not be a great solution either.
Am I missing something here?
indeed, i want to see some scientific research done on this.

We can output the wav files and compare them right? so whats the difference?

When madshi had to prove his renderer does better chroma scaling he made a screenshot comparison, and i've seen tools that can highlight the pixels that the better scaling affects.
the same should be possible for audio, no need to involve ears or speakers. just the pure wave, is it different or not, and if so where.

[kieranrk]

just the pure wave, is it different or not, and if so where.

If you want to show better chroma upsampling then you show a picture; if you want to show better audio quality you have to do it with an audio track.

[STaRGaZeR]

Some new tests with O2 and O3:

Sample 1: Blu-ray, 1080p24, ~35Mbps

O2 --> 178,12fps
O3 --> 182,43fps

Sample 2: Blu-ray, 1080i30, ~35Mbps

O2 --> 166,9fps
O3 --> 169,9fps

Sample 3: Big Buck Bunny, 720p24, ~2,5Mbps

O2 --> 672.06fps
O3 --> 677.42fps

1-2% difference. What do you think about changing it? Binaries are ~25% smaller with GCC 4.5.1

[madshi]

While this 16-bit int vs * float seems to get people a bit defensive I would like to ask how "inaccurate" is it really? Given that many formats except HD formats are 16-bit or even lower the degradation should be minimal or none at all nor do you really know if the encoder used a higher precision during encoding right? As far as I know most people use analogue cabling at least to the speakers you would also introduce further degradation since there's no digital correction of any kind. Also having in mind that speakers or headphones usually don't have a flat frequency curve this would sound degrade even further. While I do agree that precision is a good thing in general and that it may / may not make a huge performance impact I also understand if some say that rounding doesn't matter since the sound will get dirty on the way to your ears. Fine, audio processing should be lossless but interpolating which might happen since you have more precision (and then at some point round it) than during encode time might not be a great solution either.
Am I missing something here?
First of all we're not talking about interpolation here. All we're (some of us are) asking about is to do the math as precise as possible, which in the worst case should sound equal to doing the math unprecise, and in the best case should sound noticeably better.

Next, you're saying that most non-HD formats are 16bit, which is simply not true. AC3 and DTS are non-HD formats and perfectly support 24bit encodings. There's even a DTS header field which tells you which bitdepth was fed to the encoder. And from my experience there are plenty of 24bit DTS encodings out there, and I'm not talking about DTS-HD here. For AC3 we will never know which bitdepth was fed to the encoder, but the encoder also happily encodes 24bit sources. So it's a fair guess that many studio created AC3 tracks were also created from 24bit sources.

I've done tests myself with rounding vs. dithering. Ok, I've done them at a lower bitdepth than 16bit to make the difference very easily audible and the difference was big. Of course with 16bit the difference is much smaller. But still, rounding is scientifically and mathematically worse than dithering. And libav rounds down every DTS and AC3 audio track to 16bit, no questions asked.

indeed, i want to see some scientific research done on this.
Easy, the web is full of proof that dithering is needed. E.g. this is a nice starting point:

http://www.users.qwest.net/~volt42/cadenzarecording/DitherExplained.pdf

[tetsuo55]

That document clearly shows that a 24bit (lossless?) source benefits from 24bit output or dithering over truncation.
However what kierank seems to suggest is that lossless codecs seem to expect the truncation, the encoder/decoder psy optimises the stream to not become ugly like the examples in the document.

For the argument to be settled, the same test as explained in that document should be repeated (by either side of the argument) but this time using a typical lossy sample.

[madshi]

However what kierank seems to suggest is that lossless codecs seem to expect the truncation, the encoder/decoder psy optimises the stream to not become ugly like the examples in the document.
No, I don't think that's what he meant. It would be wrong, anyway. I think what he believes is that when 16bit int sources are fed into a lossy encoder, the decoder already has noise in the lower 8bit of a 24bit signal, so the signal can be truncated/rounded without side effects. I don't agree with that at all, and the paper I linked to has a clear opinion on this, as well:

> If the signal has had any processing happen to it
> at higher bit depths then choose to add dither

This is exactly what we're talking about here: "16bit int source -> lossy encoding -> lossy decoding -> 16bit int output". This processing chain has processing steps in a higher bit depth (floating point in the case of DTS and AC3), so dithering needs to be added when converting the floating point decoding results back to int16.

Furthermore, what kieranrk conveniently ignores is that AC3 and DTS tracks were often encoded directly from true 24bit studio masters.

[fastplayer]

1-2% difference. What do you think about changing it? Binaries are ~25% smaller with GCC 4.5.1
Could these 1-2% - for example, for people with low CPU specs - mean the difference between playable and stutter? Why not switch to O2, wait a few weeks, see what reaction we get and decide then finally? As long as the people don't shout "Hang the bastards!", we're good :D
By the way, what effect has O2 vs. O3 on compile/build time?

[Reimar]

I agree with madshi, the best solution would be a compile time option. Very few lines of code to make everyone happy. Can you make those patches and send them, madshi?

While I think it's worth a try (with some convincing it might get accepted in FFmpeg), this definitely is not the best option.
What I expect the developers to want you to do is to only support float output for decoders that use float internally, but also add scale/bias options so that decoders that are capable of it will apply these to the output "for free", and then use that to implement a very fast float -> 16 bit int conversion outside the codec like the one that is currently done inside it (also means you get volume control for free).
As you can see this will be a bit of effort, just deciding on the precise design will take some time.

[madshi]

Adding scale/bias options sounds like a useful idea if you really need to squeeze out the last bit of performance on very slow hardware. But scale/bias options would also be useful if the decoders keep on outputting int16. So I don't think that changing the output data format and adding scale/bias options are (or have to be) connected in any way.

[Reimar]

Adding scale/bias options sounds like a useful idea if you really need to squeeze out the last bit of performance on very slow hardware. But scale/bias options would also be useful if the decoders keep on outputting int16. So I don't think that changing the output data format and adding scale/bias options are (or have to be) connected in any way.

Let me try to make this more clear: scale/bias is _required_ to avoid a (on some hardware massive, IIRC > 50%) performance regression for the float->int16 conversion if the decoders output native float.
That is very unlikely to be accepted by FFmpeg developers.
Selectable codec output format (either at run- or compiletime) might be accepted, but it is not an ideal solution (more a quick hack) and is likely to be treated as such during review.

[STaRGaZeR]

Could these 1-2% - for example, for people with low CPU specs - mean the difference between playable and stutter? Why not switch to O2, wait a few weeks, see what reaction we get and decide then finally? As long as the people don't shout "Hang the bastards!", we're good :D
By the way, what effect has O2 vs. O3 on compile/build time?

I can't answer that with a system like mine, but considering that 2% difference I got in all cases: if your CPU is slow and can only reach 25fps during the most CPU intensive parts you'd get 24,5fps with O2 instead. Will that be enough for stutter free playback? Not sure. However if people have that kind of perfomance there's no point in using ffdshow, they should be using a faster decoder or DXVA. I like that trial period, will do that. x64 builds use O2 BTW.

And I can't really measure compile time, I'm bottlenecked by the hard drive :p

[fastplayer]

ffdshow_installer.iss (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/bin/distrib/ffdshow_installer.iss?view=markup)
Line 326 is obsolete:
Name: "audio\mp3\mp3lib"; Description: "mp3lib"; Components: ffdshow; Flags: unchecked exclusive

[dansrfe]

This is kind of off-topic for the discussion at hand however i just want to point out that ass karoke support seems broken in ffdshow because while rendering I see tags all over the place.

[STaRGaZeR]

This is kind of off-topic for the discussion at hand however i just want to point out that ass karoke support seems broken in ffdshow because while rendering I see tags all over the place.

It's a known problem. Plus you just said it here (http://forum.doom9.org/showthread.php?p=1446306#post1446306). Don't post the same bugs over and over again, it'll only slow down the process. It'll eventually be fixed by someone.

[Midzuki]

...

can't fix it due to an unmanageably messy code...

... so it's a lost cause. WYSIWYG.

I was bored :), and so I hex-edited ffdshow.ax r3562, so that it couldn't connect anymore to Windows DVD Navigator (qdvd.dll) http://forum.doom9.org/images/icons/icon3.gif. YES!, the trick did work :) :cool: , BUT...

well, ... :rolleyes: :p

now, the "multi-purpose" pin of the raw video filter connects to the output pin of the audio processor!

:readrule: :readrule: :readrule:

http://forum.videohelp.com/attachments/3656-1285826143/ffdshow_is_insane.png

P.S.: This post is dedicated to Keiyakusha ;)

[rpm7200]

lfe crossover doesn't work with surround audio files. please fix it. i need lfe crossover.

[nevcairiel]

Hey,

i noticed the other day that the audio delay doesn't work with bitstreaming, at least not with all bitstreaming formats.
I set a delay to fix A/V sync with my TV, and it was all peachy with PCM. But when bitstreaming AC3 for example, i get no sound at all anymore.
It seemed to work when streaming DTS-HD, but not with DTS.. I can run more tests on other formats if that helps.

[Sebastiii]

Hey,

i noticed the other day that the audio delay doesn't work with bitstreaming, at least not with all bitstreaming formats.
I set a delay to fix A/V sync with my TV, and it was all peachy with PCM. But when bitstreaming AC3 for example, i get no sound at all anymore.
It seemed to work when streaming DTS-HD, but not with DTS.. I can run more tests on other formats if that helps.

I also remark this when i use reclock, but without it, it's ok :)
Doesnt know what happen lol.

[v0lt]

You can add support for FOURCC 'png '? It is used in the mov-files. I used the same decoder, which decodes the "PNG1" and "MPNG". I substituted the FOURCC in the splitter, but it's not the best solution.

mov-png_example (http://www.mediafire.com/?dtglgex8vonk89d)

I wanted to do the same "jpeg" (ffdshow_mediaguids.h, section //quicktime), but do not completely understand how to add changes in TglobalSettings.cpp.

[dansrfe]

@ Midzuki
How do I do the same thing you did with the ffdshow audio processor outputting to raw?

Thanks!

[Midzuki]

@ dansrfe:

1) patch a copy of ffdshow.ax ;
2) unregister the original ffdshow.ax ;
3) hide the original ffdshow.ax in a temp folder,
move the modified .ax into ffdshow's folder ;
4) register the patched .ax file ;
5) start playing a DVD with MPC,
then press the pause button ;
6) run Graphstudio, press CTRL + G, click "Connect" ;

N.B.: I configured MPC to "prefer" ffdshow audio processor, since its default merit status is "DO_NOT_USE".

P.S.: Several weeks ago, Keiyakusha tried to convince that "it would be very bad" if ffdshow had dedicated standalone filters, without shared capabilities & settings.
Now, let's see whether he will change his mind. :)

[Keiyakusha]

Not really. I don't have anything against "dedicated" filters or something. I just don't want to see things like subtitles rendering removed from raw filter functionality.

[Gleb Egorych]

As I understand, revsion 3608 reverts 3589, i.e. mpeg decoders are now integer again.

[clsid]

Nope, they are still float.

[Gleb Egorych]

For example, all changes made in mpegaudiodec.c with 3589 are reverted with 3608. But seems these changes are relevant to disabled decoders and don't touch float decoders.

[hoborg]

MOV PCM problem

Hi.
I have problem with playback of few MOV files from Canon IXUS 200 IS.
It play in wierd slow motion in graphstudio - 2.5FPS.
If i disable audio, it play just fine.
Here is graph:
http://forum.team-mediaportal.com/attachments/codecs-external-players-55/69069d1286133179-saf-v5-00-experimental-based-ffdshow-dxva-decoder-mvi_1878.jpg
MP4Splitter.ax rev.1.4.2646.0, FFDshow 3608

MPC MPA audio decoder play it without any issue too on both machines.

Here video is sample (http://forum.team-mediaportal.com/attachments/codecs-external-players-55/69020d1286097641-saf-v5-00-experimental-based-ffdshow-dxva-decoder-mvi_1878.zip)

Media info:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L4.1
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 4s 566ms
Bit rate mode : Variable
Bit rate : 23.1 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.837
Stream size : 12.6 MiB (97%)
Language : English
Encoded date : UTC 2010-10-03 10:07:35
Tagged date : UTC 2010-10-03 10:07:35
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

Audio
ID : 2
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : sowt
Duration : 4s 566ms
Bit rate mode : Constant
Bit rate : 705.6 Kbps
Channel(s) : 1 channel
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 393 KiB (3%)
Language : English
Encoded date : UTC 2010-10-03 10:07:35
Tagged date : UTC 2010-10-03 10:07:35

The strange thing is, that it seems this problem only affect realtek sound cards, home i have SoubBlaster, and it play just fine.

[dansrfe]

Works fine on my side with ffdshow latest build, madVR latest build, and MPC-HC 32-bit latest build.

[hoborg]

Works fine on my side with ffdshow latest build, madVR latest build, and MPC-HC 32-bit latest build.

I was able to reproduce this issue on Intel Atom and Realtec HD audio. At home it is working fine C2D+Audigy4.

No idea what can causing it, but if i use MPC MPA audio decoder, it is working fine, so must be something in FFDshow.

[Atak_Snajpera]

@devs
Possible bug in h.264/avc decoder
Haali Media Splitter + ffdshow r3572 (libavcodec / ffmpeg-mt with 1-4 threads) = corrupted image
Haali Media Splitter + ffdshow r3572 (DVXA enabled) = no corruption

http://i51.tinypic.com/oi92c8.jpg

sample
http://www.mediafire.com/?4z2as0yjvnjoage

[augur]

hi,
since rev.3501 (3500 works fine) when I'm seeking fast (holding & sliding the cursor) with mpc-hc, it crash.

After many tests, i've found that this is caused by the AC3 encoding option (16, 32 & 32 float are ok), absolutely nothing else is activated (i used 48000hz inputs since resample was desactivated).

On the MPC side, i've found that if i disable his filters (avi & mp3 for my tests) it works again.
Going back to previous versions didn't do anything (last try:1.3.1896)

sorry for my poor english & testing abilities :rolleyes:, and thanks for all your work.

system: XP sp3. ffdshow x86 regular & icl11

edit: doesn't seem to crash with multichannels tracks (tried ac3,truehd, dts(hd), lpcm)

[XhmikosR]

@clsid: rev3610 broke ffmpeg-mt. It's crashing with every h264 video I've tried while rev3609 works fine.

[clsid]

Should be fixed in 3611.

[dansrfe]

ffdshow does not render pgs subtitles from a .ts file at all. Internal mpc renderer with EVR-CP renders it fine. Also I want to bump the broken karaoke ssa support in ffdshow problem. Please give some sort of eta of when these problems can be expected to be fixed. Thanks again ffdshow devs. :)

[LigH]

I have a problem with ffdshow expanding the height of the video, repeating lower lines, if it is not MOD 16. But it does that in a rather strange way.

- ffdshow_rev3611_20101006_xvidvideo-ru_x86_icl11
- mpc-homecinema.1.4.2667_(x86)_msvc2010

both from xvidvideo.ru; this effect happened with earlier versions too.

At first I usually had disabled all internal decoders and splitters of MPC-HC where useful, to allow decoding via ffdshow. But it appears that the MPC-HC internal decoder does the same as ffdshow.

The media info dialog in MPC-HC (Shift+F10; Details) shows the following values, depending on ffdshow or MPC-HC wether or not using DXVA for decoding H.264:

a) if DXVA decoding for H.264 is enabled: General { Video size = 640 x 368 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- at least MOD 16
b) if DXVA decoding for H.264 is disabled: General { Video size = 640 x 372 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- not even MOD 16?!

Test files: MP4 (http://www.holzon.de/test/00003_5s.mp4) or MKV (http://www.holzon.de/test/00003_5s.mkv) (same content, ~330 KB each)

http://www.holzon.de/test/00003_5s.png

P.S.: DGIndexNV 2026 and 2030 warn "Stream specifies cropping" (for the MKV) and report the "coded size" as 640x384 (even MOD 32).

[jmone]

Can I confirm a comment in some MADFLAC threads that FLAC decoding in FFDSHOW is only 16-Bit (eg 24-Bit source material is decoded to 16-Bit).
Thanks
Nathan

[magic144]

any chance the DXVA filter can be made to produce the same output as the software-only filter in the following respect...

for interlaced material,
output colorspace - e.g. NV12 only
set interlace flag in output media type

I find this is essential when watching e.g. some Concert Blu-Rays.

just wondering if it's possible!
also could the DXVA filter be somehow rolled into the main filter such that it can be chosen based on a profile rule?
(and is there any way of creating a profile rule to distinguish interlaced from non-interlaced content??)

[Gleb Egorych]

Can I confirm a comment in some MADFLAC threads that FLAC decoding in FFDSHOW is only 16-Bit (eg 24-Bit source material is decoded to 16-Bit).
Thanks
Nathan
Since FLAC decoding in ffdshow is done by libavcodec, the output is indead 16-bit.

[jmone]

Thanks - so all 24-Bit sources using libavcodec (eg True-HD) is also only 16bit. Any plans to support 24-bit?
Thanks
Nathan

[Reimar]

Since FLAC decoding in ffdshow is done by libavcodec, the output is indead 16-bit.

Nonsense, the libavcodec FLAC decoder isn't even able to decode > 16 bit input to 16 bit raw.
If the FLAC file encodes more than 16 bit per sample libavcodec will always produce 32 bit per sample output.
What then happens in ffdshow I do not know (it might not be able to play at all, it might reduce to 16 bit, ...).

[nevcairiel]

FLAC is actually one of the few codecs that does decode to the proper bitdepth in avcodec.
What ffdshow does with it is unknown to me, however.

FWIW, TrueHD/MLP is also properly decoded to the original bit depth.

it would be awesome if ffdshow would pass it to the renderer in the same bitdepth as it was decoded, but sadly thats not possible. :(

[jmone]

In testing with a FLAC 24 Bit (in MKV Container) I get the following results when "Output format for uncompressed or decoded streams" has "16 and 24 bit interger" checked.
1) FFDSHOW decdoing = 16 Bits output
2) MADFLAC (decodes to 24BIT PCM) --> FFDSHOW (Uncompressed) = 16 Bits ... This one gets me, If you insert FFDSHOW back into the filter graph to do post processing it still reduce the bitdebth to 16 Bit?

However, if I check "32 bit integer" I get 32 bit output for it all.

================================

I'm not sure how these 24-Bit streams are being processed internally in FFDSHOW, so I have:
1) Unchecked 16 Bit Integer in Processing
2) Checked 16, 24, and 32 Bit Integer in the Output Format for uncompressed or decoded streams

I "think" I may get 24bit input --> ??? 32 Bit ???? internal processing --> 32 bit output, but couple of Q:
- Is this assumption correct or is something still reducing the bitdepth to 16-bit at some point in the chain?
- Why does it output at 16Bits if I have only 16 and 24 bit output checked instead of 24-bit?

Thanks
Nathan

[nevcairiel]

ffdshow will always expose all output formats that you checked, and the renderer will pick whatever it likes. Maybe it doesn't like ffdshows 24 bit, for some arcane reason? I don't know.

[jmone]

ffdshow will always expose all output formats that you checked, and the renderer will pick whatever it likes. Maybe it doesn't like ffdshows 24 bit, for some arcane reason? I don't know.

Thanks - I can get 24 Bit output working if I uncheck 16 and 32 bit, but oddly not when 16 and 24 bit are checked (go figure)

Anyway I'm using Reclock - so the full Audio chain is now more like:

MKV (FLAC 24-Bit) Input --> FFDSHOW 32-Bit Output --> Reclock 24bit int padded to 32 (max the format the card with accept) --> WASAPI --> ATI HD5450

I'm just trying to avoid multiple conversions (esp at lower bit debths / sampling rate) unless there are other suggestions to FFDSHOW Config I'll leave it at 32-Bit Output with:
1) Uncheck 16 Bit Integer in Processing
2) Check 16, 24, and 32 Bit Integer in the Output Format

So is it confirmed (and againts prior assertions), that FFDSHOW using libavcodec is able to decode, process, and output 24-Bit FLAC at higher than 16-Bit?

Thanks
Nathan

[Reimar]

In testing with a FLAC 24 Bit (in MKV Container) I get the following results when "Output format for uncompressed or decoded streams" has "16 and 24 bit interger" checked.
1) FFDSHOW decdoing = 16 Bits output
2) MADFLAC (decodes to 24BIT PCM) --> FFDSHOW (Uncompressed) = 16 Bits ... This one gets me, If you insert FFDSHOW back into the filter graph to do post processing it still reduce the bitdebth to 16 Bit?

However, if I check "32 bit integer" I get 32 bit output for it all.


libavcodec never has and never will support 24 bit format (at least for decoder output, conversion is a different thing), no processor supports that format natively. Instead it will output as 32 bit and indicate that only 24 bits are really significant.
But since ffdshow obviously can do the 32 -> 16 bit conversion by itself, there's probably some code missing that converts 32 bit to 24 bit in case the decoder creates 32 bit output and you have only 16 and 24 checked.

[STaRGaZeR]

ffdshow doesn't output 24-bit unless everything else is unchecked. If the decoder outputs 24-bit, it'll use 32-bit int, with the extra bits zeroed (not sure about this though). So, if you have 24-bit sources, just be happy with 32-bit int because all your info is there untouched.

[LigH]

a) if DXVA decoding for H.264 is enabled: General { Video size = 640 x 368 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- at least MOD 16
b) if DXVA decoding for H.264 is disabled: General { Video size = 640 x 372 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- not even MOD 16?!

Any suggestion what could cause that?

[Reimar]

a) if DXVA decoding for H.264 is enabled: General { Video size = 640 x 368 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- at least MOD 16
b) if DXVA decoding for H.264 is disabled: General { Video size = 640 x 372 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- not even MOD 16?!

Test files: MP4 (http://www.holzon.de/test/00003_5s.mp4) or MKV (http://www.holzon.de/test/00003_5s.mkv) (same content, ~330 KB each)

http://www.holzon.de/test/00003_5s.png

P.S.: DGIndexNV 2026 and 2030 warn "Stream specifies cropping" (for the MKV) and report the "coded size" as 640x384 (even MOD 32).

libavcodec bug. It currently does not support cropping more than 12 pixels for interlaced streams. For this file, 384 - 360 = 24 pixels need to be cropped. (and 372 = 384 - 12).

[LigH]

Did I encode it interlaced?! ... :o - My fault then. But the content was deinterlaced. I should check my parameters again.

[Sebastiii]

Hi STaRGaZeR,

It seems that when you remove mp3lib, it break something about FFDShow.Interfaces.IffdshowBase.getParamStr3(UInt32 paramID, IntPtr& bufPtr) when use FFDshow in MediaPortal, r3602 is OK but not 3604.
I try to see why.
Thanks,
Seb.

Edit :
In FFDshowAPI.cs : i comment out line 2173 : ffdshowBase.getParamStr3((uint)param, out result);
I don't know exactly is doing but it fix the issue.

[STaRGaZeR]

Can you tell me param's value when getParamStr3 is called and it crashes?

[Sebastiii]

hi m8 :)

Yes but i'm not sure to how get this value :(
can you help me ?
Cheers,
Seb.

[STaRGaZeR]

Compile a debug build, put breakpoints in TffdshowBase::getParamStr3 (TffdshowBase.cpp, line 164) and run debug. When something calls the function the execution will be stopped at the first breakpoint. You can see variable names, values, etc. By pressing the play icon you'll go to the next breakpoint. You just have to look for what's in the variables when it crashes, that will pretty much tell you where the problem is. You know the issue is in getParamStr3 but knowing the exact line and variable values helps a lot. You see that the get(...) function is called from getParamStr3, if it crashes in this line you can put breakpoints in get(...) to further track down the crash. Maybe it's an incorrect param, I don't know :p

[Sebastiii]

Compile a debug build, put breakpoints in TffdshowBase::getParamStr3 (TffdshowBase.cpp, line 164) and run debug. When something calls the function the execution will be stopped at the first breakpoint. You can see variable names, values, etc. By pressing the play icon you'll go to the next breakpoint. You just have to look for what's in the variables when it crashes, that will pretty much tell you where the problem is. You know the issue is in getParamStr3 but knowing the exact line and variable values helps a lot. You see that the get(...) function is called from getParamStr3, if it crashes in this line you can put breakpoints in get(...) to further track down the crash. Maybe it's an incorrect param, I don't know :p

Thanks,

So i have compil debug version of FFDShow, put break point line 164.
Start debug -> select -> mediaportal.exe
Open a movie and try to select subtitle.
MVS2008 -> ask me for FFDShowAPI.cs (the one from MePo Sources).
After that, it stop on line 2254 (from this FFDShowAPI.cs) line for the one from FFDShow source is line 2173.

I have this value for param :
FFDShow.FFDShowConstants.FFDShowDataId.IDFF_subTempFilename

2010-10-11 21:19:41.291121 [ERROR][MPMain(1)]: Exception :System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at FFDShow.Interfaces.IffdshowBase.getParamStr3(UInt32 paramID, IntPtr& bufPtr)
at FFDShow.FFDShowAPI.getStringParam(FFDShowDataId param) in D:\svnroot\mediaportal_FFDshow_Patch18_Edition_MPCSubs\mediaportal\Core\Player\FFDShow\FFDShowAPI.cs:line 2254
at FFDShow.FFDShowAPI.get_CurrentSubtitleFile() in D:\svnroot\mediaportal_FFDshow_Patch18_Edition_MPCSubs\mediaportal\Core\Player\FFDShow\FFDShowAPI.cs:line 1129
at MediaPortal.Player.Subtitles.FFDShowEngine.get_CurrentSubtitleFile() in D:\svnroot\mediaportal_FFDshow_Patch18_Edition_MPCSubs\mediaportal\Core\Player\FFDShow\FFDShowEngine.cs:line 286
at MediaPortal.Player.Subtitles.FFDShowEngine.SwitchToNextSubtitle() in D:\svnroot\mediaportal_FFDshow_Patch18_Edition_MPCSubs\mediaportal\Core\Player\FFDShow\FFDShowEngine.cs:line 343
at MediaPortal.Player.g_Player.SwitchToNextSubtitle() in D:\svnroot\mediaportal_FFDshow_Patch18_Edition_MPCSubs\mediaportal\Core\Player\g_player.cs:line 2627
at MediaPortal.GUI.Video.GUIVideoFullscreen.OnAction(Action action)
at MediaPortal.GUI.Library.GUIWindowManager.OnAction(Action action) in D:\svnroot\mediaportal_FFDshow_Patch18_Edition_MPCSubs\mediaportal\Core\guilib\GUIWindowManager.cs:line 457
at MediaPortalApp.OnAction(Action action)
2010-10-11 21:19:41.291121 [ERROR][MPMain(1)]: Exception :Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
2010-10-11 21:19:41.292121 [ERROR][MPMain(1)]: site :Int32 getParamStr3(UInt32, IntPtr ByRef)
2010-10-11 21:19:41.292121 [ERROR][MPMain(1)]: source :Core
2010-10-11 21:19:41.293121 [ERROR][MPMain(1)]: stacktrace: at FFDShow.Interfaces.IffdshowBase.getParamStr3(UInt32 paramID, IntPtr& bufPtr)

But i didn't stop on breakpoint :(

I really don't know why :(
Thanks.

Ps : Thx to Underground78 to try to help me :)

[STaRGaZeR]

Thanks,

So i have compil debug version of FFDShow, put break point line 164.
Start debug -> select -> mediaportal.exe
Open a movie and try to select subtitle.
MVS2008 -> ask me for FFDShowAPI.cs (the one from MePo Sources).
After that, it stop on line 2254 (from this FFDShowAPI.cs) line for the one from FFDShow source is line 2173.

I have this value for param :
FFDShow.FFDShowConstants.FFDShowDataId.IDFF_subTempFilename



But i didn't stop on breakpoint :(

I really don't know why :(
Thanks.

Ps : Thx to Underground78 to try to help me :)

After building a debug version you have to register it (by using register.bat for example). If everything is right, your breakpoints will stay red after you start debug. If something went wrong, they'll be grey with a yellow exclamation sign. One good way of knowing if you're really using the debug version is to check deband for example, video will freeze because of the speed penalty.

This crash is related to subtitles, and I didn't change anything regarding subtitles in the mp3lib commit, so I'm out of ideas. What you can do is revert file by file until you find what makes it crash. BTW, why does MP have a different FFDShowAPI.cs? Really a noob on this I am :D

[Sebastiii]

Thanks,

I will try this this evening :)
I have look @ each file and yes nothing related to sub (and it's only happen for external sub).

I don't know exactly why the API (cs) is different, i know that i have add modification in FFDShowAPI.cs but the bug appear after r3602.

I'll and notice you :)
Thanks again.

[magic144]

raised a new issue on bug-tracker regarding subtitle (start play with subs hidden) interaction between Zoom Player 7.1a5 and clsid's newest 32-bit/x86 ffdshow build (3611)
https://sourceforge.net/tracker/?func=detail&aid=3086069&group_id=173941&atid=867360

also CC'd ZP msg board
thanks,
m

[Sebastiii]

After building a debug version you have to register it (by using register.bat for example). If everything is right, your breakpoints will stay red after you start debug. If something went wrong, they'll be grey with a yellow exclamation sign. One good way of knowing if you're really using the debug version is to check deband for example, video will freeze because of the speed penalty.

This crash is related to subtitles, and I didn't change anything regarding subtitles in the mp3lib commit, so I'm out of ideas. What you can do is revert file by file until you find what makes it crash. BTW, why does MP have a different FFDShowAPI.cs? Really a noob on this I am :D

Hi,

Debug version is working (register .ax) but the issue is always here and i didn't find what happen, i have try each file but it's hard because all is link between them (not all but a big part).

And i didn't see why is related to sub section :(
+++

[TheShadowRunner]

It seems libavcodec's VP6F decoding has a slight bug. Here is a sample video:
http://videoff7.free.fr/FF13_fn.avi (15megs)
When decoded by ffdshow, there is some disturbance at the very bottom of the screen, all along. When played via activex (on website), there is no such artefact.
I tried every renderer and no changes, if anyone has a clue on how to solve this? ^^;

[LoopDeMack]

@XhmikosR thank you for your time and your effort in building your versions of ffdshow.

I have a request for a subtitle option which is missing in your builds and generally in all ffdshow tryout builds.

When the movie has only one subtitle which is not the embedded type, you can not disable the subtitle through the tray menu because there is no "no subtitle" option, because its missing in "subtitle files" section.
http://img412.imageshack.us/img412/2134/subtitlefiles.png

You made that option available for embedded subtitles in "subtitle stream" section.
http://img716.imageshack.us/img716/2492/subtitlestream.png

This function is missing for srt and idx and other types of subtitles.

It would be great if you could add this option that user could disable the subtitle for the "subtitle files" from the tray menu, in the same manners, I mean same as its done for the "subtitle stream" type.


Thnak you

[STaRGaZeR]

Hi,

Debug version is working (register .ax) but the issue is always here and i didn't find what happen, i have try each file but it's hard because all is link between them (not all but a big part).

And i didn't see why is related to sub section :(
+++

What about asking MP guys? magic144's issue looks a lot like yours, Zoom Player is using the ffdshow API too IIRC, so maybe they know why it crashes. Try asking both.

[Sebastiii]

Hi,

Thanks ;) about MP guys for now the build with FFDSHOW is not include so no one for now can help me.
Albain has made a mega patch to include FFDShow in Mediaportal, i just change some thing about the OSD and other little thing lol.
But If i comment out the line, i have no error and all is working good. Effectively, i would like to understand why the change about mp3lib make an issue for sub :)
I will ask magic144 :)
But the API was not exactly the same between FFDShow and Mediaportal, i think the one from Mediaportal is more recent :)

Thank you :)
Seb.

[sansnom05]

Hi,

I've successfully built ffdshow with vs2010, one exception is WarpSharp will not work now, cause when linking it complains about unresolved "aws_run", so I comment it out for now. I'm guessing we need a vc100 version of aws.obj, if someone can provide it, that would be great.

I did a few test, the result ffdshow.ax works, so do all the filters. If anyone want to try it, you can PM me.

[mark0077]

Hi guys, I have an avi with an ac3 track that crashes mpc-hc when seeking but only when using the ffdshow audio decoder (either of the two available). Can anyone just let me know if this is something thats a known issue or if I should begin creating a sample from this largish avi file. Using ffdshow 3611 with mpc-hc and the crash happens with any of the mpc-hc audio renderers I have tested so I'm sure its ffdshow causing the crash on seek.

Other files with ac3 tracks don't seem to have the problem just this one avi I have.

EDIT: One other issue I notice is that the grab feature doesn't grab all frames when using a double framerate de-interlacer like yadif. Is this something I should report on an official bug tracker or is it expected? I was going to use the grab feature to deinterlace a section of an interlaced clip for importing into adobe premiere as even cs5's deinterlace is really bad compared to yadif even but only every odd frame gets grabbed, meaning I only get half of the frames written to disk.

[clsid]

Remuxing that AVI file with VirtualDub might fix it.

For the Grab issue, add it to the bug tracker.

[STaRGaZeR]

Hi,

Thanks ;) about MP guys for now the build with FFDSHOW is not include so no one for now can help me.
Albain has made a mega patch to include FFDShow in Mediaportal, i just change some thing about the OSD and other little thing lol.
But If i comment out the line, i have no error and all is working good. Effectively, i would like to understand why the change about mp3lib make an issue for sub :)
I will ask magic144 :)
But the API was not exactly the same between FFDShow and Mediaportal, i think the one from Mediaportal is more recent :)

Thank you :)
Seb.

Good luck, I still don't know why subs are affected by this :(

Hi,

I've successfully built ffdshow with vs2010, one exception is WarpSharp will not work now, cause when linking it complains about unresolved "aws_run", so I comment it out for now. I'm guessing we need a vc100 version of aws.obj, if someone can provide it, that would be great.

I did a few test, the result ffdshow.ax works, so do all the filters. If anyone want to try it, you can PM me.

Awesome. I can't provide the file, but I hope you success in making ffdshow compatible with VS2010.

[mark0077]

Remuxing that AVI file with VirtualDub might fix it.

For the Grab issue, add it to the bug tracker.

Thanks clsid, I'll do that now. One other thing I notice today. Been working in adobe premiere for the past few days and am outputting a largish clip to pure lossless rgb using the utvideo codec. I notice however when ffdshow receives the uncompressed RGB32 input, and when I'm outputting pure RGB32 from ffdshow (basically no conversion should occur), yet selecting different options in the rgb conversion output dialog has an effect on the image.

eg. selecting "Full range" for input levels and output as "Computer monitor" the image seen in mpc-hc is washed out, ie black becomes grey. I don't think ffdshow should be doing any processing here when input is rgb32 and output is rgb32 right? If you agree I'll also stick it into the tracker.

[clsid]

I would be inclined to agree with you. If the input is RGB32 then it could be outputted untouched. However, there may be situations where a user might want to adjust/correct the input.

It would probably be best to add an option to control whether RGB32 input should be processed or not. I suggest to create a report/request for that on the tracker.

[dansrfe]

Is the ffmpeg-mt AVC/H.264 decoder able to decode 10-bit 4:2:2 AVC streams? I am asking this because x264 devs have released a 10-bit 4:2:2 encoder and I want to try it out only if ffmpeg-mt has the ability to decode it. Also, if I remember correctly, x264 already has the capability to encode to 10-bit 4:4:4 AVC correct?

[nm]

Is the ffmpeg-mt AVC/H.264 decoder able to decode 10-bit 4:2:2 AVC streams? I am asking this because x264 devs have released a 10-bit 4:2:2 encoder and I want to try it out only if ffmpeg-mt has the ability to decode it. Also, if I remember correctly, x264 already has the capability to encode to 10-bit 4:4:4 AVC correct?

I haven't seen either 4:2:2 or 4:4:4 support released, only 4:2:0 9/10-bit. Libavcodec and ffmpeg-mt still only support 8-bit H.264 video.

[dansrfe]

In which circumstance can I use 10-bit 4:2:2 then? I think I understand using 4:4:4 12-bit for lossless (but again, where is the decoder?? lol). What is currently used to decode this type of material? How can this actually catch on in the consumer/prosumer market. I'm curious to know...

[nm]

In which circumstance can I use 10-bit 4:2:2 then?

With some other encoder than x264 and some other decoder than lavc. 4:2:2 support may be around the corner for x264. I haven't followed FFmpeg development lately.

I think I understand using 4:4:4 12-bit for lossless (but again, where is the decoder?? lol).

Currently x264 only supports 4:2:0 8..10 bit lossless and lossy encoding. "High 4:4:4 Predictive" refers to the H.264 profile that supports lossless encoding, not to x264's sample format support. It's still 4:2:0 only.

What is currently used to decode this type of material?

At least the "Broadcast" version of MainConcept's H.264 decoder supports 4:2:2 10-bit. I have no idea which commercial video tools include it.

How can this actually catch on in the consumer/prosumer market. I'm curious to know...

It's work in progress. Most likely it wont catch on until theres a free(ware) decoder available.

[nurbs]

I think it won't catch on because nobody is going to implement it in hardware and there will be compatibility problems in general because many commercial software products won't support it either.

[sansnom05]

I've figured out why aws_run is unresolved, actually no need for vc100 version aws.obj. So vs2010 build is now functional equal with vs2008/icl11 build, anyone want to try it, here's the vs2010 build link: http://www.mediafire.com/?p9cxbwqoaopwmot.

[fastplayer]

So far no problems with both VS2010 builds (3612 & 3614). I'm not a heavy filter user so I can't comment on that but I've noticed zero anomalies during basic playback of AVI, MP4, MOV and MKV files. :)

[sansnom05]

Here's link for vs2010 x64 build ffdshow, http://www.mediafire.com/?wu6cplmixvgcf9v.

Compare to x86, x64 build need extra works like build libboost_thread for vc100/x64, and it seems default to use sse2, so need colorspace_rgb_win64_sse2.asm for yasm. Could someone confirm that?

[sansnom05]

@devs

I have made all vs2008/icl11/vs2010 project files using props/vsprops file to set IntDir/OutDir, aka location of intermediate files(.obj/.pdb/.lib/.log/.asm etc) and output files(.lib/.exp only), .dll/.ax/.vdf/.acm files will still in $(ffdshowroot)/bin dir for installer.

Right now those files scatter in each project's subdirs, different for each configuration/arch/compiler combination, like ff_acm/Release_Win32_2008/ or ff_vfw/Debug_x64_ICL11/.

After my proposal changes, we could have only two top dirs(one if $intdir == $outdir) to put these files, including all configuration/arch/compiler/project combination, like this: $intdir/Release_Win32_ICL11/ff_acm/ and $outdir/Debug_X64_ICL11/ etc. It will be easier for finding pdb/lib files, and for cleaning too. And if you like the way it is now, you can easily get it by changing IntDir/OutDir definitions in common.props/vsprops just once.

So the question is: what should be the topdir name for IntDir/OutDir? And if anyone want to try my patch before comments, please PM me.

:thanks:

[clsid]

$(ffdshowroot)/obj ?

[Sebastiii]

Good luck, I still don't know why subs are affected by this :(

Hi :) sansnom05 find why it doesn't work :) thanks to him to help me :)

We have to apply the change made in iffdshowbase.h :
Remove the line : STDMETHOD (getPostproc)(Tlibmplayer* *postprocPtr) PURE;

In IffdshowBase.cs :
Remove the line : int getPostproc(IntPtr postprocPtr);

All is ok :)

Awesome. I can't provide the file, but I hope you success in making ffdshow compatible with VS2010.

Thanks again to sansnom05, the build works goods :)
Cheers,
Seb.

[Sebastiii]

@devs

I have made all vs2008/icl11/vs2010 project files using props/vsprops file to set IntDir/OutDir, aka location of intermediate files(.obj/.pdb/.lib/.log/.asm etc) and output files(.lib/.exp only), .dll/.ax/.vdf/.acm files will still in $(ffdshowroot)/bin dir for installer.

Right now those files scatter in each project's subdirs, different for each configuration/arch/compiler combination, like ff_acm/Release_Win32_2008/ or ff_vfw/Debug_x64_ICL11/.

After my proposal changes, we could have only two top dirs(one if $intdir == $outdir) to put these files, including all configuration/arch/compiler/project combination, like this: $intdir/Release_Win32_ICL11/ff_acm/ and $outdir/Debug_X64_ICL11/ etc. It will be easier for finding pdb/lib files, and for cleaning too. And if you like the way it is now, you can easily get it by changing IntDir/OutDir definitions in common.props/vsprops just once.

So the question is: what should be the topdir name for IntDir/OutDir? And if anyone want to try my patch before comments, please PM me.

:thanks:

Thank you :)
It's really works good :)
I hope that dev can look it :)
Seb.

[XhmikosR]

@clsid: I noticed there are random standalone icl10 and vs08 solution files except from the ffdshow ones. At least for the icl10 solution files, if you don't use them can you remove them? Also, do you know what was the ffdshow_all project supposed to do?
And we definitely have to use different bin directories, because now you have to rebuild every time you change between vs08 and vs10.

[mindbomb]

I'm having trouble with ffdshow audio decoder and bitstreaming of the dts core of a dts-hd track over spdif. The issues are greatly reduced when using mpc's internal dts filter for bitstreaming though.

[Ap3 n1nja]

Sorry for requesting this again, but can anyone here get AAC libavcodec to connect with KMPlayer's Matroska Reader? Or is this the type of thing I should ask KMPlayer developers to work on?

[Qaq]

KMPlayer developers? There are no such ones anymore.

[Ap3 n1nja]

Haha! True that.

But they did mange to release a new version a couple months ago. Yet still, it was about a year ago from their last release, so I don't expect them to be the ones to fix it.

[eliz82]

chosing "Easteurope" in subtitle Charset setting not working. the special characters are not displayed correctly.

edit: it seems you must restart the movie after changing this setting to work correctly.

[eliz82]

another problem

on the latest build (3611) the subtitle choosing from the tray menu do not appear anymore like in older builds (ex. 3466)
11739
am I missing some setting ?

[DeathTheSheep]

Latest revision of ffdshow (whatever ffmpeg-mt version it uses) is broken with b-pyramid. Try a decent, smooth clip with x264 preset veryslow/placebo and the ffmpeg-mt decoder. Tons of corruption. Previous ffdshow was fine.

Reverting...

[DeathTheSheep]

Latest revision of ffdshow (whatever ffmpeg-mt version it uses) is broken with b-pyramid. Try a decent, smooth clip with x264 preset veryslow/placebo and the ffmpeg-mt decoder. Tons of corruption. Previous ffdshow was fine.

Reverting...

Some specifics: when played through normally, the problem doesn't appear. To reproduce, I tried seeking directly into a GOP (to do this in a testing environment, load an mkv with ordered chapters and seek inside of a different linked chapter) and progressed one frame at a time. Sure enough, corruption would appear on files using b-pyramid as loaded via directshowsource and persist throughout the remainder of the file/fragment, even minutes (hours) past the initial seek point.

On mobile devices using ffmpeg (rockplayer, vplayer, etc), the problem persists in all cases, regardless of seeking. Is there anyone at ffmpeg aware of this problem? I thought I'd report it here.

[Reimar]

libavcodec bug. It currently does not support cropping more than 12 pixels for interlaced streams. For this file, 384 - 360 = 24 pixels need to be cropped. (and 372 = 384 - 12).

This bug has been fixed a few days ago in FFmpeg (r25669).

[fastplayer]

This bug has been fixed a few days ago in FFmpeg (r25669).
Yep, clsid committed this fix with rev3625 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?revision=3625&view=revision).

[LigH]

Hooray! :thanks:

[magic144]

@eliz82
I wonder if this is related to why ZP7.1a5 can't work with build3611 when it tries to hide the subs on media start?
http://forum.doom9.org/showthread.php?p=1449958#post1449958

[sansnom05]

@eliz82
I wonder if this is related to why ZP7.1a5 can't work with build3611 when it tries to hide the subs on media start?
http://forum.doom9.org/showthread.php?p=1449958#post1449958

Please try builds later than r3616 see if it's fixed.

Edit: you need to rebuild FFDShowAPI, forget to change that in that commit.

[B.F.]

Postprocessing doesn't work at all in vfw mode.
It work with divx files in usual ds mode, but do nothing with the same files in vfw mode (virtualdub, avisynth).

[clsid]

If I remember correctly this was discussed once before in the past and the conclusion was that it was by design to have untouched input in VFW.

[B.F.]

If I remember correctly this was discussed once before in the past and the conclusion was that it was by design to have untouched input in VFW.

Untouched input? Like this?http://forum.doom9.org/attachment.php?attachmentid=11757&d=1289356215
If I want to have untouched input I can just disable postprocessing.
And now the only way to have postprocessing enabled is the use buggy and not frame-accurate DirectShowSource in avisynth.

P.S.
And actually I really want to have old Milan postprocessing code back as an option. Because it can work on any source regardless of quantizer value and it work quite good.

[nm]

And now the only way to have postprocessing enabled is the use buggy and not frame-accurate DirectShowSource in avisynth.

There's also DSS2.

[clsid]

I might be remembering wrong. It is also possible that you tried with a video format for which PP is skipped (such as H.264).

Nobody is currently working on that part of ffdshow. Patches to improve functionality are welcome.

[TheShadowRunner]

It seems libavcodec's VP6F decoding has a slight bug. Here is a sample video:
http://videoff7.free.fr/FF13_fn.avi (15megs)
When decoded by ffdshow, there is some disturbance at the very bottom of the screen, all along. When played via activex (on website), there is no such artefact.
I tried every renderer and no changes, if anyone has a clue on how to solve this? ^^;

Another libavcodec decoding bug, this time for DX50 :
With Divx4/5/6 set as libavcodec, the video plays at 22.330 fps (?)
With Divx4/5/6 set as Xvid, the video plays OK at 25.000 fps.
A sample: http://videoff7.free.fr/buglibav.avi

If this is not the right place to report libavcodec decoding issues (my libavcodec VP6F decoding bug report didn't get many replies ^^), please let me know where I should do it.

[follz20]

Is anyone able to tell me why I am unable to get subtitles on screen (with internal .srt subs - blu-ray subs are OK) when both DXVA (ffdshow) and any EVR renderer (custom, sync etc) is enabled? I've never had any problems with these settings before until recent builds.

Surface overlay is enabled and (obviously) all the right boxes are ticked inside the subtitles menu within FFVA so I have no idea why it's not working.

Also, is anyone able to tell me why I get horizontal screen tearing across the MPC-HC player when playing a video which uses DXVA and the EVR renderer? The problem disappears when I use the EVR custom renderer though.

If it is relevant to screen tearing, I do NOT have aero enabled.

[nm]

If this is not the right place to report libavcodec decoding issues (my libavcodec VP6F decoding bug report didn't get many replies ^^), please let me know where I should do it.

FFmpeg bug tracker (https://roundup.ffmpeg.org/roundup/ffmpeg/)

Read this first: http://www.ffmpeg.org/bugreports.html

You should test with ffplay from latest FFmpeg SVN. Latest MPlayer compiled against FFmpeg SVN might also do.

[xv]

Hi,
ffdshow is a really great project supporting so many codecs with advanced post-processing. Thank you very much for developing it!
I have still some older avi-files using codecs that ffmpeg supports but I cannot play them with ffdshow, so I have the feature request to add those codecs:

-Indeo 5
-I263
-Ati VCR2 (ffdshow can play it by changing the fourcc to "MPG2", but colors are wrong)

Another problem is even when Atrac3 is enabled in ffdshow, MPC-HD cannot play RealMedia with Atrac3, I don´t know if it´s a ffdshow or a mpc-hd problem.

[Reimar]

Another libavcodec decoding bug, this time for DX50 :
With Divx4/5/6 set as libavcodec, the video plays at 22.330 fps (?)
With Divx4/5/6 set as Xvid, the video plays OK at 25.000 fps.
A sample: http://videoff7.free.fr/buglibav.avi

If this is not the right place to report libavcodec decoding issues (my libavcodec VP6F decoding bug report didn't get many replies ^^), please let me know where I should do it.

This one FFmpeg handles ok, so it is not an issue in libavcodec itself. The problem here is that the AVI claims 25 fps, but the MPEG-4 headers say 30 fps.
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?

[TheShadowRunner]

nm, thanks for the info.

Reimar, thanks a buch for testing.
About the AVI's wrong header, I should have checked that first ^^;;
It's just odd "Divx4/5/6 as libavcodec" is bugged when "Divx4/5/6 as Xvid" isn't with this file.

About the VP6F one, i guess remuxing it into an AVI is what made it lose its extradata and/or cropping info.. likely.
I'm going to play around some more with this one ;)
Thanks again,

TSR

[DMD]

Good morning.

Sorry for the stupid question.

Why using version rev2099_20080903_clsid_sse_icl10
The subtitles will play normally.

http://img718.imageshack.us/img718/5280/ridimensionadiscreensho.png (http://img718.imageshack.us/i/ridimensionadiscreensho.png/)

http://img408.imageshack.us/img408/9862/screenshot002cj.png (http://img408.imageshack.us/i/screenshot002cj.png/)




Instead, using all the latest releases, including the
rev3629_20101113_xvidvideo-ru_x86_icl11
the subtitles will not play.
Direct show filters are the same as the previous configuration.

http://img194.imageshack.us/img194/5280/ridimensionadiscreensho.png (http://img194.imageshack.us/i/ridimensionadiscreensho.png/)

http://img44.imageshack.us/img44/7157/screenshot001f.png (http://img44.imageshack.us/i/screenshot001f.png/)

http://img442.imageshack.us/img442/8765/screenshot002ht.png (http://img442.imageshack.us/i/screenshot002ht.png/)


What's wrong?

THANKS

[nevcairiel]

As you can see in the filter graph, with the older version the cyberlink decoder dealt with the subtitles, and in the newer graph ffdshow trys to handle them.

You can try to disable VobSub subtitles in ffdshow (or all subtitles), and let the Cyberlink handle it. This will not solve the issue in ffdshow, but should in theory get you subtitles back.

[DMD]

As you can see in the filter graph, with the older version the cyberlink decoder dealt with the subtitles, and in the newer graph ffdshow trys to handle them.

You can try to disable VobSub subtitles in ffdshow (or all subtitles), and let the Cyberlink handle it. This will not solve the issue in ffdshow, but should in theory get you subtitles back.
I tried to turn off the subtitles in the tab of ffdshow, the problem remains.

I also tried to perform the MPEG-2 decoder to Cyberlink ffdshow eliminating, the problem remains. :(

http://img844.imageshack.us/img844/1018/screenshot003c.png (http://img844.imageshack.us/i/screenshot003c.png/)

http://img442.imageshack.us/img442/5280/ridimensionadiscreensho.png (http://img442.imageshack.us/i/ridimensionadiscreensho.png/)

[LigH]

You must have misunderstood everything...

If you play a DVD (which has MPEG2 video), and you want the Cyberlink decoder handle the MPEG2 video instead of ffdshow, you have to disable the MPEG2 codec in ffdshow.

But you disabled the opposite - everything but MPEG2 ?!?

[DMD]

I have tried both with the MPEG-2 enabled and disabled,
the problem remains.

Because with the release rev2099_20080903_clsid_sse_icl10,
i have no problem?

THANKS

[entrecour]

I am having problems bitstreaming DTS with ffdshow (svn 3627 (x86) icl11). I am using the demo videos "DTS experience" and "DTS sparks sprites mix" to test and I don't get any audio from my Onkyo 1007.

I have also tried with AC3Filter and it seems to work fine.

I am using the latest build of MPC-HC and I have Dts pass-through enabled in the ffdshow output options together with libavcodec selected in the DTS codec field.

Dolby True HD bisteaming works for me but DTS and DTS-HD MA do not.

Can anyone else confirm this is a problem or is it a problem on my side somewhere?

( you can get the demo videos from http://www.demo-world.eu/trailers/dts-trailers.php )

Thanks.

[clsid]

Try changing the "Compatibility options" on the Output page in ffdshow audio decoder settings.

[entrecour]

That was it - when I changed from "Try all formats" to "Try only standard formats" things started to move in the right direction. :) Rather counter intuitive.

Even though AC3Filter was blocked in MPC it kept inserting itself into the filter chain. After disabling all formats within AC3filter options bitstreaming started to work.

I also had to use Reclock or DirectSound instead of the Intel Audio device / AVR specified as the renderer in MPC.

So I can now bitstream Dolby True HD, DTS, and DST-HD MA. :thanks:

Having some issues doing the same with DVBViewer / ffdshow but I need to do further testing there.

[RiCON]

http://imgur.com/G1r1r.png

Requesting a proper ASS renderer in ffdshow DXVA, please.

[XhmikosR]

@all: with the help of sansnom05, ffdshow can be built with ICL12. Here (http://xhmikosr.1f0.de/zzzother/ffdshow_rev3631_20101115_xhmikosr_icl12.exe) is a build. Let me know if you find any problems compared to the ICL11 builds.

[PetitDragon]

@all: with the help of sansnom05, ffdshow can be built with ICL12. Here (http://xhmikosr.1f0.de/zzzother/ffdshow_rev3631_20101115_xhmikosr_icl12.exe) is a build. Let me know if you find any problems compared to the ICL11 builds.

got it! testing.:thanks:

[Puncakes]

Let me know if you find any problems compared to the ICL11 builds.

I got some occasional audio glitches. Occurred regardless of codec or number of channels. Rolling back to ICL11 fixed it.

[XhmikosR]

Weird, I have no problems at all with every sample I have tried using the ICL12 build. You will have to provide a sample with which the problem you describe can be reproduced and also your ffdshow settings.

[STaRGaZeR]

I've been testing the ICL12 build, no problems so far with several filters enabled.

[XhmikosR]

@STaRGaZeR: Thanks for confirming my results. I'll wait a little bit more for other people to test the ICL12 build. If everything goes well, I'll replace the ICL11 projects with the ICL12(VS2008) ones.

BTW, I found another bug. If the filename includes this character "½", ffdshow causes MPC-HC to crash, pointing to ffdshow.ax.

EDIT: Hmm it might not be the filename... I'll try to found the cause.
EDIT2: And it doesn't crash if I run mpc-hc trough MSVS...
EDIT3: It seems to be unrelated to the filename or the path. ICL11 and ICL12 builds crash while the MSVC2010 doesn't. So we might have hit a similar problem to the one you fixed recently.
EDIT4: With an ffdshow debug build I get a couple of "Assertion failed!" errors (http://pastebin.com/A7r1VMMf), but after I press ignore the movie plays fine. Also building libavcodec or ffmpeg-mt with MSVC is broken.

[STaRGaZeR]

Yeah, I get those assertion failed errors too, I think they're related to subtitles but not 100% sure. About the bug, I have virtually no time for ffdshow now, but try to track down the bug like the last time so we can fix it :)

[Ap3 n1nja]

I think I have found out the audio glitching problem that Puncakes maybe mentioning, at least for AAC audio.

It seems to occur when libfaad2 is chosen as a decoder, but if it's libavcodec it's fine.

Also, some files run glitch free while others do not.

Here is a sample of one that has a glitch:
http://www.mediafire.com/?m52h0jhtsqs4fu4

If a better sample is needed feel free to ask with what you need.

[jeremy33]

Hi,

I have a question about CoreAVC and ffdshow. Is it good if I use at the same time CoreAVC and ffdshow video with raw video enabled instead of ffdshow raw to benefit filters ?

This is for my guide HomeCinema-HD Quality guide for HTPC with mpc-hc ffdshow reclock (http://www.homecinema-hd.com/intro_en.html)

[XhmikosR]

I think I have found out the audio glitching problem that Puncakes maybe mentioning, at least for AAC audio.

It seems to occur when libfaad2 is chosen as a decoder, but if it's libavcodec it's fine.

Also, some files run glitch free while others do not.

Here is a sample of one that has a glitch:
http://www.mediafire.com/?m52h0jhtsqs4fu4

If a better sample is needed feel free to ask with what you need.

I see now. I can reproduce the problem with that sample using libfaad for AAC. Unfortunately it's out of my league, but I'll try to see if any ICL setting (like disabling some optimizations) will fix it, like it happened with the first ICL11 builds.

[Reimar]

I see now. I can reproduce the problem with that sample using libfaad for AAC. Unfortunately it's out of my league, but I'll try to see if any ICL setting (like disabling some optimizations) will fix it, like it happened with the first ICL11 builds.

I think libfaad is quite full of strict aliasing violations. It's possible that ICL like gcc has an option to disable optimizations based on strict aliasing which might solve this, however using it on everything would be a _really bad_ idea, since it's likely to cause quite a slowdown. On the Linux side, ICC from version 12 on supports __attribute__((may_alias)) to work around this explicitly for individual variables, but that is even more effort and I do not know if something similar is available in ICL.

[Reimar]

I think libfaad is quite full of strict aliasing violations.

Forget about that, it seems that ICL does not use this by default, you'd have to use an explicit /Qansi-alias to enable that.

[XhmikosR]

From a quick test I did, /O2 and /O3 have this problem. With optimizations disabled for libfaad (/Od) or with /O1, it works fine.

EDIT: ...and I found the cause. It's /Ob2 that causes the problem. Using /O3 and /Ob1 there's no glitch. Here (http://xhmikosr.1f0.de/zzzother/ffdshow_rev3632_20101127_xhmikosr_icl12.exe) is the new ICL12 build, please everyone try it and report any problems.

Yeah, I get those assertion failed errors too, I think they're related to subtitles but not 100% sure. About the bug, I have virtually no time for ffdshow now, but try to track down the bug like the last time so we can fix it :)

The crash is related to libavcodec/ffmpeg-mt and it looks like it's the same one as the other one you fixed recently. But I cannot reproduce the crash if I run mpc-hc through MSVS.
EDIT: I tried a debug build of mpc-hc and I can reproduce the crash. It must be that ffdshow custom code in golomb.h, line 68. I cannot be sure but this is what I can tell from the disassembly code.

[STaRGaZeR]

The crash is related to libavcodec/ffmpeg-mt and it looks like it's the same one as the other one you fixed recently. But I cannot reproduce the crash if I run mpc-hc through MSVS.
EDIT: I tried a debug build of mpc-hc and I can reproduce the crash. It must be that ffdshow custom code in golomb.h, line 68. I cannot be sure but this is what I can tell from the disassembly code.

Do you have any samples to reproduce? I can't make it crash here.

Mmm, the ICL12 build randomly crashes pointing to Resampler.dll (a Reclock library). Causes unknown :(

[XhmikosR]

It doesn't happen with all the h264 videos. I'll try to cut a sample and see if it happens there. As for libsamplerate, I'll try to reproduce it with an ICL12 build. I had random crashes with the ICL11 builds too when using libsamplerate in the past.

[STaRGaZeR]

It's not libsamplerate, it's a Reclock library. That's why the crash is strange, it doesn't crash ffdshow, it causes a crash in a library of another application. Weird stuff. Never had "regular" Resampler.dll crashes with ICL11 builds.

[XhmikosR]

So, what should I do with the ICL12 projects? I cannot find the cause of that crash with h.264 videos but it also happens with the ICL11 builds. But if I cut a sample I cannot reproduce it there.

[iron2000]

I have a video that has problems on playback with ffdshow DXVA but plays ok with MPCHC DXVA.

The problem is that the video plays for a few seconds then the video gets stuck (audio keeps playing).
Still occurs even if all checks are skipped.

On seeking, the video sometimes plays for a few seconds then the video gets stuck again (audio keeps playing) and sometimes the seeking changes the audio only (video still on stuck frame).

Video card is NVidia GT430 with latest drivers.

The mediainfo of the video:
http://stashbox.org/1036617/mediainfo.txt

[hoborg]

I have a video that has problems on playback with ffdshow DXVA but plays ok with MPCHC DXVA.

The problem is that the video plays for a few seconds then the video gets stuck (audio keeps playing).
Still occurs even if all checks are skipped.

On seeking, the video sometimes plays for a few seconds then the video gets stuck again (audio keeps playing) and sometimes the seeking changes the audio only (video still on stuck frame).

Video card is NVidia GT430 with latest drivers.

The mediainfo of the video:
http://stashbox.org/1036617/mediainfo.txt

The same issue?
http://forum.doom9.org/showthread.php?p=1431269#post1431269

[STaRGaZeR]

So, what should I do with the ICL12 projects? I cannot find the cause of that crash with h.264 videos but it also happens with the ICL11 builds. But if I cut a sample I cannot reproduce it there.

I also get the Resampler.dll errors with ICL11 builds now too. Bad for me but good for ICL12 compatibility. Have you benchmarked both? With all the filters I enable they're about the same here.

About commiting the ICL12 projects, do it if you want but don't remove the ICL11 ones yet please.

[XhmikosR]

I'm sorry but this won't happen at least from me. ffdshow projects are a complete mess (the same goes for the source dir structure).
Makefiles, vs2008, vs2010, icl10, icl11 and now icl12 projects. That's a lot, and not only it's impossible to maintain all of them, it's also pointless.
I haven't benchmarked the ICL12 builds but they should be at least the same as the ICL11 ones.
We should decide which compilers will be supported and which not. Also I don't like the fact that no one compiles and uploads builds on SF. I could do it, as long as someone gives me the needed rights.

[fastplayer]

We should decide which compilers will be supported and which not.
+1. I'm all for MSVC.
Also I don't like the fact that no one compiles and uploads builds on SF.
There's really no point in daily builds. Heck, there's even no point in weekly or monthly builds considering that development is at an all-time low.
I could do it, as long as someone gives me the needed rights.
They've been given to you a few minutes ago :)

[clsid]

The main project files are only the vs2008 ones. All others ones should be maintained by whoever uses them.

[XhmikosR]

The main project files are only the vs2008 ones. All others ones should be maintained by whoever uses them.

Let's say that VS2008 stays as the main compiler. VS2010 is the same compared to VS2008 and probably better and faster (I still haven't had the time to make any benchmarks whatsoever).
ICL10 is only used by you so if you want to keep the ICL10 projects that's fine since you maintain them.
I don't plan to use ICL11 anymore since the ICL12 builds seem to be as stable as the ICL11 ones for me, or at least no one else has reported any other problems with them. So why keep the ICL11 projects?
And how about the makefiles? And the random solution files in various folders.


There's really no point in daily builds. Heck, there's even no point in weekly or monthly builds considering that development is at an all-time low.

True, but this doesn't mean that there shouldn't be any ICL11 or ICL12 builds in the official page.


They've been given to you a few minutes ago :)
Thanks, I'll make a new folder and I'll upload once in a while ICL11 or ICL12 builds.

[STaRGaZeR]

I'm sorry but this won't happen at least from me. ffdshow projects are a complete mess (the same goes for the source dir structure).
Makefiles, vs2008, vs2010, icl10, icl11 and now icl12 projects. That's a lot, and not only it's impossible to maintain all of them, it's also pointless.
I haven't benchmarked the ICL12 builds but they should be at least the same as the ICL11 ones.
We should decide which compilers will be supported and which not.

I agree 100% with you. However, what you can't do is delete ICL11 the next day ICL12 is released, needing new project files and stuff.

ICL builds are necessary, they're a lot faster with filters enabled. VS should always be the main compiler. What we should do is upgrade to VS2010 and ICL12, and only keep those IMO. But giving people time to upgrade. What's the status on migrating to VS2010 BTW?

And if you have suggestions about how to improve the projects and source dir structure, just post and then implement them if people agree!

So why keep the ICL11 projects?

I don't have ICL12 yet :D. Since it seems I'll be the only one using them, I'll maintain them until I get ICL12 and then I'll delete all the ICL11 stuff. You're OK with this?

[sansnom05]

ICL builds are necessary, they're a lot faster with filters enabled. VS should always be the main compiler. What we should do is upgrade to VS2010 and ICL12, and only keep those IMO. But giving people time to upgrade. What's the status on migrating to VS2010 BTW?


No problem building ffdshow using VS2010 with ICL 12. Here's the link if you or anyone want to try it: http://www.mediafire.com/?px9u12giiqyud5c, so far I see no problems. :)

[Ap3 n1nja]

@sansnom05: The ICL12 build seems to have the audio glitches XhmikosR's ICL12 build had before. Not sure if the cause is the same or not.

[fastplayer]

ICL builds are necessary, they're a lot faster with filters enabled.
That was an argument back in 2005. :p In 2010 you get hexa-core CPUs for less than 200 bucks, quad-core for less than 100.
By the way, didn't the gap between ICL and MSVC get smaller? I think we talked about this a few months ago...

[STaRGaZeR]

No problem building ffdshow using VS2010 with ICL 12. Here's the link if you or anyone want to try it: http://www.mediafire.com/?px9u12giiqyud5c, so far I see no problems. :)

I know, was talking about the adoption by the devs here. I've already switched to MSVC2010 thanks to your patches :)

That was an argument back in 2005. :p In 2010 you get hexa-core CPUs for less than 200 bucks, quad-core for less than 100.
By the way, didn't the gap between ICL and MSVC get smaller? I think we talked about this a few months ago...

Nope, it's the same today, because CPUs have improved, but video content has improved too :p. The gap hasn't changed. I can't use yadif+deband+resize+sharpen+subtitles+RGB32HQ(with dithering) with 1080i60 Blu-ray content using MSVC2008 or 2010 builds because they're slow, while it runs perfectly fine with ICL11/12 builds. When using these filters and content, playing and seeking is almost instant with ICL11/12, MSVC2010 can't even do realtime, if you seek you can wait an eternity for the player to resume. Not to mention the CPU heats up significantly more.

Blu-ray, 1080i60, MBAFF, ~35mbps average, with the filters listed above:

----------ICL12---------------------ICL11---------------------ICL10-------------------MSVC2010-----------------MSVC2008
http://thumbnails36.imagebam.com/10953/dba84e109528787.jpg (http://www.imagebam.com/image/dba84e109528787) http://thumbnails.imagebam.com/10953/603316109528790.jpg (http://www.imagebam.com/image/603316109528790) http://thumbnails.imagebam.com/10956/1c1ab8109555541.jpg (http://www.imagebam.com/image/1c1ab8109555541) http://thumbnails16.imagebam.com/10953/c090fd109528793.jpg (http://www.imagebam.com/image/c090fd109528793) http://thumbnails35.imagebam.com/10953/493632109528795.jpg (http://www.imagebam.com/image/493632109528795)

Compared to MSVC2008: MSVC2010 is ~4,1% faster, ICL10 is ~19,3% faster, ICL11 is ~18,5% faster, ICL12 is ~20,2% faster.

Keep in mind that 60fps is realtime here. Playing the file in MPC-HC, ICL11/12 run and seek fine, MSVC2010 runs but freezes after 5 secs to never recover, MSVC2008 freezes at start. All of this is when using the specs in my sig. I can't imagine how bad it is with those cheap CPUs, being painful already with an i5 at stock. Less demanding content just seeks faster, and the CPU is always quieter, sucks less power and produces less heat. I know that supporting 2 compilers is a pain in the ass, but the benefits are clear IMO.

[clsid]

Those who regularly build with ICL11/12 should together decide if ICL11 projects are removed or not in favor of ICL12, and whether it is based on vs2008 or vs2010.

I will continue to maintain the ICL10 project, since that has no known problems and I don't yet feel the need for updating. If I remember correctly, in the last benchmark ICL10 was also at least as fast as ICL11. Also, I use a patched ICL that allows SIMD use on AMD CPUs.

Makefiles for stuff that is compiled with Visual Studio by default can be removed if nobody objects.

It would be interesting to see some more benchmarks with a variety of files, settings, and CPUs. It would be cool if vs2008 is really a few % faster in some situations, because newer versions of visual studio are not always faster than their predecessors.

Are the ICL12 audio problems caused by ffdshow.ax or by libfaad? If it is the latter, then we could just use a plain vs2010 build for that.

off topic: have all vs2010 related issues for MPC-HC been solved already?

[dann23]

@STaRGaZeR. from where to download that program you used to test the decoding speed? I want to test it on my amd system.

I also tested the ICL12 build and I didn't see any noticeable problems and until now I didn't experince sound problems.

[fastplayer]

I know that supporting 2 compilers is a pain in the ass, but the benefits are clear IMO.
Thanks for the numbers! :) These are pretty impressive results coming from a pain in the butt compiler! :p
I wish I could see half the boost you're getting on my Athlon64 X2 setup (K8@2.4GHz): +6% over MSVC2008 was the best I could get from ICL10/11 (720p H.264, subtitles+RGB32HQ+dithering). Results with a more current Athlon/Phenom II would be really interesting. Just to see how much love Intel has left for AMD... :D

[STaRGaZeR]

Those who regularly build with ICL11/12 should together decide if ICL11 projects are removed or not in favor of ICL12, and whether it is based on vs2008 or vs2010.

ICL11 projects will be removed, but not yet. For ICL12 I'd choose VS2010.

I will continue to maintain the ICL10 project, since that has no known problems and I don't yet feel the need for updating. If I remember correctly, in the last benchmark ICL10 was also at least as fast as ICL11. Also, I use a patched ICL that allows SIMD use on AMD CPUs.

Do ICL11/12 builds work properly on AMD CPUs? Because if yes, the only reason to keep the ICL10 projects would be that H.264 crash (and your feel for updating :p), that is probably related to code that is there for fixing ICL10 bugs that are probably not present in newer versions like the one I fixed in r3588. I added ICL10 results to my previous post.

Makefiles for stuff that is compiled with Visual Studio by default can be removed if nobody objects.

I vote for removal.

It would be interesting to see some more benchmarks with a variety of files, settings, and CPUs. It would be cool if vs2008 is really a few % faster in some situations, because newer versions of visual studio are not always faster than their predecessors.

Indeed. Almost all of my content is Blu-ray, so I can't bench other stuff. But what we have to test are the filters, and only those that are not ffmpeg filters. They are content independent as they work with the decoded material. The only variables are resolution, fps, specs and builds.

Anyone with an AMD CPU to test? I can upload my sample if needed.

Are the ICL12 audio problems caused by ffdshow.ax or by libfaad? If it is the latter, then we could just use a plain vs2010 build for that.

The audio problems were caused by libfaad, and disabling an optimization fixed it.

@STaRGaZeR. from where to download that program you used to test the decoding speed? I want to test it on my amd system.

Graphstudio, go to View-->Decoder perfomance. If you can test different builds as I did, that would be great :)

[dann23]

Anyone with an AMD CPU to test? I can upload my sample if needed.

I have two AMD systems. One with athlon x2 and one with phenom II x4. I use ICL11 builds on both of them and didn't notice any problems. Just video decoding. no filters. It's worth mentioning that I'm using lavf splitter for mkv files and when it's possible ffdshow dxva. Tomorrow I'll try to post some results with different ffdshow builds.

[STaRGaZeR]

I have two AMD systems. One with athlon x2 and one with phenom II x4. I use ICL11 builds on both of them and didn't notice any problems. Just video decoding. no filters. It's worth mentioning that I'm using lavf splitter for mkv files and when it's possible ffdshow dxva. Tomorrow I'll try to post some results with different ffdshow builds.

If you're not using filters you won't see any differencies, as all the work will be done by ffmpeg, compiled with GCC in all builds. You can try high quality RGB conversion with dithering (you have to output RGB32 for this obviously), deband, sharpen-->unsharp mask, etc. In short, everything that doesn't use ffmpeg.

[STaRGaZeR]

The crash is related to libavcodec/ffmpeg-mt and it looks like it's the same one as the other one you fixed recently. But I cannot reproduce the crash if I run mpc-hc through MSVS.
EDIT: I tried a debug build of mpc-hc and I can reproduce the crash. It must be that ffdshow custom code in golomb.h, line 68. I cannot be sure but this is what I can tell from the disassembly code.

Try with this patch: http://www.mediafire.com/?hnw9w9m7ja1sv1d

Check if ICL11/12 and debug buils are fixed. Fingers crossed :)

[sansnom05]

Try with this patch: http://www.mediafire.com/?hnw9w9m7ja1sv1d

Check if ICL11/12 and debug buils are fixed. Fingers crossed :)

Here's updated icl12/vs2010 builds with STaRGaZeR's golomb patch and /Ob1 flags for libfaad2(aac) to fix audio glitchs. http://www.mediafire.com/?jc0xbxaczqad44r

And if anyone want the vs2010/icl12 project files, please PM me.

[XhmikosR]

My plan was to first get VS2008/ICL12 builds to work fine and then move to VS2010/ICL12 finally. I'll talk to sansnom05 on irc and we'll see what will go in the svn. I have only VS2008/ICL12 projects in my local tree.

@STaRGaZeR: OK then since you do plan to delete the ICL11 projects. I don't like having 20 files in a dir with 15 files being projects :p
I'll give a try to your patch and I'll let your know. (I only have ICL12 installed so I can't try the ICL11 builds anymore)

@clsid: I agree with removing the makefiles from stuff build with VS. I suggest that we remove any random solution files since there are already solution files for ffdshow which includes those projects, like KernelDeint.


EDIT:
@STaRGaZeR: I still get the crashes even with that patch. ICL12 build (http://xhmikosr.1f0.de/zzzother/ffdshow_rev3637_20101204_xhmikosr_icl12.exe).

[STaRGaZeR]

I vote for VS2010 and VS2010/ICL12. I'll delete all the ICL11 stuff as soon as I upgrade. What's left to do to delete VS2008 projects and start making "generic" builds with VS2010?

About the patch, then I'm out of ideas. I'd need a sample to reproduce the crash plus the name of a function or something to start from there. Did it at least fix the crash in debug builds? Does it happen if you use libavcodec instead of ffmpeg-mt?

BTW, I just tested x64 builds with the same sample and filters as before and there's no difference between VS2008/10.

[XhmikosR]

Just to make sure we talk about the same thing, when I said VS2008/ICL12 I mean the ICL12 projects with VS2008. Cause with ICL12 you can use VS2010 now but I had a few problems so I did what was easier at the time. If you mean the generic MSVC builds, I too vote for 2010 since it has no change in size and performance is better. I'll talk to sansnom05 on the irc about the ICL12 builds.
As for the crash I'll need to start digging into the problem with debug builds.

[STaRGaZeR]

Just to make sure we talk about the same thing, when I said VS2008/ICL12 I mean the ICL12 projects with VS2008. Cause with ICL12 you can use VS2010 now but I had a few problems so I did what was easier at the time. If you mean the generic MSVC builds, I too vote for 2010 since it has no change in size and performance is better. I'll talk to sansnom05 on the irc about the ICL12 builds.
As for the crash I'll need to start digging into the problem with debug builds.

Yup, I meant ICL12 projects with VS2010 instead of 2008. And make the generic builds (x86 and x64) with VS2010 from now on.

So who's against removing VS2008 projects and for what reason? There are no known problems with them AFAIK.

[XhmikosR]

OK, I have good news. I'm talking with sansnom05 on irc trying to get the new projects ready and VS2010/ICL12 builds don't crash with the same sample that the VS2008/ICL12 build crashed. Very weird...
I have no problem in removing VS2008 projects, I won't use them anymore.

[STaRGaZeR]

Didn't you say that it happened with ICL11 too? But whatever, if it's fixed with ICL12/VS2010... :p

[fmagreed2]

Could support for HDYC pixel format be added to the encoder? HDYC is the output of the popular black magic capture cards. The default codecs lack options, and aren't really suited for many popular uses of the cards (such as recording console gameplay).

According to fourcc.org HDYC is identical to UYVY in layout, but uses the BT709 colorspace instead of normal BT470.

Off that information, it sounds like it shouldn't be too hard to add, but I really have no idea about these things.

Thank you for your time.

[XhmikosR]

@devs:
How about commenting out the code regarding the donates? The link doesn't work anymore.
Also, do we need all the Japanese translated text files? And also the build scripts are kinda of useless and obviously we don't need 10 batch files for simply building ffdshow. And I'm pretty sure everyone is using their scripts since the ones in the svn do not work as expected in all cases and they do not cover all the compilers.

@STaRGaZeR: when you update to icl12 please remove the icl11 projects.

[clsid]

@devs:
How about commenting out the code regarding the donates? The link doesn't work anymore.It can be removed.

[XhmikosR]

Done. How about the other stuff I asked?

[STaRGaZeR]

And also the build scripts are kinda of useless and obviously we don't need 10 batch files for simply building ffdshow. And I'm pretty sure everyone is using their scripts since the ones in the svn do not work as expected in all cases and they do not cover all the compilers.

Agree.

And what do you think about renaming libavcodec.dll and associated stuff to ffmpeg.dll? Our libavcodec is not libavcodec anymore.

[XhmikosR]

I'm fine with it as long as the installer deletes the old dlls on install if it's an upgrade.
How about the translated readme files? They are not used as far as I can tell and the root directory is too populated in my opinion.

Oh, by the way, is anyone going to update x264, tremor or unrar? The current unrar source is butchered and it's hard for me to update it. sansnom05 updated unrar but he didn't commit it though it worked. I can't remember the reason.

EDIT: I want to apply astyle formatting in ffdshow's own code only since right now its code it's practically unreadable for the most people. What do you prefer, tabs or spaces? Right now I have used 4 spaces for indentation.

[STaRGaZeR]

I don't know how to do that with InnoSetup, but why do it? It wasn't done with libmplayer.dll and since nothing is going to use the dll it should be fine to leave it there.
I'm all for deletion, but if other devs don't want to do it one solution would be to not delete them, create a doc directory and put everything there.

I won't update x264. IMO it has no reason to be there but I know a lot of people use it and will complain, so meh. I asked about Tremor some time ago and there were no responses, libavcodec has been the default decoder for vorbis audio for quite some time with no complaints. So I'll delete it when I have time. I don't care about unrar either.

Spaces of course. If possible try to mimic ffmpeg's style. Just open any of its files and look at it, very easy to read, very well organized, looks really good...

BTW, there's something wrong with debug builds with VS2010. It compiles fine, but when you hit debug I get this warning:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(E:\ffdshow\obj\Debug_Win32_VC2010\ffdshow.ax) does not match the
Linker's OutputFile property value (E:\ffdshow\bin\ffdshow.ax). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName)
and $(TargetExt) property values match the value specified in %(Link.OutputFile).
Creating library E:\ffdshow\obj\Debug_Win32_VC2010\/ffdshow.lib and object E:\ffdshow\obj\Debug_Win32_VC2010\/ffdshow.exp
ffdshow_2010.vcxproj -> E:\ffdshow\obj\Debug_Win32_VC2010\ffdshow.ax

Then an error popup "Unable to start program "E:\ffdshow\obj\Debug_Win32_VC2010\ffdshow.ax"". Can you take a look at it?

[XhmikosR]

It's easy to do it with Inno Setup in the [InstallDelete] section but I'll leave it to clsid to decide about it.

As for the VS2010 warnings, they are caused because the OutDir is different that the linker outdir etc. Cause the dlls and the ax files are output in the bin dir while all other files are output in different dirs. That's why I said in the past that I don't like this approach. I would prefer if everything used one outdir based on the config/compiler.

And also the template configs should be removed since they are useless.

As for astyle, check this and tell me what you think, or suggest any specific options http://pastebin.com/qJtD1XsM
I used 4 spaces for that and all other options are the default ones.

[clsid]

Renaming libavcodec.dll to ffmpeg.dllI don't mind this change if you guys would really like it. But I don't consider this very important. I do would like to keep the name libavcodec in the GUI though, as changing it would confuse people, and of course the decoders are part of libavcodec, so it is still correct.
Deleting files with InnoSetup is easy. Just one line in [InstallDelete] section.
Translated text filesUnused ones could be removed.
Build scriptsI would like to keep these. They are also useful for non-dev builders and serve as a good example for create custom scripts. The ICL one could be removed though.
Astyle formattingI prefer these settings:
--style=kr
--indent-switches
--indent-namespaces
--add-brackets
--convert-tabs

The formatting should be applied just a few files at a time (25 max?) and a build should be made before each commit. This to avoid errors and make it simpler to track down any possible regressions.

The formatting should only be applied to files belonging directly to ffdshow. Files from external sources should not be touched, for example the various codec libs, zlib, etc.

Removing tremorI am not aware of any bugs/limitations in the current libavcodec Vorbis decoder. So unless anyone can come up with a good reason to keep tremor, I agree that it may be removed.

Removing x264I don't mind if this would be removed. It is not really being maintained anymore, and alternatives such as x264vfw as available. Although I agree that some users may not be happy if it were to be removed, but we can't make everybody happy.

We could also consider removing other encoders from ffdshow. FFV1 and FFVHUFF are useful, but what about the others? Is there any good reason for anyone to use for example the libavodec MPEG4 encoder instead of Xvid?

[XhmikosR]

I always test before committing, and I was thinking about the same thing, apply astyle in one dir at a time and check things. I'll try your suggested settings and I'll let you know. And of course I'm not going to apply it in 3rd party code, I know how painful it's to update them after that :p

I do believe that the current scripts are bad. The last time I tried them just for the fun of it, it simply failed. I could share my script but it's not completely silent at the moment, since I use some choice commands to choose what to build. If you could at least remove most of them and simply update the base script to use a few arguments that would be better. Also the Inno Setup path is simply wrong. See the mpc-hc batch file for how to get its path correctly.

EDIT: I'm not sure about the --add-brackets option though I do see the purpose of it. I agree with the rest and also using 4 spaces.

[dann23]

We could also consider removing other encoders from ffdshow. FFV1 and FFVHUFF are useful, but what about the others? Is there any good reason for anyone to use for example the libavodec MPEG4 encoder instead of Xvid?

As I remember, drevil_xxl used to update x264 and if I'm remembering correctly it happend 3 or 4 months ago. Maybe I'm wrong about this. Also I'm using libavcodec mpeg4 encoder instead of xvid. :)

[clsid]

Yes, but WHY are you using the libavcodec MPEG4 decoder?

[dann23]

I have no special reason. It's just that I need to make something with dx50 as fourcc and some time ago xvid seemed to be dead. As decoder I don't know anyone to use xvid. that's why I didn't use the xvid encoder.

[STaRGaZeR]

@clsid

The name change only affects the dll. Changing the GUI would be wrong, because as you say the decoder itself is libavcodec.

I'll remove Tremor then.

So do we remove x264? I vote yes. Also a list fo encoders I'd remove: all libavcodec ones except HuffYUV, FFV1 and maybe DV. And about xvid, xvid also has a vfw codec that works perfectly well, so the same x264 argument could be applied here.

I have no special reason. It's just that I need to make something with dx50 as fourcc and some time ago xvid seemed to be dead. As decoder I don't know anyone to use xvid. that's why I didn't use the xvid encoder.

xvid can also encode with DX50 FOURCC.

[clsid]

ffdshow also has a DirectShow encoder in addition to its VFW one. But there also is an alternative (http://blog.monogram.sk/janos/2009/05/20/monogram-x264-encoder-1050/) for that in case of x264. I don't know if it is good though.

Here is a list of encoders in ffdshow, with my votes/comments:
MPEG4 => remove
Xvid => remove
H.264 => remove
DivX3 => remove
MS MPEG4 => remove
MPEG2 => Remove from VFW, keep in DS? Any free DS alternatives?
MPEG1 => Remove from VFW, keep in DS? Any free DS alternatives?
H.261/3/3+ => Any VFW alternatives?
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => keep?
Lossless JPG => keep? Any advantage over for example Huffyuv?

We could possibly only disable stuff now, await feedback, and then decide in a few months what to remove.

[dann23]

for me it's ok but how to use directshow encoder with virtualdub?
I can quit using vfw completly. I have no problem with this. But I need a similiar tool like virtualdub that is capable to use directshow encoder. Any suggestions?

[CruNcher]

Could somebody check Karls Matroska RV9 testcase for me it drops heavily frames with ffdshows RV40 libavcodec decoder in MPC-HC im not sure why it seems strange as CPU utilization is very low obviously, you can find it here http://www.mediafire.com/?tc6tb131m1i677z.
Tried it also in graphstudio same result it drops frames heavily on both Gabest and Haalis Splitter with the ffdshow decoder. No problems with mplayer,vlc only ffdshow and also the ffplay builds from http://ffmpeg.arrozcru.org/autobuilds/ show this performance issue.

Maybe some Optimization is missing @ compilation in ffdshow as well as those ffplay builds ?

[XhmikosR]

Astyle formatting should be completed. If I applied it in a couple of 3rd files feel free to revert the changes, I tried to review most of the files just in case they are 3rd party code. If I missed any source file, feel free to apply astyle to it.

EDIT: Why exactly do we have to call update_version.bat from the IS script? Isn't it enough to get the needed stuff from svn_version.h? You must have compiled ffdshow before building the installer which means you already have svn_version.h anyway.

[clsid]

There may be changes committed unrelated to building ffdshow.ax, so that is why is never hurts to update version from IS as well.

The RV40 issue is a known FFmpeg bug:
https://roundup.ffmpeg.org/issue814

[XhmikosR]

I'm sorry but this is impossible. The revision will be the last committed rev so calling update_version.bat is pointless. Or at least give me one example where this is needed. Cause it beats me :p

[clsid]

I already gave the example. Commit something does does not affect ffdshow directly. Don't (re)compile ffdshow.ax. Build installer. Yes, I know that the version in the .ax will then be somewhat 'outdated'. But it is masochistic to compile again it just to update a mostly meaningless number.

Please focus on things that actually make ffdshow better in terms of functionality/stability/performance.

[XhmikosR]

OK so you want to keep the case where the wrong revision will be used? That's simply wrong. I will focus where I can and have interest atm.

PS. STaRGaZeR, update your Inno Setup version :p

[clsid]

It is not wrong. The revision applies to the project as a whole, not individual files. If ffdshow.ax has not changed since rev X, then there is no requirement to update its version to rev X+1. That is just optional.

[STaRGaZeR]

ffdshow also has a DirectShow encoder in addition to its VFW one. But there also is an alternative (http://blog.monogram.sk/janos/2009/05/20/monogram-x264-encoder-1050/) for that in case of x264. I don't know if it is good though.

Here is a list of encoders in ffdshow, with my votes/comments:
MPEG4 => remove
Xvid => remove
H.264 => remove
DivX3 => remove
MS MPEG4 => remove
MPEG2 => Remove from VFW, keep in DS? Any free DS alternatives?
MPEG1 => Remove from VFW, keep in DS? Any free DS alternatives?
H.261/3/3+ => Any VFW alternatives?
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => keep?
Lossless JPG => keep? Any advantage over for example Huffyuv?

We could possibly only disable stuff now, await feedback, and then decide in a few months what to remove.

Where is that DS encoder? I didn't know about it and it doesn't show in Graphstudio.

The disable proposal sounds good to me, but in a few months is possible that nobody is active to remove them. I'd remove them now, we can always revert the commit if people complain too much. My opinion:

MPEG4 => remove
Xvid => remove (people should use xvid itself)
x264 => remove (nobody should use it, outdated, can't configure it properly, has proper vfw and cli alternatives)
DivX3 => remove
MS MPEG4 => remove
MPEG2 => remove (if anyone actually wants to encode something in MPEG-2 they should use a proper encoder, like HCenc)
MPEG1 => remove
H.261/3/3+ => remove
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => remove
Lossless JPG => remove

A lot of them are exotic formats that shouldn't really be supported in ffdshow. These formats are so rarely used that if people want to encode to them I'm sure they're advanced enough to use ffmpeg directly, something they should be doing in the first place. So basically I agree with you: only keep FFV1, HuffYUV and DV.

for me it's ok but how to use directshow encoder with virtualdub?
I can quit using vfw completly. I have no problem with this. But I need a similiar tool like virtualdub that is capable to use directshow encoder. Any suggestions?

What formats do you want to encode to? H.264, use x264vfw in Virtualdub. xvid, use xvid in virtualdub. Both have way better GUIs, they're updated, etc.

PS. STaRGaZeR, update your Inno Setup version :p

Done, but is 5.3.8 not enough or what? :eek:

[CruNcher]

There may be changes committed unrelated to building ffdshow.ax, so that is why is never hurts to update version from IS as well.

The RV40 issue is a known FFmpeg bug:
https://roundup.ffmpeg.org/issue814

Thx for the hint but im not sure if that is the real problem as VLC (nightlies) actually plays it fine sound drops from time to time but overall much better.

The end result is this absolutely unwatchable because of the jitter in mpc-hc + ffdshow

http://img31.imageshack.us/img31/6158/jitterheavy.png

[dann23]

Where is that DS encoder? I didn't know about it and it doesn't show in Graphstudio.

The disable proposal sounds good to me, but in a few months is possible that nobody is active to remove them. I'd remove them now, we can always revert the commit if people complain too much. My opinion:

MPEG4 => remove
Xvid => remove (people should use xvid itself)
x264 => remove (nobody should use it, outdated, can't configure it properly, has proper vfw and cli alternatives)
DivX3 => remove
MS MPEG4 => remove
MPEG2 => remove (if anyone actually wants to encode something in MPEG-2 they should use a proper encoder, like HCenc)
MPEG1 => remove
H.261/3/3+ => remove
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => remove
Lossless JPG => remove

A lot of them are exotic formats that shouldn't really be supported in ffdshow. These formats are so rarely used that if people want to encode to them I'm sure they're advanced enough to use ffmpeg directly, something they should be doing in the first place. So basically I agree with you: only keep FFV1, HuffYUV and DV.



What formats do you want to encode to? H.264, use x264vfw in Virtualdub. xvid, use xvid in virtualdub. Both have way better GUIs, they're updated, etc.



Done, but is 5.3.8 not enough or what? :eek:

Fine. Remove all the formats. vfw is old and in windows 7 is present just for compatibility with old software. But where is the DS encoder and how to use it??

[khagaroth]

@XhmikosR
revision 3668, ffdshow.rc:
19: // Neutral resources
20:
21: #if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_NEU)
22: #ifdef _WIN32
23: LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
24: #pragma code_page(1253)
25: #endif //_WIN32
shouldn't that be 1252 (latin 1) instead 1253 which is Greek

[LigH]

I'd like to vote to keep ffdshow's M-JPEG codec. It is by far the best quality M-JPEG codec I know. See my comparison thread in the german board (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&highlight=picvideo). There is no substitution for me.

Reply #1 (start) = artifical still content with samples (click the smilies for sample pictures); reply #19 (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&p=217751&viewfull=1#post217751) = VQEG comparison with PSNR and SSIM

[XhmikosR]

It is not wrong. The revision applies to the project as a whole, not individual files. If ffdshow.ax has not changed since rev X, then there is no requirement to update its version to rev X+1. That is just optional.
Well, in case you don't know, you do NOT have to rebuild the ffdshow project to change the revision. The only file which is affected by the revision is ffdshow.rc. So, the resource compiler will rebuild the resource file and that's all. This will take something like 3 seconds.
It's redundant and should be removed.

Done, but is 5.3.8 not enough or what? :eek:
v5.4.0 is the latest which has a much improved editor. I can tell from the fact that every time you edited the .iss file a new empty line was inserted at the end of the script which was fixed in the latest version.:p
And 5.3.8 is almost one year old, there have been so many improvements.

shouldn't that be 1252 (latin 1) instead 1253 which is Greek
Probably, but this is what VS does.

[_xxl]

Originally Posted by clsid
ffdshow also has a DirectShow encoder in addition to its VFW one. But there also is an alternative for that in case of x264. I don't know if it is good though.
We could possibly only disable stuff now, await feedback, and then decide in a few months what to remove.
I don't have time to update them, please start remove all unnecessary code and maybe fix all warnings. I vote to remove them.

[Px]

shouldn't that be 1252 (latin 1) instead 1253 which is GreekProbably, but this is what VS does.
Location: Hellas (Greece)
:rolleyes:

[XhmikosR]

:rolleyes:

Hmm, so?

[LigH]

So for some reason, your personal matching locale was possibly preferred over a compatible "common base".

[STaRGaZeR]

I'd like to vote to keep ffdshow's M-JPEG codec. It is by far the best quality M-JPEG codec I know. See my comparison thread in the german board (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&highlight=picvideo). There is no substitution for me.

Reply #1 (start) = artifical still content with samples (click the smilies for sample pictures); reply #19 (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&p=217751&viewfull=1#post217751) = VQEG comparison with PSNR and SSIM

So you made a comparison back in 2005 with a sinthetic image and ffmpeg's MJPEG encoder won. Have you ever used it for anything other than that comparison or you just want to keep it in ffdshow because it's good?

[clsid]

Also, does the MJPEG encoder have any practical use? I mean, when does one use it instead of some other video format?


Guys, should we also remove xvidcore.dll from the installer? Some people use it as decoder in ffdshow (instead of libavcodec). Do we keep it, or should such people just install Xvid if they want to be able to use xvidcore inside ffdshow?

[fastplayer]

Guys, should we also remove xvidcore.dll from the installer?
Please do so! When was the last time ffmpeg screwed up Xvid/DivX decoding so badly that you had to switch to xvidcore? (That was a rhetorical question...)

[CruNcher]

@clsid
something is wrong there is no other solution then to switch to the proprietary RealVideo decoder instead, it fixed the Jitter issue immediately obviously its performance is also still better then ffv40 (at least the used one in ffdshow)

Proprietary Decoder (drvc.dll)

http://img72.imageshack.us/img72/2083/jitterfixed.png

[Brazil2]

When was the last time ffmpeg screwed up Xvid/DivX decoding so badly that you had to switch to xvidcore?
Since Xvidcore can properly play this video but none of the ffmpeg decoders:
http://www.mediafire.com/download.php?nub79dtss0kacb2

Not to mention I always thought the idea behind ffdshow is an all-in-one tool and all about options and that's why it's great.
I understand the wish to remove some encoders but why the decoders ? They are always usefull for someone somewhere because there is no one standard ffdshow configuration running on one standard computer but each individual is a particular case.

[LigH]

So you made a comparison back in 2005 with a sinthetic image and ffmpeg's MJPEG encoder won. Have you ever used it for anything other than that comparison or you just want to keep it in ffdshow because it's good?

1. Yes, the test was old, and the first part was quite artifical. But you ignored the second part (VQEG). And you don't seem to care about the magnitude of the advantage either.

2. I'd like to keep that codec because it is good, yes. So if you want it out of ffdshow by all means, don't let it die completely. ffdshow's MJPG codec is not just better. It is by far better than all commercial MJPG codecs with an impressive distance.

3. I am not the one who uses it often. But use my voice vicariously for all those who still use it but are not a board member here (e.g. because they don't speak english) and are not heard here. If necessary, I will collect signatures of those who like it still today.

[CruNcher]

Since Xvidcore can properly play this video but none of the ffmpeg decoders:
http://www.mediafire.com/download.php?nub79dtss0kacb2

Not to mention I always thought the idea behind ffdshow is an all-in-one tool and all about options and that's why it's great.
I understand the wish to remove some encoders but why the decoders ? They are always usefull for someone somewhere because there is no one standard ffdshow configuration running on one standard computer but each individual is a particular case.

though i would prefer rather the divx decoder then xvidcore it also shows no decoding problems on the interlaced parts has better performance and multithreading support compared to xvidcore.
You also should really report this decoding problem to the ffmpeg developers and upload it to their test ftp with a description of the decoding problem.
I guess if you upload this to youtube it should also fail *g*

[nm]

Since Xvidcore can properly play this video but none of the ffmpeg decoders:
http://www.mediafire.com/download.php?nub79dtss0kacb2

Plays fine with mplayer -lavdopts bug=16 and ffplay -bug 16

Bug=16 is "(mpeg4): padding bug (autodetected)", so it looks like a problem in encoder bug detection in h263dec.c.

As CruNcher said, it would be a good idea to report this on FFmpeg bug tracker even when you have another decoder that works better. FFmpeg is ubiquitous.

[clsid]

Libavcodec workarounds can be enabled in the ffdshow settings, on the 'Decoder options' page.

By default autodetect is used. That obviously does not work for this sample, so please report it to FFmpeg bug tracker.
https://roundup.ffmpeg.org/

Due to the existence of the autodetect option, I assume that there may be unwanted side effect to forcing workarounds when not needed (enable always). Does anyone know if that is really the case?

[clsid]

@LigH

The encoders from ffdshow come from FFmpeg, so anyone who would like to use the MJPEG (or other) encoder can do so by using FFmpeg or any of the many conversion programs that are based on it. So lets rephrase the question. Is there a specific need for using ffdshow to encode to MJPEG? Also, when do people use MJPEG?

[STaRGaZeR]

1. Yes, the test was old, and the first part was quite artifical. But you ignored the second part (VQEG). And you don't seem to care about the magnitude of the advantage either.

2. I'd like to keep that codec because it is good, yes. So if you want it out of ffdshow by all means, don't let it die completely. ffdshow's MJPG codec is not just better. It is by far better than all commercial MJPG codecs with an impressive distance.

3. I am not the one who uses it often. But use my voice vicariously for all those who still use it but are not a board member here (e.g. because they don't speak english) and are not heard here. If necessary, I will collect signatures of those who like it still today.

Do you understand that all these encoders are ffmpeg encoders? We are simply removing from ffdshow those that virtually nobody uses for virtually anything. If you want to use it, it's better to use ffmpeg to have full control over it or, as clsid said, one of the multiple programs that will give you exactly the same. ffdshow is just a wrapper for ffmpeg in this regard.

And yes, it would be useful to know: 1. who uses MJPEG, 2. for what purpose, 3. vfw through ffdshow?

@devs, I have a patch that completely removes x264 from ffdshow, tell me when and if you want it commited.

[Brazil2]

By default autodetect is used. That obviously does not work for this sample, so please report it to FFmpeg bug tracker.
https://roundup.ffmpeg.org/
Well, I'm not going to create an account just to report only one bug while I'm quite sure many of you already have accounts and some of you may even be in touch with the ffmpeg devs. So feel free to report this bug.


Libavcodec workarounds can be enabled in the ffdshow settings, on the 'Decoder options' page.

Due to the existence of the autodetect option, I assume that there may be unwanted side effect to forcing workarounds when not needed (enable always).
Exactly, that's why I'm asking to keep Xvidcore in ffdshow, at least while awaiting for the ffmpeg decoder to be fixed.

[fastplayer]

@devs, I have a patch that completely removes x264 from ffdshow, tell me when and if you want it commited.
If _xxl doesn't intend to maintain it anymore and nobody wants to fill in, then please remove it.

[Brazil2]

3. I am not the one who uses it often. But use my voice vicariously for all those who still use it but are not a board member here (e.g. because they don't speak english) and are not heard here.
That's a good point, I also think that the vast majority of ffdshow users have never heard about this board and they are using ffdshow because it's quite simple, all-in-one and also to avoid codec packs and their related problems. I do believe that the advanced users of this board are not representative of this vast majority of users.


And yes, it would be useful to know
3. vfw through ffdshow?
Anyone who is using VirtualDub(Mod) and it seems there is still an army of VD users.

[clsid]

Considering that the current x264 encoder is buggy and there is no maintainer, I agree it can be removed.

@Brazil2, the ability to decode using xvidcore will not be removed. We are just considering to remove the dll from the installer. ffdshow will still be able to use an externally installed copy. Files that need it are very rare and made by buggy encoders, plus there is a known workaround.

I don't have an account there either. Is there anyone here that has one and is willing to report this issue?

[dann23]

@clsid. you said that ffdshow has a DS encoder. how do we use it and where do we find it? also it will be usefull if you recommed a substitute for virtualdub. because, now, with ffmpef mpeg4 removed, virtualdub is useless for me. I don't have a problem if the devs remove all vfw from ffdshow, but we need some alternative if you do this.

[clsid]

ffdshow is feature rich, but not an "all-in-one" solution. Some people think they can do everything with it, but that is just not true. I have needed to help people many times that were missing for example a source filter, thinking ffdshow would take care of it, possibly after being told that ffdshow was 'all they need'. Some even think it can convert their files. The number of people that actually have real problems with codec packs are much much smaller than codec pack haters like you think. Plus most problems are user errors or unrelated problems caused by other software. Besides, a codec pack is not suddenly needed if ffdshow no longer supports MJPEG encoding. Many encoding tools rely on their own private encoders.

Adding/keeping features is not something we must do simply because we can, it must be done if it has significant benefits for the users. If something is used rarely and there are good enough or even better alternatives available, then we might better off without it. Manpower for maintaining/fixing things in ffdshow is simply too scarce.

[clsid]

@clsid. you said that ffdshow has a DS encoder. how do we use it and where do we find it? also it will be usefull if you recommed a substitute for virtualdub. because, now, with ffmpef mpeg4 removed, virtualdub is useless for me. I don't have a problem if the devs remove all vfw from ffdshow, but we need some alternative if you do this.
Why is VirtualDub suddenly useless? If you want to encode MPEG-4, then simply install Xvid (or DivX). That is also better than the encoder offered by ffdshow.

If you want to use the ffdshow filters inside VirtualDub, you can still do that, even regardless of your chosen encoder. Simply use the VirtualDub plugin (ffvdub.vdf) that is included with ffdshow.

The GUID of the DS encoder is {4DB2B5D9-4556-4340-B189-AD20110D953F}, but it has the same functionality as the VFW one.

[dann23]

then the DS encoder is useless to :)
I used ffmpeg mpeg 4 because it was there and I didn't have to install other encoders. So in this case I have to get used to virtualdub external encoders and comand line parameters.

[GrofLuigi]

I use commercial MJPEG codec, but I would imagine many users would still benefit from it in ffdshow.

Mainly because of VFW interface and capture, either from screen or external source. Yes, even webcam, it can be quite useful.

I don't know much about the current implementation, but if it isn't broken and doesn't break other things, why not keep it? :thanks:

GL

[clsid]

It would mostly just mean size reduction for ffmpeg.dll (edit: diff is about 240 KB).

The question I still haven't seen answered is: why use MJPEG instead of some other video formats like Huffyuv (lossless) or Xvid/H.264 (lossy)? Is it faster, does it have better compression/quality ratio for certain types of content, etc. I rarely do any encoding, so I don't have any experience with the MJPEG format.

[STaRGaZeR]

That's a good point, I also think that the vast majority of ffdshow users have never heard about this board and they are using ffdshow because it's quite simple, all-in-one and also to avoid codec packs and their related problems. I do believe that the advanced users of this board are not representative of this vast majority of users.

Anyone who is using VirtualDub(Mod) and it seems there is still an army of VD users.

Let's get real here. The vast majority of ffdshow users don't even know it encodes, let alone its MJPEG capabilities. So yes, you're right, this forum is not representative of the vast majority of users. Besides, the encoder part of ffdshow is far from being all-in-one, easy to use and bug free.

You forgot 1. and 2., please answer these before answering 3. otherwise it's meaningless. We are talking about the MJPEG encoder, not about the vfw encoder in general.

Considering that the current x264 encoder is buggy and there is no maintainer, I agree it can be removed.

OK, I'll remove it then.

I use commercial MJPEG codec, but I would imagine many users would still benefit from it in ffdshow.

Mainly because of VFW interface and capture, either from screen or external source. Yes, even webcam, it can be quite useful.

I don't know much about the current implementation, but if it isn't broken and doesn't break other things, why not keep it? :thanks:

GL

The vfw interface is not going away. Again, x264 and xvid have really good vfw interfaces that are a lot better, are updated and bug free, ffdshow is not. People using vfw should use them.
Just curious, why do you capture to MJPEG and not to a higher quality, easier to use format?

[HeadlessCow]

I've used the MJpeg functionality in the past because it was significantly lower size and CPU usage than using one of the lossless codecs and I didn't care about perfect quality.

My preference (for what it matters) is to leave the formats that libavcodec supports internally and ditch all the formats that are using external libraries (xvid, x264, WMV, ??).

The bare minimum I'd like to see kept is HuffYUV and FFV1, though I mostly use Lagarith lately instead.

[XhmikosR]

How much size will we gain if the encoders supported by ffmpeg are removed from ffdshow? Of course someone can use ffmpeg directly but one might not want or know how to use ffmpeg through the commandline, or simply it's easier to configure the settings through ffdshow. Maybe they shouldn't be removed.
I still want to have different output dirs based on the compiler used. ffmpeg and gcc built files will still be in the bin directory since I don't wanna mess with the makefiles at the moment. This way we can make sure everything goes well for people using different compilers. Does everybody agree with this?

[clsid]

Avidemux is an easy to use, VirtualDub like, interface for using FFmpeg encoders.

Removing MJPEG and Lossless JPEG saves about 240KB in ffmpeg.dll

Use these dirs: bin\x86, bin\x64, bin\x86_icl
Installer should then use a defined value "bin_dir", set by user settings, and use non-icl dir otherwise.

[XhmikosR]

I don't like your suggestion for the simple reason that there are a lot of configurations and I want to keep the compiled files, the pdb files etc in one dir. I'm still thinking about it but it will be something like root\bin10 for VS2010 and root\icl12 for ICL12 (this will fix those warnings about the OutDir and the linker's dir).
I don't really care about VS08 so I may not even touch those projects. The same goes for the ICL10 projects. Whoever uses and maintains those can make any changes they want.
Oh, and it's a good time to remove the random solution files.

As for the installer, that's what my plans are. Also, I have a few suggestions for the installer.

-remove the types since only one is used.
-remove the various MinVersion and use a MinVersion in [Setup] section. Since Inno Setup Unicode is used the minimum version is 0,5.0.
-the main ffdshow component shouldn't be uncheckable like it is now.

[STaRGaZeR]

I've used the MJpeg functionality in the past because it was significantly lower size and CPU usage than using one of the lossless codecs and I didn't care about perfect quality.

Do you use it now? If yes, for what, and would you use it with xvid and x264 around, considering the compatibility, highly customizable compression/speed/size ratios of these 2 encoders? These are the questions to answer. So far no responses, the closest to a good reason has been yours, and you're comparing it to lossless codecs (why?). Still waiting to see some evidence of LigH's "all those who still use it but are not a board member here" though, sounds like a lot of people.

On a side note, I just encoded something with it. Ignoring the crashes because of access violations I got, man it looks horrible. For the same size and encoding speed, x264 and xvid look a lot better, night and day. If you can use ffdshow vfw for webcam capture or something like that as previously mentioned, you can also use x264vfw and xvid, so do yourself a favor and use them instead.

How much size will we gain if the encoders supported by ffmpeg are removed from ffdshow? Of course someone can use ffmpeg directly but one might not want or know how to use ffmpeg through the commandline, or simply it's easier to configure the settings through ffdshow. Maybe they shouldn't be removed.

It's not about the size gain, which is nice, is about why keep them there if nobody realistically uses them, they're buggy and there are way better alternatives. We do have evidence that people use the lossless encoders a lot, none so far about MJPEG, lossless JPEG and the others.

[Valeron]

Hi, XhmikosR.
I've a question regards to your MSVC10 build.
Can MSVC10 build ffmpeg now? Afaik, MSVC10 is still incapable of compiling C99 codes, isn't it?
:thanks:

[betaking]

BUG report! installed last ffdshow_rev3680_20101213_xhmikosr_MSVC2010(X86) or ffdshow_rev3680_20101213_MSVC2010(X86)form xvidvideo.ru click stat-ffdshow-Video decoder configuration click about- Version details,The settings interface did not automatically turn off any tips!
but not happen on ffdshow_rev3679_20101212_MSVC2010(X86) form xvidvideo.ru & ffdshow_rev3680_20101213_xhmikosr_icl12!

[LigH]

Sometimes it happens that the majority of developers assumes wrong about the habits of the majority of the users.

When would anyone decide to use an MJPEG VfW codec? ... Well, I wonder for what purpose all the other commercial MJPEG codecs were made, if not for e.g. analog capturing.

I don't belong to the people who regularly use a capture card. But I am quite certain that there are still some.

What kind of substitution for an MJPEG VfW codec would you recommend for analog capturing? Lossless codecs take more space. DV codecs may have a worse chroma subsampling and less bitrate control. Stronger compressing codecs (e.g. Xvid) may have more obvious artefacts. IMHO, MJPEG is still a useful codec for that purpose. It would be a pity to lose the best-quality variant of them only because the developers believe there are no users.

I believe you will at least agree that a stand-alone ffmpeg.exe won't be used for analog video capturing as long as there are tools like VirtualDub, VirtualVCR etc.
__

P.S.: Let's see how this poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) will develop over the next week(s)...

[GRKNGLR]

BUG report! installed last ffdshow_rev3680_20101213_xhmikosr_MSVC2010(X86) or ffdshow_rev3680_20101213_MSVC2010(X86)form xvidvideo.ru click stat-ffdshow-Video decoder configuration click about- Version details,The settings interface did not automatically turn off any tips!
but not happen on ffdshow_rev3679_20101212_MSVC2010(X86) form xvidvideo.ru & ffdshow_rev3680_20101213_xhmikosr_icl12!

I have same problem too.

[STaRGaZeR]

Sometimes it happens that the majority of developers assumes wrong about the habits of the majority of the users.

When would anyone decide to use an MJPEG VfW codec? ... Well, I wonder for what purpose all the other commercial MJPEG codecs were made, if not for e.g. analog capturing.

I don't belong to the people who regularly use a capture card. But I am quite certain that there are still some.

What kind of substitution for an MJPEG VfW codec would you recommend for analog capturing? Lossless codecs take more space. DV codecs may have a worse chroma subsampling and less bitrate control. Stronger compressing codecs (e.g. Xvid) may have more obvious artefacts. IMHO, MJPEG is still a useful codec for that purpose. It would be a pity to lose the best-quality variant of them only because the developers believe there are no users.

I believe you will at least agree that a stand-alone ffmpeg.exe won't be used for analog video capturing as long as there are tools like VirtualDub, VirtualVCR etc.
__

P.S.: Let's see how this poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) will develop over the next week(s)...

I won't comment on the bolded parts, they speak for themselves.

MJPEG is a lossy codec. Any faster, better quality, better compression lossy encoder will do the job. And if you are into video encoding, you'd know MJPEG is a very, very bad choice unless you're forced to use it for some reason.
Stronger compressing codecs may have more obvious artifacts? Seriously, what are you talking about?

Yes, I agree. We are telling you to use better-in-all-aspects vfw encoders for that, not ffmpeg.exe

And please, when posting links from the German forum here, post at least a Google translate link. This is the English forum, not the German forum. Or better, write in proper English what the poll options mean, because Google fails. About the poll itself, I bet the winner will be the equivalent of "I never use it, but it'll be nice if they keep it, just in case". It has been there for a long time already, just in case. That's the point.

I have same problem too.

Can you please describe it in detail? I don't really understand what "The settings interface did not automatically turn off any tips!" means.

[betaking]

download screen recoder files! After seeing this I think you should understand!
http://www.mediafire.com/?v79zkluwl22p7mm

[STaRGaZeR]

I see now. It crashes here instead of disappearing. ICL12 is fine. Duh.

[XhmikosR]

Hi, XhmikosR.
I've a question regards to your MSVC10 build.
Can MSVC10 build ffmpeg now? Afaik, MSVC10 is still incapable of compiling C99 codes, isn't it?
:thanks:

No one uses MSVC for ffmpeg, all the release builds use gcc for ffmpeg(-mt). MSVC can be used for the debug builds which has some code commented out, but right now debug builds won't compile.


It's not about the size gain, which is nice, is about why keep them there if nobody realistically uses them, they're buggy and there are way better alternatives. We do have evidence that people use the lossless encoders a lot, none so far about MJPEG, lossless JPEG and the others.
Good point. I guess there's no real reason to keep them then.

[GRKNGLR]

Can you please describe it in detail? I don't really understand what "The settings interface did not automatically turn off any tips!" means.

When I go to ffdshow settings > about screen and hit the version details, the window gets closed instead of showing the details. I thought that message was the same as mine; that's why I said I had the same problem.

[HeadlessCow]

Do you use it now? If yes, for what, and would you use it with xvid and x264 around, considering the compatibility, highly customizable compression/speed/size ratios of these 2 encoders? These are the questions to answer. So far no responses, the closest to a good reason has been yours, and you're comparing it to lossless codecs (why?). Still waiting to see some evidence of LigH's "all those who still use it but are not a board member here" though, sounds like a lot of people.

On a side note, I just encoded something with it. Ignoring the crashes because of access violations I got, man it looks horrible. For the same size and encoding speed, x264 and xvid look a lot better, night and day. If you can use ffdshow vfw for webcam capture or something like that as previously mentioned, you can also use x264vfw and xvid, so do yourself a favor and use them instead.



It's not about the size gain, which is nice, is about why keep them there if nobody realistically uses them, they're buggy and there are way better alternatives. We do have evidence that people use the lossless encoders a lot, none so far about MJPEG, lossless JPEG and the others.

Like I said, I used it in the past, not now.

I compared to lossless codecs because that was what clsid asked about it.


The question I still haven't seen answered is: why use MJPEG instead of some other video formats like Huffyuv (lossless) or Xvid/H.264 (lossy)? Is it faster, does it have better compression/quality ratio for certain types of content, etc. I rarely do any encoding, so I don't have any experience with the MJPEG format.

At the time, xvid was too slow to encode at real time on the system I was using (at least without turning off so much stuff that it looked like shit) and with a high quality setting for MJpeg I was able to capture in realtime to a high enough quality that I was able to edit the capture and reencode the results to a format that I actually wanted. Lossless files were too large to deal with.

I don't use it anymore because of three things:
1) A processor fast enough to do x264 in realtime.
2) Tons of cheap disk space.
3) Not capturing video anymore.

Having MJpeg available in ffdshow was convenient since capture apps let you choose a vfw encoder and ffdshow was free and better quality than the competitors.

I don't know if anyone STILL requires this, but it's not hard for me to imagine someone being in the position I used to be in.

[clsid]

I have updated the ac3 encoder, but I haven't got the hardware to test spdif output. Everyone please test it.

[STaRGaZeR]

When I go to ffdshow settings > about screen and hit the version details, the window gets closed instead of showing the details. I thought that message was the same as mine; that's why I said I had the same problem.

Should be fixed after r3682. Thanks to sansnom05 for finding the cause :)

[betaking]

Should be fixed after r3682. Thanks to sansnom05 for finding the cause :)

YES it fixed! thanks!

[dann23]

ati released 10.12 driver and it brings support for decoding divx on gpu. any chance to see this implemented on ffdshow? and I hope someday we'll get mpeg2 decoding using dxva.

[sansnom05]

Everyone:

I've updated the ff_unrar from 3.40 beta 4(2004-08-03) to 3.93 beta 0(2010-03-15), here's the test build link: http://www.mediafire.com/?3cvpw2t14yown4a.

Please test it then report back, if it's ok I'll consider commit it. :thanks:

Edit: the link is corrected.

[GrofLuigi]

Just curious, why do you capture to MJPEG and not to a higher quality, easier to use format?

As others said, because of:

1. CPU usage (my computers are not top-notch and I want to see lower than 50% CPU usage if I need to troubleshoot a problem or have a chance of using another, any, realtime filter).

2. 100% quality is very close to lossles to my eyes, so it's often good enough for me, especially considering the quality of SD sources.

3. If I'm pressed for disk space (not a problem lately, but it might happen), I just lower the quality a little bit and the job is done.

4. General ease of use, all the parameters are well known to me.

GL

[fastplayer]

Please test it then report back, if it's ok I'll consider commit it. :thanks:
I tested it only with one VobSub and it seems to work. :)

[LigH]

Just 5 replies to my poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) so far... but mainly positive answers.

a) must have - rescue it: 1x (not mine!)
b) would use if improved: 1x -- not sure what to be improved; I believe there are compatibility issues with some capturing tool like VirtualVCR
c) nice to have - keep it: 3x (one was mine)
d) don't care, kick it out: 0x

Probably not an urging argument; but at least you can't say "nobody needs it"; such an assumption is quite generalized, don't you agree?

The MJPEG format has its advantages in cases with limited resources. It is a basic and unique format, a milestone in the development of video technologies, with a unique computing/quality/size relation (useful where computing power is low and little quality loss acceptable).

And in ffdshow's VfW codec, the price/quality ratio is exceptional -- I don't even know only one other free MJPEG codec available. So if you really need to remove it from ffdshow, please try to release it separately. Or tell me about a free alternative MJPEG codec with similar quality.

[MicMec]

Sorry to change the subject, I have two questions regarding using ffdshow tryout rather than developing the application. Firstly when I pause a video it works fine but does not display the current frame on the screen I just see a black screen with the time bar at the bottom, is this the intended behaviour? Secondly I think playback works correctly for all audio/video/container combinations I have encountered except AC3 audio in an AVI container is this supported?

I am running ffdshow_rev3631_20101115_clsid under Windows 7 32 bit.

[adam777]

Hello all,
Just a quick question - while playing 24 bit DTS content, I noticed FFDShow which is used as the decoder (libavcodec) choose to output as 16 bit, although 24 bit is also chosen as possible output format.
Anything special I should check to find out what might be the reason?
Thanks, Adam.

[clsid]

Pause behavior is done by your player, ffdshow does nothing more than decode.

AC3 in AVI is extremely common and supported just fine by ffdshow.

libavcodec decodes to 16bit, hence the 16bit output.

[STaRGaZeR]

@devs, I need you help.

I'm trying to use new ffmpeg functions. As I've always done, I export them from ffmpeg.dll putting them in ffmpeg.def, then I load them in Tlibavcodec so they can be used elsewhere. However, this time it's not working.

Here's a simple patch to show the issue: http://www.mediafire.com/?3jvbbagt9dajknq

The problem is that when dll->loadFunction(avfilter_graph_alloc,"avfilter_graph_alloc"); is called, the pointer is set to 0x00000000 instead of the proper address, causing ffdshow to crash. I can see (with DLL Export Viewer) that the function is apparently correctly exported. All the other functions are set to their proper addresses, but if I try to add this or any other function, it'll crash for the same reason. Any suggestions?

[panda-34]

Can an AviSynth script running in ffdshow on MPEG2 video somehow automatically determine what field is first? Or maybe can I reorder top-field-first video so that the script always gets its favorite bottom-field-first stuff? I don't seem to be getting meaningful results with GetParity().

[adam777]

libavcodec decodes to 16bit, hence the 16bit output.

Thanks for the quick reply, clsid.
So using libavcodec, even if I force, say, 32 bit output by allowing only 32 bit in output formats, I will basically output padded 16 bit? (and lose some information from the original 24 bit stream).

Are there any disadvantages to using libdts in this case?
It seems it outputs 24 bit as expected (actually 32 bit but I think I read somewhere about FFDShow not outputting 24 bit usually but padding it to 32 bit).
I used libavcodec as I'm not sure if/when libdts gets updated.

Thanks again.

[clsid]

When software works, there is no need for constant updates. You can safely use libdts, which is also the default in ffdshow. That one decodes to 32-bit float by default.

[adam777]

When software works, there is no need for constant updates. You can safely use libdts, which is also the default in ffdshow. That one decodes to 32-bit float by default.

:thanks:

[STaRGaZeR]

@devs, I need you help.

I'm trying to use new ffmpeg functions. As I've always done, I export them from ffmpeg.dll putting them in ffmpeg.def, then I load them in Tlibavcodec so they can be used elsewhere. However, this time it's not working.

Here's a simple patch to show the issue: http://www.mediafire.com/?3jvbbagt9dajknq

The problem is that when dll->loadFunction(avfilter_graph_alloc,"avfilter_graph_alloc"); is called, the pointer is set to 0x00000000 instead of the proper address, causing ffdshow to crash. I can see (with DLL Export Viewer) that the function is apparently correctly exported. All the other functions are set to their proper addresses, but if I try to add this or any other function, it'll crash for the same reason. Any suggestions?

No one? Without this I can't even try to implement libavfilter's gradfun :(

[sansnom05]

No one? Without this I can't even try to implement libavfilter's gradfun :(

Maybe you were trying to load it from ffmpeg-mt.dll instead of ffmpeg.dll?

[STaRGaZeR]

Maybe you were trying to load it from ffmpeg-mt.dll instead of ffmpeg.dll?

Nope, check the patch. The 3 yadif functions load correctly, the new one doesn't. All of them are only in ffmpeg.dll.

[sansnom05]

Nope, check the patch. The 3 yadif functions load correctly, the new one doesn't. All of them are only in ffmpeg.dll.

How and where you use this new function? Cause seems to me your avfilter_graph_alloc is not initialized, this will happen when you use ffmpeg-mt, right?

[clsid]

@STaRGaZeR

Have you tried adding add this to avfiltergraph.h?
#ifdef __cplusplus
extern "C" {
#endif

[STaRGaZeR]

How and where you use this new function? Cause seems to me your avfilter_graph_alloc is not initialized, this will happen when you use ffmpeg-mt, right?

That's the problem: the function is not even used, the patch only puts its pointer in Tlibavcodec. It compiles fine as it should, it's like ffdshow doesn't find the function in ffmpeg.dll at runtime and returns a NULL pointer, but according to the DLL viewer (and the code) it's there.

@STaRGaZeR

Have you tried adding add this to avfiltergraph.h?
#ifdef __cplusplus
extern "C" {
#endif

Same error unfortunately.

[clsid]

After the rar update, I get this compile error with vs2008 for x64:

.\src\subtitles\Tstream.cpp(514) : error C2664: 'void (HANDLE,UNRARCALLBACK,LPARAM)' : cannot convert parameter 2 from 'overloaded-function' to 'UNRARCALLBACK'
None of the functions with this name in scope match the target type

No problem with x86 build. Any ideas?

[sansnom05]

After the rar update, I get this compile error with vs2008 for x64:

.\src\subtitles\Tstream.cpp(514) : error C2664: 'void (HANDLE,UNRARCALLBACK,LPARAM)' : cannot convert parameter 2 from 'overloaded-function' to 'UNRARCALLBACK'
None of the functions with this name in scope match the target type

No problem with x86 build. Any ideas?

Sorry it's my fault, forgot to change callback function declaration in this commit, though I did make the change in the patch I gave to XhmikosR months ago :(. Will fix it now.

[grayedout]

Need help with ffdshow x64 version.

I've got crash in ffdshow x64 when memory usage of the program exceeds 2GB. The program I'm developing is 64-bit and using 64-bit version of DirectShow. Main thread is creating several decoder objects and every object creates its own filtergraph which uses ffdshow x64 for decoding. As soon as memory working set of the program exceeds 2GB, program crashes when trying to create next filtergraph with ffdshow in it. Call stack shows that crash is somewhere in libavcodec.dll.

When using another codec (for example CoreAVC x64) in the same configuration, everything works fine even program's working set is 5-6Gb.

Any suggestions why this happens? Thanks in advance.

[Reimar]

Any suggestions why this happens? Thanks in advance.

Non-64-bit-safe coding. E.g. casting a pointer to an int (HANDLE type might be just as bad, I don't know for sure), or calling a function without including the proper header (should cause an error with C++ though, and for C you should set compiler options so any of these result in a compile error).

[sansnom05]

@clsid

Maybe you forget to copy vp3.c/vp3data.h/xiph.c/xiph.h from ffmpeg -> ffmpeg-mt after you added MT support for vp3/theora?

[clsid]

Fixed ;)

[grayedout]

Non-64-bit-safe coding.

Is there any chance to fix it in ffdshow x64?

[grayedout]

Guys, I've tried this build - ffdshow_rev3690_20101220_xhmikosr_x64_MSVC2010.exe taken from the site from XhmikosR signature. And this version works fine so far. Program's working set is over 5GB and no crashes!

[STaRGaZeR]

1 more reason to upgrade to VS2010 for generic builds :D

[clsid]

There was a malloc related change in ffmpeg recently. So maybe it is just by using a recent ffdshow build the problem got fixed.

[Gser]

Install vfwxvid and x264 to get them back. They were removed because it was pointless to include them in the first place and a major hassle to keep updating them (hence they weren't).

[MicMec]

Thanks for the prompt response clsid,

Looks as though my problem with AC3 in AVI container was related to a couple of corrupt videos and actually works fine with all the other files in the same format - My bad.

I also discovered that the black screen on pause issue goes away if I disable "queue output samples". Not sure what this feature does but it doesn't seem to have caused any other issues.

Now a very happy camper.

[iron2000]

I'm still experiencing the same freezing problem (http://forum.doom9.org/showthread.php?p=1461102#post1461102) with recent builds.

[Gingko]

Hello,

I am trying to decode digital TV with audio as "AAC in transport stream with a synchronization layer (LOAS) and a multiplex layer (LATM)" used in some countries, and to find codecs working with this.

I more or less succeeded with Monogram AAC Decoder (http://blog.monogram.sk/janos/2009/03/08/monogram-aac-decoder-0960/), but I had to modify and recompile it in order to get it working, because the proper Media Type was not exposed to DirectShow (although internally used). Now it works, but with some instabilities.

This Media Type, as far as I understand correctly, is defined (at least by Microsoft (http://msdn.microsoft.com/en-us/library/dd390676%28v=VS.85%29.aspx)) as MEDIASUBTYPE_MPEG_LOAS, and its value is {00001602-0000-0010-8000-00AA00389B71}.

Monogram AAC Decoder is a wrapper for libfaad2, which is used also by ffdshow-tryouts, so logically, ffdshow-tryouts should be able to decode it, but unfortunately, it does not expose this Media Type either.

I'm wondering if it wouldn't be possible to include it in future versions of ffdshow-tryouts in order to make possible, or more easy, to get ffdshow-tryouts decoding AAC+LOAD+LATM?

If you need some sample, you can use this file :
http://gingko.homeip.net/misc/TDT_Continente_2010-12-09_19-20-02.ts

This is a 30 seconds record of a full DVB-T Transport Stream multiplex (from Portuguese TV) with 4 TV channels (plus an empty one), all encoded as H264 (for video) and AAC+LATM+LOAS for audio.

Regards,

Gingko

[robpdotcom]

I have a question about decoding TrueHD:

From what I've read, all TrueHD streams are 24 bit, but sometimes are actually 16 bit padded with 8 empty bits.

So, which output format should be selected to output bit-exact decoded PCM streams? Do you need to know if there are 8 empty bits, and select 16 bit in those cases, or should 24 bit be used for all TrueHD streams?

[xv]

I already made a feature request for Indeo5/I.263 for ffdshow. Since nobody seemed to be interested in that I tried it myself.
I was able to add I.263 support, but I fail with Indeo 5:
For Indeo 5 I have to build ffmpeg.dll myself. Unfortunately that doesn´t work, because all mingw64 versions I tried produce global symbols without underscores in front (I read that this was changed in april 2010).
Unfortunately ffdshow seems to expect underscores in front of global symbols. Can someone post a link to a working version of mingw64 or tell me how to change mingw64 behavior?

[clsid]

Have you also tested the i263 with multiple samples? It was disabled in the past because it did not work properly. But that may have been fixed since then.

Use the sezero mingw64 builds. Or better yet, make a x86 build.

[xv]

Have you also tested the i263 with multiple samples? It was disabled in the past because it did not work properly. But that may have been fixed since then.
No, not all, but most samples, work:
-With PB-frames enabled non-keyframes are corrupted
-With "Strict H.263 Compliance" enabled it doesn´t work at all. (using normal H263 decoder, the files play fine).
Both problems are ffmpeg problems.
All other files work fine and nothing results in a crash.
Maybe I´m able to fix at least the second problem.
Use the sezero mingw64 builds. Or better yet, make a x86 build.That are the builds I used and it contains a readme:
Compatibility Notice: ** No leading underscore **
------------------------------------------------------------------------
Unlike the other builds from mingw-w64 up to 2010-04-27, these new win64
targetting toolchains do *not* prepend an undersocore to the symbols and
follows the MSVC x64 convention. Therefore, any of the link libraries
from previous toolchains are incompatible with the ones created by these
new builds.
That seems to be the problem. Is there a build from 2010-04-27 or older available somewhere? What build should I use for x86? The sezero build only supports x64.

[clsid]

You can find a MinwG32 installer on the ffdshow SourceForge page.

I have just added Indeo5 support.

Can you upload non-working I263 samples? It is always useful to have such samples. Here is FFmpeg bug tracker is case you want to report it:
https://roundup.ffmpeg.org/

[xv]

Both samples are using PB-Mode:

ftp://ftp1.mplayerhq.hu/MPlayer/samples/V-codecs/I263/i263.avi
ftp://ftp1.mplayerhq.hu/MPlayer/samples/V-codecs/I263/i263_2.avi

In Strict mode the files are H.263 compatible, the only difference seems to be the header, my idea is to detect standard H.263 at the beginning of ff_intel_h263_decode_picture_header and just call h263_decode_picture_header if it is standard H.263.

I uploaded file:
https://roundup.ffmpeg.org/issue2449

Note that I.263 was not just disabled in ffdshow, but treated as a extension of H.263 rather than a different codec in several parts of the code, I fixed that to make it work.

Edit:
I was able to compile ffmpeg.dll x86 and fixed the Intel I.263 bug with strict H.263 compliance. Not sure if the PB-frames bug is as easy.
I submitted patch here: https://roundup.ffmpeg.org/issue2449
Edit 2:
Can you (or somebody else) forward this patch to ffmpeg-devel, I´m too stupid for mailing lists.

[PaulJBis]

Hi all:

I've recently been trying to convert a DVD that I have to AVI/Xvid, using ffdshow's Xvid encoding, but I had it crash on me every time. My setup is the following:

-I'm using Windows 7 64 bit.
-Virtualdub 1.9.11 (and 1.9.9 before that). Stock binary from the official download site (in other words, it's the 32 bit version).
-ffdshow v. 3154, 8 dec. 2009 (or, in other words, the last version marked as stable in the official download site (which is also 32-bit)).
-I import the VOBs using the MPEG2 importer plugin for Virtualdub (but before that I was also using DGIndex and Avisynth to frameserve).
-I then resize the video to my desired size, get into ffdshow and, in the "Encoder" section, I pick Xvid. I then set it up for "2 pass encoding, 1st pass".
-...And then, when I hit "Save as AVI", Virtualdub crashes.

I have pasted below the crash report generated by Virtualdub:

VirtualDub crash report -- build 32842 (release)
--------------------------------------

Disassembly:
0f4f9800: 00c0 add al, al
0f4f9802: c785dcfcffff01 mov dword ptr [ebp-324], 00000001
000000
0f4f980c: 8985e4fcffff mov [ebp-31c], eax
0f4f9812: ff1504c2520f call dword ptr [0f52c204]
0f4f9818: 6a00 push 00h
0f4f981a: 8bd8 mov ebx, eax
0f4f981c: ff1508c2520f call dword ptr [0f52c208]
0f4f9822: 8d8528fdffff lea eax, [ebp-2d8]
0f4f9828: 50 push eax
0f4f9829: ff150cc2520f call dword ptr [0f52c20c]
0f4f982f: 85c0 test eax, eax
0f4f9831: 750c jnz 0f4f983f
0f4f9833: 85db test ebx, ebx
0f4f9835: 7508 jnz 0f4f983f
0f4f9837: 6a02 push 02h
0f4f9839: e82d960000 call 0f502e6b
0f4f983e: 59 pop ecx
0f4f983f: 68170400c0 push c0000417
0f4f9844: ff154cc2520f call dword ptr [0f52c24c]
0f4f984a: 50 push eax
0f4f984b: ff1510c2520f call dword ptr [0f52c210]
0f4f9851: 8b4dfc mov ecx, [ebp-04h]
0f4f9854: 33cd xor ecx, ebp
0f4f9856: 5b pop ebx
0f4f9857: e817960000 call 0f502e73
0f4f985c: c9 leave
0f4f985d: c3 ret
0f4f985e: 8bff mov edi, edi
0f4f9860: 55 push ebp
0f4f9861: 8bec mov ebp, esp
0f4f9863: ff350425670f push dword ptr [0f672504]
0f4f9869: e8fa790000 call 0f501268
0f4f986e: 59 pop ecx
0f4f986f: 85c0 test eax, eax
0f4f9871: 7403 jz 0f4f9876
0f4f9873: 5d pop ebp
0f4f9874: ffe0 jmp eax
0f4f9876: 6a02 push 02h
0f4f9878: e8ee950000 call 0f502e6b
0f4f987d: 59 pop ecx
0f4f987e: 5d pop ebp
0f4f987f: e9b2feffff jmp 0f4f9736
0f4f9884: 33c0 xor eax, eax
0f4f9886: 50 push eax
0f4f9887: 50 push eax
0f4f9888: 50 push eax
0f4f9889: 50 push eax
0f4f988a: 50 push eax
0f4f988b: e8ceffffff call 0f4f985e
0f4f9890: 83c414 add esp, 14h <-- FAULT
0f4f9893: c3 ret
0f4f9894: 8bff mov edi, edi
0f4f9896: 55 push ebp
0f4f9897: 8bec mov ebp, esp
0f4f9899: 83ec20 sub esp, 20h
0f4f989c: 8b4508 mov eax, [ebp+08h]
0f4f989f: 56 push esi
0f4f98a0: 57 push edi
0f4f98a1: 6a08 push 08h
0f4f98a3: 59 pop ecx
0f4f98a4: bebc15580f mov esi, 0f5815bc
0f4f98a9: 8d7de0 lea edi, [ebp-20h]
0f4f98ac: f3a5 rep movsd
0f4f98ae: 8945f8 mov [ebp-08h], eax
0f4f98b1: 8b450c mov eax, [ebp+0ch]
0f4f98b4: 5f pop edi
0f4f98b5: 8945fc mov [ebp-04h], eax
0f4f98b8: 5e pop esi
0f4f98b9: 85c0 test eax, eax
0f4f98bb: 740c jz 0f4f98c9
0f4f98bd: f60008 test [eax], 08h
0f4f98c0: 7407 jz 0f4f98c9
0f4f98c2: c745f400409901 mov dword ptr [ebp-0ch], 01994000
0f4f98c9: 8d45f4 lea eax, [ebp-0ch]
0f4f98cc: 50 push eax
0f4f98cd: ff75f0 push dword ptr [ebp-10h]
0f4f98d0: ff75e4 push dword ptr [ebp-1ch]
0f4f98d3: ff75e0 push dword ptr [ebp-20h]
0f4f98d6: ff1500c2520f call dword ptr [0f52c200]
0f4f98dc: c9 leave
0f4f98dd: c20800 ret 0008
0f4f98e0: 8bff mov edi, edi
0f4f98e2: 55 push ebp
0f4f98e3: 8bec mov ebp, esp
0f4f98e5: 51 push ecx
0f4f98e6: 53 push ebx
0f4f98e7: 8b450c mov eax, [ebp+0ch]
0f4f98ea: 83c00c add eax, 0ch
0f4f98ed: 8945fc mov [ebp-04h], eax
0f4f98f0: 648b1d00000000 mov ebx, fs:[00000000]
0f4f98f7: 8b03 mov eax, [ebx]
0f4f98f9: 64a300000000 mov fs:[00000000], eax
0f4f98ff: 8b db 8bh

Built on Aegis on Fri Dec 24 13:18:44 2010 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7600) []

EAX = 0018efb8
EBX = 00000001
ECX = 00000000
EDX = 00000000
EBP = 00000000
ESI = 0d3d47d8
EDI = 0d43a088
ESP = 0018f28c
EIP = 0f4f9890
EFLAGS = 00200206
FPUCW = 18f004
FPUTW = 0003

Crash reason: unknown exception 0xc0000417

Crash context:
An exception occurred in module 'ffdshow'...

...while passing start message to video compressor (w32videocodecpack.cpp:337).

Pointer dumps:

EAX 0018efb8: 00010001 76eedec6 00000001 00000000 0018f000 0018efec 00000000 0018f004
ESI 0d3d47d8: 0f579ba4 0f579be8 0d4350f4 0d43510c 0d43a088 0d417268 00000000 00000000
EDI 0d43a088: 0f55cb04 0d435600 0d435600 00000001 00000003 00000384 0002123b 00000190
ESP 0018f288: 00000000 0f4f9890 00000000 00000000 00000000 00000000 00000000 0f408407
0018f2a8: 00000000 0d4350f8 0d4353f0 00000001 0f4fd3ba 0dd80000 0d3cd750 00000060
0018f2c8: 00000001 00000000 00000000 00000000 0f4f9356 00000000 00000001 0d4353f4
0018f2e8: 0f3f66ab 00010381 00000000 00000250 00000140 00000000 00000000 00000000

Thread call stack:
0f4f9890: ffdshow!DllGetClassObject [0f2b0000+246430+3460]
0f4f9890: ffdshow!DllGetClassObject [0f2b0000+246430+3460]
0f408407: ffdshow!configureEnc [0f2b0000+106a40+519c7]
0f4fd3ba: ffdshow!DllGetClassObject [0f2b0000+246430+6f8a]
0f4f9356: ffdshow!DllGetClassObject [0f2b0000+246430+2f26]
0f3f66ab: ffdshow!configureEnc [0f2b0000+106a40+3fc6b]
0f4eb20d: ffdshow!configureEnc [0f2b0000+106a40+1347cd]
0f4edc08: ffdshow!configureEnc [0f2b0000+106a40+1371c8]
02d940c5: ff_vfw!DriverProc [02d90000+3f58+16d]
741b1759: MSVFW32!ICSendMessage [741b0000+1728+31]
0057e97a: VDVideoCompressorVCM::Start()
76ef36fa: ntdll!RtlImageNtHeader [76ec0000+32fe4+716]
76ef32f2: ntdll!RtlImageNtHeader [76ec0000+32fe4+30e]
758b14d1: kernel32!HeapFree [758a0000+114bd+14]
005b306d: free()
005b308c: free()
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
005b308c: free()
00577bd8: VDResamplerGenerateTable()
0057005c: VDResamplerSeparableTableRowStage8SSE41::Process()
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eedea3: ntdll!RtlFreeHeap [76ec0000+2de25+7e]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eedf72: ntdll!RtlAllocateHeap [76ec0000+2dec6+ac]
005b306d: free()
005b308c: free()
005b308c: free()
0049f9a6: ?$vdfastvector_base::_reserve_always()
76eedea3: ntdll!RtlFreeHeap [76ec0000+2de25+7e]
005b306d: free()
005b308c: free()
005b308c: free()
0055f19a: VDPixmapUberBlitterGenerator::~VDPixmapUberBlitterGenerator()
0055724c: VDPixmapResampler::Init()
75bc4a70: USER32!GetMonitorInfoA [75ba0000+24a21+4f]
75bc4efa: USER32!EnumDisplayDevicesA [75ba0000+24c48+2b2]
75bc4adc: USER32!GetMonitorInfoA [75ba0000+24a21+bb]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
0057005c: VDResamplerSeparableTableRowStage8SSE41::Process()
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eedf72: ntdll!RtlAllocateHeap [76ec0000+2dec6+ac]
005b2fb6: malloc()
0f4eda8c: ffdshow!configureEnc [0f2b0000+106a40+13704c]
02d94125: ff_vfw!DriverProc [02d90000+3f58+1cd]
741b1759: MSVFW32!ICSendMessage [741b0000+1728+31]
005b2fb6: malloc()
005b5097: realloc()
005b526e: realloc()
0041a6ae: Dubber::InitOutputFile()
0041c0f3: Dubber::Init()
0041c0fa: Dubber::Init()
75bbc9e6: USER32!GetWindowLongA [75ba0000+1c9ac+3a]
75bc2d97: USER32!UpdateWindow [75ba0000+22d12+85]
0046309e: VDProject::RunOperation()
004134c7: SaveAVI()
76edf88a: ntdll!NtCallbackReturn [76ec0000+1f878+12]
00523ff9: VDGetSaveFileName()
004608ca: VDProject::SaveAVI()
004528b1: SaveAVI()
00465890: VDProjectUI::SaveAVIAsk()
0046c4e6: VDProjectUI::MenuHit()
75bb6ec0: USER32!GetClassNameW [75ba0000+16b04+3bc]
004794a0: VDUIFrame::DefProc()
0046da41: _catch$?MainWndProc@VDProjectUI@@IAEJIIJ@Z$0()
00465ac0: VDProjectUI::WndProc()
00479b65: VDUIFrame::StaticWndProc()
75bb6238: USER32!gapfnScSendMessage [75ba0000+15fc8+270]
75bb68ea: USER32!gapfnScSendMessage [75ba0000+15fc8+922]
75bb6899: USER32!gapfnScSendMessage [75ba0000+15fc8+8d1]
76ed00e6: ntdll!KiUserCallbackDispatcher [76ec0000+100b8+2e]
75bb7d31: USER32!LoadStringW [75ba0000+17c12+11f]
75bdeec0: USER32!PeekMessageA [75ba0000+3ed58+168]
75bbced4: USER32!GetAncestor [75ba0000+1cebf+15]
75bb8112: USER32!DispatchMessageA [75ba0000+18103+f]
00452596: WinMain@16()
005b78db: __tmainCRTStartup()
758b3677: kernel32!BaseThreadInitThunk [758a0000+13665+12]
76ef9d72: ntdll!RtlInitializeExceptionChain [76ec0000+39d0f+63]
76ef9d45: ntdll!RtlInitializeExceptionChain [76ec0000+39d0f+36]

-- End of report


If you guys need more information, please ask. Apologies if I've skipped some of the existing protocol to report bugs.

[DMD]

Good evening and happy holidays

I apologize if the question has already been posted,
I could not do a thorough search.

What is the difference between the versions:

1 - icl12
2 - MSVC2010
3 - MSVC2008

THANKS

[clsid]

@PaulJBis
You should use the normal Xvid codec. Encoding MPEG-4 with ffdshow is inferior, buggy, and has recently been removed.

@DMD
Read the first post and the last few pages of this topic.

[clsid]

@xv
I will have a look at your patches and if they work I will apply them to our ffdshow trunk.

[xv]

I made I full patch for ffdshow to revision 3701 (attached to this post). supports I263 except PB-mode without strict H.263 compliance (according to http://wiki.multimedia.cx/index.php?title=I263 it uses an old version of enhanced pb-frame mode, ffmpeg doesn´t seem to support that).
Therefore I called the codec "Intel H.263 (incomplete)".

Edit:
You´re really fast, I see you already added I.263. Just my patch(s) for intelh263dec.c are still missing.

[PaulJBis]

@PaulJBis
You should use the normal Xvid codec. Encoding MPEG-4 with ffdshow is inferior, buggy, and has recently been removed.



Oh, okay then. However, I also tried with Xvid 1.2.2, and it also crashed, although it did on the second pass.

[LigH]

Current poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) result:

4× "must have!"
1× "need fixes" -- probably already solved
5× "nice to have"
1× "don't care"

Well, more or less a 10:1 for "keep MJPEG".

I hope it has any value.

[nevcairiel]

You forget about the thousands of people that just use ffdshow, but would never even bother to read any forum about it ;)

[lych_necross]

Current poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) result:

4× "must have!"
1× "need fixes" -- probably already solved
5× "nice to have"
1× "don't care"

Well, more or less a 10:1 for "keep MJPEG".

I hope it has any value.
Well, it verifies what I thought. <opinion>MJPEG should be kept for the time being.</opinion>

[clsid]

I count "nice to have" as "don't care" rather than "must have!". So the poll results are up to different interpretation. And polls like these are biased to begin with.

Skimming through that topic I for example see than someone voted to keep it because he needs to to decode videos from his digital camera. No decoders are going to be removed! The discussion is solely about the encoder.

But don't worry. It won't be removed. For now. This may change in the future.

[Blight]

Hi Guys,
Some recent change(s) to the FFDShow API broke backward compatibility in the 'IffDecoder' interface (the 'putParamStrW' function now crashes due to incompatible headers). Is it possible to update the Delphi header files to the most recent version and possibly keep backward compatibility in future builds?

[clsid]

Please figure out which change broke the API. Your program is a user of the API, so you can test it better. If you post a patch, I will apply it.

Edit: It is probably due to r3603/r3516:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=3616
I am not sure what the proper solution would be. Perhaps adding a dummy function?

[THX-UltraII]

i m using mpc-hc lastest build and ffdshow latest (dl-ed from http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/).

problem is that my subtitles flicker a lot during a movie. what could cause this?

[Blight]

clsid:
I'm not trying to get backward compatibility as I realize it's probably a lost cause. What I'm trying to do is modify my code to be compatible with the current builds, but the Delphi header translation on the SVN is 13 months old and no longer compatible.
I was hoping one of the devs would update the delphi headers and from now on when changes are made, they would be made to a different class (i.e. iffdecoder2, iffdecoder3, etc...) thus maintaining compatibility from now on. I tried doing it myself, but I don't think I'm doing it right as I keep getting crashes.

P.S.
Backward compatibility has been broken at least once before this current issue, that's why I'm asking ...

[Sebastiii]

clsid:
I'm not trying to get backward compatibility as I realize it's probably a lost cause. What I'm trying to do is modify my code to be compatible with the current builds, but the Delphi header translation on the SVN is 13 months old and no longer compatible.
I was hoping one of the devs would update the delphi headers and from now on when changes are made, they would be made to a different class (i.e. iffdecoder2, iffdecoder3, etc...) thus maintaining compatibility from now on. I tried doing it myself, but I don't think I'm doing it right as I keep getting crashes.

P.S.
Backward compatibility has been broken at least once before this current issue, that's why I'm asking ...

Hi,

This is FFDShowAPI that we use in mediaportal -> all is working good so i hope that it's working for you too :)
FFDShowAPI Mediaportal (http://www.mediafire.com/?uhmjo81fzyonmbi)

Edit :
This is the patch that works on FFDShow (small modification on using FFDShow (mediaportal) and FFDShowAPI (FFDShow) and also Copyright).
FFDShowAPI Diff (http://www.mediafire.com/?b3dgaf4vciqyqno)

Cheers,
Seb.

[clsid]

I shall commit that patch.

[Sebastiii]

I shall commit that patch.

Thank you :)

clsid:
I'm not trying to get backward compatibility as I realize it's probably a lost cause. What I'm trying to do is modify my code to be compatible with the current builds, but the Delphi header translation on the SVN is 13 months old and no longer compatible.
I was hoping one of the devs would update the delphi headers and from now on when changes are made, they would be made to a different class (i.e. iffdecoder2, iffdecoder3, etc...) thus maintaining compatibility from now on. I tried doing it myself, but I don't think I'm doing it right as I keep getting crashes.

P.S.
Backward compatibility has been broken at least once before this current issue, that's why I'm asking ...

For the Delphi API, i think you should comment out this line in delphi\IffDecoder_com.pas :

Line 504 : function getPostproc(postprocPtr:ppointer):HRESULT;stdcall;

I think with that all should be ok :)
Seb.

[LigH]

I count "nice to have" as "don't care" rather than "must have!". So the poll results are up to different interpretation. And polls like these are biased to begin with.

Yes, it is possibly biased ... but as I already mentioned, ffdshow's MJPEG encoder is exceptional in quality. There is no known substitute for me. In contrast to e.g. MPEG4-ASP and MPEG4-AVC codecs where we have Xvid and x264 as much more practical solutions for end users.

Well -- I am relieved. :cool: :thanks:

[xv]

I found out that ffmpeg supports neither standard pb-frame nor enhanced correctly. Not sure if it´s a regression or it never worked.

I just noticed you forget to add CODEC_ID_H263I in TimgFilterPostproc.cpp. Or was this intentional?

[Snowknight26]

ffdshow still seems to have issues doing colorspace conversions from BGR24, including a couple of crashes referring ffmpeg.dll (that don't seem to reproduce with the ffmpeg cli).

Sample: http://stfcc.org/misc/ffdshow.fraps.bug.rar

[clsid]

Any help solving those colorspace problems is welcome.

Could you post (small) sample file(s) to reproduce the problems? That will be helpful for anyone that wants to try to fix these problems.

[xv]

I found an interesting bug:
Post-processing using mplayer method will result in a crash with Indeo3 and Indeo5 (Indeo2 not tested). Also when you watch a few seconds without ffdshow crashing chroma artefacts are introduced.
Could the problem be the 4:1:0 colorspace?
All other post-processing except fast SPP doesn´t seem to do anything at all.

[clsid]

I shall disable PP for Indeo until someone figures out what is wrong and fixes it.

[STaRGaZeR]

Current poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) result:

4× "must have!"
1× "need fixes" -- probably already solved
5× "nice to have"
1× "don't care"

Well, more or less a 10:1 for "keep MJPEG".

I hope it has any value.

As expected, not a single "yes, I use it now, for XXX in YYY because of ZZZ" yet. All of them are don't care/don't know/what's MJPEG/it's a pity to lose something nobody uses so keep it. So yes, it does have value, but against MJPEG not the other way around. And that's in a forum full of people in the know. What we know for sure is that people don't want to lose things, even when they don't use them ;)

There is no known substitute for me.

And it seems you fit the above description quite well. You don't use it, but there's no substitute :rolleyes:

_______________________________


Another quick test. Random file, 1050p. 2 passes with MJPEG. Pass 1 results in a 341MB file. Pass 2 with a target size of 200000 KBytes ends up in the same 341MB file.

Another file, same 1050p resolution. Pass 1 results in a 174MB file. Pass 2 with a target size of 100000 KBytes results in a 132MB file.

If I choose large target sizes, VirtualDub crashes.

My conclusion: 2 pass mode doesn't work properly.

This time with the first sample only:

1 pass average bitrate: 7000 kbps results in a 228MB file. 9500 kbps results in the same 228MB file. My conclusion: this doesn't work either.

Constant quantizer and quality work OK aparently. I say aparently because the only thing I've looked at is that lower quantizers and higher quality both result in better quality and bigger files as they should, so I don't know if the files are actually encoded with the configured CQ.

_______________________________

Less talk and more tests are wecomed ;)

[LigH]

Well, looks like I should have asked everyone who still uses it to walk up the barricade with waving flags, instead of just clicking a checkbox anonymously. May be that I hardly use it. But I am not so "selfish" that I only think of myself and my own needs; I try to consider the needs of others too. And I am scolded for it. What a community... :rolleyes:

Enough of fruitless arguing. I can only assume that there are still users, with a probability like there are aliens in outer space, but I can't point on one of them and name them.
__

2-pass MJPEG?! :eek: I never even considered that... :cool:

MJPEG with a fixed quantizer is useful for real-time urgent encodings like analog capturing. With a fixed quantizer or a "constant quality" it may even be partially suitable for intermediate heavily-filtered videos for a following 2-pass encode. But 2-pass encoding to a target bitrate ... hmm, considering the own bitrate requirements, that is an ... "interesting idea".

[clsid]

@LigH
You must also understand things from out point of view. We are trying to remove all inferior and non-working stuff. For two main reasons: (1) because they are not maintained and thus we can't do any bugfixes, and (2) to direct users to better alternatives. I absolutely don't mind keeping MJPEG if there are good reasons to keep it. But such arguments should come from people who still use it now and not from people who used it a few times long ago. So far I have seen one good argument, it having good performance for capturing. It having good quality has already been debunked, as other format perform significantly better in that area. Of course the performance argument could use some validation as well. Anyone interested in testing fps compared to 1-pass Xvid and H.264 encoding with fast settings?

@STaRGaZeR
If you want and have time, you could remove 2-pass mode for MJPEG. I assume that those who use MJPEG use it as an intermediate format during capturing.

[STaRGaZeR]

Well, looks like I should have asked everyone who still uses it to walk up the barricade with waving flags, instead of just clicking a checkbox anonymously. May be that I hardly use it. But I am not so "selfish" that I only think of myself and my own needs; I try to consider the needs of others too. And I am scolded for it. What a community... :rolleyes:

Enough of fruitless arguing. I can only assume that there are still users, with a probability like there are aliens in outer space, but I can't point on one of them and name them.
__

2-pass MJPEG?! :eek: I never even considered that... :cool:

MJPEG with a fixed quantizer is useful for real-time urgent encodings like analog capturing. With a fixed quantizer or a "constant quality" it may even be partially suitable for intermediate heavily-filtered videos for a following 2-pass encode. But 2-pass encoding to a target bitrate ... hmm, considering the own bitrate requirements, that is an ... "interesting idea".

We told you we wanted people to give us reasons to keep the encoder, not to check an option in a poll. I hope you can see the difference...

Did you even know the option was there? :D
I know nobody uses 2 passes, but it's there and it's buggy as I said. I did some qualitative tests days ago, that's why I told you the encoder was buggy. I like to backup my claims, unlike others.

Of course the performance argument could use some validation as well. Anyone interested in testing fps compared to 1-pass Xvid and H.264 encoding with fast settings?

@STaRGaZeR
If you want and have time, you could remove 2-pass mode for MJPEG. I assume that those who use MJPEG use it as an intermediate format during capturing.

The MJPEG encoder is single threaded, and with 1 thread its speed is unmatched. This, combined with the close to lossless quality of low quantizers or high quality makes it a good choice for intermediates, so I'll change my vote to remove it to don't care, as I don't use it and thus I can't decide because of that. However, nobody uses xvid or x264 with 1 thread, and with only 3 threads perfomance was close to MJPEG, but compression was a lot higher of course. No numbers this time as I did the test days ago, will have to redo them unless someone does it for me.

I prefer to do everything in one step, so when you decide to remove the hidden encoders I can remove the buggy features too.

[clsid]

No need for any detailed numbers. Your description of the test results is enough.

[Blight]

This post is just to confirm that Sebastiii's patch fixes the Delphi compatibility issue.

[Sebastiii]

Great :) thank you :)

[Gingko]

I am trying to decode digital TV with audio as "AAC in transport stream with a synchronization layer (LOAS) and a multiplex layer (LATM)" used in some countries, and to find codecs working with this.

I more or less succeeded with Monogram AAC Decoder (http://blog.monogram.sk/janos/2009/03/08/monogram-aac-decoder-0960/), but I had to modify and recompile it in order to get it working, because the proper Media Type was not exposed to DirectShow (although internally used). Now it works, but with some instabilities.

This Media Type, as far as I understand correctly, is defined (at least by Microsoft (http://msdn.microsoft.com/en-us/library/dd390676%28v=VS.85%29.aspx)) as MEDIASUBTYPE_MPEG_LOAS, and its value is {00001602-0000-0010-8000-00AA00389B71}.

Monogram AAC Decoder is a wrapper for libfaad2, which is used also by ffdshow-tryouts, so logically, ffdshow-tryouts should be able to decode it, but unfortunately, it does not expose this Media Type either.

I'm wondering if it wouldn't be possible to include it in future versions of ffdshow-tryouts in order to make possible, or more easy, to get ffdshow-tryouts decoding AAC+LOAD+LATM?

If you need some sample, you can use this file :
http://gingko.homeip.net/misc/TDT_Continente_2010-12-09_19-20-02.ts

This is a 30 seconds record of a full DVB-T Transport Stream multiplex (from Portuguese TV) with 4 TV channels (plus an empty one), all encoded as H264 (for video) and AAC+LATM+LOAS for audio.

Regards,

GingkoHello,

Is there any chance that I could get an answer to this ?

I am developer on a DVB-T application, and the lack of this mediasubtype makes problematic for me to find a codec able to decode soundtracks in this kind of video stream.

Even Media Player Classic HC, for example, seems to be unable to play it.

Gingko

[LigH]

@ clsid and STaRGaZeR:

A first verbose reply from Tom Keller (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG&p=415122&viewfull=1#post415122). Brief translation:

Due to a rather slow capturing system, he needs a both fast and easily cuttable (keyframe only) and high quality video format as VfW codec. So ffdshow's MJPEG is the optimum for his case because:

it is fast
it is free of charge
it provides acceptably high quality
and even though ffdshow is "just a VfW wrapper for ffmpeg", he needs exactly that
Xvid is no substitute because it is neither fast enough on his system nor freely cuttable (or who would try to set it up for 0 P-frames?)
FFV1 is no substitute because even though it compresses tightly for a lossless codec and can provide I-frames only, it is too slow on his system
Huffyuv is no substitute because although it is fast enough and even lossless, the result is way too big


Recommendations like "buy bigger harddisks" or "buy a faster PC" are easy. But not every user is able to do that. If they were, then ffdshow would need no encoder at all, and we could use "lossless x264vfw" for capturing.

So much about Tom's opinion. Now I have at least one specific person I can point at. ;)

[clsid]

Hello,

Is there any chance that I could get an answer to this ?

I am developer on a DVB-T application, and the lack of this mediasubtype makes problematic for me to find a codec able to decode soundtracks in this kind of video stream.

Even Media Player Classic HC, for example, seems to be unable to play it.

Gingko
LATM/LOAS are not supported by ffdshow. It would require adding a parser for such headers.

If you want to see this capability added to ffdshow you need to submit a patch for it. We have no manpower available to do it.

[Ger]

Even Media Player Classic HC, for example, seems to be unable to play it.


Your sample plays with audio in MPC-HC if you use the latest LAVFSplitter beta and Monogram AAC decoder.

LAVFSplitter gets the duration of your sample wrong though, like it does with most H.264/HD samples, due to limited TS support in libavformat, but hopefully the TS duration issue will be resolved in LAFVSplitter eventually, since it is supposed to replace the internal MPC-HC splitters for the supported formats when it's deemed ready.

You may want to check out the LAVFSplitter thread (http://forum.doom9.org/showthread.php?t=156191). We've discussed LATM there before.

If you are a developer with the necessary time and skill to create a patch for LATM/LOAS support in ffdshow it would be appreciated though, since we wouldn't need the Monogram AAC decoder for those particular streams anymore.

[roozhou]

Hi clsid,

Is it possible to use ffdshow DXVA in encoding apps? It seems ffdshow gets the decoded frame back to main memory via IAMVideoAccelerator::GetBuffer or IDirectXVideoDecoder::GetBuffer in overlay mode. If ffdshow provide a new interface, the encoding app could pass a callback function to ffdshow and ffdshow calls it when it gets the frame. This should be useful for ATI and Intel graphic card users.

[clsid]

Hi clsid,

Is it possible to use ffdshow DXVA in encoding apps? It seems ffdshow gets the decoded frame back to main memory via IAMVideoAccelerator::GetBuffer or IDirectXVideoDecoder::GetBuffer in overlay mode. If ffdshow provide a new interface, the encoding app could pass a callback function to ffdshow and ffdshow calls it when it gets the frame. This should be useful for ATI and Intel graphic card users.
Even if it would be possible, the performance will probably be disappointing. But more importantly, I doubt any of the current developers has any interest in implementing this. So if you want it you need to code it yourself.

[Gingko]

LATM/LOAS are not supported by ffdshow. It would require adding a parser for such headers.

If you want to see this capability added to ffdshow you need to submit a patch for it. We have no manpower available to do it.

If you are a developer with the necessary time and skill to create a patch for LATM/LOAS support in ffdshow it would be appreciated though, since we wouldn't need the Monogram AAC decoder for those particular streams anymore.I see.

Necessary time is probably the most needed resource for me if I want to do that (difficult to work on several projects in the same time), but maybe I will try it anyway one day or another. :)

Gingko

[STaRGaZeR]

@ clsid and STaRGaZeR:

A first verbose reply from Tom Keller (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG&p=415122&viewfull=1#post415122). Brief translation:

Due to a rather slow capturing system, he needs a both fast and easily cuttable (keyframe only) and high quality video format as VfW codec. So ffdshow's MJPEG is the optimum for his case because:

it is fast
it is free of charge
it provides acceptably high quality
and even though ffdshow is "just a VfW wrapper for ffmpeg", he needs exactly that
Xvid is no substitute because it is neither fast enough on his system nor freely cuttable (or who would try to set it up for 0 P-frames?)
FFV1 is no substitute because even though it compresses tightly for a lossless codec and can provide I-frames only, it is too slow on his system
Huffyuv is no substitute because although it is fast enough and even lossless, the result is way too big


Recommendations like "buy bigger harddisks" or "buy a faster PC" are easy. But not every user is able to do that. If they were, then ffdshow would need no encoder at all, and we could use "lossless x264vfw" for capturing.

So much about Tom's opinion. Now I have at least one specific person I can point at. ;)

It was hard, huh? It would have been inmediate if you would have proposed the poll in a less biased and more informative tone. 6 "Yes, absolutely - must stay inside!" explanations left for you ;)

@STaRGaZeR
If you want and have time, you could remove 2-pass mode for MJPEG. I assume that those who use MJPEG use it as an intermediate format during capturing.

Since it was easy, I've done it in r3709. 2 pass and 1 pass bitrate are no longer available for MJPEG.

[fastplayer]

It was hard, huh?
Since Tom Keller has a small disk and slow system in general, he can stick with older builds of ffdshow. Nobody is taking that away from him.

By the way, I still see no "Keep MJPEG or die!" petition on PetitionOnline.com (http://www.petitiononline.com/)...

[dann23]

By the way, I still see no "Keep MJPEG or die!" petition on PetitionOnline.com (http://www.petitiononline.com/)...

+1

I also need mpeg4 encoder from ffdshow and I'm sure I can make a poll and gather a few votes for this. But what's the point? So I believe it's better to remove all of the old and buggy encoders or let them just the way they were.

[clsid]

Can anyone with a S/PDIF setup please test the AC3 encoding functionality? I got a report that it is not working properly after its recent update, and I need confirmation.

[VipZ]

Can anyone with a S/PDIF setup please test the AC3 encoding functionality? I got a report that it is not working properly after its recent update, and I need confirmation.

EDIT: Sorry my bad, tested with 3661, indeed 3708 doesn't work for me either. After testing it seems 3681 broke AC3 encoding.

[Perls]

Tested encoding via HDMI both 2.0 and 5.1 @ 48kHz, working fine for me. 44.1kHz doesn't work natively for me, re sampling to 48kHz solves it, this could be the issue being reported.

Maybe automatically re sampling to 48kHz on AC3 encoding could be a solution?

For me, updating from 3626 to 3707 broke AC3 encoding of 2.0 at 48 kHz. Haven't tested anything else.

[tetrahex]

Hi!

I'd like to express my (somewhat lengthy :rolleyes: ) opinion about moving the encoders out of ffdshow. I don't like it.

For me, the ffdshow was a very welcome alternative after years and years of using first all kinds of codec packs and suffering for that, after which I used specific codecs or encoding apps for anything I needed. But even with a few codecs/splitters and a couple of encoding apps (like VirtualDub/Mod, Megui, AviDemux) I felt that simpler solution would be better, especially after I bought my first laptop. I wanted to keep the number of individual apps/codecs/whatever as small as possible, so as not to clutter the system too much and keeping it light and simple. And it worked, very well for my needs: all I needed was ffdshow for any kind of encoding/decoding, VHScreenCapture codec for capturing flash videos from web browser window (from national broadcasting company; not possible to download) and VirtualDub to put it all together.

Mainly I used XviD (and sometimes x264 for testing hardware etc.) from ffdshow, though I tried some other codecs too just for the experience. Now that almost all the possibly useful encoders have been taken out, I tried separate XviD for capturing. It worked of course (despite a few crashes which didn't happen with ffdshow, probably due to updating VirtualDub), but for my eyes/hardware, the quality and the speed seem to be pretty much the same as with ffdshow. So now I don't really know what use I'd have for ffdshow, since I can get the decoders with the encoders. Which means more apps/codecs for no apparent benefit for me, only more clutter and hassle.

The one thing that ffdshow is (was?) known for (at least for me & people I know & the magazines I read) is it's ability to handle almost all kinds of encoding/decoding needs, with possibly 1-3 additional codecs/splitters, and you could do anything. But remove the encoders (I REALLY have no use for FFV1, MJPEG, DV, HuffYuv..) and all you've got is a playback addon, which needs the splitter anyway for anything else than avi basically. Of course there's the filters/postprocessing stuff etc., of which subtitles would be the only one I needed, but since it's so inferior to DirectVobSub, that's no good either.

So what would I do with ffdshow? I can playback movies with the codecs I now need to install anyway, if they haven't come with the OS already. I really liked the vfw interface, similar GUI for audio/video decoding and for different video encodings, nice to try some filters/more rare codecs just for fun if there was no actual need. But now the fun & the experience seems to be over, which is really a pitty. If the encoders are taken out, I simply have no (practical) use for ffdshow.

Anyway, it was fun while it lasted. And I do understand your reasons for minimizing outdated/buggy/inferior code from the app, I've coded too and I know how precious time is, and how frustrating it is to do things that seem to only consume time and not bring any benefits.
I just hope that the large masses of people that are using ffdshow for things I mentioned would notice the changes you've done in time and have the ability (ie. language skills, finding the forum, time to read your reasons & know-how to explain use cases which you asked for) to express their opinions before it's too late, before another great app is being taken down the road not everybody's happy about, by the decision of a small number of developers. Those kind of situations we've all come across, I'm sure, just see eg. Firefox's disappearing features, or OpenOffice/LibreOffice, even Mac not being able to play flash videos, or Oracle's acquiring Sun and the worries and disappointments that's brought out (way out of proportion to this situation, I know, but basically the same issue).

Thank you if you've read all this, and thank you for your efforts and for your accomplishments; any way you go, you still deserve to be applauded!! :thanks:

[clsid]

What is the total size of your Windows and program files folders combined? Several gigabytes I guess? But installing a single extra codec suddenly creates a clutter? Oh, the horror.

Your heartwarming story is just more and more confirmation that our decision was in fact excellent.

By using the official Xvid codec you will soon be able to enjoy several nice improvement that have been recently committed to its CVS. Like better MT encoding and MT deblocking during playback. But if you prefer what you had, then you can just keep using an old version of ffdshow.

[kieranrk]

What is the total size of your Windows and program files folders combined? Several gigabytes I guess? But installing a single extra codec suddenly creates a clutter? Oh, the horror.

Your heartwarming story is just more and more confirmation that our decision was in fact excellent.


K-lite methodology on ffdshow. It's no wonder ffdshow is a total mess as acknowledged by ffmpeg developers themselves...

[clsid]

It is a mess that we are trying to clean up. The Xvid encoding in ffdshow was merely an unmaintained wrapper for an old version of xvidcore.dll. Are you suggesting we should keep that? What is wrong with the official Xvid codec?

Also, if you are suggesting that I am somehow responsible for the messy code in ffdshow then you know very little about the history of ffdshow.

Idiot.

[kieranrk]

It is a mess that we are trying to clean up. The Xvid encoding in ffdshow was merely an unmaintained wrapper for an old version of xvidcore.dll. Are you suggesting we should keep that? What is wrong with the official Xvid codec?

Also, if you are suggesting that I am somehow responsible for the messy code in ffdshow then you know very little about the history of ffdshow.


I was commenting on your response about bloat. Never said that anything about you being responsible for ffdshow's mess...

[iron2000]

Seem like MPC-HC's DXVA is more compatible.
Still having the freezing problem with ffdshow DXVA in 3713.

[avih]

Guys, take it easy please. Keep the discussion on topic. Thanks.

[_xxl]

I'll update soon xvidcore to latest. Maybe only ffmpeg encoding with ffdshow shouldn't be removed.... That shouldn't be to hard to maintain...

[clsid]

I was commenting on your response about bloat. Never said that anything about you being responsible for ffdshow's mess...
What you call bloat is a gift from god for another. Your needs do not equal those of everybody else.

The reasoning is to prefer two good dedicated solutions over a single mediocre all-in-one. Also to avoid wasting time on replicating functionality that already exists. That time is better spend on improving parts of ffdshow for which there isn't a good alternative.

We could even turn around the bloat story. Why should we include xvid in every single ffdshow installation, when the majority of users only plays files and thus never uses it? Force bloat on many to avoid bloat on a few?

I'll update soon xvidcore to latest. Maybe only ffmpeg encoding with ffdshow shouldn't be removed.... That shouldn't be to hard to maintain... If you want, go ahead. But if you do, also update the GUI. From a quick glance at the changelog these things might require attention: threads, slices, VHQ metric combobox, max bitrate, profiles, frame_drop_ratio.
http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/ChangeLog?r1=1.16&r2=1.17

I still think it is a waste of time to replicate xvidvfw.

[Milardo]

Hi,
Not sure if this the right area but it is mostly i believe a ffdshow problem i think.
I'm using virtualdub 32 bit on my win 7 x64 os and I've got ffvdub.vdf and ffdshow encoder. Either one I have used when I am encoding video in virtualdub will not output any of the image processing filters like post processing or visualizations! Is that how it is supposed to work? Basically I would like whatever image processing filter i checked and configured to be encoded/processed into my output file.

[STaRGaZeR]

A new year present for you all, the new ffmpeg's gradfun (deband filter in ffdshow). Improvements? Faster and it works just fine with x64 :D

ICL12: http://www.mediafire.com/?jvs457q43cixbq0
MSVC 2010 x64: http://www.mediafire.com/?aem2r27pddm1ldd

Please test and report bugs or whatever, there's still some things to do before I commit it.

[Milardo]

After some thorough testing, it seems some filters work and some don't like post processing doesn't work but noise does? Why is that?

[ranpha]

A new year present for you all, the new ffmpeg's gradfun (deband filter in ffdshow). Improvements? Faster and it works just fine with x64 :D

ICL12: http://www.mediafire.com/?jvs457q43cixbq0
MSVC 2010 x64: http://www.mediafire.com/?aem2r27pddm1ldd

Please test and report bugs or whatever, there's still some things to do before I commit it.

It is faster, no doubt about that and works on 1080p sources too.

[cyberbeing]

ffdshow builds after rev3326 appear to have an Ordered Chapters regression which crashes libavcodec and ffmpeg-mt when decoding H264.

Sample:
http://www.mediafire.com/?xlz5xe8l3gpcoqc

The March 22, 2010 ffdshow rev3328 ffmpeg update seems likely to blame.

[fastplayer]

A new year present for you all, the new ffmpeg's gradfun (deband filter in ffdshow). Improvements? Faster and it works just fine with x64 :D
I like how this year starts! :thanks:

[clsid]

ffdshow builds after rev3326 appear to have an Ordered Chapters regression which crashes libavcodec and ffmpeg-mt when decoding H264.

Sample:
http://www.mediafire.com/?xlz5xe8l3gpcoqc

The March 22, 2010 ffdshow rev3328 ffmpeg update seems likely to blame.
I am investigating it now, but it seems those two files don't use the same x264 encoding settings. The first file doesn't show any x264 metadata in MediaInfo.

[cyberbeing]

That's only because I split it multiple times to cut down on the filesize for upload, they both use identical x264 settings.

[clsid]

I have narrowed it down to this change:
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=c1e15f7a54852ce64e345ac7b7f61edcbbc58478

Edit: and the actual crash occurs in h264.c line 1801:
h->frame_num= get_bits(&s->gb, h->sps.log2_max_frame_num);

Edit2: implemented a workaround in r3714

[STaRGaZeR]

Please test and report bugs or whatever, there's still some things to do before I commit it.

New version with fixes and a new option: radius. Right now I'm using ffmpeg defaults, threshold = 1.2 and radius = 16. If someone feels these defaults are off just propose new ones :p

ICL12: http://www.mediafire.com/?9s21x7txnrvqm11

BTW, debugging really needs to be fixed in the MSVC2010 solution, having to use 2008 only for that is a pain in the ass.

[arestarh]

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

[Milardo]

Hi,

Can someone build ffdshow with post processing enabled in ffvdub and/or ffdshow encoder? How hard would it be compile ffdshow myself that has the filter enabled when encoding video? I would really like to use the all the image processing filters when encoding video.

[cyberbeing]

Thanks for the quick fix in rev3714 clsid. It does indeed seem to resolve the ordered chapter decoder crash.

[god_md5]

is the ffdshow h264 in decode first have bug ?
i try the ver is 3713
sample is here
http://dl.dropbox.com/u/3668343/sample.ts
http://dl.dropbox.com/u/3668343/sample2.ts
and xhmikosr ,i all the decode software is you comilpe ver ,thank you
i install you compile DirectVobSub
DirectVobSub_2.40.2499_x86.exe ,is it not have vobsub.dll and vobsub.ax inside?

[cyberbeing]

STaRGaZeR, could you please add old gradfun2db back to ffdshow and give an option to use either that or the new ffmpeg gradfun?

While the new ffmpeg gradfun may be fast, I find the quality utterly horrible on anime content... It doesn't appear to deband all that well, it's temporally unstable, makes nasty rings on hard edges (worse than gradfun2db), and it produces blocking artifacts at higher thresholds...

It may have it uses as a fast deband option on 1080p and such, but I think gradfun2db should be kept as well for those who desire a higher quality deband option.

[Keiyakusha]

cyberbeing
emm maybe I miss something but since when gradfun2db and debanding filter in ffdshow is NOT the same code?

[cyberbeing]

Since around 13 hours ago with FFDshow rev3717.

[Keiyakusha]

Oops... For some reason I thought its the same filter just improved in speed. Need to test the new revision then...

[STaRGaZeR]

There's a problem in the filter, ffmpeg produces correct output while ffdshow doesn't. I'll look into it.

[TheShadowRunner]

Build 3713 crashes badly when feeding it the attached XVID file (crash in ntdll.dll).
No issues with build 3703 !
(XP SP3 32bit)

[nightfly]

How hard would it be to implement the following rule for "Swap Channel" feature:

If LPCM == 6 Channel then enable the swap channel setting/feature.

The reason is that Nvidia's HDMI driver has had this nastly bug for some time where if you have a 7.1 speaker setup and playback a 5.1 LPCM track, it'll output the surround channels to the rear channel instead of the side.

I've hacked on MPC-HC before so I am willing to take a look, just need to know where to start or solicit alternate ideas.

[cyberbeing]

That isn't really a bug. It's not strange for the rear left and rear right surrounds of a 5.1 track to playback on the rear left and rear right surrounds in a 7.1 speaker setup. The side channel speakers you speak of, don't exist in a 5.1 setup.


Does setting a Preset solve your problem?

on decoder match: raw LPCM
AND
on number of channels: 6

[STaRGaZeR]

Deband is fixed in r3718. Report any issues as always.

ICL12: http://www.mediafire.com/?168mvl4d0vpc786
MSVC x64: http://www.mediafire.com/?qyxbeb0jpjtzyjq

Despite the name, the builds are r3718.

[clsid]

Build 3713 crashes badly when feeding it the attached XVID file (crash in ntdll.dll).
No issues with build 3703 !
(XP SP3 32bit)Please upload the file somewhere else.

[clsid]

I have noticed a weird bug with decoding Techsmith video (TSCC). It decodes with correct colors during DirectShow playback (using r3719). It then converts from BGR24 to RGB32.
When decoding in VirtualDub using VFW mode, the colors are wrong. Red and blue seem swapped. However, when I force a different colorspace like RGB32 or YV12 (VDub menu > Video > Color Depth), it decodes with correct colors. Colors are also wrong when using the Old Renderer in MPC, in which case it outputs RGB24.
Does anyone have an idea what might be wrong?

Here is a sample file:
http://www.mediafire.com/?7llbdqshl33s620

[nightfly]

That isn't really a bug. It's not strange for the rear left and rear right surrounds of a 5.1 track to playback on the rear left and rear right surrounds in a 7.1 speaker setup. The side channel speakers you speak of, don't exist in a 5.1 setup.


Does setting a Preset solve your problem?

on decoder match: raw LPCM
AND
on number of channels: 6

Well, a 7.1 differs from a 5.1 setup by adding rear speakers and thus the rears should only be used in 7.1 audio formats.

I am not familiar with "Presets" but will look around ffdshow and see if I can find what you're referencing as that does sound like it could work.

So I'd define a preset and that preset would contain the channel swap?

[Snowknight26]

Does anyone have an idea what might be wrong?


Conversion from BGR is broken. I think I've mentioned it (when it came up with Fraps) a few too many times. ;)

[cyberbeing]

Deband is fixed in r3718. Report any issues as always.

ICL12: http://www.mediafire.com/?168mvl4d0vpc786
MSVC x64: http://www.mediafire.com/?qyxbeb0jpjtzyjq

Despite the name, the builds are r3718.

No wonder it looked so bad before, the initial commit was borked.

I haven't compared against the old ffdshow gradfun2db yet, but the r3718 fixed ffmpeg deband filter does seem to be working properly now. The major problems I had with r3717 seem to be gone.

Well, a 7.1 differs from a 5.1 setup by adding rear speakers and thus the rears should only be used in 7.1 audio formats.
This is incorrect. A 7.1 setup adds side speakers to a 5.1 setup.

5.1 (Front L, Center, Front R, Rear L, Rear R)
7.1 (Front L, Center, Front R, Rear L, Rear R, Side L, Side R)

I am not familiar with "Presets" but will look around ffdshow and see if I can find what you're referencing as that does sound like it could work.

So I'd define a preset and that preset would contain the channel swap?
Yes, you create a preset which auto-loads with 6 channel LPCM and does your channel swap. Your default preset will load in all other cases.

[madshi]

A 7.1 setup adds side speakers to a 5.1 setup.

5.1 (Front L, Center, Front R, Rear L, Rear R)
7.1 (Front L, Center, Front R, Rear L, Rear R, Side L, Side R)
No, that's not true. The surround channels in a 5.1 setup are considered "side/surround", not "rear/back". There was a long discussion about this in the eac3to thread, and after studying Dolby and DTS papers and even an email reply from Microsoft the general consensus was that 5.1 has side/surround channels and not rear/back channels.

[cyberbeing]

Interesting, but I think it really just comes down to how someone has their 7.1 system set up.

If the 7.1 system is setup like this, the sides wouldn't represet a 5.1 surround channels very well, since they are suppose to represent sound from the rear surrounds of the viewer (not direct sides):
http://img193.imageshack.us/img193/9123/standard71surroundsound.png
In a setup like that, using the 7.1 Rear Left and Right would be closer to the 5.1 Left and Right Surrounds.

[madshi]

Interesting, but I think it really just comes down to how someone has their 7.1 system set up.

If the 7.1 system is setup like this, the sides wouldn't represet a 5.1 surround channels very well, since they are suppose to represent sound from the rear sides of the viewer (not direct sides)

[...]

In a setup like that, using the 7.1 Rear Left and Right would be closer to the 5.1 Left and Right Surrounds.
Check out the Dolby speaker placement guide:

http://www.dolby.com/consumer/setup/speaker-setup-guide/index.html

If you click on "5.1", the guide says:

"Left and Right Surround Speakers: These speakers should be placed to the sides of your seating position".

The recommended angle is 90-110°. Now compare that to the Dolby recommended setup for 7.1, and you'll find that the position of the surround speakers is *exactly* the same. 7.1 just adds back speakers to 5.1. The placement of the 5.1 speakers doesn't change at all.

And if you think about it, it makes sense, at least if you want to watch 5.1 movies in their original form and not artificially upconverted to 7.1 (by some phony algorithm by the receiver). If the surround speaker placement would differ between 5.1 and 7.1, you'd have to move the surround speakers around all the time, if you switch between 5.1 and 7.1 movies.

So the final word is:

A 7.1 setup adds back speakers to a 5.1 setup.

[cyberbeing]

http://img832.imageshack.us/img832/3067/70289179.pnghttp://img141.imageshack.us/img141/7994/77417220.png

Even though they list the same numbers, they must be calculating them differently, as Dolby Digital's diagrams show significantly different placement. And as before, ignoring numbers, with speaker placement as those diagrams show, the 7.1 rears would be closer to what the 5.1 rear surrounds are supposed to represent.

[madshi]

I would rather trust the numbers than the diagrams. In the 7.1 diagram it looks like 90°, while in the 5.1 diagram it looks like 110°. So both diagrams are "within spec".

There are more indications for what I said, all already discussed in the eac3to thread. Let me list a couple:

(1) according to MS docus the MS mixer drops the *back* channels if you play 7.1 content with a 5.1 speaker system
(2) the header files for XPSP2 and newer OSs define the 5.1 speaker mask in such a way that surround/side channels are included, but rear/back channels are not
(3) 5.1 DTS-HD files have speaker information stored in the header, they list: "C L R Ls Rs LFE" (you can check with "eac3to some.dts -logdts")
(4) the official Dolby AC3 spec names the speakers of the 5.1 AC3 format "L,C,R,Ls,Rs, LFE"

[cyberbeing]

I would rather trust the numbers than the diagrams. In the 7.1 diagram it looks like 90°, while in the 5.1 diagram it looks like 110°. So both diagrams are "within spec".
As I mentioned, the 5.1 seems the be calculated from the center (rear?) of the viewers head, while the 7.1 seems calculated from the front (center?) of the viewers lap. The intention seems clear. The 5.1 rear surrounds are designed to act as both side and rear speakers (which is why the 5.1 surrounds are angled exactly between where the 7.1 side and rear are in the diagram). With 7.1 it split the rear surrounds of 5.1 into distinct side and rear speakers.

Using the dot on the diagram, the 5.1 in that diagram shows 120° with a range of 115°-125°. Using the center of where the viewer's head would be as the reference, the 5.1 in that diagram shows 100° with a range of 90°-110°.

The 7.1 in that diagram shows 100° with a range of 90°-110° from the dot.

There is no right or wrong, it only comes down to where you have your 7.1 side and rear speakers placed in your setup. In some cases the sides would be sufficient, in others the rears would be preferable. If your 7.1 side speakers are arranged like the surround in the 5.1 diagram, then they are best used on 5.1 tracks. If your 7.1 side speakers are arranged like the 7.1 diagram, the rears would be best used on 7.1 tracks.


So the final word is:

A 7.1 setup splits 5.1 rear surrounds into distinct side and rear speakers :rolleyes:

[nevcairiel]

Wow, you're seriously arguing with the dot-position now? The dot is the head. No matter what gfx of a sofa is under there. Also, trust numbers, don't trust graphics.

Anyhow, if you setup your 5.1 surround speakers as rear speakers, thats just how it is.
If you setup 7.1, you will have side speakers, which should be directly to the side, or a bit behind you.

If your personal preference is to have the 5.1 go to the rear speakers, thats your personal opinion, of course. Having an option to output it there might be useful for you, i guess. But its not the "right" way, nor the "wrong" way. Just not the "standard" way. Maybe someone will some day write it for you :d

With profiles you should be able to do it anyway, unless you're bitstreaming to your receiver.

[STaRGaZeR]

No wonder it looked so bad before, the initial commit was borked.

I haven't compared against the old ffdshow gradfun2db yet, but the r3718 fixed ffmpeg deband filter does seem to be working properly now. The major problems I had with r3717 seem to be gone.

Yeah, sorry about that. The filter system in ffdshow is... strange.

[BatKnight]

The main question is simple:
Is ffdshow audio mixer correctly playing 5.1 and 7.1 files, sending the audio to the correct speaker, considering the Dolby setup?

Nuno

[clsid]

Conversion from BGR is broken. I think I've mentioned it (when it came up with Fraps) a few too many times. ;)Isn't that a different problem, related to tv/pc range?
BGR24 to RGB32 is done properly for TSCC. But it seems that BGR24 is outputted as RGB24 without conversion.

[TheShadowRunner]

Please upload the file somewhere else.

Sure, here it is:
http://videoff7.free.fr/Check_color_space_vmr9-test.zip

(Build 3713 crashes badly when feeding it the attached XVID file (crash in ntdll.dll). No issues with build 3703 !)

[nightfly]

As I mentioned, the 5.1 seems the be calculated from the center (rear?) of the viewers head, while the 7.1 seems calculated from the front (center?) of the viewers lap. The intention seems clear. The 5.1 rear surrounds are designed to act as both side and rear speakers (which is why the 5.1 surrounds are angled exactly between where the 7.1 side and rear are in the diagram). With 7.1 it split the rear surrounds of 5.1 into distinct side and rear speakers.

Using the dot on the diagram, the 5.1 in that diagram shows 120° with a range of 115°-125°. Using the center of where the viewer's head would be as the reference, the 5.1 in that diagram shows 100° with a range of 90°-110°.

The 7.1 in that diagram shows 100° with a range of 90°-110° from the dot.

There is no right or wrong, it only comes down to where you have your 7.1 side and rear speakers placed in your setup. In some cases the sides would be sufficient, in others the rears would be preferable. If your 7.1 side speakers are arranged like the surround in the 5.1 diagram, then they are best used on 5.1 tracks. If your 7.1 side speakers are arranged like the 7.1 diagram, the rears would be best used on 7.1 tracks.


So the final word is:

A 7.1 setup splits 5.1 rear surrounds into distinct side and rear speakers :rolleyes:

There's just no convincing you huh? Believe what you want. (Regardless, thanks for the 'Preset' tip, that will work for me ;-))

In a 7.1 setup with a 7.1 audio track, each channel has a distinct channel signal (the rears and/or sides may have duplicated content, but they are distinct channels - no multiplexing going on...). In a 6.1 audio track, the rears share the same channel (DD Ex, DTS 6.1, etc.)

Before 7.1 there was 5.1 for many years. The "surrounds" where specified to mounted to the side of the listener, about 3 to 5 ft higher than their heads - this was from Dolby. You go to any non stadium (perhaps older) theaters and they are all only 5.1 setups with multiple side speakers, typically between every two rows - nothing in the rear.

Also, any 5.1 audio track decoded by my receiver has the sides correctly output to the side surrounds: this was two diff HKs and two Denons. Also, even now, sp/dif output correctly on my HTPC for everything but LPCM/PCM.

So it's only wrong when Nvidia is in the loop and has to choose what channel goes where. Also, from what I've read the new SandyBridge drivers suffer from the same issue for LPCM.

I first got into 7.1 due to the LOTR DVDs that had a DTS 6.1 track and you simply put those speakers behind you. All DD/DTS 5.1 never ever used the rears. It's that simple. I just want LPCM 5.1 on Nvidia systems to do the same.

[Snowknight26]

Isn't that a different problem, related to tv/pc range?
BGR24 to RGB32 is done properly for TSCC. But it seems that BGR24 is outputted as RGB24 without conversion.

Nope, same issue (it's changed a bit since then but the point remains.):
http://forum.doom9.org/showthread.php?p=1412801#post1412801

First shot illustrates BGR32 -> RGB32, which shows the same issue as BGR24->RGB24.
BGR32->RGB24 is fine, just like with your BGR24->RGB32.

[nevcairiel]

T I just want LPCM 5.1 on Nvidia systems to do the same.

I just have ReClock set the appropriate channel count on the audio device, that way on 6 channel sources, the audio is output as 6 channel, and not as 8 channels with 2 channels blank, that way it always seems to work just fine, also i can tell my receiver to upmix stereo sources instead of trying to use some matrix in ffdshow

PS:
I haven't tried this for quite a while, maybe something new broke in the drivers. Since moving into a new place i only have 5.1 speakers setup. Barely have anything with 6.1/7.1 audio anyway ~.~

[TheShadowRunner]

Thanks clsid, 3721 fixed the XVID issue.

[Mark_A_W]

There's just no convincing you huh? Believe what you want. (Regardless, thanks for the 'Preset' tip, that will work for me ;-))

In a 7.1 setup with a 7.1 audio track, each channel has a distinct channel signal (the rears and/or sides may have duplicated content, but they are distinct channels - no multiplexing going on...). In a 6.1 audio track, the rears share the same channel (DD Ex, DTS 6.1, etc.)

Before 7.1 there was 5.1 for many years. The "surrounds" where specified to mounted to the side of the listener, about 3 to 5 ft higher than their heads - this was from Dolby. You go to any non stadium (perhaps older) theaters and they are all only 5.1 setups with multiple side speakers, typically between every two rows - nothing in the rear.

Also, any 5.1 audio track decoded by my receiver has the sides correctly output to the side surrounds: this was two diff HKs and two Denons. Also, even now, sp/dif output correctly on my HTPC for everything but LPCM/PCM.

So it's only wrong when Nvidia is in the loop and has to choose what channel goes where. Also, from what I've read the new SandyBridge drivers suffer from the same issue for LPCM.

I first got into 7.1 due to the LOTR DVDs that had a DTS 6.1 track and you simply put those speakers behind you. All DD/DTS 5.1 never ever used the rears. It's that simple. I just want LPCM 5.1 on Nvidia systems to do the same.

I don't really want to get in the middle of this...

But I prefer my 5.1 surrounds to be the sides in my 7.1 system - for a 5.1 signal.

The Xonar also sends 5.1 to the rears, when 7.1 speakers are active, which is different to the behaviour of a typical receiver, in my experience.

So, I would also like some sort of setting where you can send the 5.1 over 7.1 to either sides or rear, with 2 channels of silence. But intelligently leave 7.1 alone (so a simple permanent channel swap is no good).

In my case I'd have to send the full 7.1 channels (2 silent) for 5.1, or the Xonar messes it up.


Or.....decent upmixing of 5.1 to 7.1 would just make this all go away!

[nightfly]

I don't really want to get in the middle of this...

But I prefer my 5.1 surrounds to be the sides in my 7.1 system - for a 5.1 signal.

The Xonar also sends 5.1 to the rears, when 7.1 speakers are active, which is different to the behaviour of a typical receiver, in my experience.

So, I would also like some sort of setting where you can send the 5.1 over 7.1 to either sides or rear, with 2 channels of silence. But intelligently leave 7.1 alone (so a simple permanent channel swap is no good).

In my case I'd have to send the full 7.1 channels (2 silent) for 5.1, or the Xonar messes it up.


Or.....decent upmixing of 5.1 to 7.1 would just make this all go away!

That hasn't been my experience with the Xonar...it only has problems with 5.1 LPCM when Nvidia is in the loop (or more precisely, when their HDMI driver is outputting decoded audio)

Otherwise, there's no beef - cyberbieng is happy with his setup (though I guess he'll never bitstream as then 5.1 will always be wrong for him) and I am very happy with cyberbieng's tip - works great for me.

I am checking out the Reclock tip - as that sounds like a better overall solution for music and video. I just want my HTPC to let my Receiver handle all audio "everything" just hand it off untouched and be done. Bitstreaming gets me 75% of the way there.

[Mark_A_W]

I'm using my Xonar via 7.1 Analogue out, so we have different setups.


BTW the non Asus Unified Xonar Drivers seem to work fine.

[cyberbeing]

Otherwise, there's no beef - cyberbieng is happy with his setup (though I guess he'll never bitstream as then 5.1 will always be wrong for him) and I am very happy with cyberbieng's tip - works great for me.

For the record, I only have 5.1 setups at my computer and home theater, so I'm personally unaffected by any 7.1 issues. In any case, it's nice to hear that a simple ffdshow preset was able workaround your issue.

Also since it seems what I was saying was being misunderstood, and Dolby makes crappy diagrams, I made a corrected 7.1 diagram (moved dot and corrected angles to spec) to hopefully clear up any confusion. As it turns out, for the 7.1 Dolby diagram in my previous post the angles listed were wrong based on the 1 dot's incorrect location. This in turn means the side channels were way out of spec, sitting at 80°, which is why I was saying if someone had their 7.1 system setup like that diagram, the 7.1 rear channels would likely be better for 5.1 tracks.

http://img189.imageshack.us/img189/5462/701456.png

The above image shows what correct in-spec 7.1 setup looks like, one in which a 5.1 track rear surrounds should playback on the 7.1 side surrounds.

The moral of the story is if you have a correct in-spec 7.1 setup with angles based on the center of the viewer's head, the side channels should always be used on 5.1 tracks. If you have an out-of-spec or creatively laid out 7.1 setup (like the 7.1 image in my previous post from Dolby) with the side channels placed in front of you, the 7.1 rear channels would then become preferable for 5.1 tracks.

[god_md5]

i get this file no video output ,is use mpc-hc 1.4.2820 with ffdshow 3721
is Splitter bug?
http://dl.dropbox.com/u/3668343/sample3.ts

[nightfly]

For the record, I only have 5.1 setups at my computer and home theater, so I'm personally unaffected by any 7.1 issues. In any case, it's nice to hear that a simple ffdshow preset was able workaround your issue.

Also since it seems what I was saying was being misunderstood, and Dolby makes crappy diagrams, I made a corrected 7.1 diagram (moved dot and corrected angles to spec) to hopefully clear up any confusion. As it turns out, for the 7.1 Dolby diagram in my previous post the angles listed were wrong based on the 1 dot's incorrect location. This in turn means the side channels were way out of spec, sitting at 80°, which is why I was saying if someone had their 7.1 system setup like that diagram, the 7.1 rear channels would likely be better for 5.1 tracks.

http://img189.imageshack.us/img189/5462/701456.png

The above image shows what correct in-spec 7.1 setup looks like, one in which a 5.1 track rear surrounds should playback on the 7.1 side surrounds.

The moral of the story is if you have a correct in-spec 7.1 setup with angles based on the center of the viewer's head, the side channels should always be used on 5.1 tracks. If you have an out-of-spec or creatively laid out 7.1 setup (like the 7.1 image in my previous post from Dolby) with the side channels placed in front of you, the 7.1 rear channels would then become preferable for 5.1 tracks.

Regardless of one's individual speaker setup and preferences (I won't argue your points there, to each his own) according to everything I've experienced and read, in a 5.1 audio track, the surround channels go to the side speakers. If nothing else, use your receiver as a reference when it decodes any 5.1 audio format.

[cyberbeing]

Regardless of one's individual speaker setup and preferences (I won't argue your points there, to each his own) according to everything I've experienced and read, in a 5.1 audio track, the surround channels go to the side speakers. If nothing else, use your receiver as a reference when it decodes any 5.1 audio format.

The behavior of receivers to output a 5.1 tracks rear surrounds to the 7.1 side channels is correct, when someone has their 7.1 system set up in-spec like the corrected diagram in my previous post. If I got a 7.1 setup, that is how I would set it up as well. And yes, if your 7.1 setup is in-spec, it does indeed add rear channels to a 5.1 setup.

I was only basing my statement that a 7.1 rear channels would be preferable based on poor out-of-spec diagrams like the one from the Dolby website. If your 7.1 setup is out-of-spec, it may end up more like the 7.1 setup is adding side speakers to a 5.1 setup. Since I'm sure the majority of people never do measurements and just place speakers roughly based on potentially inaccurate diagrams, it's still relevant, even if technically wrong.

From a software point of view, the best behavior would be defaulting to side speakers since that is the in-spec behavior, but also having option to output to rear or both rear and side if desired for people with less-than-optimal setups. For example here is what the Creative drivers do:
http://img23.imageshack.us/img23/7521/creative5171.png

[XhmikosR]

@devs: With libavcodec AAC no bitrate is shown in the Info & cpu tab. I didn't notice the same with other ffmpeg decoders.

@STaRGaZeR: can you post again your patch regarding the crash with ICL12? I can reproduce it again unfortunately.

[clsid]

The ffdshow forum is being swamped with spammers. I am tired of cleaning it up every day, so I have disabled posting.

The problem is that there is no user account verification because there is no working e-mail setup on the board and the captcha system isn't effective. Does anyone know of a free SMTP server that doesn't require SSL? Maybe updating phpbb will help combat the spambots?

[madshi]

FWIW, I've recently updated my own forum to phpbb3 and it helped in so far that I can now easily delete a user with all of his posts in one step. With phpbb2 you had to delete user and posts manually, which could be extremely painful.

[STaRGaZeR]

@devs: With libavcodec AAC no bitrate is shown in the Info & cpu tab. I didn't notice the same with other ffmpeg decoders.

@STaRGaZeR: can you post again your patch regarding the crash with ICL12? I can reproduce it again unfortunately.

The bitrate problem is because we don't use the AAC parser, and it seems that bitrate is updated in the parser. So unless someone finds why the parser doesn't work the bug is here to stay.

I don't have it anymore, I just changed the ICL #ifdefs in that golomb file, so you can do it again in your PC. But it didn't work for you so maybe the problem is elsewhere.

BTW, it would be nice to see some MSVC vs ICL again with the new deband, with the same sample and filters as in my previous comparison MSVC2010 and ICL12 are less than 1% (margin of error) away from each other. I have virtually no reason to use ICL12 builds anymore.

[Brazil2]

What is wrong with the official Xvid codec?
You need to install it and to configure it separately. Which is not a problem for you and me and the vast majority of the users of this forum, but which can be a real pain for some people (e.g. my old mother, my sisters) while ffdshow did that in only one install, untill now.

[STaRGaZeR]

You need to install it and to configure it separately. Which is not a problem for you and me and the vast majority of the users of this forum, but which can be a real pain for some people (e.g. my old mother, my sisters) while ffdshow did that in only one install, untill now.

ffdshow doesn't configure itself to encode anything "in one install" as you say. So I don't really get your point.

[XhmikosR]

The bitrate problem is because we don't use the AAC parser, and it seems that bitrate is updated in the parser. So unless someone finds why the parser doesn't work the bug is here to stay.

I don't have it anymore, I just changed the ICL #ifdefs in that golomb file, so you can do it again in your PC. But it didn't work for you so maybe the problem is elsewhere.

BTW, it would be nice to see some MSVC vs ICL again with the new deband, with the same sample and filters as in my previous comparison MSVC2010 and ICL12 are less than 1% (margin of error) away from each other. I have virtually no reason to use ICL12 builds anymore.
I don't have the time to make any benchmarks. The last time I did a benchmark I used deband + xsharpen + High quality YV12 to RGB conversion. But that was for ICL11 vs MSVC2008.

I'll try to see what I can do with the ICL12 crash when I have some time.


EDIT: Is there any reason why the manifest files are not embedded?

[ikarad]

DXVA decoder in ffdshow 3721 doesn't work with some movies. It works with some movies but it doesn't work with other movies. I have sound but screen is black.
Although, with ffmpeg-mt it works very well

geforce9600mt with 260.99 drivers
vista 32 sp2

[e-t172]

Hi, I have an issue with Blu-ray subtitles (PGS, Presentation Graphics Stream) using MPC-HC and ffdshow.

Here is the result with madVR as the video renderer:

http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7t.jpg (http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7.html)

As you can see, it's quite ugly. The issue appears with (at least) madVR and EVR, although it seems less visible in EVR. Also, the subtitles flicker in madVR (but that's probably an unrelated issue). Other subtitles (SRT for example) seem to work fine.

Software used (all latest, 32-bit):
- Media Player Classic Homecinema 1.4.2499.0
- ffdshow r3721
- madVR 0.36
- Windows 7

Any idea what's going on?

[ikarad]

Hi, I have an issue with Blu-ray subtitles (PGS, Presentation Graphics Stream) using MPC-HC and ffdshow.

Here is the result with madVR as the video renderer:

http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7t.jpg (http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7.html)

As you can see, it's quite ugly. The issue appears with (at least) madVR and EVR, although it seems less visible in EVR. Also, the subtitles flicker in madVR (but that's probably an unrelated issue). Other subtitles (SRT for example) seem to work fine.

Software used (all latest, 32-bit):
- Media Player Classic Homecinema 1.4.2499.0
- ffdshow r3721
- madVR 0.36
- Windows 7

Any idea what's going on?

Maybe a problem with madvr because without madvr I don't have this bug since many versions of ffdshow.

Can you test without madvr?

[e-t172]

With EVR there is still some chroma issues around the edges of the letters, albeit much more subtle:

http://uppix.net/d/b/3/9f4e3227209f06dfe5938f56aa4eft.jpg (http://uppix.net/d/b/3/9f4e3227209f06dfe5938f56aa4ef.html)
(see the bottom of "assassination")

Maybe the problem with madVR is unrelated to the much smaller corruption in EVR. Should I post in the madVR thread?

[hoborg]

Hi.
I have problem to open this MOV video (http://www.ronkramer.net/MVI_2280.MOV) - tested using LAVF and MPC-HC MP4 splitter.
Medialooks QT source + QTLite 4.10 doesnt work either.
It plays fine in Firefox using QTLite 4.10

Complete name : D:\download\Mvi_2280.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 10.5 MiB

D:\download\Mvi_2280.mov::Output

Media Type 0:
--------------------------
Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: Unknown GUID Name {08E22ADA-B715-45ED-9D20-7B87750301D4}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0


Media Type 1:
--------------------------
Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

Not supported by FFDshow? Any idea what decoder use to play it in DirectShow?
Thanks.

[nm]

Hi.
I have problem to open this MOV video (http://www.ronkramer.net/MVI_2280.MOV) - tested using LAVF and MPC-HC MP4 splitter.
Medialooks QT source + QTLite 4.10 doesnt work either.
It plays fine in Firefox using QTLite 4.10

Complete name : D:\download\Mvi_2280.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 10.5 MiB

Looks like you only got part of the 28 MB file. Might explain some of the difficulties with it.
MPlayer plays the clip fine with libavformat.

[takenori]

Hi, my first post here:)
I have a problem with a dvd ripped-video via Handbrake 0.9.5 ("regular-high profile" profile) in which the video crashing out the mpc-hc when ffdshow set as decoder (all setting in default)

strangely enough, when I play other video and then play the said video without closing the player, the video play just fine.

heres the mediainfo:
Format : Matroska
File size : 111 MiB
Duration : 2mn 54s
Overall bit rate : 5 333 Kbps
Writing application : HandBrake 0.9.5
Writing library : libmkv 0.6.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=1, N=16
Codec ID : V_MPEG4/ISO/AVC
Duration : 2mn 54s
Nominal bit rate : 5 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 29.908 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.484
Writing library : x264 core 112
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=29 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=5000 / ratetol=1.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English
Color primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

for a cmoparison, heres the rip with handbrake 0.9.4, with the same profile, which works fine
Format : Matroska
File size : 155 MiB
Duration : 4mn 4s
Overall bit rate : 5 329 Kbps
Writing application : HandBrake 0.9.4

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4mn 4s
Bit rate : 5 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.603
Stream size : 143 MiB (92%)
Writing library : x264 core 79
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=1 / wpredb=1 / wpredp=2 / keyint=240 / keyint_min=24 / scenecut=40 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=5000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English
Color primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

thanks for the answer :thanks:

[adam777]

Hello all,
I've recently came across a VobSub (sub/idx) subtitle that for some reason FFDShow was not able to load.
I made sure VobSub subtitles are ticked under "Subtitles" and it also worth noting that FFDShow is able to play srt files with no problems and also that the above VobSub subtitles loads just fine in DirectVobSub.
Any ideas as to what I should look at to help resolve this issue?
Thank, Adam.

[clsid]

It is a know bug with VobSubs.

There is nothing you can do except try to fix it yourself and submit a patch. None of the current devs has time/knowledge/motivation to fix it.

[Brazil2]

@ clsid

FYI the link to "ffdshow SVN builds" in your signature is now pointing to the "Very old builds" folder rather than your main folder (http://sourceforge.net/projects/ffdshow-tryout/files/SVN builds by clsid/).

[adam777]

It is a know bug with VobSubs.

There is nothing you can do except try to fix it yourself and submit a patch. None of the current devs has time/knowledge/motivation to fix it.

Fair enough, thanks for the quick reply clsid :)

[GRKNGLR]

I also have the PGS subtitle problem. The software I use are:
- ffdshow rev. 3747
- LAVFSplitter 0.12
- madVR v0.36
- Media Player Classic - Home Cinema v1.4.1.2881.0
- WinXP SP3

http://img214.imageshack.us/img214/7002/85335295.th.png (http://img214.imageshack.us/i/85335295.png/)

When can this be fixed?

[grayedout]

I already wrote about the problem with ffdshow x64 - it crashes when memory usage of the program exceeds 2GB. However later I started using builds from xhmikosr which were made in MSVC2010. Those builds are working just fine and no crashes happen. Anyway I was still waiting for the new official x64 builds. Unfortunately all new official builds from clsid including ffdshow_rev3744_20110119_clsid_x64.exe still have 2Gb crash problem.

Question: is there any chance this problem will be fixed in official builds?

[JEEB]

Hello there.

It seems ffmpeg just got its wavpack decoder fixed, that finally seems to be able to handle >2 channels fine (link (http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=3bdc886c22710d3207b1bd75f8d2d65ec77cace5)).

Looking forward towards seeing this on ffdshow-tryouts as well.

[Vincent Vega]

i've unsuccessfully posted this question in mpc-hc thread, i really hope for better luck here.

this is a small sample recording made by my DVB-S viewing application (which supposedly demuxes requested program stream from .TS and muxes it to mp4):
http://www.mediafire.com/?x294obqj404fs8j

video is interlaced avc. however most DS players/decoders (example mpc-hc+ffdshow/yadif) don't recognize it as interlaced, and subsequently don't deinterlace it during playback.

i tried to 'heal' such files by remuxing to mkv:
-mkv remux by gdsmux does the trick, ffdshow begins to use deinterlacer;
-mkv remux by mkvmerge does not help - ffdshow keeps thinking its progressive.

maybe someone could take a closer look at this file and tell me what is wrong with it? i am suspecting the TV app somehow messes up cutting/demuxing from TS, and thus video streams come out slightly broken.

[Dstruct]

WMA 8/9 audio problem with this http://www.gearwire.com/media/yamaha-msp7-studio-monitors-winter-namm.wmv video.

General
Format : Windows Media
File size : 8.87 MiB
Duration : 3mn 2s
Overall bit rate : 407 Kbps
Maximum Overall bit rate : 398 Kbps
Encoded date : UTC 2007-01-26 23:54:37.000
Writing application : Flip4Mac WMV Export Component for QuickTime (Mac) 2103

Video
ID : 2
Format : VC-1
Format profile : MP
Codec ID : WMV3
Codec ID/Info : Windows Media Video 9
Codec ID/Hint : WMV3
Description of the codec : Windows Media Video V9 - 428 x 240, 29.96 fps, 350 kbps (CBR)
Duration : 3mn 2s
Bit rate : 334 Kbps
Width : 428 pixels
Height : 240 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.108
Stream size : 7.27 MiB (82%)
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 V9 Standard - 64 kbps, 44 kHz, 16 bit, Stereo (CBR)
Duration : 3mn 2s
Bit rate mode : Constant
Bit rate : 64.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 1.40 MiB (16%)
Language : English (US)



Working fine in REAPER (using FFmpeg rev26400) so it must be a ffdshow issue.




EDIT: Weird, it's not working because I had "AC3 (S/PDIF encode mode) disabled in the Output tab!? Why does this option need to be enabled for this?

[VipZ]

Can anyone confirm recent AC3 bitstream issues, few AC3 streams when bitstreamed play video at 60fps while audio stays at correct speed? There are 3 Fixes, use LAVFSplitter for MKV, use MPC-HC AC3 SPDIF, or deselect connect with PCM first. Not sure if this is a MPC splitter bug or ffdshow bug.

[terminaldawn]

Is there a recommended way to upgrade or switch versions FFDShow Tryouts?

Do I first un-install or do I just install over the top of the existing version?

Thanks!!!!

[Dstruct]

Is there a reccomended way to upgrade or switch versions FFDShow Tryouts?

Do I first un-install or do I just install over the top of the existing version?

Thanks!!!!

Just install them on top. No need to uninstall first.

[terminaldawn]

Just install them on top. No need to uninstall first.

Even if I need to go back a version?

[Dstruct]

Even if I need to go back a version?

Yeah it's pretty safe.

[terminaldawn]

Awesome, thank you very much for your help.

[jmone]

Like with detecting pulldown in NTSC Material (eg it will detect pulldown in a 29.97 stream and output the correct 23.976fps), can FFDSHOW when decoding and deinterlacing a PAL encoded source selectivly output:
- 50p (if original content was 50i)
- 25p (if original content was 24fps)

This is so later filters can apply a PAL Speeddown on 24fps material that has been PAL encoded (and of course you don't want to do this with native PAL content, just the stuff that came from film). If possible where are these settings?

Thanks
Nathan

[hoborg]

I have trouble to play some MOVs with twos/sowt audio, looks like hi CPU issue is the problem here.

I have here only older Intel Atom CPU. If i open this MOV test sample (http://hobring.esero.net/saf/ffdshow/mov_wrong_speed_2.zip) in graphstudio and remove video decoder, the playback is slow and CPU usage went to 20% (nearly full usafe of one core). I am not using any FFDShow audio postprocessing.

Here is screen from graph:
http://hobring.esero.net/saf/ffdshow/graph.png

If i use MPC MPA decoder, all is working fine, cpu usage is low and playback is correct.

Tested on ffdshow tryouts project, svn 3751 (x86) - MSVC2010 and "MP4Splitter.ax" 1.5.1.2910 as splitter.

Any ideas? Thanks.

[dann23]

can't access http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/

what happend??

[clsid]

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

@dann23
SourceForge was recently hacked, and now some functionality on the website is still disabled pending security improvements and integrity checks.

[travolter]

Hi,

In ffdshow x64 I notice that it skips frames on delay "always".

In the x86 version Im able to use an avisynth script to increase framerate and if it becomes superior to monitor refresh rate.. the player show the video in slowmotion (so its an useful feature to create these videos).

That feature is gone in ffdshow x64, or its just a bug?

[HeadlessCow]

Hi,

In ffdshow x64 I notice that it skips frames on delay "always".

In the x86 version Im able to use an avisynth script to increase framerate and if it becomes superior to monitor refresh rate.. the player show the video in slowmotion (so its an useful feature to create these videos).

That feature is gone in ffdshow x64, or its just a bug?

Can't you just set a lower framerate in Avisynth? (aka AssumeFPS(1) to stretch it 30x assuming 30fps input)

[travolter]

Can't you just set a lower framerate in Avisynth? (aka AssumeFPS(1) to stretch it 30x assuming 30fps input)
The behavior is totally different in x86 and x64.
In x86 works.. but in x64 there is some kind of "frameskip"

[dansrfe]

Can I use 32-bit AviSynth with the 64-bit version of ffdshow?

[Snowknight26]

Using r3752's ffmpeg-mt to decode H.264 tracks seems to crash ffdshow almost instantly. I've tested about a dozen or so sources now and each produce the issue.
Are there any recent debug builds floating around that contain a pdb file as well?

[jmone]

Does anyone have an issue where Subs stop displaying during playback? MKV rips of Blu-ray converted with BDSupToSub.
Thanks
Nathan

[god_md5]

i get the some ts is not have video out,ffdshow ver is 3721
can you help to fix this ,thank you
http://www.mediafire.com/?b5wcwcf4klljewk

[clsid]

@travolter
settings -> decoder options -> disabling "drop frame on delay" might help

@dansrfe
No. You need 32-bit ffdshow.

@Snowknight26
With 64-bit build only? If so, I am about to commit a workaround for a known crash.

[travolter]

@travolter
settings -> decoder options -> disabling "drop frame on delay" might help


Fails in the x64 version.
Works OK in the x86 one.

I dont know if its a bug or a feature/limit of the x64 version

edit.- Im testing using avisynth script to change framerate. Im not sure now if its a problem of avisynth x64.
Everytime that I try to change the FPS to a lower value than the inputFPS it fails.

I wonder if ffdshow x64 try to sync the audio with the image so thats the cause of the bug. Anyway I really dont undestan why that dont happen in the x86 version

[v0lt]

SPP deblocking is not working in ffdub plugin. :(

[GRKNGLR]

can't access http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/

what happend??

@dann23
SourceForge was recently hacked, and now some functionality on the website is still disabled pending security improvements and integrity checks.

When will it be active, then?

[Superb]

When will it be active, then?
It's back now.
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/?sortby=date

[GRKNGLR]

It's back now.
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/?sortby=date

:thanks:

[Snowknight26]

@Snowknight26
With 64-bit build only? If so, I am about to commit a workaround for a known crash.

Whoops. No, 32-bit build, but it seems to be fixed in r3755 anyway.

[Eliminateur]

@Snowknight26
With 64-bit build only? If so, I am about to commit a workaround for a known crash.

i'm getting the same problem as snowknight, upgraded mpc-hc to 2917 and ffdshow from 3698 to 3755 -all x64 builds- and it crashes on every H264 file i try to open.
Reverted back to 3698, everything works ok

[AluminumHaste]

What happened to all the awesome encoder settings? Such as X264, H264, MPEG4 etc

[Dstruct]

What happened to all the awesome encoder settings? Such as X264, H264, MPEG4 etc

Got removed. Search this thread for more info.

[adam777]

Hello all,
I've recently stumbled upon what seems to be the ffmpeg-mt development page (http://gitorious.org/ffmpeg/ffmpeg-mt), and it seems pretty active.
I was wondering what is the status of merging the ffmpeg-mt code into FFDShow, does it get updated as often as the normal ffmpeg (or is it that it get merged into the normal ffmpeg libraries and from there to FFDShow?).
Thanks, Adam.

[nevcairiel]

ffmpeg-mt will be merged with the normal ffmpeg eventually, probably going to happen this year, but it still might be a while.

In any case, if the decoder is working, constantly updating for minor changes is just wasted energy. ;)

[clsid]

The ffmpeg-mt code used by ffdshow is kept up-to-date regularly.

Some patches for merging ffmpeg-mt into official ffmpeg have been recently submitted to the ffmpeg developer mailing list, and a few of them are already queued for commit. Hopefully the rest will follow soon.

[adam777]

OK.
Thank you both, nevcairiel and clsid.

[EpsilonX]

Hi to all the FFDShow devs...
I have a little "problem" and need a confirmation if possible... :)
I haven't been able to use a direct "FFDShow Video Decoder" => "MadVR" to play DVD in ZoomPlayer...
MadVR users should know of the dreaded Macrovision problem when loading the DVD... :D
I'm using Windows 7 32-bit and FFDShow...

Yesterday, I tried again an suddenly it worked just fine... :eek:
FFDShow's libavcodec decoding MPEG2, outputing YV12 to MadVR...
No error whatsoever and it played just fine...
This is using rev3751 ICL12 from XvidVideo.ru...
Today I updated to rev3755 ICL12 from XhmikosR...
The Macrovision error is back... :(

Re-install rev3751, works fine again...
Then I tried rev3750, 3752, 3753 from XhmikosR, no go...
Tried the previous rev3740 from XvidVideo.ru, no go...
Tried rev3755 MSVC2010, no go...
Tried a clean profile with rev3755, still no go...

Since XhmikosR didn't compile rev3751, I can't compare it and be sure that it's the compiler difference (version, settings) that cause it... :rolleyes:
And since rev3751 is the latest from XvidVideo.ru, can't say that FFMpeg's update post rev3751 that cause it... :rolleyes:
So I kinda need other MadVR users to test it to see if you have the same result...
Aside from this, what other factor can possible cause this..?
I'll post a link to this post in MadVR's thread to see if there's any clue about this...
Thanks in advance...

Update :
rev3757 from XvidVideo.ru works fine...

[clsid]

The macrovision erro only depends on the renderer. ffdshow should have no effect on it. You might have played a DVD that didn't contain any protection or something like that.

[fastplayer]

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.

[EpsilonX]

The macrovision erro only depends on the renderer. ffdshow should have no effect on it. You might have played a DVD that didn't contain any protection or something like that.

Now that's weird...
I only use 1 DVD title for all those test...
And yet, I got different results from 2 builds... :confused:
I'll post update when XhmikosR compile rev3757...
As of now, only XvidVideo's build works... :confused:

UPDATE :
Still no go with XhmikosR's rev3758

[madshi]

Which OS are you on, EpsilonX?

[EpsilonX]

Which OS are you on, EpsilonX?

Ah madshi...
Windows 7 Ultimate 32-bit + ZoomPlayer...
Details of my test are a couple of posts above, also linked to MadVR's thread...

[kc7bfi]

I am trying to decode H.264 video from Axis and Vivotek cameras. The cameras set to send video at 30fps. However, when I look at the ffdshow dialog box while the video is playing I see the Movie FPS increasing. When this happens the video quality begins to degrade. I know the camera is not sending the video faster than 30fps but sometimes I see a Movie FPS as high as 49fps. Does anyone know why this happens or how to prevent it. Thanks much. David

[mark0077]

Hi guys, I'm using some avisynth mvtools scripts to get 24fps clips upto 60fps. I have been struggling even with my relatively high spec machine, to get 1080p content to 60fps without frame drops.

To make a long story short, I can get 0 frame drops for large sections of movies but often get clumps of frame drops here and there. just now I find two things that I'm wondering are they ffdshow specific.

1) With buffer forward / back in avisynth in ffdshow disabled, these frame drops go to 0. Is it optimized or are there known problems that cause this to be giving me issues when enabled?
2) With it off, audio / video sync is lost, about half a second difference between the two, is this a ffdshow or avisynth problem?

[travolter]

Hi guys, I'm using some avisynth mvtools scripts to get 24fps clips upto 60fps. I have been struggling even with my relatively high spec machine, to get 1080p content to 60fps without frame drops.

To make a long story short, I can get 0 frame drops for large sections of movies but often get clumps of frame drops here and there. just now I find two things that I'm wondering are they ffdshow specific.

1) With buffer forward / back in avisynth in ffdshow disabled, these frame drops go to 0. Is it optimized or are there known problems that cause this to be giving me issues when enabled?
2) With it off, audio / video sync is lost, about half a second difference between the two, is this a ffdshow or avisynth problem?

Im using these scripts here.. doing 1080 60fps is very very cpu hungry.. so that the cause of framedrops. In certain scenes maybe the video is using few bitrate and your cpu can do the 60fps conversion ok .. other times the cpu is not enough.

My solution is use resize before apply the script. I resize always to 1280x720. You can try upper resolutions until find your cpu limit.

Hey !! I have a question for you .. . cause nobody reply here.
I use assumefps() in my script. Using the x86 version of avisynth/ffdshow I can change the input fps.. but using the x64 version it does not work.

Are you suing x64? can you confirm this issue? clsid said that disabling "drop frame on delay" checkbox is the solution. I bet that x64 have that drop frame on delay feature always enabled (the checkbox dont do nothing) Could you confirm this? do you know some alternative ffdshow version without that "drop frame on delay" bug fixed?

[mark0077]

Sorry I'm using x86. I found tweaking the buffer ahead to 12 got rid of all frame drops. Wonder why setting it to even 16 causes drops. Are you getting much speed benefit from x64 with your scripts. I wonder is there a way to give avisynth script process less priority than the video renderer because I have a very strong feeling I'm gettin dropped frames not because my CPU is even nearly maxed out but because madvr isn't getting enough CPU to do it's work in time.

I want to try giving it higher priority than avisynth to see can I confirm this. Anyone?

[travolter]

Sorry I'm using x86. I found tweaking the buffer ahead to 12 got rid of all frame drops. Wonder why setting it to even 16 causes drops. Are you getting much speed benefit from x64 with your scripts. I wonder is there a way to give avisynth script process less priority than the video renderer because I have a very strong feeling I'm gettin dropped frames not because my CPU is even nearly maxed out but because madvr isn't getting enough CPU to do it's work in time.

I want to try giving it higher priority than avisynth to see can I confirm this. Anyone?

the magic of x64 is mvtools2. I have 10% performance boost with it (I did my tests), so if your cpu is in the limit.. you can get rid of framedrops.
Btw Im using the script without buffer. ( just uncheck the buffers checkbox). Im not sure if this is a feature of x64.. I never tried to disable buffers in x86.

Anyway I dont know people saying that does not have framedrops with 1080 at 60fps.. try ffdshow resize before the avisynth script.. 1280x720 looks also awesome

[mark0077]

Ah cheers, so where did you get your x64 mvtools from. I never managed to get playback to work in x64, mpc-hc 64bit would just freeze the moment I select avisynth... And turning on buffers and setting it to the number of threads I use, ie 12 reduced my frame drops to 0 where as before that I would get random drops here and there...

[travolter]

Ah cheers, so where did you get your x64 mvtools from.
http://forum.doom9.org/showthread.php?t=152800

[cyberbeing]

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

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

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