ffdshow tryouts project: Discussion & Development

[betaking]

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

[clsid]

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

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

[betaking]

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

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

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

[clsid]

Found the cause. Fixing it now.

[betaking]

Found the cause. Fixing it now.

:thanks:
test ffdshow_rev3808_20110405_xhmikosr_MSVC2010.exe all is ok!

[Tom Keller]

Any news on this problem(?):

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

[Midzuki]

@ Tom Keller:

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

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


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

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

[Tom Keller]

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

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

[Midzuki]

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

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

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

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

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

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

Bottom lines:

--- don't use Windows Movie Maker ;

--- don't use Windows Media Encoder ;

--- don't use Expression Encoder ;

--- don't use Silverlight ;

That's all. :D

[Midzuki]

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

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


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

[Tom Keller]

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

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

[Midzuki]

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

You're wellcome ^_^

[Carpo]

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

[fastplayer]

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

[tetsuo55]

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

[nevcairiel]

Hey guys,

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

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

Thanks!

[Damien147]

Hi there.

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

rev3811

[burfadel]

Hi there.

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

rev3811

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

[VipZ]

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

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

[clsid]

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

[clsid]

Hey guys,

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

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

Thanks!
Committed.

[nevcairiel]

Thanks.

[VipZ]

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

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

@Tal

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

Thanks

[sneaker_ger]

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

[Shark007]

Hi develovers!

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

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

[Blight]

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

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

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

[Blight]

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

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

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

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

[clsid]

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

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

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

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

[VipZ]

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

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

[Blight]

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

[pankov]

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

[clsid]

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

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

[VipZ]

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

Thanks for looking into it.

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

[nevcairiel]

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

[clsid]

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

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

Edit2: fixed in 3816

[Sebastiii]

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

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

Edit2: fixed in 3816

Thanks :)

[VipZ]

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

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

Edit2: fixed in 3816

Thanks all good now :)

[Mr VacBob]

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

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

Edit2: fixed in 3816

I'm curious, would you happen to have the non-working and working asm for that function with ICL? It could be an aliasing problem in the code.

I pushed a fix for some PAFF files to ffmpeg-mt.

[clsid]

It is not an asm issue. The problem is in the bitstream reading code. See here:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/libavcodec/golomb.h?r1=3816&r2=3815&pathrev=3816

[XhmikosR]

That change should have fixed the remaining crashes I had with ICL builds and h264 videos. So far I cannot reproduce any crash anymore which is a good thing.

[Milardo]

Hello,
Is it possible to compile ffdshow with postprocessing enabled in ffvdub and ffdshow encoder? Also, is it easy to change the code for this so i could compile ffdshow myself?

[fastplayer]

@Devs:
Isn't branches/ obsolete by now? Everything's been merged with trunk already.

[clsid]

Hello,
Is it possible to compile ffdshow with postprocessing enabled in ffvdub and ffdshow encoder? Also, is it easy to change the code for this so i could compile ffdshow myself?We can't help you with this. You will hve to try and see for yourself.

Some PP algorithms use data that is only available during decoder, so they can't be used in situations where ffdshow isn't doing the decoding.

@Devs:
Isn't branches/ obsolete by now? Everything's been merged with trunk already. Yes, they are obsolete. Removing them is fine with me.

[SamuriHL]

Stupid question time. I'm trying to pull from SVN and in the last day or two I keep getting an error when it goes to pull the boost source.


C:\dev\projects\ffdshow-tryout\src\boost
OPTIONS of 'http://svn.boost.org/svn/boost/branches/release/boost':
authorization failed: Could not authenticate to server: rejected Basic
challenge (http://svn.boost.org)


It's popping up an authentication dialog box. The first time I pulled the source it didn't ask me for this. Am I doing something incredibly stupid? Any help here would be greatly appreciated. I've been enjoying building my own builds of ffdshow, lav splitter, and mpc-hc in the last week or so and would like to continue doing so. Thanks!

[Snowknight26]

FPS1 -> RGB32 conversion results in flipped B and R components. It seems to be outputting BGR32 instead. I believe it happened after the recent reduction of RGB colorspaces but I'm can't verify that.

[magic144]

quick Q

just noticed that on my PC attached to my TV (ATI gfx card, HDMI to plasma), a particular 1280x720 file renders with RGB32 output color space, whereas in my office on another PC attached to LCD monitor (NVidia gfx card, DVI), it chooses to use YV12 (both using clsid rev 3814, both have multiple color-spaces selected for output) when playing the same file

(in fact, if I disable ALL BUT YV12 on my plasma setup PC for this file, ffdshow won't load to play the file and another M$oft filter gets used instead)

also strange, a different 1280x720 file on the plasma setup WILL render with YV12 color-space output chosen...

what affects the choice of output color space, and why would two h.264 files with the same resolutions choose different output color-spaces??

thanks in advance!

[clsid]

FPS1 -> RGB32 conversion results in flipped B and R components. It seems to be outputting BGR32 instead. I believe it happened after the recent reduction of RGB colorspaces but I'm can't verify that.Will fix that.

[magic144]

also, does the "ATI Pixel Format" play a part in how the output color space is chosen? - I don't explicitly set that, but it's possible a newer driver could have changed the default?

*EDIT* apparently not... tried them all and no change in YV12->RGB32 choice @ ffdshow, even though YV12 is also selected as an option
...by the way, driver is AMD Catalyst 11.3 (latest)

[Ger]

@magic144
Normally ffdshow should use this output priority from top to bottom: YV12, NV12, RGB32, YUY2, YUVU.

In your case, if all colorspaces are checked, when YV12 is used it found/negotiated a match with the next filter right away. When RGB32 is used (with all colorspaces checked) it usually indicates that both YV12 and NV12 were rejected by the next filter (normally the video renderer). If you get RGB32 with everything checked with ATI hardware that implies either VMR7 renderless or Haali video renderer is in use (both of those reject YV12 and NV12 on my ATI system) or some other filter that rejects both of those.

Which colorspaces are accepted by the video renderer is consistent in some cases (madVR accepts YV12, NV12 and in theory two more not available in ffdshow while Haali accepts YUY2 and RGB32) and depends on the driver/hardware in other cases (YV12 is accepted with EVR+Nvidia, but rejected by EVR+ATI meaning NV12 will be used for EVR+ATI).

[magic144]

@Ger - thanks!

fyi I believe everything is checked EXCEPT NV12 in this case... I found that NV12 would tend to have been chosen and gave a somewhat unnatural appearance on my plasma set. I DO use NV12 for interlaced material (to enable HW deinterlacing), but that's about the only time.

I am using EVR. Maybe I never noticed this propensity to select RGB32 in favour of YV12 with this setup in the past...
However, like I said, there is (at least) one 1280x720 (progressive video) file which DOES render with YV12 with this setup, hence my confusion... perhaps there is some other aspect of the video attributes that EVR is considering?? Does the DISPLAY play any part in the negotiation?

Lastly, if RGB32 is the chosen output color space, doesn't that mean that an extra processor usage burden now exists since ffdshow has to perform the YV12 (input) to RGB32 (output) conversion in software?

Thanks so much,
m