ffdshow tryouts project: Discussion & Development

[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?