ffdshow tryouts project: Discussion & Development

[sneaker_ger]

From what I've seen libass do, it has become very usable. I would trade MPC-HC's internal renderer for it any day. The former can behave really oddly sometimes and render differently than the standalone vsfilter, plus it's awfully slow and unstable.

[kirakami]

Maybe i'm wrong but i guess ass3/4 means ScriptType: v4.00+ which is nothing new and this is the default format of the aegisub. Just ffdshow's subtitles filter is broken compared to vsfilter

i got new vsfilter here but fail to install it
it didn't work with MPC-HC external filter :(
http://code.google.com/p/threaded-vsfilter/
does anyone know?

[sneaker_ger]

Be more specific as to what does not work.
To register it: start->(run->)"cmd" (On Vista/7 you may need to press ctrl+shift+enter to start the console with admin rights)
Then navigate to vsfilter.dll's folder and enter "regsvr32 vsfilter.dll". You may also need to add "DirectVobSub (Auto-loading version)" as a preferred external filter in MPC-HC.

[Keiyakusha]

i got new vsfilter here but fail to install it
it didn't work with MPC-HC external filter :(
http://code.google.com/p/threaded-vsfilter/
does anyone know?
Also that's not official version. Don't know if its authors are present on this forum, maybe try to ask them directly?
Also they say it won't work on XP, thats not the case for you?

[sneaker_ger]

Here's another vsfilter version, claiming to be faster than the threaded project:
http://www.cccp-project.net/forums/index.php?topic=5976.0

@kirakami
Are you on Win XP?

[kirakami]

yes i m on XP SP3

[sumawo13]

I believe FFDShow Tryouts is doing an improper YUV -> RGB conversion. I think it's using the wrong coefficients (BT601 instead of BT709). I have Rev3978 set to output RGB32.

I created two 8-bit YUV files of the 1080p Crowd Run sequence using sgi2yuv from the original 1080p 16-bit SGI files, one 4:2:0 and one 4:4:4. The 4:2:0 encode produces the correct colors, while the 4:4:4 video produces incorrect colors. Here are examples taken from the videos compared to one of the frames from the sequence (SGI file converted to PNG using ImageMagick).

Original
http://ompldr.org/tYWVoNw (http://ompldr.org/vYWVoNw)

4:2:0
http://ompldr.org/tYWVoOA (http://ompldr.org/vYWVoOA)

4:4:4
http://ompldr.org/tYWVoOQ (http://ompldr.org/vYWVoOQ)

Both were encoded with x264 and used the same encoding parameters except for --input-csp and --output-csp which were set to i420 and i444 respectively.

[Thunderbolt8]

Here's another vsfilter version, claiming to be faster than the threaded project:
http://www.cccp-project.net/forums/index.php?topic=5976.0also: http://xhmikosr.1f0.de/index.php?folder=bXBjLWhjL21wYy1oY19hcHBzL3ZzZmlsdGVy

[kirakami]

also: http://xhmikosr.1f0.de/index.php?folder=bXBjLWhjL21wYy1oY19hcHBzL3ZzZmlsdGVy

its the same original ver.
http://www.videohelp.com/tools/VSFilter_DirectVobSub

[sneaker_ger]

yes i m on XP SP3

In the thread I've linked someone says that the threaded version does not work on XP. Try the one linked in that thread instead. (Best to just read the whole thread, seems to contain some valuable info.)

[kirakami]

In the thread I've linked someone says that the threaded version does not work on XP. Try the one linked in that thread instead. (Best to just read the whole thread, seems to contain some valuable info.)

this vsfilter mod worked on XP
http://code.google.com/p/xy-vsfilter/
but still don't know whether it supports ass sub ver.3/4/+

[mandarinka]

I believe FFDShow Tryouts is doing an improper YUV -> RGB conversion. I think it's using the wrong coefficients (BT601 instead of BT709). I have Rev3978 set to output RGB32.

I created two 8-bit YUV files of the 1080p Crowd Run sequence using sgi2yuv from the original 1080p 16-bit SGI files, one 4:2:0 and one 4:4:4. The 4:2:0 encode produces the correct colors, while the 4:4:4 video produces incorrect colors. Here are examples taken from the videos compared to one of the frames from the sequence (SGI file converted to PNG using ImageMagick).

Original
http://ompldr.org/tYWVoNw (http://ompldr.org/vYWVoNw)

4:2:0
http://ompldr.org/tYWVoOA (http://ompldr.org/vYWVoOA)

4:4:4
http://ompldr.org/tYWVoOQ (http://ompldr.org/vYWVoOQ)

Both were encoded with x264 and used the same encoding parameters except for --input-csp and --output-csp which were set to i420 and i444 respectively.

This might be because with yv12, ffdshow handles the stuff itself (yv12 is passed through, and if rgb is to be outputed, it will do so using bt601 for SD and bt709 for HD, or based on stream's info iirc).

With 10bit video, swscale needs to be used, which could lead to improper matrix being used (might not matter for yv12 ouptut, but it breaks rgb). Maybe this is the case with 4:4:4 too? Are wrong coeficients being used when ffdshow outputs yv12 (or maybe other yuv formats), or just when outputing rgb?

[nevcairiel]

ffdshows RGB HQ converter only supports 4:2:0 and 4:2:2 input, 4:4:4 is probably going through some other code path.

[Dogway]

I used to use ffdshow_rev3972_20110818_xvidvideo-ru_x86-MSVC2010.exe but Im having some problems I think come from encoding FFV1 so I updated to ffdshow_rev3982_20110915_clsid.exe. But now I can't select ffmpeg-mt in h.264 decoding. Is this OK?

[nevcairiel]

ffmpeg-mt was integrated into the normal decoder quite a while ago. Its all good.

[Dogway]

It should perform better than libav right? I don't know why it doesn't show in the list to select, probably I need to update MPC-HC?
Maybe Id need to update to ffdshow_rev3972_20110818_xvidvideo-ru_x86-MSVC2010.exe instead of clsid builds?. I had a mistake in my previous post, I had before: ffdshow_rev3861_20110527_xvidvideo-ru_x86-msvc2010.zip. But this webpage stopped with its builds one month ago.

[Atak_Snajpera]

FFmpeg-mt is in libavcodec

[Dogway]

ah ok!, sorry for the confusion. I just wondered because before it was selecteable. thanks

[kirakami]

real audio cook codec is still buggy
audio becomes shuttery after playing for a while :(

[kirakami]

ffdshow's real audio cook codec also gets buggy as soon as i seek
using MPC-HC. it doesn't have internal cook codec?

[clsid]

LAV Audio works better for COOK

[Midzuki]

@ kirakami: why not use a "manual install" of the RealAlternative files, instead of insisting on ffdshow? :confused:

http://forum.doom9.org/showthread.php?p=1298640#post1298640 ... explains it all. :)

[Zerofool]

Hello,
I'd like to report an issue I'm having, I don't know if it's a bug, or lack of functionality, but anyways, here it is.

I was experimenting with the 4:4:4 support in x264, and I encoded some gameplay footage. It's all in full range (and so, I used the --fullrange parameter while encoding), but obviously ffdshow doesn't care about that (allways works for 4:2:0 fullrange videos), and treats the video as limited range, and, therefore, it looks darker than it should. I tried to force ffdshow to recognize the clip as full range (Overlay->Output-> and I only enable RGB32 here; Overlay->Output->RGB conversion-> Input levels: Full Range, Output levels: Computer Monitor, also the "HQ YV12 to RGB conversion" is enabled, although that shouldn't matter in this case, I guess), but there's no change at all, no matter what I set in these fields (unlike with 4:2:0 footage, where the difference is clearly visible). So would I be wrong to presume that these settings only apply to 4:2:0->RGB conversion, and not 4:4:4->RGB ? If that's correct, it would be nice if such a feature is implemented (and probably also native YV24 output support).

The only way I was able to correctly play the file was through madVR's internal decoder (and rendered with madVR of course :)).

Details:
ffdshow version: rev3984_20110922_clsid (32bit)
Player: MPC-HC (BE mod) v1.5.3.3734 (32bit)
renderer: I tested almost all of them - no difference; madVR is v0.74
OS: Windows 7 Ultimate x64
Video Card: ATI (AMD) Radeon HD5870 (non-reference PCB, XFX), currently with Catalyst 11.9 RC, but two days ago I had 11.8 WHQL - the same thing.
Display: 22" Mitsubishi Diamond Pro 2070SB (CRT)

Thanks and keep it up guys!
Cheers

[clsid]

The HQ RGB converter is not used in that case. The low quality swscale one is used. Any problems with that will NOT be fixed unless someone volunteers to do it.

[Zerofool]

I see. Thank you for clearing that up.

Best regards

[magic144]

just trying "The Killing" BD on my PC - seems like ffdshow Audio is choking on the LPCM 24-bit mono (48000Hz, uncompressed) soundtrack for some reason - plays back ~1/2 speed???
if I switch over to LAV Audio, all is A-OK
no other problems with ffdshow Audio to date...
...am using latest r3984, but reverted back as far as 3919 but the same issue persists

I'm using ZoomPlayer 8 MAX (latest release candidate).
Win7 32-bit, Analogue output via Speakers, DELL XPS420

[kirakami]

i compared xy-vsfilter http://code.google.com/p/xy-vsfilter with ffdshow 3984 sub render on MPC-HC
SSA sub plays fine but fonts size, bold broken vsfilter works fine check here http://www.mediafire.com/?icoztozy2nh
ASS subs some 3d effects seems to be broken try playing Dragon Crisis BD Opening once with ffdshow sub render then with xy-vsfilter & you will know.
http://www.mediafire.com/?0m7j6u2butp4cq5
i couldn't post screenshots 'cuz print screen doesn't work with video.

[kirakami]

Dragon Crisis BD Opening
http://www.mediafire.com/?0m7j6u2butp4cq5

[kirakami]

ffdshow 3984 weirdly fails to decode this H.264 codec
http://www.mediafire.com/file/zmmgky2gnny/Gen-ttt
potplayer plays it fine

[TheShadowRunner]

LAV Audio works better for COOK

Hmm in LAV Audio dec 0.37, I don't see COOK anywhere in the format list, nor does the decoder want to accept subtype {4B4F4F43-0000-0010-8000-00AA00389B71}

Strangely, ffdshow doesn't want to accept this subtype either!?

When it comes to COOK, only thing I found working is the Gabest splitter + cook.dll

Is COOK supposed to be handled by current ffdshow/LAV?

[roytam1]

Hmm in LAV Audio dec 0.37, I don't see COOK anywhere in the format list, nor does the decoder want to accept subtype {4B4F4F43-0000-0010-8000-00AA00389B71}

Strangely, ffdshow doesn't want to accept this subtype either!?

When it comes to COOK, only thing I found working is the Gabest splitter + cook.dll

Is COOK supposed to be handled by current ffdshow/LAV?

LAV Splitter will split COOK audio with 4cc "cook"(YES lowercased) which LAV Audio will accept.

[TheShadowRunner]

roytam, I see.
I guess ffdshow only accepts the lowercased "cook" 4cc as well. Strange (and annoying) that these decoders won't accept COOK uppercase as presented by Gabest's FLV Splitter.

[ikarad]

When I see a hi10p video I have these information with ffdshow+madvr+ mpc-hc

http://img11.hostingpics.net/pics/575998osdincorrect.png (http://www.hostingpics.net/viewer.php?id=575998osdincorrect.png)

In this site http://haruhichan.com/wpblog/?p=205#confirm, it said it's incorrect


The correct osd is here
http://img11.hostingpics.net/pics/184932madvrosdcorrect.png (http://www.hostingpics.net/viewer.php?id=184932madvrosdcorrect.png)

is-it normal or not?

If I use h264 internal decoder of madvr instead of ffdshow I have
http://img11.hostingpics.net/pics/809221Sanstitre.jpg (http://www.hostingpics.net/viewer.php?id=809221Sanstitre.jpg)

Anybody could explain me the differences and the good method to see hi10p movie with the best quality?

[nevcairiel]

ffdshow does not support 10bit output, it'll always be converted to 8-bit.

[TheRyuu]

With the addition of this (http://git.libav.org/?p=libav.git;a=commit;h=27237d524e56210992b18486924894bb4f3fdbb8) to libav external pthreads should no longer be required and everything should work all the same.

Only really matters if you want to reduce a dependency, otherwise it really makes no difference.

[seo125]

Am I wrong or 'Cubic Blending' is broken? I see a lot of artifact in build 1090. I'm using this post as a base of the best deinterlacing method. Any suggestion?

__________________
´ (http://www.travelling2peru.com)´´´My Profile´´´ (http://forum.doom9.org/member.php?u=202175)´ (http://www.travelling2peru.com)

[kirakami]

ffdshow rev. 3996 ???
http://www.afterdawn.com/software/audio_video/codecs/ffdshow.cfm
its not uploaded here
www.videohelp.com/tools/ffdshow/version-history

[roytam1]

ffdshow rev. 3996 ???
http://www.afterdawn.com/software/audio_video/codecs/ffdshow.cfm
its not uploaded here
www.videohelp.com/tools/ffdshow/version-history

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/

[Moti172]

Hi

In order to decode dts I'm using lav-audio+dtsdecoderdll |(mpc-hc), and ffdshow to process it (downmix...).
The audio decoded out put is 24bit while ffdshow process it with 32-bit integer floating point.
Does it has any impact on the sound quality?

Thanks

[LigH]

At least it would not make it worse: Single Precision IEEE float has an effective mantissa of 24 bit too, but that is the precision over the whole volume range, not only for the loudest parts.

[Thunderbolt8]

when activating OSD and frame type, then it looks as if the video consits only of I frames. there is no other change of frame types, every video I open just has I frames written all over (ffdshow for raw video & LAVsplitter & coreavc & WMVdecoderDMO)

[zmaster]

I saw this message:For those who are wondering why Hi10P isn't working with the x64 build. It has been disabled because it crashed.

The crash happens in the golomb code used in the SPS parser. It isn't the first time that this code has been causing problems in x64 builds. It really needs to be replaced with something better.

I tried replacing it with the CByteParser class from LAV Filters, but a simple function call replace didn't work properly (assertion failures in both x86 and x64 build). Need to be analyzed deeper. If anyone else want to give it a go, please do. but decided to ask because the inability to decode Hi10p becoming a growing problem and would like to know takes place whether the development in this direction.

[clsid]

when activating OSD and frame type, then it looks as if the video consits only of I frames. there is no other change of frame types, every video I open just has I frames written all over (ffdshow for raw video & LAVsplitter & coreavc & WMVdecoderDMO)Only the decoder knows the frame type. You are not using ffdshow for decoding.

[clsid]

I saw this message: but decided to ask because the inability to decode Hi10p becoming a growing problem and would like to know takes place whether the development in this direction.LAV Video can decode it. ffdshow development is pretty much frozen at this moment.

[zmaster]

clsid,
LAV Video can decode it...Yes, but I'm a fan of ffdshow ;)

Thanks for reply!

[haruhiko_yamagata]

Hi, everybody. Sorry for my long absence and thank you for the good maintenance work.

I've been playing with the subtitles for a month. By importing a lot of code from MPC-HC,


Implement rotation (\frx,\fry,\frz,\org).
Implement \clip.
Implement \h.
Implement \r<style>
Implement \blur<strength>
Implement \be<strength>
Implement polygon drawings (\p)

Improved rendering (boundary of the body and the outlines)
Improved gradation of the outlines.
Improved, rotatable opaque box.

Subpixel accurate positioning.

Some compatibility fixes.
a few regression fixes

Other bug fix

ffdshow color space converter:YV12->RGB32:If the output horizontal size is not a multiple of 4, the heap gets broken.

TODO

Implement \t
Implement \clip polygon bitmap mask version
Improve YV12 rendering

I've created a branch in the svn. A test build. (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev3998_20111025_branch.exe)
Please give it a try, if you are interested in ffdshow's subtitles filter.

[fastplayer]

Welcome back, Haruhiko! :)

[haruhiko_yamagata]

Hello! Nice to see you are still here.

[_xxl]

@haruhiko_yamagata

Nice to see you again !

[_xxl]

Do you have new idea's for ffdshow?:)

[haruhiko_yamagata]

Hi, nice to see you again.:)
10bit color space support may be important. But as for me, I would like to concentrate on subtitles for the time being.

[_xxl]

I don't know how to get new developers to be interested in FFdshow...

[haruhiko_yamagata]

Yeah, it's important. ffdshow is a huge project and it is not possible for a small numbers of developers to satisfy all requests.

[SamuriHL]

If you're looking at subtitle support I think it would be helpful to maybe take a look at adding support for the extended vobsub format used by HD DVD. I know it's a dead format, but, a LOT of people have converted them to MKV's and are really only missing subtitle support. Just something to consider.

[Keiyakusha]

Hi, nice to see you again.:)
10bit color space support may be important. But as for me, I would like to concentrate on subtitles for the time being.

Wow,Yamagata-san, welcome back ^__^

About subtitles, do you think ffdshow's engine even deserves to be improved? It has more potential than vsfilter?

[Kurtnoise]

If you're looking at subtitle support I think it would be helpful to maybe take a look at adding support for the extended vobsub format used by HD DVD. I know it's a dead format, but, a LOT of people have converted them to MKV's and are really only missing subtitle support.
Seriously ? :rolleyes:

How many people use/buy HDDVD nowadays ? Please, tell me...

There are several ways to convert hddvd to bd discs...no need to waste some time for this.

Just my 0.02€.

[SamuriHL]

Seriously ? :rolleyes:

How many people use/buy HDDVD nowadays ? Please, tell me...

There are several ways to convert hddvd to bd discs...no need to waste some time for this.

Just my 0.02€.

No skin off my nose if it's not implemented. How many BUY them now a days? NONE. How many OWN them and have converted the to MKV? TONS. I already have a subtitle renderer that can display them in an MKV, so, personally I don't care either way. It was a suggestion because there are people that would use it and no free subtitle renderer can display them. For completeness, it would be a good idea to implement it. If not, whatever. :)

[haruhiko_yamagata]

About subtitles, do you think ffdshow's engine even deserves to be improved? It has more potential than vsfilter?
Hi, don't be so serious. I'm just playing. It's fun to code for subtitles.

[haruhiko_yamagata]

If you're looking at subtitle support I think it would be helpful to maybe take a look at adding support for the extended vobsub format used by HD DVD. I know it's a dead format, but, a LOT of people have converted them to MKV's and are really only missing subtitle support. Just something to consider.Not to mention HD DVD, the vobsub support in ffdshow is quite incomplete. I'm not much interested in it.

[SamuriHL]

Not to mention HD DVD, the vobsub support in ffdshow is quite incomplete. I'm not much interested in it.

No problem. Just thought I'd mention it since you were playing in the subtitle code. Not a big deal, as like I said, I have a solution that works perfectly for me. J River implemented their own subtitle renderer that supports nearly all the subtitle formats.

[Midzuki]

@ Yamagata-sama, a shameless :o feature request :)

http://forum.doom9.org/showthread.php?p=1416657#post1416657

P.S.: also:

http://forum.doom9.org/showthread.php?p=1444038#post1444038

[ikarad]

Hi, everybody. Sorry for my long absence and thank you for the good maintenance work.

I've been playing with the subtitles for a month. By importing a lot of code from MPC-HC,


Implement rotation (\frx,\fry,\frz,\org).
Implement \clip.
Implement \h.
Implement \r<style>
Implement \blur<strength>
Implement \be<strength>
Implement polygon drawings (\p)

Improved rendering (boundary of the body and the outlines)
Improved gradation of the outlines.
Improved, rotatable opaque box.

Subpixel accurate positioning.

Some compatibility fixes.
a few regression fixes

Other bug fix

ffdshow color space converter:YV12->RGB32:If the output horizontal size is not a multiple of 4, the heap gets broken.

TODO

Implement \t
Implement \clip polygon bitmap mask version
Improve YV12 rendering

I've created a branch in the svn. A test build. (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev3998_20111025_branch.exe)
Please give it a try, if you are interested in ffdshow's subtitles filter.
good news.

1)There is a bug with animated sub
bug tracker
http://sourceforge.net/tracker/?func=detail&aid=3186705&group_id=173941&atid=867360

this problem is not corrected with your version

2) Albain have allowed the support of pgs subs but when two silmutaneous subs are displayed i nthe same time, there are random crash.

3) other bug with subtitle renderer (between 1hour17 and 1hour 18 with sub file subs are displayed not correctly)
file: http://www.zshare.net/info.html?95171226-cba83d2230ae9f09ae5be28229de3580

Dialogue: 0,1:17:38.00,1:17:41.09,Signs,,0000,0000,0000,,{\an7\fs80\pos(322.666667,276.666667)\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\fnTempus Sans ITC}My body...
Dialogue: 0,1:17:38.00,1:17:41.09,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(339.333333,276.666667,613.333333,276.666667,28,445)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:17:39.34,1:17:41.09,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs80\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(322.666667,526.666667)}is made of swords.
Dialogue: 0,1:17:39.34,1:17:41.09,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(327.333333,519.333333,796.666667,519.333333,23,732)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:17:43.13,1:17:46.59,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs80\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(408,278.666667)}Iron is my blood
Dialogue: 0,1:17:43.13,1:17:46.59,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(416.666667,270,844.666667,270,29,696)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:17:44.59,1:17:46.59,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs80\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(451.333333,536.666667)}and glass is my heart.
Dialogue: 0,1:17:44.59,1:17:46.59,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(459.333333,533.333333,1000,533.333333,0,1029)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:17:48.89,1:17:57.61,Signs,,0000,0000,0000,,{\an7\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(252,216.666667)\fnTempus Sans ITC\fs56.666667\b1}I have overcome countless battlefields undefeated.
Dialogue: 0,1:17:48.89,1:17:57.61,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(258.666667,208.666667,1170,208.666667,24,1609)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:17:51.89,1:17:57.61,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs56.666667\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(252,390)}Not once have I retreated,
Dialogue: 0,1:17:51.89,1:17:57.61,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(258.666667,384.666667,734.666667,384.666667,27,1612)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:17:54.89,1:17:57.61,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs56.666667\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(252,563.333333)}nor once have I been understood.
Dialogue: 0,1:17:54.89,1:17:57.61,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(274.666667,560,871.333333,560,30,1615)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:17:59.90,1:18:05.49,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs56.666667\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(369.333333,220)}Always alone
Dialogue: 0,1:17:59.90,1:18:05.49,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(378,210,620.666667,210,25,651)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:18:01.94,1:18:05.49,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs56.666667\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(369.333333,395.333333)}on the hill of swords...
Dialogue: 0,1:18:01.94,1:18:05.49,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(416.666667,388.666667,778.666667,388.666667,29,571)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:18:03.44,1:18:05.49,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs56.666667\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(369.333333,579.333333)}intoxicated with victory...
Dialogue: 0,1:18:03.44,1:18:05.49,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(371.333333,578.666667,840.666667,578.666667,30,698)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:18:08.58,1:18:13.62,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs83.333333\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(207.333333,293.333333)}Thus, this life has no meaning.
Dialogue: 0,1:18:08.58,1:18:13.62,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(230.666667,284.666667,1026.666667,284.666667,21,1105)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:18:11.79,1:18:13.62,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs83.333333\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(207.333333,526.666667)}This body... was definitely...
Dialogue: 0,1:18:11.79,1:18:13.62,Signs,,0000,0000,0000,,{\an7\bord0\shad0\p1\c&H000000&\move(226.666667,523.333333,928.666667,523.333333,22,1148)}m 0 0 l 933 0 933 100 0 100{\p0}
Dialogue: 0,1:18:14.29,1:18:17.00,Signs,,0000,0000,0000,,{\fnTempus Sans ITC\an7\fs120\bord3.333333\blur10\b1\3c&H1331E8&\c&HCCD0F5&\pos(242,426.666667)}made out of blades.

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

[clsid]

Welcome back, Haruhiko!

[cc979]

i am aware about flac needing a splitter, my question is when using opencodec from xiph - i have ffdshow set to handle all supported raw audio, is there a reason why ffdshow does not handle the output from opencodec in mpc_hc with windows 7 ?

cheers


Filter : Audio Switcher - CLSID : {18C16B08-6497-420E-AD14-22D21C2CEAB7}

- Connected to:

CLSID: {79376820-07D0-11CF-A24D-0020AFD79767}
Filter: Default DirectSound Device
Pin: Audio Input pin (rendered)

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 44100Hz stereo 1411kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 2
nSamplesPerSec: 44100
nAvgBytesPerSec: 176400
nBlockAlign: 4
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x00000003
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 02 00 44 ac 00 00 10 b1 02 00 04 00 10 00 þÿ..D¬...±......
0010: 16 00 10 00 03 00 00 00 01 00 00 00 00 00 10 00 ................
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

Set as the current media type

- Enumerated media type 1:

Audio: PCM 44100Hz stereo 1411kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 18

WAVEFORMATEX:
wFormatTag: 0x0001
nChannels: 2
nSamplesPerSec: 44100
nAvgBytesPerSec: 176400
nBlockAlign: 4
wBitsPerSample: 16
cbSize: 0 (extra bytes)

pbFormat:
0000: 01 00 02 00 44 ac 00 00 10 b1 02 00 04 00 10 00 ....D¬...±......
0010: 00 00 ..

[haruhiko_yamagata]

Welcome back, Haruhiko!
Nice to see you again. I'm happy to see current status of ffdshow.

[haruhiko_yamagata]

@ Yamagata-sama, a shameless :o feature request :)

http://forum.doom9.org/showthread.php?p=1416657#post1416657

P.S.: also:

http://forum.doom9.org/showthread.php?p=1444038#post1444038
Sorry, I'm not interested in the audio part.

[haruhiko_yamagata]

good news.
No the less I'm just playing, I'm glad to hear that.:)

1)There is a bug with animated sub
bug tracker
http://sourceforge.net/tracker/?func=detail&aid=3186705&group_id=173941&atid=867360

this problem is not corrected with your version

Do you mean the vertical part is a few pixels off to the right? I think it's a bug of vsfilter.
ffdshow does not have a emulation code for the bug. Maybe I have to implement it anyway.

2) Albain have allowed the support of pgs subs but when two silmutaneous subs are displayed i nthe same time, there are random crash.

How can I build a testing environment?

3) other bug with subtitle renderer (between 1hour17 and 1hour 18 with sub file subs are displayed not correctly)
file: http://www.zshare.net/info.html?95171226-cba83d2230ae9f09ae5be28229de3580



bug tracker here
https://sourceforge.net/tracker/?func=detail&aid=3428392&group_id=173941&atid=867360
The black bars are not positioned correctly. The problem was reproduced. :thanks:

[ikarad]

How can I build a testing environment?



I can give you a build but the problem is the crashs are random. Often it can works very well and sometimes it can crash. It's very difficult to reproduce this problem.
The only thing That I said is that when mpc-hc with ffdshow crash it's only when two subs (pgs subs only) are displayed simultaneous by ffdshow.

Example: in a bluray movie (1hour 30) I had simultaneous subs during 15 min and I have only 2 crash only when two simultaneous subs are displayed i nthe same time. But If I restart at the same moment, I didn't have crash.

[ikarad]

Do you mean the vertical part is a few pixels off to the right? I think it's a bug of vsfilter.
ffdshow does not have a emulation code for the bug. Maybe I have to implement it anyway.


No, I mean that with ffdshow there are no animation if you check complex subs and with mpc-hc there are animations of subs. Moreover the vertical bar sub at the right with mpc-hc sub renderer become no vertical bar sub (horizontal bar) at the right with ffdshow sub renderer

[Midzuki]

Sorry, I'm not interested in the audio part.

Thanks for making your lack-of-interest very clear :)

But my request actually has nothing to do with audio,

it has to do with forms/window design ;) :p

Anyway, let's see how much your skills have been improved during your sabbatical :D

[haruhiko_yamagata]

No, I mean that with ffdshow there are no animation if you check complex subs and with mpc-hc there are animations of subs. Moreover the vertical bar sub at the right with mpc-hc sub renderer become no vertical bar sub (horizontal bar) at the right with ffdshow sub renderer
It works for me.
Are we talking about [FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv? Please make sure you have downloaded my test build from Doom9 and installed it. Or maybe some style overrides by the dialog check box?

[haruhiko_yamagata]

Thanks for making your lack-of-interest very clear :)

But my request actually has nothing to do with audio,

it has to do with forms/window design ;) :p

Anyway, let's see how much your skills have been improved during your sabbatical :D
Then you are talking about the way to destroy adamantium :rolleyes:
The window is too small for font section of the subtitles. I cannot add any more items there. The reason why the window is small is that we wanted to support VGA projectors. Currently, VGA projectors is hardly used, so it's time to widen the window.
But it takes a lot of time. If it is inevitable, I am going to do so.

[haruhiko_yamagata]

I can give you a build but the problem is the crashs are random. Often it can works very well and sometimes it can crash. It's very difficult to reproduce this problem.
The only thing That I said is that when mpc-hc with ffdshow crash it's only when two subs (pgs subs only) are displayed simultaneous by ffdshow.

Example: in a bluray movie (1hour 30) I had simultaneous subs during 15 min and I have only 2 crash only when two simultaneous subs are displayed i nthe same time. But If I restart at the same moment, I didn't have crash.Thank you for explanation. If it is possible, please send me a sample.
The randomness of the crash makes debugging difficult, but it doesn't mean the effort doesn't worth while.

[ikarad]

It works for me.
Are we talking about [FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv? Please make sure you have downloaded my test build from Doom9 and installed it. Or maybe some style overrides by the dialog check box?

Yes and I speak about subs called complexe karaoke and not subs called simple karaoke. I try with your version and they don't worked like before
with simple karaoke (it's like with mpc-hc) and it's worked.


with complex karaoke (animated subs doesn't worked instead of working with mpc-hc)
http://img11.hostingpics.net/thumbs/mini_739865Sanstitre2.jpg (http://www.hostingpics.net/viewer.php?id=739865Sanstitre2.jpg)

with mpc-hc there are animations even with complex karaoke subs
http://img11.hostingpics.net/thumbs/mini_411523Sanstitre3.jpg (http://www.hostingpics.net/viewer.php?id=411523Sanstitre3.jpg)

Moreover with ffdshow subs at the right of the screen is horizontal and cut at the middle and with mpc-hc sub is vertical and complete

[haruhiko_yamagata]

Yes and I speak about subs called complexe karaoke and not subs called simple karaoke. I try with your version and they don't worked like before
with simple karaoke (it's like with mpc-hc) and it's worked.
...

It works for me. It is identical to MPC-HC except that the vertical subs are a few pixels off to the right.
Would you re-install and reboot to make sure ffdshow.ax is replaced by the new one? And if the problem is still there, would you uninstall ffdshow and re-install to exclude the settings related problem. Before uninstalling, please backup the registry [HKEY_CURRENT_USER\Software\GNU].

By the way, for better quality, I would like to recommend RGB32 output.

[ikarad]

I find another problem with sub
With ffdshow (under subs, rectangle is opac and not under subs)
http://img11.hostingpics.net/thumbs/mini_255859Sanstitre4.jpg (http://www.hostingpics.net/viewer.php?id=255859Sanstitre4.jpg)
with mpc-hc (under subs, rectangle is transparent and under subs)
http://img11.hostingpics.net/thumbs/mini_641964Sanstitre5.jpg (http://www.hostingpics.net/viewer.php?id=641964Sanstitre5.jpg)

file here
http://www.nyaa.eu/?page=torrentinfo&tid=252194

[ikarad]

It works for me. It is identical to MPC-HC except that the vertical subs are a few pixels off to the right.
Would you re-install and reboot to make sure ffdshow.ax is replaced by the new one? And if the problem is still there, would you uninstall ffdshow and re-install to exclude the settings related problem. Before uninstalling, please backup the registry [HKEY_CURRENT_USER\Software\GNU].

By the way, for better quality, I would like to recommend RGB32 output.

I do like you said but I have the same problem.

with ffdshow subs I have with complex karoke subs
http://img11.hostingpics.net/thumbs/mini_739865Sanstitre2.jpg (http://www.hostingpics.net/viewer.php?id=739865Sanstitre2.jpg)

and not like with mpc-hc
http://img11.hostingpics.net/thumbs/mini_411523Sanstitre3.jpg (http://www.hostingpics.net/viewer.php?id=411523Sanstitre3.jpg)

I don't understand why you have the good thing and me the wrong thing. Although your version is well installed because I see the differences under some subs.

[haruhiko_yamagata]

OK, I enabled MPC-HC's internal Matroska splitter and changed video renderer to EVR Custom (and disabled MPC-HC's subtitle), I finally reproduced the problem. :thanks:

[ikarad]

Thank you for explanation. If it is possible, please send me a sample.
The randomness of the crash makes debugging difficult, but it doesn't mean the effort doesn't worth while.

Here the example (2 min with some moments with two subs displayed simultaneous)
file : 570 mb
link : http://www.zshare.net/download/9519883738674ed5/

[haruhiko_yamagata]

Here the example (2 min with some moments with two subs displayed simultaneous)
file : 570 mb
link : http://www.zshare.net/download/9519883738674ed5/
I've got two files and reproduced both issues. Please wait a week or two.:)

[mini-moose]

I'm sure this has been asked before but I didn't quite find a definite answer.

ffdshow has 2 decoding options for VC-1: libavcodec and wmv9.

Is one of them recommended over the other?

another thing, I've noticed frameserving using ffdshow/wmv9 via avisynth (directshowsource("vid.m2ts, audio=false) loaded on virtualdub shows a lot of glitches which are not present once the script is actually being used for transcoding to x264. Granted, I've used a relatively older version of ffdshow (rev3886) so I'm yet to try a newer version (maybe that's the cause).

[Atak_Snajpera]

wmv9 supports interlaced decoding. on libavcodec you will see black screen.

[mini-moose]

wmv9 supports interlaced decoding. on libavcodec you will see black screen.

thanks Atak_Snajpera. and other than that? assuming most of the
videos I watch or backup to x264 are progressive and not interlaced?

[the_weirdo]

assuming most of the
videos I watch or backup to x264 are progressive and not interlaced?

That means your videos are in H.264/AVC format and have nothing to do with VC-1, so you don't need to worry about it.

[mini-moose]

That means your videos are in H.264/AVC format and have nothing to do with VC-1, so you don't need to worry about it.

that's incorrect. there are lots of 24p VC-1 blurays.

[the_weirdo]

that's incorrect. there are lots of 24p VC-1 blurays.

Sorry, I misunderstood. I thought you mean your encoded videos.

Note to self: Need to read more carefully.

[carlmart]

I am having a hard time finding out which codecs to install with Windows 7 64-bit. Some advice there would be infinitely valuable.

I read that ffdshow, which is 32-bit only, has to be enabled precisely for every video codec. I also wonder about matroska.

What would you recommend?

[Keiyakusha]

I am having a hard time finding out which codecs to install with Windows 7 64-bit. Some advice there would be infinitely valuable.
Of course you should only install the ones you need.
There is 64bit ffdshow. however not sure if it works well...

[carlmart]

Of course you should only install the ones you need.
There is 64bit ffdshow. however not sure if it works well...

Well, what I need are video codecs, that cab work with avi, mkv, etc.

Right now I have a problem with Subtitle Workshop which I can't make to show a video image. That was usually related with video codecs, but I installed ffdshow (32bit) and nothing. I couldn't find a 64 bit version.

[kirakami]

ffdshow doesn't output Hi10p videos to p010
only to YV12 (converts 10bits to 8bits before it hits display) :(
is there any plans on adding p010/p016 output in future?

[haruhiko_yamagata]

Maybe in the future, if my motivation persists long enough.

[dukey]

Is it possible to get hardware acceleration without outputting a DXVA output pin ? So renderers like haali and madrv can be used ?

xbmc does something like this

[haruhiko_yamagata]

Technically it is possible. But sorry, as for me, I have no plan for now.

[egur]

Is it possible to get hardware acceleration without outputting a DXVA output pin ? So renderers like haali and madrv can be used ?

xbmc does something like this

This is what I've done with my ffdshow-quicksync project.
It will only work (well) on the latest Intel GPU (SandyBridge - 2nd Generation Core i3/5/7 2xxx). Will work on future Intel CPUs as well.
Can be combined with a renderer working on a discrete GPU.
My code copies the image back to system memory for normal SW processing.
Code is quite stable and needs integration into ffdshow's main trunk. On my immediate todo list.

Adding non-DXVA output to the DXVA flavor of ffdshow can use my code as reference. Should be quite simple.

Check it out at:
http://forum.doom9.org/showthread.php?t=162442

[nevcairiel]

The problem is that such copying actions are dead slow on ATI/AMD cards, and on NVIDIA/Intel you can just use one of those other hardware decoders that do it by design anyway.

[madshi]

The problem is that such copying actions are dead slow on ATI/AMD cards, and on NVIDIA/Intel you can just use one of those other hardware decoders that do it by design anyway.
The standard hardware decoders that copy frames back to system RAM are probably too slow on Intel hardware, too, I think, at least if they use standard Direct3D surface reading. You can get things fast with Intel GPUs only by using specific Intel APIs, at least that was the case last time I checked. So there's a good chance that egur's implementation is (currently) the only one which is really able to do GPU decoding + copying back to system RAM in real time for Intel GPUs. @egur, please correct me if I'm wrong.

[nevcairiel]

As i understood it, its not using any special "API", its just using a special SSE4 instruction that was optimized for copying memory from such sources (http://software.intel.com/en-us/articles/increasing-memory-throughput-with-intel-streaming-simd-extensions-4-intel-sse4-streaming-load/)

[madshi]

Ah, ok, I didn't even know that SSE4 instruction.

[dukey]

The problem is that such copying actions are dead slow on ATI/AMD cards, and on NVIDIA/Intel you can just use one of those other hardware decoders that do it by design anyway.

I am actually an opengl programmer :p Uploading to graphics cards is typically highly optimised, even on ghetto ATI cards. The problem is often getting the data back out again, since this is not an optimised path. In order to get good performance you have to know the internal format of the texture and copy it out exactly. If the internal format is ABGR and you read out RGBA it'll hurt performance a lot.

nvidia has this handy chart ..
http://developer.nvidia.com/system/files/akamai/gamedev/docs/nv_ogl_texture_formats.pdf?download=1

[dukey]

I found some code I wrote 5 or some years ago for a company. Captures real time stereo video, HD resolution * 2.

glReadPixels (offsetX,offsetY,videoWidth,videoHeight,GL_BGR_EXT,GL_UNSIGNED_BYTE,buffer);
glReadPixels (offsetX+tempXOffset,offsetY+tempYOffset,videoWidth,videoHeight,GL_BGR_EXT,GL_UNSIGNED_BYTE,buffer + (videoWidth*videoHeight*3));

aviCapture->captureFrame(buffer);

with a byte alignment of 4 bytes. I think I cropped the resolution so it was mod 16. I could capture dual HD RGB + encode it in real time on ATI and Nvidia cards. The pixel format makes a lot of difference.

[madshi]

@dukey, here are benchmarks from an ATI 5700 GPU on win7 x64:

DXVA Surface speed test:
NV12: upload 254 fps, download 4 fps
YV12: upload 255 fps, download 4 fps
A8R8G8B8: upload 272 fps, download 2 fps

A8R8G8B8 Texture speed test:
default: upload 109 fps, download 217 fps
dynamic: upload 304 fps, download 2 fps

All the "downloads" are 1:1 without any format change. As you can see, the results differ a lot, depending on resource type (Surface / Texture) and on allocation type (DXVA / D3D9, default/dynamic pool). The general result is, though, that NV12 downloads are painfully slow with ATI cards, and that's exactly what you need if you want to download untouched DXVA decoding results to CPU RAM. The download in my benchmark was *not* done via SSE4, though, so probably that would speed things up.

For comparison here are results from a GTX 295 in win7 x64:

DXVA Surface speed test:
NV12: upload 458 fps, download 593 fps
YV12: upload 729 fps, download 205 fps
A8R8G8B8: upload 345 fps, download 201 fps

A8R8G8B8 Texture speed test:
default: upload 191 fps, download 314 fps
dynamic: upload 211 fps, download 30 fps

[dukey]

That's really unusually slow. From what I recall with nvidia, if you ask for a RGBA texture, it's actually laid out ABRG in memory. So if you read out ABRG it's fast, where as if you read out RGBA it's painfully slow. ABRG matches the windows pixel format. I guess that explains

A8R8G8B8: upload 272 fps, download 2 fps

and

A8R8G8B8 Texture speed test:
default: upload 109 fps, download 217 fps

My guess is the graphics card is converting NV12 to a different format internally, then doing software conversion when you read it back.
With my own opengl renderer, I split NV12 into a luminance texture for (Y), and a luminance alpha texture for (UV).

[hoborg]

@madshi:
Just for info, did you have any results from AMD FUSION APUs?

[madshi]

That's really unusually slow.
FWIW, I've about 40 benchmark results for ATI and also 40 for NVidia from different users. They all pretty much say the same thing.

From what I recall with nvidia, if you ask for a RGBA texture, it's actually laid out ABRG in memory. So if you read out ABRG it's fast, where as if you read out RGBA it's painfully slow. ABRG matches the windows pixel format. I guess that explains [...]
I don't think so in this case. I've allocated all RGB resources in exactly the same format, just with different pool flags. The difference is probably caused by whether the resource is allocated in GPU RAM or in PCIe RAM or something like that.

My guess is the graphics card is converting NV12 to a different format internally, then doing software conversion when you read it back.
Software conversion would be much faster than 4fps, unless they use interpreted Visual Basic code... :p

With my own opengl renderer, I split NV12 into a luminance texture for (Y), and a luminance alpha texture for (UV).
I do that, too, in madVR. But you cannot tell DXVA to do that. The DXVA output is an NV12 surface and there's no way to properly split it into separate Y/UV textures on the GPU (except by using CUDA). Unfortunately ATI offers no OpenCL / Direct3D9 interop, so for ATI cards we're simply out of luck.

Just for info, did you have any results from AMD FUSION APUs?
I'm not sure, maybe. If I have, they're pretty old. But it doesn't really matter, anymore. Not to me, at least.

[haruhiko_yamagata]

@ikarad and who are interested in subtitles,

[FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv
"Complex karaoke", one of the two embedded ASS subtitles, uses \t. Current ffdshow does not have \t implementation. Please wait until it is implemented.

[Rising_Sun]_Chihayafuru_-_01_[HDTV_-_720p_-_H264_-_AAC][9130C84A].mkv
The script has \pos and \move in the same line. Bug fixed.
The script has {\1aH&99&}, which is a typo of {\1a&H99&}. Fixed anyway.

1.m2ts
PGS crashes: The bug was hidden temporally. It no longer crashes.

_utw_ fate stay night - unlimited blade works _bd__h264-720p ac3__70764ba9_.ass
Positioning bug fixed.

A test build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4018_20111104_branch.exe)

[ikarad]

@ikarad and who are interested in subtitles,

[FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv
"Complex karaoke", one of the two embedded ASS subtitles, uses \t. Current ffdshow does not have \t implementation. Please wait until it is implemented.

[Rising_Sun]_Chihayafuru_-_01_[HDTV_-_720p_-_H264_-_AAC][9130C84A].mkv
The script has \pos and \move in the same line. Bug fixed.
The script has {\1aH&99&}, which is a typo of {\1a&H99&}. Fixed anyway.

1.m2ts
PGS crashes: The bug was hidden temporally. It no longer crashes.

_utw_ fate stay night - unlimited blade works _bd__h264-720p ac3__70764ba9_.ass
Positioning bug fixed.

A test build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4018_20111104_branch.exe)
Thanks, I am going to try.

I expect that your correct pgs crash definitively if you can and the problem with complex karaoke.

But one problem: deband filter doesn't work with your version.
Clsid had correct this bug before because it was compiler that make a problem with deband filter
Those changes are required to compile with 4.5.3.
4.6.1 gives broken deband.

[alexins]

Thanks, I am going to try.

I expect that your correct pgs crash definitively if you can and the problem with complex karaoke.

But one problem: deband filter doesn't work with your version.
Clsid had correct this bug before because it was compiler that make a problem with deband filter.

Originally Posted by clsid
Those changes are required to compile with 4.5.3.
4.6.1 gives broken deband.


gcc 4.6.2 gives working deband :D

[Midzuki]

gcc 4.6.2 gives working deband :D

Great :) :) :)

@ betaking - have you read this? ;) :rolleyes:

[ikarad]

@ikarad and who are interested in subtitles,


I think I find another bug with sub renderer.
I try your test build and with mpc sub renderer I have this at 18"25
http://img11.hostingpics.net/thumbs/mini_150933mpc.jpg (http://www.hostingpics.net/viewer.php?id=150933mpc.jpg)

With ffdshow I have this
http://img11.hostingpics.net/thumbs/mini_793494ffdshow.jpg (http://www.hostingpics.net/viewer.php?id=793494ffdshow.jpg)

file here:http://www.nyaa.eu/?page=torrentinfo&tid=256116

[haruhiko_yamagata]

@alexins
Thanks, I'll get 4.6.2.

@ikarad
Thank you for testing.
[Hiryuu] Maken-Ki! 04 [Hi10P 1280x720 H264] [D6466060].mkv uses \t as well.
The implementation is hard, but planed in the near future.

[Infernodash]

Is it possible to enable the deinterlacing and debanding options in ffdshow raw filter while using lav video decoder? When I play 8 bit files the filters applies, however, it dithers my 10bit files to 8bit. I want the filter to only apply to 8bit files. Is there a way to do that and maintain 10bit playback?

Edit: I am using MPC-HC, MadVR, Haali Splitter, LAV Audio and Video decoders, as well as ffdshow raw filter.

[betaking]

Great :) :) :)

@ betaking - have you read this? ;) :rolleyes:

OK.so i wait 4.6.2 Stable Release now!:D

[Keiyakusha]

Infernodash
no, ffdshow doesn't supports 10bit output so you can't maintain it.
Also ffdshow's deband filter is very crappy and broken, unlikely it will ever support 10bit. Instead someone needs to port new good and shiny solutions from avisynth :P

[ikarad]

@alexins
Thanks, I'll get 4.6.2.

@ikarad
Thank you for testing.
[Hiryuu] Maken-Ki! 04 [Hi10P 1280x720 H264] [D6466060].mkv uses \t as well.
The implementation is hard, but planed in the near future.

Thanks
I find a bug with your version (bug is not present with ffdshow3984)

At 2"20, video crash all the time if subs are selected on in ffdshow
video here: http://www.zshare.net/download/95645287c2805c9b/

[mini-moose]

the current builds of ffdhshow have ffmg-mt migrated into libavcodec. When I use ffdshow as directshowsource for x264 transcoding, the encode speeds are the same, however I noticed
that during first pass if I run other processes (for example eac3to) this slows down the encode speeds considerably which didn't happen with ffmpg-mt. Not sure why it would do that considering 1st pass only uses about 50% of cpu.

[haruhiko_yamagata]

Thanks
I find a bug with your version (bug is not present with ffdshow3984)

At 2"20, video crash all the time if subs are selected on in ffdshow
video here: http://www.zshare.net/download/95645287c2805c9b/
The crash was confirmed. Thank you.

[Infernodash]

Infernodash
no, ffdshow doesn't supports 10bit output so you can't maintain it.
Also ffdshow's deband filter is very crappy and broken, unlikely it will ever support 10bit. Instead someone needs to port new good and shiny solutions from avisynth :P

Thank you for your reply. I'm hoping there will be some new solutions ported over as well.

I will be reading this forum more often so I can stay abreast with all the developments happening. I felt absolutely lost when trying to figure out this problem last night.

[egur]

The standard hardware decoders that copy frames back to system RAM are probably too slow on Intel hardware, too, I think, at least if they use standard Direct3D surface reading. You can get things fast with Intel GPUs only by using specific Intel APIs, at least that was the case last time I checked. So there's a good chance that egur's implementation is (currently) the only one which is really able to do GPU decoding + copying back to system RAM in real time for Intel GPUs. @egur, please correct me if I'm wrong.

The fast GPU->CPU copy is done by using the MOVNTDQA instruction (SSE4.1). Also availble by using the intrinsic _mm_stream_load_si128.
Originally found in VLC's code.
There are two speedup tricks:
1) Source and target page offsets (12 lsb of addresses) should be 2K apart.
2) MSVC compiler uses a maximum of two xmm registers when using the intrinsic function. Some speed is gained by using all 8/16 registers by manually coding in ASM.

Performance is about 2x slower than using memcpy on system memory in SandyBridge.
Vtune showed that more time is spent locking the d3d surface than the actual copy...
Using this copy on older HW or to copy from a discrete GPU will give a significantly worse results as PCIe traffic is involved.
In SNB, memory and L3 cache is shared between the CPU and GPU, making this vopy operation a viable option.

Haven't tested this on Liano, should work well I guess.

It's very easy for me to export DXVA samples instead of simple memory buffers. I'll do it at a later stage.

Also need to submit my ffdshow fixes, hope to get to this done by end of the week.

[madshi]

Sounds quite good, thanks for the useful information!

[CruNcher]

This is current state of SB (GT1) on Aero with newest Driver 2509

Windows 7 x64 Service Pack 1
Intel(R) HD Graphics Family

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: lossy (0-0)

DXVA Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: StretchRect failed

DXVA Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: lossy (0-0)

D3D9 Surface speed test:
NV12: upload 275 fps, download 15 fps, trick download failed
YV12: upload 156 fps, download 20 fps, trick download failed
A8R8G8B8: upload 145 fps, download 7 fps, trick download failed

DXVA Surface speed test:
NV12: upload 302 fps, download 15 fps, trick download failed
YV12: CreateSurface failed
A8R8G8B8: CreateSurface failed

A8R8G8B8 Texture speed test:
default: upload 262 fps, download 143 fps
dynamic: upload 265 fps, download 10 fps, trick download 146 fps

Btw Mirillis Render implementation looks rocking it's damn performant (it's currently one of the lowest resource ones (8 Bit) i saw from the top 4 ISVs (Cyberlink,Corel,Nero,Arcsoft) on Windows only Potplayers Direct3D renderer comes close (still missing Shader PP though), Custom EVR is as heavy as MadVR on minimum) and needs very low resources on both GPU/CPU and also allows its shader PP to be used @ 1080p the same time (very amazing performance optimization using 70-80% of the GPU (Picture2,Detail Boost) compared to others who would overflow it with above 100% utilization (Sharpen Complex 2 @ Fullscreen) :) with Shader PP (Quality is comparable to Sharpen Complex 2 if not even better) it needs as much CPU as MadVR with anything turned down to a minimum (nearest neighbour ect) and GPU usage is still very good even on the highest PP Level (round about 70-80% @ Fullscreen :) (and they even render a very Graphical partly animated UI on top of this without any Performance slowdowns just amazing and Deinterlacing works without any Performance problems as the cream on top)
Though Recording the Players Output via Quick Sync is the most efficient currently with MadVR (from a Custom renderer stand, not EVR) :)

I wonder how much it will impact their Performance once they include 10 Bit Output Rendering though, but so far it looks excellent you don't see such a optimized piece of Software every day (Remembers about the early days of CoreCodec, only that CorePlayer never became reality in the form like Mirillis seems to did it) :) and that this is High optimized Multimedia Software from Poland, not bad (compared to all the Asian ISVs and even OSS like MPC-HC or non OSS private dev MadVR (which still has the stability advantage) ;)

Will be very interesting to see how they will crush Fraps and others with their Low Level knowledge :)

For those who are interested http://www.mediafire.com/download.php?lr93jn6pnut54bg a Quick Sync (Aero,DWM) Recording the Performance Counter update @ 500ms (adds additional stress)

@ Madshi
though this result blows in its own category (stability with the low latency timer running) http://www.mediafire.com/download.php?7uhdibw4i3r2jce :)

[ryrynz]

Infernodash
ffdshow's deband filter is very crappy and broken, unlikely it will ever support 10bit. Instead someone needs to port new good and shiny solutions from avisynth :P

I vote Flash3kyuu_deband.

[Keiyakusha]

I vote Flash3kyuu_deband.

I was thinking about it when I wrote that ^__^

[dimitrik]

Well, what I need are video codecs, that cab work with avi, mkv, etc.

Right now I have a problem with Subtitle Workshop which I can't make to show a video image. That was usually related with video codecs, but I installed ffdshow (32bit) and nothing. I couldn't find a 64 bit version.

To solve your subtitle workshop problem set Directvobsub in the "general->loading" settings from "always load" or "load when needed" to "do not load". The downside is that if you really want to use Directvobsub you need to switch it back on and off.

To find the 64bit ffdshow, try xvidvideo.ru
You can also go to codecguide.com to get the 64 bit k-lite codec pack which includes ffdshow and a couple of other essential tools to control the codecs on your system.

If you need more help, open a new thread though as this diverts from the current topic.

[LigH]

Do you remember in which revision you fixed MPEG-1 aspect ratio signalling?

After possibly years of annoyance with rare but extreme samples, I finally found enough time last weekend to make a bunch of test cases to report an issue (http://forum.gleitz.info/showthread.php?45184-MPEG1-Video-mit-verr%FCckten-Seitenverh%E4ltnissen-im-MPC-HC-via-ffdshow) with really crazy sample aspect ratios in different renderers for rather "exotic" MPEG-1 aspect ratio flags (from about 1:5 to 5:1); then I was told that xvidvideo.ru is active again, updated ffdshow after months ... and it appears to be fine now.

:thanks:

[egur]

As per my discussion with clsid, I've committed my integration work. The DLL's itself is in another SF project (svn:externals).
I merge to to head revision, in advance so the merge was trivial.

Here's the changelog:
Added support for Intel QuickSync Decoder:
* Add 2 files that load and manage the decoder.
* Added external reference to the IntelQuickSyncDecoder project on SF (qsdecoder).
* Changed installer files.
* Added fallback in some cases where the decoder would not init well.

Bug fixes & other changes:
* Fixed H264 SPS header crash.
* Fixed NV12->NV12 crash by not using swscale to perform the copy. Added SSE2 copy function to perform the task.
* Fixed crash when a NULL string was translated.
* Cleanup - removed missing files from projects files - caused unnecessary rebuilds.
* Changed FPS measurement so VFR clips show a more correct frame rate.

BTW, I did compile this build and tested it quite extensively but you should check it anyway.
The code changes to ffdshow's code base are very small.

[Atak_Snajpera]

clsid can you update your build at sourceforge?

[betaking]

@ Midzuki,I have uploaded last ffdshow svn built by msvc2010 and gcc 4.6.2 stable on my site! you can get it!
ps: big thanks for alexins!

[clsid]

Eric, the minimum requirement for ffdshow is MMX. Could you please add fallbacks were appropriate where SSE2/SSE4 is currently used?

[egur]

Eric, the minimum requirement for ffdshow is MMX. Could you please add fallbacks were appropriate where SSE2/SSE4 is currently used?

OK, no problem. Added just SSE2 copy within ffdshow. Can revert to memcpy.
SSE4 is only used within the QuickSync Deocder DLL and it can't be disabled internally (make no sense as this should only be used for SNB and newer CPUs).
What I can do is disable Quicksync altogether if SSE4 is not supported (disable from within ffdshow's code).

Update:
Done. Committed at revision 4032.

[Midzuki]

@ Midzuki,I have uploaded last ffdshow svn built by msvc2010 and gcc 4.6.2 stable on my site! you can get it!
ps: big thanks for alexins!

Many :thanks: for that :)

However don't forget, I am no one important :o ,

it's ikarad who always has the last word on the subject :D

[ikarad]

Many :thanks: for that :)

However don't forget, I am no one important :o ,

it's ikarad who always has the last word on the subject :D

What?

[Midzuki]

What?

http://forum.doom9.org/showthread.php?p=1536401#post1536401

I guess you need more cups of coffee per day ;) :p

[ikarad]

http://forum.doom9.org/showthread.php?p=1536401#post1536401

I guess you need more cups of coffee per day ;) :p

I don't know where is the problem.
I just say haruhiko_yamagata that with this test build, deband doesn't work and that clisd had a similar problem with the compiler.

It's all, no need coffee.

[egur]

OK, no problem. Added just SSE2 copy within ffdshow. Can revert to memcpy.
SSE4 is only used within the QuickSync Deocder DLL and it can't be disabled internally (make no sense as this should only be used for SNB and newer CPUs).
What I can do is disable Quicksync altogether if SSE4 is not supported (disable from within ffdshow's code).

Update:
Done. Committed at revision 4032.

Fix wasn't 100% (disabled QuickSync Decoder). please build revision 4033. Sorry for the mess.

[Midzuki]

I don't know where is the problem.

The problem is, you are seeing problems where they do not exist -.-

If your attention is not big enough to perceive the (very-obvious) reasons why I write what I write, well... -.-

[ikarad]

The problem is, you are seeing problems where they do not exist -.-

If your attention is not big enough to perceive the (very-obvious) reasons why I write what I write, well... -.-

Problem existed.

I don't understand where is your joke. Maybe a custom of your country :confused:

Sorry for my misunderstanding.

[haruhiko_yamagata]

A new build from the branch. (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4037_20111110_branch.exe)

Thanks to alexins, GCC 4.6.2 is used for the build. Deband should work now.

@ikard,
The crash has been fixed. The offending line triggered two other bugs. Three bugs has been fixed.

The build also contains Eric's QuickSync Decoder and ffdshow converters new feature, support for 10bit 420 YCbCr color space input.
Please give some trials on ffdshow converters vs swscale (quality and/or speed). In RGB conversion page, check/uncheck "High quality YV12 to RGB conversion".
Checked: ffdshow converter
Unchecked: swscale
Which do you like?

@Eric,
Great work! My only frustration is that I do not have sandy bridge. I'm not sure my build is working for your part.

[egur]

@Eric,
Great work! My only frustration is that I do not have sandy bridge. I'm not sure my build is working for your part.

Thanks :)
My build is pretty straight forward. No ICL12 option yet (I have a different version of the Intel compiler/composer and this produces a different project setting). Will Add ICL12 project in the near future.

BTW, please keep my decoder out ofthe defaults as it doesn't work in WMC fullscreen (can't create d3d device for surface allocation under fullscreen). This will probably mean a significant design change - postpone initialization till time of actual decode and have FFDShow pass the D3D9 device manager to my decoder... :(

[mandarinka]

This is not about comparing the converter to swscale, but I did some comparing of the HQ software RGB conversion (just with a plain 8-bit source) against the reportedly similar software converter in LAV video. It seems that comparing the outputs, there is some spatial shift of chroma. I took some pictures to illustrate the difference (taken with ffdshow's grab, for LAV video, I had it output rgb32 and set ffdshow to decode raw formats, allowing me to use grab with LAV video too).
Tested versions: ffdshow 4026, LAV video 0.38. (pc used: windows xp sp3 32bit, Athlon 64 cpu.)

http://screenshotcomparison.com/comparison/93625

I think the author of LAV video's converter mentioned some chroma position treatment difference in this post (http://forum.doom9.org/showthread.php?p=1521532#post1521532), there is more discussion of the converter there. In post 5056, Madshi responds on that too...

[haruhiko_yamagata]

Yes, there is some shift of chroma. ffdshow uses bilinear interpolation and chroma is positioned in the center of four luma pixels. 75:25 for both horizontally and vertically.
I know this is not the default of MPEG2, H.264, etc.
H.264 has the flag that defines the position of chroma. If many people want it to be used, I may consider implementing it.
In my opinion, it is hard to see the difference in motion. It may not be very important.

[mandarinka]

I see, thanks for the info.

[ikarad]

A new build from the branch. (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4037_20111110_branch.exe)

Thanks to alexins, GCC 4.6.2 is used for the build. Deband should work now.

@ikard,
The crash has been fixed. The offending line triggered two other bugs. Three bugs has been fixed.

Thanks.
Have you succeed to implement \t ?

[haruhiko_yamagata]

Thanks.
Have you succeed to implement \t ?
Not yet. It will take a month or longer.
I'm implementing scroll/banner. It requires spatial fading, which is taking longer time than expected.

[haruhiko_yamagata]

Eric, the minimum requirement for ffdshow is MMX. Could you please add fallbacks were appropriate where SSE2/SSE4 is currently used?
clsid,
The wiki (http://ffdshow-tryout.sourceforge.net/wiki/faq:builds)says ffdshow supports Pentium Pro. Is MMX required? I agree that it is pointless to support non-MMX CPUs. Should I update the wiki?

Eric,
Any troubles fixing CPU detection? Can I help you?

[clsid]

Yes, MMX is required.

I was thinking of making two builds for next release, one MMX and one SSE, and then continue with just SSE from there.
A good time for a release would be after Eric's work is finished and tested, and maybe (some of) your subtitle improvements have been merged.

Are you using VS2010? If so, the VS2008 projects could be removed as nobody here uses them anymore.

[_xxl]

Please remove old VS2008. How faster is SSE version?

[haruhiko_yamagata]

Then, for generic builds, Pentium II / Athlon are minimum requirement, aren't they?
I have updated the wiki.
And yes, "Pentium III or newer" is a good candidate for the near future release.

I'm using VS2010 trial version. OK, I'll buy one.

[haruhiko_yamagata]

Is anyone using GCC 4.5.x? Can we migrate to GCC 4.6.2?
Is this patch OK?
Index: src/ffmpeg/config.h
===================================================================
--- src/ffmpeg/config.h (revision 4043)
+++ src/ffmpeg/config.h (working copy)
@@ -43,8 +43,8 @@
#define ASMALIGN(ZEROBITS) ".p2align " #ZEROBITS "\n\t"

#if ARCH_X86_64
- #define EXTERN_PREFIX "_"
- #define EXTERN_ASM _
+ #define EXTERN_PREFIX ""
+ #define EXTERN_ASM
#else
#define EXTERN_PREFIX "_"
#define EXTERN_ASM _
Index: src/makefile_c.inc
===================================================================
--- src/makefile_c.inc (revision 4043)
+++ src/makefile_c.inc (working copy)
@@ -12,8 +12,8 @@
TARGET_OS=x86_64-w64-mingw32
CFLAGS+=-DWIN64 -D_WIN64 -D__MINGW64__
OPTFLAGS+=-O2 -m64
- YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64 -DPREFIX
- LDFLAGS+=--entry=_DllMainCRTStartup@12
+ YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64
+ LDFLAGS+=--entry=DllMainCRTStartup@12
else
TARGET_OS=i686-w32-mingw32
CFLAGS+=-DWIN32 -D_WIN32 -D__MINGW32__
@@ -22,7 +22,7 @@
endif

CFLAGS+=-mdll -mthreads -pipe
-OPTFLAGS+=-fno-common -fno-tree-vectorize
+OPTFLAGS+=-fno-common
CPPFLAGS+=-fno-rtti
OUTPUTFLAG=-MMD -o\

@@ -31,8 +31,6 @@
YASMFLAGS+=-g cv8
else
CFLAGS+=-DNDEBUG -UDEBUG
- OPTFLAGS+=-fomit-frame-pointer
- LDFLAGS+=-s
endif

ifeq ($(EXCEPTIONS),1)

[egur]

Yes, MMX is required.

I was thinking of making two builds for next release, one MMX and one SSE, and then continue with just SSE from there.
A good time for a release would be after Eric's work is finished and tested, and maybe (some of) your subtitle improvements have been merged.

Are you using VS2010? If so, the VS2008 projects could be removed as nobody here uses them anymore.

Maybe it's time to drop MMX altogether... It's inferior to SSE2 and I would be very surprised if there are functional platforms that don't have SSE2 - anyway they couldn't play any 720p+ content. I had a P4 system that could barely play 720p (w/o any processing).

My initial integration work is finished and it was tested quite a lot.
I'm aware of some issues:
Will not work under WMC fullscreen because I need to get the D3D device manager from the renderer otherwise I can't allocate surfaces. WMC users will not be able to use the HW acceleration. This will be fixed in a week or two and require some modifications on both my decoder (late initialization) and small ffdshow changes (pass the d3d device manager to the internal decoder so the only usable D3D device in fullscreen exclusive can be used to allocate surfaces). Other players that use full screen playback seem to work fine.

Another thing that needs to be done is the ability (config option) to fail the pin connection if HW acceleration isn't supported and allow another filter to become the decoder. Alternatively, ffdshow will select the default internal decoder. This feature's reasoning is to allow LAV decoder handle 10 bit formats as it outputs 10/16 bits.

Both these changes are not show stoppers for a release.

Oh, I also need to provide an ICL12 project build although it's not critical - can build my DLL with VC2010 like in the VS2010 solution. The ICL build will probably improve nothing so it's a low priority issue.
I would also like to spend a little time on cleaning up the hundreds of warning during ffdshow's build so new issues are quickly caught.

[dann23]

Is it possible to make ffdshow compatible with media foundation? I'm thinking especially at the subtitle part.

[_xxl]

Maybe it's time to drop MMX altogether... It's inferior to SSE2 and I would be very surprised if there are functional platforms that don't have SSE2 - anyway they couldn't play any 720p+ content. I had a P4 system that could barely play 720p (w/o any processing).
There are millions of old SSE only cpu's... this from my experience with some customers that still have old PC's. Only MMX I don't see to often...

[haruhiko_yamagata]

Is it possible to make ffdshow compatible with media foundation? I'm thinking especially at the subtitle part.
Of course it is possible. It's just very hard. As for me, I'm not sure if I'm going to do it.

[Px]

Then, for generic builds, Pentium II / Athlon are minimum requirement, aren't they?
Pentium III or Athlon XP, original Athlons doesn't have sse support

[fastplayer]

And yes, "Pentium III or newer" is a good candidate for the near future release.
Please don't bump CPU requirements unless there are significant benefits. Lots of SSE-only CPUs like Athlon XP are perfectly capable of playing 720p content.
I'm using VS2010 trial version. OK, I'll buy one.
You might wanna try C++ 2010 Express:
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express

[haruhiko_yamagata]

Pentium III or Athlon XP, original Athlons doesn't have sse support
We only need MMX. But Pentium MMX does not work, Pentium II should work. If I remember correctly, some instructions have been added between Pentium MMX and Pentium Pro. Unfortunately Pentium Pro does not have MMX, and so Pentium II is required.

[haruhiko_yamagata]

Please don't bump CPU requirements unless there are significant benefits. Lots of SSE-only CPUs like Athlon XP are perfectly capable of playing 720p content.
In my opinion, SSE-only CPUs should not be dropped for the time being. MMX only CPUs may be dropped in the near future.

You might wanna try C++ 2010 Express:
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express
Thank you. I have not tried it for ffdshow yet, but last time I tried it for MPC-HC, it didn't work. I have to compile and trace MPC-HC, so I need the professional version.

[fastplayer]

In my opinion, SSE-only CPUs should not be dropped for the time being. MMX only CPUs may be dropped in the near future.
Sounds good to me!
Thank you. I have not tried it for ffdshow yet, but last time I tried it for MPC-HC, it didn't work. I have to compile and trace MPC-HC, so I need the professional version.
I had successfully build ffdshow with the Express edition months ago (even though its functionality is quite limited). I'm not sure if it's still possible...
Here's a link which compares the Visual Studio editions:
http://msdn.microsoft.com/en-us/library/hs24szh9.aspx

[haruhiko_yamagata]

I had successfully build ffdshow with the Express edition months ago (even though its functionality is quite limited).
Good news for someone who don't want to buy MSVC.:)

[fastplayer]

Good news for someone who don't want to buy MSVC.:)
There's even better news if you're a student because then you get the latest Visual Studio Professional edition and lots of other MS software for free: https://www.dreamspark.com/

[fastplayer]

Haruhiko,
currently ffdshow uses the threadpool library which itself depends on Boost. nevcairiel found an alternative for his RGB converter in LAVFilters: Parallel Patterns Library (PPL) (http://msdn.microsoft.com/en-us/library/dd492418.aspx)
Maybe ffdshow can take advantage of this library too and get rid of the Boost dependency?

[Superb]

My guess is that 3765 caused the new crash regression (is has to do more w/ colorspace stuff), but I can't be sure unless someone provides me w/ 3764 compilation.Just popped by to verify that rev4043 doesn't have the crash issue anymore. Probably due to egur's patches, if I had to guess. Thx for all the work. I can finally use the latest ffdshow revision again.

[haruhiko_yamagata]

Haruhiko,
currently ffdshow uses the threadpool library which itself depends on Boost. nevcairiel found an alternative for his RGB converter in LAVFilters: Parallel Patterns Library (PPL) (http://msdn.microsoft.com/en-us/library/dd492418.aspx)
Maybe ffdshow can take advantage of this library too and get rid of the Boost dependency?Thanks for the info. PPL seems to be a similar library to threadpool.
I introduced boost to learn about it and the next version of C++ (C++11). Actually it has been too difficult for me to fully understand. I'm only using its thread and BOOST_FOREACH.
Still the dependency is deep and hard to remove.

[haruhiko_yamagata]

Just popped by to verify that rev4043 doesn't have the crash issue anymore. Probably due to egur's patches, if I had to guess. Thx for all the work. I can finally use the latest ffdshow revision again.
Good news.
Speaking of rev 3765, RGB24 has been removed from the output color spaces. But isn't it necessary to interact with VFW codecs?

[clsid]

You can re-add RGB24 if you think it is needed.

[haruhiko_yamagata]

OK, I'll re-add RGB24.

[haruhiko_yamagata]

NV12 input has been disabled at rev3985. It seems to work now. Maybe fixed at rev4029?
Index: src/settings/TglobalSettings.cpp
===================================================================
--- src/settings/TglobalSettings.cpp (revision 4054)
+++ src/settings/TglobalSettings.cpp (working copy)
@@ -808,8 +808,8 @@
FF_FOURCC1_OP(411P,(rawv==1 || rawv==2 || rawv==FOURCC_411P)& dxvamask,CODEC_ID_411P) \
FF_FOURCC1_OP(Y41B,(rawv==1 || rawv==2 || rawv==FOURCC_Y41B)& dxvamask,CODEC_ID_411P) \
FF_FOURCC1_OP(410P,(rawv==1 || rawv==2 || rawv==FOURCC_410P)& dxvamask,CODEC_ID_410P) \
- /*FF_FOURCC1_OP(NV12,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV12)*/ \
- /*FF_FOURCC1_OP(NV21,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV21)*/ \
+ FF_FOURCC1_OP(NV12,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV12) \
+ FF_FOURCC1_OP(NV21,(rawv==1 || rawv==2 || rawv==FOURCC_NV12)& dxvamask,CODEC_ID_NV21) \
/* exotic */ \
FF_FOURCC_OP (MP4S,mp4v & rawmask & dxvamask,c_mpeg4) \
FF_FOURCC_OP (SEDG,mp4v & rawmask & dxvamask,c_mpeg4) \

[clsid]

If that bug was fixed then of course it should be re-enabled. Please test in combination with LAV Video.

[mandarinka]

Edit: Just after posting the following, I realised that the video was encoded with 10bit build of x264, which means that the issue is caused by the swscale conversion from 10bit yuv in the build used. If that is the case then I think it can be disregarded, as long as the new 10bit to rgb code is used for grabbing and as long as it switches colormatrix properly. I won't get to testing newer builds for now myself I'm afraid.
Sorry for teh chaotic report.

Doing something with grab, (I think) I noticed another issue with the color conversion. I'm afraid I didn't have much time to poke it further,
so this will be just a brief report for all that is worth.

Taking screens of a 960x720 h.264 video ripped from a bluray source with ffdshow's grab while having LAV video decoding with forced rgb32 output
enabled, I was getting different results than from grabbing with ffdshow decoding itself.
I tried all three colormatrix options in the rgb conversion menu (bt709, bt601 and auto based on resolution), and all of them have the same
color balance (different from LAV video rgb result), meaning that the same colormatrix was used each time, despite me switching... If I use ffdshow
for decoding and force rg32 output teh situation is the same, switching bt709/bt601 has no effect.

I didn't know how to quickly figure which coeficients were actually used and if LAV video got it right. It seems to me though that LAV video used
the same as my gpu's rendering used (Radeon x700 with 10.2 driver, win xp sp3 32bit, Athlon 64 cpu). In any case, it seems that neither switching
based on resolution, nor manual switching of colormatrix does work ATM.

This was observed on revision 3996 (what is shipped with last version of CCCP).

Images (color converters used specified in filename, all taken with ffdshow's grab as described above):

http://img696.imageshack.us/img696/6605/yyhffdshowauto.png
http://img192.imageshack.us/img192/5426/yyhffdshowforcebt601.png
http://img706.imageshack.us/img706/7852/yyhffdshowforcebt709.png
http://img190.imageshack.us/img190/6389/yyhlavvideo.png

[haruhiko_yamagata]

Edit: Just after posting the following, I realised that the video was encoded with 10bit build of x264, which means that the issue is caused by the swscale conversion from 10bit yuv in the build used. If that is the case then I think it can be disregarded, as long as the new 10bit to rgb code is used for grabbing and as long as it switches colormatrix properly. I won't get to testing newer builds for now myself I'm afraid.
Sorry for teh chaotic report.
The latest version should work.
Thank you for giving me the opportunity to advertise the latest version.

[haruhiko_yamagata]

If that bug was fixed then of course it should be re-enabled. Please test in combination with LAV Video.It worked if no video filter was used. I found Cb and Cr were swapped for video filters. I had to remove NV21 to fix the bug without messing the source code too much. If anybody need NV21, please tell me, it's not too hard to restore.

[TheRyuu]

There are millions of old SSE only cpu's... this from my experience with some customers that still have old PC's. Only MMX I don't see to often...

It's 2011, anything remotely new has SSE2. x87 needs to go die.

[clsid]

Forcing the compiler to use a certain instruction set has little benefit in the case of ffdshow. We have already tested that in the past. Going from MMX to SSE has a very tiny performance gain, going from SSE to SSE2 has almost no gain. The move to SSE will be made.

Before any n00bs misunderstand the above: performance critical parts in ffdshow and its decoders are already hand optimized and use MMX/SSE/SSE2/SSSE3/SSE4/etc whenever possible. Those optimized code parts are used only when the CPU supports it and impose no additional requirements on the CPU.

[Chikuzen]

Is anyone using GCC 4.5.x? Can we migrate to GCC 4.6.2?
Is this patch OK?
The problem(name mangling behavior) is not based on the version of gcc and based on the difference in mingw and mingw-w64.
I think that you should not take such a way.

I sent a patch to xvid-devel ML about the same problem.
(This refers to the method which x264 took)
http://list.xvid.org/pipermail/xvid-devel/2011-September/006341.html

I think that this is better solution than yours.

[haruhiko_yamagata]

The problem(name mangling behavior) is not based on the version of gcc and based on the difference in mingw and mingw-w64.
I think that you should not take such a way.

I sent a patch to xvid-devel ML about the same problem.
(This refers to the method which x264 took)
http://list.xvid.org/pipermail/xvid-devel/2011-September/006341.html

I think that this is better solution than yours.
Thanks for the info.
I'm afraid we do not use autoconf. We have fixed makefiles. We simply do not want to use our time to support various versions of compilers.

[TheRyuu]

The move to SSE will be made.

Hasn't it used SSE since forever? Several parts won't even compile without sse enabled (kerneldeint, tomsmocomp, libmpeg2).

[clsid]

Those are non-essentials parts and the SSE requirement only applies when using GCC for compiling them. They compile fine with MSVC, which is the default.

[_xxl]

If I remember correctly almost critical parts are optimized by hand written code "asm". Why to force SSE ? There are some parts that won't compile without SSE... with MinGw GCC.

[ikarad]

I have a problem with ffdshow 4079 (same problem with 4072)

If I check nv 12 8bit and po10 output and see 8bit movie. I have no problem.
http://img15.hostingpics.net/thumbs/mini_1424168bit8bit.jpg (http://www.hostingpics.net/viewer.php?id=1424168bit8bit.jpg)

If I check only po10 and see 8bit movie.ffdshow select 10 bit
http://img15.hostingpics.net/thumbs/mini_6310698bit10bit.jpg (http://www.hostingpics.net/viewer.php?id=6310698bit10bit.jpg)

If I check only po10 and see 10bit movie. ffdshow select 10 bit
http://img15.hostingpics.net/thumbs/mini_91000310bit10bit.jpg (http://www.hostingpics.net/viewer.php?id=91000310bit10bit.jpg)

If I check 8bit and po10 output and see 10bit movie. I have the problem. ffdshow select 8 bit
http://img15.hostingpics.net/thumbs/mini_61706410bit8bit.jpg (http://www.hostingpics.net/viewer.php?id=61706410bit8bit.jpg)

Why ffdshow don't select the best output like with lav video?

[haruhiko_yamagata]

If I check 8bit and po10 output and see 10bit movie. I have the problem. ffdshow select 8 bit

Why ffdshow don't select the best output like with lav video?
If any image filters including subtitles are enabled ffdshow has to convert the image to 8 bit before processing. In that case, it is reasonable to output 8bit.
If only Resize is checked ffdshow outputs 10 bit, but it doesn't seem to be doing 10 bit native scaling.

[ikarad]

If any image filters including subtitles are enabled ffdshow has to convert the image to 8 bit before processing. In that case, it is reasonable to output 8bit.
If only Resize is checked ffdshow outputs 10 bit, but it doesn't seem to be doing 10 bit native scaling.

Is it not possible to enable sub renderer without stay at 10bit?

If I use mpc-hc sub renderer, video stay at 10 bit.

Can you make that filter can be used with 10 bit video without converting to 8bit? Is it possible or not?

[haruhiko_yamagata]

Is it not possible to enable sub renderer without stay at 10bit?

If I use mpc-hc sub renderer, video stay at 10 bit.

Can you make that filter can be used with 10 bit video without converting to 8bit? Is it possible or not?
I plan to implement RGB64 output and subtitles renderer for it.
Improving YV12 subtitles renderer is low priority for me. I have no plan to write subtitles renderer for P010/P016.

Unless you have 10-bit enabled video card and monitor, the recommended setting for 10-bit video stream with subtitles is RGB32 output (you may want a good CPU). ffdshow's subtitles in YV12 is not very good.

[haruhiko_yamagata]

In "Output" page in ffdshow decoder's dialog, there is "DV" check box.
It is meant to encode the output in DV like ffdshow audio can encode the output in AC3.
Has anybody ever seen it working?
I think it has been broken for years (maybe I broke it?).
I'm going to remove it. Anybody who want the feature back?

[ikarad]

I plan to implement RGB64 output and subtitles renderer for it.
Improving YV12 subtitles renderer is low priority for me. I have no plan to write subtitles renderer for P010/P016.

Unless you have 10-bit enabled video card and monitor, the recommended setting for 10-bit video stream with subtitles is RGB32 output (you may want a good CPU). ffdshow's subtitles in YV12 is not very good.
With rgb32, madvr doesn't work. With nv12 or YV12, mad vr works

RGB32
http://img15.hostingpics.net/thumbs/mini_482396Sanstitre.jpg (http://www.hostingpics.net/viewer.php?id=482396Sanstitre.jpg)

NV12 or YV12
http://img15.hostingpics.net/thumbs/mini_197490Sanstitre.jpg (http://www.hostingpics.net/viewer.php?id=197490Sanstitre.jpg)

It works with RGB24. The problem occurs with only RGB32

[haruhiko_yamagata]

@ikarad, it's not ffdshow's fault anyway. Sorry I can't target your hardware.

[ikarad]

@ikarad, it's not ffdshow's fault anyway. Sorry I can't target your hardware.

geforce gtx285 (same problem), vista 32 sp2.

Yes, I agree with you but I can't use rgb32 for this moment. What is the differences between rgb24 and rgb32? The quality is similar or not?

[haruhiko_yamagata]

If the output color space is RGB24, ffdshow's subtitles filter convert the image to RGB32, draw subtitles and after that, the output filter converts RGB24 to RGB32. So the quality is fine, just slower than RGB32 output.

[crl2007]

Hi, I have a problem that started a couple of hours ago. I use Stereoscopic Player for 3D movies and until today it worked ok with ffdshow subtitle filter. Now, all of a sudden, if I put ffdshow subtitle filter as video processor, the player just closes. No error, nothing. Also, I can't seem to make the subtitle display on the black borders. They always appear above the black bars. What's the setting for lowering subtitles on the black borders ? I ticked "Process whole image" but nothing. Thanks in advance.

[mandarinka]

Outputting rgb32 (with HQ conversion of course) is probably a good choice if one is going to use vsfilter for rendering, too.
With that though, I'm starting to feel more regret about that chroma position thing. Life's so complicated! :)

Edit: Oh, somewhat related question - do the software scalers in ffdshow work with rgb video (when for example, another decoder outputting rgb is used first), or do they also force a conversion to yv12, like (some of) the other filters?

[fastplayer]

Haruhiko, would a fix for the chroma shift require a lot of effort?

[clsid]

In "Output" page in ffdshow decoder's dialog, there is "DV" check box.
It is meant to encode the output in DV like ffdshow audio can encode the output in AC3.
Has anybody ever seen it working?
I think it has been broken for years (maybe I broke it?).
I'm going to remove it. Anybody who want the feature back?I don't mind if it gets removed.

[haruhiko_yamagata]

Hi, I have a problem that started a couple of hours ago. I use Stereoscopic Player for 3D movies and until today it worked ok with ffdshow subtitle filter. Now, all of a sudden, if I put ffdshow subtitle filter as video processor, the player just closes. No error, nothing.Did you update ffdshow recently? Did you try older version?
Also, I can't seem to make the subtitle display on the black borders. They always appear above the black bars. What's the setting for lowering subtitles on the black borders ? I ticked "Process whole image" but nothing. Thanks in advance.
If the black bar is added by ffdshow, it should work. Is "Letterbox" in Subtitle placement page checked?

[haruhiko_yamagata]

Haruhiko, would a fix for the chroma shift require a lot of effort?
No, it wouldn't. Just a few lines if I do not care about MPEG-1.:)

[haruhiko_yamagata]

I don't mind if it gets removed.
Thanks for reply. I'll wait until tomorrow and if nobody wants the feature, I'll remove it.

[crl2007]

Did you update ffdshow recently? Did you try older version?

If the black bar is added by ffdshow, it should work. Is "Letterbox" in Subtitle placement page checked?


I tried older versions too. I checked letterbox too. It's just a normal 2.35:1 HD movie.

[haruhiko_yamagata]

I tried older versions too. I checked letterbox too. It's just a normal 2.35:1 HD movie.
If the crash does not depend on version of ffdshow, and the crash started recently, it may be Windows update, video/audio driver update or malfunction of your hardware. Similar problem is reported here (https://sourceforge.net/projects/ffdshow-tryout/forums/forum/597594/topic/4838949).
To control the position of subtitles, use slider in Subtitles placement page. If the subtitles are SSA/ASS, "Override SSA/ASS positioning ..." may help, but not recommended.

[haruhiko_yamagata]

Edit: Oh, somewhat related question - do the software scalers in ffdshow work with rgb video (when for example, another decoder outputting rgb is used first), or do they also force a conversion to yv12, like (some of) the other filters?
Reading the code, it seems to convert to YUV 4:4:4 and scale. it's not ideal, but not too bad.

[haruhiko_yamagata]

@clsid,
Was High 4:2:2 Profile of H.264 added at rev 4089? Does it support 10-bit?
Do you have any samples?

[_xxl]

I'm going to remove it.
Please do it. I prefer less but safe.

[clsid]

@clsid,
Was High 4:2:2 Profile of H.264 added at rev 4089? Does it support 10-bit?
Do you have any samples?
Yes, libavcodec now supports 4:2:2 8/10bit. But it is disabled in ffdshow because it can not handle the relevant colorspaces yet. I don't have any samples.

[crl2007]

If the crash does not depend on version of ffdshow, and the crash started recently, it may be Windows update, video/audio driver update or malfunction of your hardware. Similar problem is reported here (https://sourceforge.net/projects/ffdshow-tryout/forums/forum/597594/topic/4838949).
To control the position of subtitles, use slider in Subtitles placement page. If the subtitles are SSA/ASS, "Override SSA/ASS positioning ..." may help, but not recommended.


No update in windows or drivers whatsoever. I just installed the latest ffdshow and the subtitle filter causes Stereoscopic Player to close without error or warning. It just closes.

As for the subtitles, I can't get them to display on the black border, like this:

http://thumbnails63.imagebam.com/16161/aadc1c161601550.jpg (http://www.imagebam.com/image/aadc1c161601550)

ffdshow displays them like this:

http://thumbnails24.imagebam.com/16161/802ecb161601552.jpg (http://www.imagebam.com/image/802ecb161601552)

The movie resolution is 1920x816, so the black borders are added by ffdshow.

LE: I solved the player close issue. It was because I had ffdshow installed in program files and I installed K-Lite because I needed some more codecs and K-Lite changed the ffdshow path to program files\k-lite\ffdshow and from here on every player didn't know what to do with subtitle filter. ffdshow itself was working fine tho. I installed ffdshow back and k-lite without ffdshow. Now it only remains the positioning.

[haruhiko_yamagata]

@crl2007,
Good to hear it was solved.
Incidentally, I have found ffdshow crashes if letter box is used for 10-bit image since the addition of P010/P016 color spaces.

As for positioning, the player or the video renderer may add the black borders. What is your settings for Letter box? What happens if you enter 4:3 or even 4:5?

[crl2007]

I use 16:9 Letterbox. If I use 4:3 or 4:5, I get a huge black border on top and no border below. MPC-HC has something like this:

http://thumbnails59.imagebam.com/16168/e3a765161677202.jpg (http://www.imagebam.com/image/e3a765161677202)

It displays the subtitles on the black border without using another setting. Maybe a similar option could be added to ffdshow too.

[haruhiko_yamagata]

ffdshow draw subtitles on the black borders for me. I can't find how to draw on video image...

[Reino]

ffdshow_rev4052_20111120_clsid.exe small bug-report:

- CRAM video (http://samples.mplayerhq.hu/V-codecs/CRAM/BARBIE.AVI), immediate crash.

- RLE video (http://samples.mplayerhq.hu/V-codecs/RLE/HCN.avi), immediate crash.

- Volume Normalization on WavPack Audio (http://www.degeelebosch.nl/reino/Chris Rea_test (flac,wv,tta).mka) glitch:
Although this of low priority, I've seen this issue has been around for a long time now. While the volume levels refresh realtime on FLAC or TTA, when the WavPack audio stream is selected, the volume levels are only refreshing once every 1 or 2 seconds or so, or aren't refreshing at all.

- Lastly, a request (which I have requested earlier (http://forum.doom9.org/showthread.php?t=156427), but has fallen into oblivion):
To test and play avs-files (Avisynth-script pointing to YV12-material) and not having to install the Helix YUV Codecs 1.2, because of FFDShow's ability to handle raw YV12 material, is of course great. However, the downside to enabling raw YV12 in FFDShow is, it becomes an unnecessary DirectShow filter in case of all lossy/encoded YV12 material. When you let the LAV Video Decoder handle H.264 for instance, the FFDShow Video Decoder comes after that serving no purpose at all.
So, an option to allow FFDShow only in this case (AVI/AVS-files with or pointing to raw YV12 video) would be ideal. And of course the idea behind it, something like; if other than FFDShow decoder present, then don't load. And if no other decoder capable of handling raw YV12 video, then load FFDShow Video Decoder.

[haruhiko_yamagata]

Please do it. I prefer less but safe.
I have removed it at rev 4092.

[haruhiko_yamagata]

Yes, libavcodec now supports 4:2:2 8/10bit. But it is disabled in ffdshow because it can not handle the relevant colorspaces yet.
OK, I'll work on it.
I don't have any samples.
No problem, I have created a sample.

[crl2007]

ffdshow draw subtitles on the black borders for me. I can't find how to draw on video image...

It draws subtitles on black borders if the movie isn't cropped, but if it is cropped and you use coreavc and ffdshow subtitle filter as video processor, then the subtitles are drawn on video, like in my pic.

[nevcairiel]

It draws subtitles on black borders if the movie isn't cropped, but if it is cropped and you use coreavc and ffdshow subtitle filter as video processor, then the subtitles are drawn on video, like in my pic.

You need to configure ffdshow to actually add the black borders, otherwise there are no black borders to render on.

Check the Aspect/Resize options, and make sure its in the tree above the subtitle options.

[crl2007]

My problem it's not when I use ffdshow as my video decoder, because then I can use letterbox 16:9 and the subtitles are placed correctly. I use only ffdshow subtitle filter in Stereoscopic Player and the player native video decoder. These are the only options in the subtitle filter:

http://thumbnails24.imagebam.com/16171/56135b161705024.jpg (http://www.imagebam.com/image/56135b161705024)

I asked if there is a way to lower the subtitle on the black border if another decoder adds the black borders. I want to be able to lower / raise them all the way up and down, even if the borders are added by other decoders.

[nevcairiel]

You can only render subtitles into the black border if the border is already there, you cannot render them into the border if the border is added after subtitle rendering (ie. in the renderer). What you want cannot be done with the options you have available.

[pankov]

crl2007,
enable the Leterbox option and set it to match your display aspect ratio. Store the settings and restart the player.
You should now have subtitles in the black bars.
I've just tried this and it works with any video decoder (I've tested with LAV Video decoder, CoreAVC and FFDShow decoder)

[crl2007]

Yeah, after restarting the player, it seems that the letterbox works ok. With ffdshow the settings are saved on the fly and applied, but with this standalone filter it seems that you have to restart the player for certain settings.

[hoborg]

clsid:
Hi.
Can you please update FFDshow DXVA decoder to include MPC-HC 3864 fix (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=3864)?

[haruhiko_yamagata]

With that though, I'm starting to feel more regret about that chroma position thing. Life's so complicated! :)Once we know about it, the quality is not as good as before...
I have fixed at rev 4096 and it still renders MPEG-1 correctly.

[mandarinka]

Once we know about it, the quality is not as good as before...

Yes, it is exactly as you say...
Thanks a lot for your work :)

[clsid]

- CRAM video (http://samples.mplayerhq.hu/V-codecs/CRAM/BARBIE.AVI), immediate crash.
- RLE video (http://samples.mplayerhq.hu/V-codecs/RLE/HCN.avi), immediate crash.Please test some old versions to see if it worked before. Narrow down the revision range in which it got broken.

[MatLz]

Please test some old versions to see if it worked before. Narrow down the revision range in which it got broken.
3960 doesn't work.

[dukey]

DXVA and subtitles seem a little broken. The image around the subtitles seems to get corrupted by them. I am not sure how else to get DXVA working with subtitles.

http://i.imgur.com/M9fuW.jpg

[haruhiko_yamagata]

DXVA and subtitles seem a little broken. The image around the subtitles seems to get corrupted by them. I am not sure how else to get DXVA working with subtitles.

I don't have DXVA enabled video card and I don't know how albain has implemented DXVA + subtitles.
It looks like DXVA decoder is referencing the frames which subtitles are drawn by ffdshow. If it is true, it is almost impossible to fix.
In the future, I may implement hardware overlay, but not sure. It may be the only way to fix it.

[dukey]

Yeah, it looks like that. The subtitle fragments move around with the picture.

[haruhiko_yamagata]

Yes, libavcodec now supports 4:2:2 8/10bit. But it is disabled in ffdshow because it can not handle the relevant colorspaces yet.
New color spaces have been implemented. H.264 High 4:2:2 Profile has been enabled at rev 4101.

[fastplayer]

Once we know about it, the quality is not as good as before...
I have fixed at rev 4096 and it still renders MPEG-1 correctly.
You only see the difference in screenshots but once you've seen it, it's stuck in your mind. :D
Thanks for "fixing" this! :)

[leeperry]

hi Haruhiko, glad to see you back! 2 points if I may:

1) the MPEG1 chroma placement you've recently changed is only used for RGB32 conversion I would presume? Because I use the rgb3dlut() Avisynth plugin for gamut mapping, and it already has a function for horizontal MPEG1 placement when converting YUY2 to RGB32:
cplace -

Specifies horizontal chroma placement... used when input is yuy2. Possible settings:

0 - chroma is aligned with left pixel in each pair (mpeg2, mpeg4, h264)

This would be the case if during 4:4:4 -> 4:2:2 conversion odd pixel chroma values
were simply dropped, or if an odd length FIR filter centered on the even pixels was
used, such as a [1 2 1] kernel.

1 - chroma is centered between each pair of pixels (h261, h263, mpeg1)

This would be the case if during 4:4:4 -> 4:2:2 conversion the chroma of every
two pixels was averaged together, or if an even length FIR filter centered between
each pair of pixel values was used, such as a [1 4 4 1] kernel.

Should I use 0 now that you've made changes? are your changes also active in the resizing filter or only at the RGB32 conversion?

2) I use resizing>avisynth filters in ffdshow video(ffdshow audio simply decodes) and I'm having performance issues >4085 :(

I'm using the builds from http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ so I dunno where the issue lies between 4085 and 4090, but I'm using the ICL12 builds on XPSP3 w/ a 3.5Ghz Q9450. I need to drastically lower my resizing otherwise 4090 and 4096 stutter like hell. I wanted to post timecodec comparisons but for some reason ffdshow isn't in the rendering list for those DX50 files =/

I guess it could be due to a libav update(4089) or anything else really...but something definitely killed performance for me, and it happened between 4086 and 4090 :o

:thanks:

[haruhiko_yamagata]

leeperry, MPEG1/2 chroma placement fix is for YCbCr to RGB conversion. Resize is not related.

[clsid]

@haruhiko
Can you remove/disable AYUV output? The Windows renderers emulate this in software, making it very slow. So it not very useful and could cause performance problems for people.

@lee
swscale was updated in 4089, so that might be related.

[clsid]

The swscale performance issue is because of a data alignment issue. See swscale.c, line 2620.
Haruhiko, can you have a look at that?


I noticed a DXVA regression. There is some video corruption on some files. I will try to fix that.

[hoborg]

I noticed a DXVA regression. There is some video corruption on some files. I will try to fix that.

Hi.
Sorry to ask again, but it is posstible to update FFDshow DXVA decoder to latest MPC-HC release? There was some DXVA related fixes done.

[clsid]

Will do. But the problem I was talking about is related to Libav changes.

[hoborg]

Will do.
:thanks:

[hoborg]

BTW, this (http://tinyurl.com/7bdkv4q) VC-1p sample crash Graphstudio if FFDshow (libavcodec/wmv9)/FFDshow DXVA video decoder is in use (LAV splitter).
LAV video decoder play it OK.
rev.4096 here.

[clsid]

^ fixed

[haruhiko_yamagata]

@haruhiko
Can you remove/disable AYUV output? The Windows renderers emulate this in software, making it very slow. So it not very useful and could cause performance problems for people.
It works only with madVR for me. I think it depends on the video card and the driver.
EVR connects but black screen for me. You are right, it should be disabled by default.

EDIT: It was black because of a bug. Fixed at rev 4114.

[betaking]

can not compile last svn
1>src\codecs\TDXVADecoderH264.cpp(201): error C2065: “m_pFilter”: 未声明的标识符
1>src\codecs\TDXVADecoderH264.cpp(201): error C2227: “->GetAVCtx”的左边必须指向类/结构/联合/泛型类型

[madshi]

AYUV output is useful for 4:4:4 content. The ffmpeg h264 decoder supports 4:4:4 decoding.

[haruhiko_yamagata]

AYUV output is useful for 4:4:4 content. The ffmpeg h264 decoder supports 4:4:4 decoding.
Never mind, it's just disabled by default. Current video driver does not support AYUV, but things will change in a long time.

[Reino]

- CRAM video (http://samples.mplayerhq.hu/V-codecs/CRAM/BARBIE.AVI), immediate crash.
- RLE video (http://samples.mplayerhq.hu/V-codecs/RLE/HCN.avi), immediate crash.Please test some old versions to see if it worked before. Narrow down the revision range in which it got broken.The following revisions are the latest ones still working:
- ffdshow_rev3814_20110411_clsid.exe
- ffdshow_rev3817_20110412_xhmikosr_MSVC2010.exe
- ffdshow_rev3822_20110415_xvidvideo-ru_x86-MSVC2010.exe
Revision 3823 - Directory Listing
Modified Tue Apr 19 22:06:39 2011 UTC (7 months, 2 weeks ago) by clsid2

Updated LibavI guess this one is the culprit.

[clsid]

^ fixed

[Reino]

Thx clsid.

Then some other things:
- Lately I've noticed the alignment of the OSD has changed a bit. For the worse if you ask me. The letters slightly disappear in the left side of the screen. If you could just move them to the right 1 or 2 pixels, then it'll be just as it used to be.

- FFDShow DXVA Video Decoder crashes here on VC1 material. Whether it's a m2ts-file (through LAV Splitter), or a wmv-file (through WM ASF Reader), it crashes immediately, with an "Microsoft Visual C++ Runtime Library, Runtime Error!" message as a result. Doesn't happen with MPC-HC's VC1 DXVA Decoder. H.264 material with the FFDShow DXVA Video Decoder is not a problem either.
Perhaps my old computer is the cause of it? I'm still using an AMD Athlon XP 3200+ (only MMX(+), 3DNow!(+) and SSE).
I have the following stuff installed (on Windows XP Pro SP3):
- Microsoft .NET Framework 2.0 Service Pack 2
- Microsoft .NET Framework 3.0 Service Pack 2
- Microsoft .NET Framework 3.5 SP1
- Microsoft Visual C++ 2005 Redistributable
- Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148
- Microsoft Visual C++ 2010 x86 Redistributable - 10.0.30319

- Lastly, a request (which I have requested earlier (http://forum.doom9.org/showthread.php?t=156427), but has fallen into oblivion):
To test and play avs-files (Avisynth-script pointing to YV12-material) and not having to install the Helix YUV Codecs 1.2, because of FFDShow's ability to handle raw YV12 material, is of course great. However, the downside to enabling raw YV12 in FFDShow is, it becomes an unnecessary DirectShow filter in case of all lossy/encoded YV12 material. When you let the LAV Video Decoder handle H.264 for instance, the FFDShow Video Decoder comes after that serving no purpose at all.
So, an option to allow FFDShow only in this case (AVI/AVS-files with or pointing to raw YV12 video) would be ideal. And of course the idea behind it, something like; if other than FFDShow decoder present, then don't load. And if no other decoder capable of handling raw YV12 video, then load FFDShow Video Decoder.I was thinking; why not remove the "Raw video"-format from the Video Decoder and let FFDShow Raw Video Decoder handle that, including the Avisynth issue (see quote above)? Isn't that what the Raw Video Decoder is for?
And about that; why isn't a shortcut for the Raw Video Decoder config made after install, like the Video,Audio,DXVA and VFW config? When I manually create a shortcut for it (read about creating it on this forum some time ago), with the entry "%windir%\system32\rundll32.exe ffdshow.ax,configureRaw", it crashes immediately on the first tab "Codecs". :(

[clsid]

OSD is based on subtitle functionality, so Haruhiko needs to answer that one.

VC1 crash was fixed yesterday. It still randomly crashes while closing the player though.

The raw filter is not for use during normal playback. It is a special filter that needs to be manually inserted by an application. Hence its standard merit of "do not use". You can also use the Xvid codec for raw YV12.

[mandarinka]

@CoRoNe
ffdshow inserted after another decoder isn't useless - it can be used as a postprocessor for various filtering or for example software scaling. I'm sure quite some number of users actually have it set-up like that.

[THEAST]

A small bug I noticed just now, using rev4102, if resizing is enabled in ffdshow and "Specify horizontal and vertical size" or "Specify horizontal size" is chosen and if the horizontal size is a number like 1680 which will result in an odd number if divided by 16, a [I think] one-pixel wide green column will appear at the rightmost part of 10-bit videos during playback. 8-bit videos are fine, numbers like 1600, 1616, 1632, etc are also fine.

[hoborg]

@clsid:
About DXVA update - i just tested rev. 4119:
- VC-1 no longer crashing :)
- MP4 HD AVC recordings from my Camcorder no longer stuttering in DXVA mode :D
- this h.264 sample (http://www4.uschovna.cz/download/D4YHWM795S73ELZ5-273/82A7SPD6NX) have still problem with FFDShow DXVA decoder - picture freeze, but sound continue to play. This doesnot happend with MPC-HC DXVA decoder. Strange.

[hoborg]

BTW, what about "removing FFDshow DXVA decoder from graph (http://www.youtube.com/watch?v=KZreMRTsuXk)" crash? It is still there. It make it nearly useless in LiveTV applications :/
Anyone interested to fix it?

Maybe this crash is connected with FFDShow DXVA video decoder icon which remaining in systray after playback, until hower cursor over it.

[nevcairiel]

Why are you using ffdshow DXVA anyway, instead of MPC-HCs DXVA? We all know that ffdshows DXVA code is just a copy of MPC-HCs, and apparently the subtitle overlay causes image corruption as well, so .. huh? :)

[hoborg]

Why are you using ffdshow DXVA anyway, instead of MPC-HCs DXVA? We all know that ffdshows DXVA code is just a copy of MPC-HCs, and apparently the subtitle overlay causes image corruption as well, so .. huh? :)

Becouse of DXVA + subtitles. FFDshow is only way right now how to have DXVA + subtitles in my HTPC based on NPVR. I don't have any coruptions here, and i don't got any report of that issue from SAF users yet.
Next thing i need is keyboard shortcuts for audio/subtitles streams switching and enable/disable subtitles (will be good if LAV splitter support that some day) :).

[leeperry]

The swscale performance issue is because of a data alignment issue.
Glad you found the culprit, hopefully it'll be fixable. I was about to try the LAV video decoder in order to see whether there was any difference.

BTW, could you please add 176400 and 192000 Hz in the resampler rate presets? I like to upsample prior to processing through VST plugins and it chews Reclock's job too.

I would also dream about a way to use 3DLUT's in ffdshow, taking YV12 input from my Avisynth scripts and sending P010/P016 to madVR, but I guess I would have to learn myself how to code in C++ to see it happening ^^

The nice added value would be the ability to make automatic profiles for gamut mapping, and not in lossy RGB32 as I'm currently doing...mVR does accept 16bit LUT's but you cannot make automatic profiles, I really think that ffdshow is the best place to do it. It's just sad that Avisynth still doesn't support 10bit, it would be like an audio editor not supporting a higher bitdepth than 16int :(

:thanks:

[Reino]

@CoRoNe
ffdshow inserted after another decoder isn't useless - it can be used as a postprocessor for various filtering or for example software scaling. I'm sure quite some number of users actually have it set-up like that.I know and I never mentioned it's useless. I'm just trying to find an easy solution for AVI/AVS-files with or pointing to raw YV12 video.

[Reino]

Ever since Tremor has been removed (Dec 11 2010) I miss its ability to correctly report the current input bitrate. Now with libavcodec, Vorbis audio is, of all the other audio formats, the only audio format where, instead of the correct input bitrate, the uncompressed input bitrate (1411Kbps with 44100Hz and 1536Kbps with 48000Hz for instance) is reported.
Is libavcodec incapable of doing this for Vorbis audio unlike Tremor, or is this a thing you people can reintroduce?

[Milardo]

Hi, can anybody post a link to the x86 build 3670(the last one with all the vfw encoders)? Also, just wondering, why doesn't anybody update the sourceforge main ffdshow site with a mention of a new stable build? http://ffdshow-tryout.sourceforge.net/

[Milardo]

Oh yeah, I forgot to mention a problem I'm having no matter what build I use right now using 4052, when I try to use ffdshow within kmplayer with this filter I've attached anaglyph.ax with my tv tuner card I get messed up picture. I have to use rgb24 for capture pin and then ffdshow decodes the picture with an output of yuv and the filter gets attached to ffdshow. VMR9 is the video renderer. Anybody could take a look at this would appreciate thanks in advance. The filter and messed up picture jpeg are attached in the zipped folder.

[Reino]

I think this, ffdshow tryouts project, svn 3667 (x86/x64) (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-3667-x86-x64.html), is the closest you'll get.

[Milardo]

Yes, that is the only one i found so far.

[haruhiko_yamagata]

Thx clsid.

Then some other things:
- Lately I've noticed the alignment of the OSD has changed a bit. For the worse if you ask me. The letters slightly disappear in the left side of the screen. If you could just move them to the right 1 or 2 pixels, then it'll be just as it used to be.
Can you fix it by setting "Horizontal position:" slider in "OSD" page?

[haruhiko_yamagata]

- Lastly, a request (which I have requested earlier (http://forum.doom9.org/showthread.php?t=156427), but has fallen into oblivion):
To test and play avs-files (Avisynth-script pointing to YV12-material) and not having to install the Helix YUV Codecs 1.2, because of FFDShow's ability to handle raw YV12 material, is of course great. However, the downside to enabling raw YV12 in FFDShow is, it becomes an unnecessary DirectShow filter in case of all lossy/encoded YV12 material. When you let the LAV Video Decoder handle H.264 for instance, the FFDShow Video Decoder comes after that serving no purpose at all.
So, an option to allow FFDShow only in this case (AVI/AVS-files with or pointing to raw YV12 video) would be ideal. And of course the idea behind it, something like; if other than FFDShow decoder present, then don't load. And if no other decoder capable of handling raw YV12 video, then load FFDShow Video Decoder.
I don't understand what you are talking. How avs file is decoded and how it is connected to ffdshow? Could you show me how it is rendered in graphedt.exe?

[haruhiko_yamagata]

A small bug I noticed just now, using rev4102, if resizing is enabled in ffdshow and "Specify horizontal and vertical size" or "Specify horizontal size" is chosen and if the horizontal size is a number like 1680 which will result in an odd number if divided by 16, a [I think] one-pixel wide green column will appear at the rightmost part of 10-bit videos during playback. 8-bit videos are fine, numbers like 1600, 1616, 1632, etc are also fine.
I see green or garbage if I enter 724 or something. If it is multiple of 8, it works for me.
Rev 4120 may fix the issue. I cannot reproduce even if I disable patch 4120 though.

[Reino]

Can you fix it by setting "Horizontal position:" slider in "OSD" page?Moving the slider one bit to the right, moves the OSD 7 pixels to the right. Not what I intended. No, I think the following entry is the culprit:
Revision 4039 - Directory Listing
Modified Thu Nov 10 04:51:59 2011 UTC (3 weeks, 4 days ago) by h_yamagata

subtitles branch: fixed OSD spacinghttp://img7.imageshack.us/img7/4361/ffdshowosd1.th.png (http://img7.imageshack.us/img7/4361/ffdshowosd1.png) http://img26.imageshack.us/img26/8385/ffdshowosd2.th.png (http://img26.imageshack.us/img26/8385/ffdshowosd2.png)
Also notice the extra blurring for some reason (especially noticeable on the first line)


About uncompressed YV12 material:
This is about people who frequently use Avisynth or are using other video editing software, who are working with uncompressed YV12 material. Be it uncompressed YV12 video in an AVI container (sample (http://www.mediafire.com/?zs7vmfucqxqv16p)), or through a simple Avisynth-script:
MPEG2Source("Avisynth_YV12-sample.d2v", cpu=0)

Crop(4,2,-4,-2)
LanczosResize(720,404)
For testing you obviously need a YV12 decoder and since FFDShow already has one, who needs the XviD Video codec or the Helix YUV Codecs 1.2?
We can simply set "Raw video" on the "Codecs"-tab at "YV12" or "All supported", in which case the DirectShow Graph look like this:
http://img444.imageshack.us/img444/5940/dsgraphavs.png

The whole downside of this story is, now FFDShow will also function as a post-processing filter for compressed YV12 material (MPEG2,DivX,XviD,H.264,etc):
http://img32.imageshack.us/img32/7016/dsgraphother.png
And instead of the LAV Video Decoder picture every non-FFDShow filter of course. Every decoder that spits out YV12 video.

I would very much welcome an option on the "Codecs"-tab for FFDShow to decode uncompressed YV12 material (directly (avi-file) or indirectly through an Avisynth-script) and not behave as a post-processing filter on all YV12 material.
I hope you understand now, I can't explain it any better.

[nevcairiel]

For testing you obviously need a YV12 decoder

How so?
If your renderer supports YV12 material, why do you need a special filter in between?
In theory there is no difference between the output from a decoder and the output from an AviSynth script.

As an alternative, you could also increase the merit of the ffdshow raw filter a bit, so that its above MERIT_DO_NOT_USE, but still way below the merit of the renderers, so that it doesn't get auto-inserted if its not needed.

[Reino]

Afaik among Windows XP its available video renderers (Full Screen Renderer, Video Renderer, Video Mixing Renderer 7 and Video Mixing Renderer 9 (all quartz.dll)), there's not one that can handle YV12 video without a decoder.

And about that; why isn't a shortcut for the Raw Video Decoder config made after install, like the Video,Audio,DXVA and VFW config? When I manually create a shortcut for it (read about creating it on this forum some time ago), with the entry "%windir%\system32\rundll32.exe ffdshow.ax,configureRaw", it crashes immediately on the first tab "Codecs". :(I get a Rundll Application Error when I try to open the config through the shortcut, changing the merit with Softella DirectShow Filter Manager (http://www.softella.com/dsfm/index.en.htm) has no effect, trying to access the config with the same program results in the Rundll error again, and thus trying to manually add the FFDShow Raw Video Filter in MONOGRAM GraphStudio (http://blog.monogram.sk/janos/2009/06/14/monogram-graphstudio-0320/) has no effect at all. I somehow can't use it to be short. (happened with latest rev4122)

[mandarinka]

I see green or garbage if I enter 724 or something. If it is multiple of 8, it works for me.
Rev 4120 may fix the issue. I cannot reproduce even if I disable patch 4120 though.

The green stuff on right edge happens with 10-bit video even without software scaling, the requirement is that the video width (I'm not sure about height) must be non-mod4 AND vsfilter must follow ffdshow in the playback chain (tested: revision 4096). I didn't report it here yet, because it is a bit messy matter, but I notified CCCP team (since they ship with vsfilter) here, for reference:

http://www.cccp-project.net/forums/index.php?topic=6084.msg39465#msg39465

See post 23 (before to that point the thread is about an older bug). A sample that replicates the behavior can be found in post 1 though).

Edit: I quickly tested a build of r4122 (xvidvideo.ru, 32-bit msvc) and it seems that reverting that vsfilter workaround has broken non-mod4 width video totally (both 8bit and 10bit) - essentially the old bug reported in the first post of that cccp forum thread got reintroduced. I didn't test r4123 (no builds yet...)

[Reino]

I don't know how, but the Rundll Application Error upon opening the FFDShow Raw Video Decoder config is over now. I was searching for the revision that would cause the error, but ultimately ended up installing the latest revision again...and the error was gone...weird.
But now I'm facing another problem; with all the revisions I installed, including the latest one, the merit slider on the "DirectShow control"-tab is grayed out. I can't use it.
Changing the merit with Softella DirectShow Filter Manager also now still has no effect.
(Although it's not the aim, the Raw Video Decode does work though when manually adding it on MPC-HC's "External Filters"-tab and changing the merit to 00400000)

[Dstruct]

Minor installer bug: With "DXVA" unchecked in Installer, ffdshow (rev4122) still copies the Intel QuickSync DLL into the program folder. Should get fixed.


SOLVED

[oddball]

I have an issue with the delogo filter. It won't work right up to the edge of the frame. It always leaves about 2 pixels or so visible. If I try to cover those two pixels the delogo mask vanishes completely. Example below. You can see part of the logo at the bottom left. I have tried different aspects and touching from from inside and outside etc to no avail.

http://www.imagebam.com/image/74363e162953570

[clsid]

Minor installer bug: With "DXVA" unchecked in Installer, ffdshow (rev4122) still copies the Intel QuickSync DLL into the program folder. Should get fixed.QuickSync is a plugin for the regular ffdshow video decoder. It is not in any way related to the DXVA functionality of ffdshow.

[clsid]

I don't know how, but the Rundll Application Error upon opening the FFDShow Raw Video Decoder config is over now. I was searching for the revision that would cause the error, but ultimately ended up installing the latest revision again...and the error was gone...weird.
But now I'm facing another problem; with all the revisions I installed, including the latest one, the merit slider on the "DirectShow control"-tab is grayed out. I can't use it.
Changing the merit with Softella DirectShow Filter Manager also now still has no effect.
(Although it's not the aim, the Raw Video Decode does work though when manually adding it on MPC-HC's "External Filters"-tab and changing the merit to 00400000)
You must right-click and "run as admin" to be able to change merits with programs or ffdshow config.

[Reino]

I'm using an nLited (http://www.nliteos.com/nlite.html) Windows XP Pro SP3. I'm always running as Admin, so in essence I can access everything. No hidden settings. That makes me wonder how FFDShow detects if one is running as admin or not.
It's only the Raw Video Decoder config, the other configs I can change the merits no problem.

[haruhiko_yamagata]

The green stuff on right edge happens with 10-bit video even without software scaling, the requirement is that the video width (I'm not sure about height) must be non-mod4 AND vsfilter must follow ffdshow in the playback chain (tested: revision 4096). I didn't report it here yet, because it is a bit messy matter, but I notified CCCP team (since they ship with vsfilter) here, for reference:

http://www.cccp-project.net/forums/index.php?topic=6084.msg39465#msg39465

See post 23 (before to that point the thread is about an older bug). A sample that replicates the behavior can be found in post 1 though).

Edit: I quickly tested a build of r4122 (xvidvideo.ru, 32-bit msvc) and it seems that reverting that vsfilter workaround has broken non-mod4 width video totally (both 8bit and 10bit) - essentially the old bug reported in the first post of that cccp forum thread got reintroduced. I didn't test r4123 (no builds yet...)
It was my fault for not testing properly and misread the situation. That vsfilter's bug was still alive.
In DirectShow, the down stream filter prepares buffer. There is no explicit transmission of the strides. Thus both filters have to guess stride from the dimensions.
MSDN in Japanese document (http://msdn.microsoft.com/ja-jp/library/cc352308.aspx) says that for YUV format such as YV12 stride has to be rounded to the nearest DWORD alignment. Sorry, I can't find English documentation. It look like that part was deleted/changed.
vsfilter does not align the stride at all. If ffdshow does not take the bug into account, the picture is messed up.
I think it is not wise to fix vsfilter now, because filters that have the workaround gets broken again.

[nevcairiel]

For the record, ffdshow raw also doesn't deal with any stride, it will exhibit the same problems (green bar, etc).
The best solution would be if the post-processor takes over the buffer control and then requests the stride (much like a renderer would function).

[haruhiko_yamagata]

For the record, ffdshow raw also doesn't deal with any stride, it will exhibit the same problems (green bar, etc).
Oops, then ffdshow has the same bug.
The best solution would be if the post-processor takes over the buffer control and then requests the stride (much like a renderer would function).
Would you explain the detail?

[haruhiko_yamagata]

Afaik among Windows XP its available video renderers (Full Screen Renderer, Video Renderer, Video Mixing Renderer 7 and Video Mixing Renderer 9 (all quartz.dll)), there's not one that can handle YV12 video without a decoder.Thank you for explanation.
ffdshow's default output color space has been YV12 for a long time. On Windows Xp, YV12 should work fine except very rare cases.

OSD:
I'll take a look later.

[JEEB]

Yeah, the stride bug was found to be in both VSFilter as well as the raw input filter, I think it's mentioned in the related CCCP thread as well...

Anyways, I was going to report these things as soon as I got off my lazy turd to make a sample of another file where -tryouts was using the wrong channel mapping with a 4ch AC3 stream if libavcodec's decoder was used (probably matched to whatever liba52 was putting out since using that one seems to output the same as VLC/LAV Audio). That sample is now available here (http://www.cccp-project.net/beta/test_files/4ch_ac3sample.mka).

[Dstruct]

QuickSync is a plugin for the regular ffdshow video decoder. It is not in any way related to the DXVA functionality of ffdshow.

Ok, thanks! Didn't know that.

[GMJCZP]

I'm using version ffdshow_rev4052_20111120_clsid and noticed that one avi video which is H.264 video component could not play in Media Player Classic, so I tried installing an older version, the ffdshow_rev3336_20100327_clsid, and with that I was able to play the video, but not wanting to keep an older version I chose to use the Haali Media Splitter, and leaving "disabled" option decoding.

I hope you can resolve this inconsistency. Thank you.

[Reino]

Thank you for explanation.
ffdshow's default output color space has been YV12 for a long time. On Windows Xp, YV12 should work fine except very rare cases.

OSD:
I'll take a look later.Uhm...that was a reply to nevcairiel. My reply to you is 2 post earlier.

You must right-click and "run as admin" to be able to change merits with programs or ffdshow config.I'm using an nLited (http://www.nliteos.com/nlite.html) Windows XP Pro SP3. I'm always running as Admin, so in essence I can access everything. No hidden settings. That makes me wonder how FFDShow detects if one is running as admin or not.
It's only the Raw Video Decoder config, the other configs I can change the merits no problem.Ok, first of all, FFDShow's Raw Video Decoder does work now. I guess, after changing its merit with Softella DirectShow Filter Manager, somehow a reboot is required for it to work...weird though o_O.

However, even after having tested it on another computer ('normal' Windows XP using an admin-account with full access), also here the merit-slider is greyed out and inaccessible.
Has anyone reading this topic access to this merit-slider at all (you can find it on the "Codecs"-tab of FFDShow's Raw Video Decoder config)?

[clsid]

It is greyed out deliberately. It should be removed completely imo.

[haruhiko_yamagata]

The swscale performance issue is because of a data alignment issue. See swscale.c, line 2620.
Haruhiko, can you have a look at that?OK, I'm working on it.

[Reino]

@ clsid:
Then why hold up the "run as admin"-story at all? Rather misleading.
You don't want people to use the Raw Video Decoder at all?

[ikarad]

OK, I'm working on it.

Do you still work on sub renderer and support of /t subs?

[Blight]

Bug report:
This is not a new report, it's just troubling.
When using the FFDShow Subtitle Renderer filter (not rendering with the video decoder) with the "Set interlaced flag in output media type" checkbox enabled in the "output" section, FFDShow crashes GraphStudio (and elsewhere) as soon as the graph is run.

Here's a sample file and a grf file to test with
It uses FFDShow for Audio decoder and sub renderer and LAV for the splitter and video decoder. EVR is used as the video renderer.
The crash occurs whether ffdshow is used as an audio/video decoder or not.

Download sample:
http://www.multiupload.com/SV8IKUHXS5

The GRF file was created under "D:\X"

[clsid]

@ clsid:
Then why hold up the "run as admin"-story at all? Rather misleading.
You don't want people to use the Raw Video Decoder at all?The raw filter is supposed to be manually inserted into the filter graph by an application that desires to use it. It is not designed to be used like a normal filter.
Changing merits requires admin privileges and therefore "run as admin" can help.

[GMJCZP]

I'm using version ffdshow_rev4052_20111120_clsid and noticed that one avi video which is H.264 video component could not play in Media Player Classic, so I tried installing an older version, the ffdshow_rev3336_20100327_clsid, and with that I was able to play the video, but not wanting to keep an older version I chose to use the Haali Media Splitter, and leaving "disabled" option decoding.

I hope you can resolve this inconsistency. Thank you.

Please, follow with the problem, I must be getting disabled / libavcodec and is an inconvenience. Thanks.

[cyberbeing]

@haruhiko_yamagata

It seems you also need to apply a similar VSFilter stride fix P010 & P016 as well.

FFDShow r4127 with mandarinka's mod-2 width sample results in a green bar on the right side of the image when outputting P010 or P016 to xy-VSFilter. The problem doesn't occur with LAV Video 0.42.

[haruhiko_yamagata]

Bug report:
This is not a new report, it's just troubling.
When using the FFDShow Subtitle Renderer filter (not rendering with the video decoder) with the "Set interlaced flag in output media type" checkbox enabled in the "output" section, FFDShow crashes GraphStudio (and elsewhere) as soon as the graph is run.

Here's a sample file and a grf file to test with
It uses FFDShow for Audio decoder and sub renderer and LAV for the splitter and video decoder. EVR is used as the video renderer.
The crash occurs whether ffdshow is used as an audio/video decoder or not.

Download sample:
http://www.multiupload.com/SV8IKUHXS5

The GRF file was created under "D:\X"
Thank you for testing that filter. I've been thinking of removal of the registration, but if you have any plan to use it, I'll fix it.

[haruhiko_yamagata]

Do you still work on sub renderer and support of /t subs?Not now, please wait.

[haruhiko_yamagata]

@haruhiko_yamagata

It seems you also need to apply a similar VSFilter stride fix P010 & P016 as well.

FFDShow r4127 with mandarinka's mod-2 width sample results in a green bar on the right side of the image when outputting P010 or P016 to xy-VSFilter. The problem doesn't occur with LAV Video 0.42.They are different two problems. It's not a fault of xy-VSFilter. Anyway, I'll fix it.

[haruhiko_yamagata]

Please, follow with the problem, I must be getting disabled / libavcodec and is an inconvenience. Thanks.Please provide a sample. H.264 in AVI plays fine for me.

[ikarad]

Not now, please wait.

Thanks very much for your answer. Your works on ffdshow is very important.

I'll wait but no too long I hope :D

[GMJCZP]

Please provide a sample. H.264 in AVI plays fine for me.

I took a sample of the video, and amazingly it does reproduce normally, it may be a registry problem the file header. Even so, the current ffdshow should play, as does a 2010 version.

[mandarinka]

I can confirm that after updating to r4130 build, the problems with playback of the bleh.mkv sample from CCCP forums are fixed.

A glitch with non-mod4 width video remains in the grab filter apparently - the last two columns on the right border are missing from the grabbed screens, there is just black bar there instead. This is reproducible with the same sample.
screenshot made with MPC: http://i.imgur.com/RKKj0.png
screenshot made with ffdshow's grab: http://i.imgur.com/8bkHa.png

P.S. I tried to force rgb32 output for that sample, but MPC crashed in ffdshow.ax. I fear the crash might not be reproducible though :(
As far as I can see, the requirement for it to crash is to have vsfilter enabled with the rgb32 input; if I disable vsfilter, crash goes away.
This crash also seems to affect 8-bit h.264 (tested with a diferent 714x480 sample).

[haruhiko_yamagata]

I took a sample of the video, and amazingly it does reproduce normally, it may be a registry problem the file header. Even so, the current ffdshow should play, as does a 2010 version.
If just cutting a small part from the video fix the issue, the file is likely to be broken.
You could use binary editor to cut first 1MB. If it plays fine by the older version and does not play by the latest version, please send me the sample.

[haruhiko_yamagata]

I can confirm that after updating to r4130 build, the problems with playback of the bleh.mkv sample from CCCP forums are fixed.

A glitch with non-mod4 width video remains in the grab filter apparently - the last two columns on the right border are missing from the grabbed screens, there is just black bar there instead. This is reproducible with the same sample.
screenshot made with MPC: http://i.imgur.com/RKKj0.png
screenshot made with ffdshow's grab: http://i.imgur.com/8bkHa.png
Rev 4135 should work.

P.S. I tried to force rgb32 output for that sample, but MPC crashed in ffdshow.ax. I fear the crash might not be reproducible though :(
As far as I can see, the requirement for it to crash is to have vsfilter enabled with the rgb32 input; if I disable vsfilter, crash goes away.
This crash also seems to affect 8-bit h.264 (tested with a diferent 714x480 sample).
I can't reproduce.

[mandarinka]

Oh, I feared so...
I don't actually feed rgb32 to the renderer, so I'm fine. I use the grab function a lot though, thanks for adressing the glitch in it! Rev. 4136 works great :)

BTW, I'm curious... for 10-bit video, does the grab filter convert straight to rgb, or does it need to convert to yv12 first (assuming that HQ conversion is enabled)?

[GMJCZP]

If just cutting a small part from the video fix the issue, the file is likely to be broken.
You could use binary editor to cut first 1MB. If it plays fine by the older version and does not play by the latest version, please send me the sample.

Here the link of sample:

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

Remember that this sample works fine with last ffdshow, but not the entire video. Good luck!

[cyberbeing]

They are different two problems. It's not a fault of xy-VSFilter. Anyway, I'll fix it.

Since the issue still exists in FFDShow r4136, I assume the r4132 + r4134 commits weren't supposed to fix this? What exactly is the problem related to, so I can identify it in the sourceforge svn log when it gets fixed?

[haruhiko_yamagata]

BTW, I'm curious... for 10-bit video, does the grab filter convert straight to rgb, or does it need to convert to yv12 first (assuming that HQ conversion is enabled)?It's direct.:)

[mandarinka]

Perfect :D

[haruhiko_yamagata]

Since the issue still exists in FFDShow r4136, I assume the r4132 + r4134 commits weren't supposed to fix this? What exactly is the problem related to, so I can identify it in the sourceforge svn log when it gets fixed?
Rev 4139 should work.

[haruhiko_yamagata]

Here the link of sample:

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

Remember that this sample works fine with last ffdshow, but not the entire video. Good luck!I need a sample that does not work.
Would you narrow the range of regression? I need the information about the last working version and the first version that does not work.

[GMJCZP]

One problem: The original video has been removed from all servers, and I can not upload it because I do not have internet itself.
The only thing left is to see if this small file has the same features of the other:

Link (http://www.wupload.com/file/59282586/[deluvian]_[1972]_Umi_no_Triton_-_01_[3FA3BB44].avi)


The version of ffdshow with problems is ffdshow_rev4052_20111120_clsid, and the version that work is the ffdshow_rev3336_20100327_clsid.

[ryrynz]

Hi Haruhiko, any chance you could take a look at this issue? Thanks.

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

[haruhiko_yamagata]

Hi Haruhiko, any chance you could take a look at this issue? Thanks.

http://sourceforge.net/tracker/?func=detail&atid=867360&aid=3400530&group_id=173941
I can't reproduce. Please export the settings and send me the file.

[cyberbeing]

@haruhiko_yamagata

I sent you a PM with a test build of xy-VSFilter (work-in-progress refactor2 branch (http://repo.or.cz/w/xy_vsfilter.git/shortlog/refs/heads/Refactor2)). When using madVR, FFDShow r4136 is outputting P010 to that build even with 8-bit video, and even when P010 output is disabled in FFDShow (tested on WinXP with MPC-HC). At least the problem of outputting P010 when it's disabled seems to be a FFDShow bug. This doesn't happen in CoreAVC or LAV Video, but that may be because neither of those decoders allow 8-bit -> 10-bit conversion.

Edit: I can confirm that r4139 fixed the P010 non-mod4 bug

[mandarinka]

Maybe you have P010 set in the preferred colorspace option? I noticed that when I pick a colorspace there, it will get used for output even if I untick it in the menu bellow.

[cyberbeing]

The Primary Output Colorspace is set to Auto in FFDShow, but it does seem possible that something xy-VSFilter is doing causes that Auto setting to fail.

Update: I tried setting Primary Output Colorspace to YV12 in FFDShow, but it still outputs P010 for 8-bit video to that xy-VSFilter build. Something else must be going on.

[madshi]

important bug report:

It seems that ffdshow does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2. Broadcasts and DVDs often switch between soft-telecine and hard-telecine. So they will look like a wild mix of 3:2 and 2:2, which will make it hard to perform a proper IVTC.

FWIW, LAV Video Decoder sets this flag correctly.

@haruhiko_yamagata, I'm sorry that you're getting burried in bug reports at the moment. And I'm sorry that I just reported another one. It's good to have you back!

[fano]

Hy,
in your opinion it's possible to do a realtime Dolby True HD encoding as it's doable now with ffdshow audio, with the function "AC3 (SPDIF encode Mode)"?
In this way if I've an AAC file (for example but it can be a high quality FLAC file) instead of converting to LPCM (and windows can modify it add its annoying "click" or "plimp" when it has done or FAILED its unuseful things!) but a Dolby True HD bitstream cannot be touched...

It's that I do now (trascoding all audio stereo audio, too), with satisfaction as before if I was browsing and contemporary playing a song, the song "clicked" when I moved the mouse, I know should be the audio "exclusive mode" but, in my case, it does not worked... windows likes to do click and it clicks!
My audio is garbage, now :(

But a Dolby True HD bitstream goes untuched, right?
... and for its uncompressed nature, I do not have to compress and deteriorate my audio to avoid the clicks...

What do you say? It's feasible? Or too CPU intensive to do in realtime?

[nevcairiel]

Its not possible because none of the "HD" codecs have a free encoder available. You should rather go debug your audio setup, its certainly possible to stop windows from messing with it.

[fano]

Well but we've decoders, right?

It's not simple to do an encoder?
I suppose no :angry:

[haruhiko_yamagata]

@haruhiko_yamagata

I sent you a PM with a test build of xy-VSFilter (work-in-progress refactor2 branch (http://repo.or.cz/w/xy_vsfilter.git/shortlog/refs/heads/Refactor2)). When using madVR, FFDShow r4136 is outputting P010 to that build even with 8-bit video, and even when P010 output is disabled in FFDShow (tested on WinXP with MPC-HC). At least the problem of outputting P010 when it's disabled seems to be a FFDShow bug.
ffdshow's output pin is called for IPin::Connect twice.
The first call is called with pmt=NULL and succeeds.
The second call which should not happen is called with pmt fully specified. It's NV12 for me, not P010 though.
ffdshow has no choice to connect with NV12 but to reject connection.
The second call does not happen with normal vsfilter, so please look into your code.
ffdshow accepts unchecked color spaces in such cases. ffdshow is not too strict. It's not a bug.
Other filters may reject connection for the second call.
Good luck.:)

[ryrynz]

I can't reproduce. Please export the settings and send me the file.

I'll look further into it and get back to you if I can reproduce. I had similar problems last night but am not sure what was causing it.

Regarding naming of saved presets, is there any chance of having it the file name greater than 9 characters? All my preset names get truncated if I don't correct them.

Just one other thing, I've never managed to ever import my Avisynth code from the ffdshow exported settings without going viewing the exported file and manually copying the code for each preset, I documented that here.

http://sourceforge.net/tracker/index.php?func=detail&aid=3149428&group_id=53761&atid=471489

[haruhiko_yamagata]

important bug report:

It seems that ffdshow does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2. Broadcasts and DVDs often switch between soft-telecine and hard-telecine. So they will look like a wild mix of 3:2 and 2:2, which will make it hard to perform a proper IVTC.

ffdshow handles soft-telecine internally if detected. It average timestamps and output the frame as progressive. So video renderers do not have to take care of soft-telecine. In theory...
Please make sure "Soft telecine" is checked in "Decoder options" page. And enable OSD "Frame timestamps" and "Frame duration".
ffdshow might be failing to detect soft-telecine. In that case, please send me the sample.
By the way, current MPEG2 decoders in ffdshow doesn't seem to be stable...

[xy]

Hi, I'm the current dev of xy-VSFilter. I'm not yet look into the problem myself. But:

ffdshow's output pin is called for IPin::Connect twice.
The first call is called with pmt=NULL and succeeds.
The second call which should not happen is called with pmt fully specified. It's NV12 for me, not P010 though.
ffdshow has no choice to connect with NV12 but to reject connection.
The second call does not happen with normal vsfilter, so please look into your code.


Normal vsfilter doesnot have any reconnection logic, definitely reconnection is a must for any filter want to make a effort to avoid color space transformation. xy-VSFilter does the reconnection in the stardard way (http://msdn.microsoft.com/en-us/library/windows/desktop/dd377502%28v=vs.85%29.aspx).


ffdshow accepts unchecked color spaces in such cases. ffdshow is not too strict. It's not a bug.


This is definitely a bug. Any trans-in-place filter will have reconnection logic. It means that when such filters connect to ffdshow, ffdshow may output unallowed formats.


Other filters may reject connection for the second call.

According to the document (http://msdn.microsoft.com/en-us/library/windows/desktop/dd377502%28v=vs.85%29.aspx), if QueryAccept return S_OK, they should not reject the reconnection (or at least, the reconnection is expected to success).

[haruhiko_yamagata]

xy, it is not you who decide it's a spec or bug. It's the spec. Be modest, you have to deal with existing filters.
ffdshow connects as requested. Your filter requests ffdshow to connect using NV12, and so ffdshow accepts it even if NV12 is unchecked in the dialog. What's wrong?

[haruhiko_yamagata]

For the record, ffdshow raw also doesn't deal with any stride, it will exhibit the same problems (green bar, etc).
The best solution would be if the post-processor takes over the buffer control and then requests the stride (much like a renderer would function).In my two years absence, it has been buried in oblivion. Anyway, done at rev 4142 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&sortby=date&revision=4142). This is a big change, which needs testing.
ffdshow's allocator was copied from guliverkli, so it is natural that vsfilter and ffdshow have the same issue.
TffdshowDecVideoAllocator.cpp says,
/*
* Copyright (c) 2004-2006 Milan Cutka
* based on CDirectVobSubInputPin by Gabest
I hope MPC-HC project can handle this as well. Who should I contact?

[cyberbeing]

What's wrong?
Downstream video filters shouldn't be allowed to connect with formats that the user has explicitly disabled in FFDShow? When an end-user disables something, the expectation is for it to always stay disabled?

FFDShow shouldn't do an 8-bit->10-bit conversion for 8-bit 4:2:0 video if the filter/renderer supports YV12/NV12, even if it asks for P010? From a performance and practicality point of view, FFDshow should only perform 8-bit -> 10-bit conversion as a last resort if the filter/renderer doesn't accept any 8-bit formats?

Both fall under the umbrella of having FFDShow using its knowledge of the video bit-depth and chroma sub-sampling to make smarter output format decisions, and not allow other filters to do stupid things because they don't know any better. Leaving FFDShow converters completely unrestricted as they are now, has both advantages and disadvantages.

filter requests ffdshow to connect using NV12, and so ffdshow accepts it
That xy-VSFilter test build requesting formats it shouldn't be requesting was the biggest issue in that build. FFDShow was indeed doing exactly what xy-VSFilter asked, and that was the problem.
Be modest, you have to deal with existing filters.
The only reason I PM'ed you a broken build was because it was causing some 'odd' behavior in FFDShow, not because xy planned to keep it that way. Changes to this fix this undesired behavior were already underway before I originally posted.

[xy]

What's wrong?

I'll repeat it:
Any trans-in-place filter will have reconnection logic. It means that when such filters connect to ffdshow, ffdshow may output unallowed formats.


Your filter requests ffdshow to connect using NV12, and so ffdshow accepts it even if NV12 is unchecked in the dialog.

Before the request, xy-VSFilter would quire ffdshow if it want to output NV12, and ffdshow returns OK even if NV12 is unchecked in the dialog.

[haruhiko_yamagata]

Downstream video filters shouldn't be allowed to connect with formats that the user has explicitly disabled in FFDShow? When an end-user disables something, the expectation is for it to always stay disabled?
As xy explained above, ffdshow must output unallowed formats. It is already connected and rejecting reconnection is not a good choice even if it is possible in QuerryAccept.

FFDShow shouldn't do an 8-bit->10-bit conversion for 8-bit 4:2:0 video if the filter/renderer supports YV12/NV12, even if it asks for P010? From a performance and practicality point of view, FFDshow should only perform 8-bit -> 10-bit conversion as a last resort if the filter/renderer doesn't accept any 8-bit formats?
xy-filter force ffdshow to do so.

Both fall under the umbrella of having FFDShow using its knowledge of the video bit-depth and chroma sub-sampling to make smarter output format decisions, and not allow other filters to do stupid things because they don't know any better. Leaving FFDShow converters completely unrestricted as they are now, has both advantages and disadvantages.
ffdshow has no choice in this case.

That xy-VSFilter test build requesting formats it shouldn't be requesting was the biggest issue in that build. FFDShow was indeed doing exactly what xy-VSFilter asked, and that was the problem. The only reason I PM'ed you a broken build was because it was causing some 'odd' behavior in FFDShow, not because xy planned to keep it that way. Changes to this behavior were already underway before I originally posted.
Please don't send me a broken build!
Without any explanation...
It's not odd at all. It's a computer program and it works as it is forced to do.

[haruhiko_yamagata]

I'll repeat it:
Any trans-in-place filter will have reconnection logic. It means that when such filters connect to ffdshow, ffdshow may output unallowed formats.
So ffdshow is working as it should. What do you want to say?

[xy]

So ffdshow is working as it should. What do you want to say?

FFDShow has unexpected behavior when working with any filters that have reconnection logic, not only xy-VSFilter. So you are confirming that?

[xy]

rejecting reconnection is not a good choice even if it is possible in QuerryAccept

If QuerryAccept returns the right value, than the reconnection never happen. If a downstream filter do a reconnection before QuerryAccept or even if upstream filter doesnot accept it, than that is its fault.

[cyberbeing]

Please don't send me a broken build!
Without any explanation...
My mistake, I'll try to be a bit more clear in the future. :scared:

When I stated it was a "work-in-progress test build", from secondary "refactor branch", which I was unwilling to post publicly, I was attempting to imply it was experimental non-release build which had known issues and bugs.The build was sent only to assist in reproducing the behavior and determining why FFDShow was doing what it was doing.

After-all, FFDShow is the only decoder which contains an unrestricted 8bit->10bit converter, and that is the main reason why that build broke. Fault of xy-VSFilter for not anticipating it. ;)

[haruhiko_yamagata]

If QuerryAccept returns the right value, than the reconnection never happen. If a downstream filter do a reconnection before QuerryAccept or even if upstream filter doesnot accept it, than that is its fault.
I know ffdshow can return an error on QuerryAccept. But QuerryAccept may be called for an inevitable reason (for example, the hardware can no longer accept the prior color space), in that case, rejecting may result the application stop working. What happens after rejection depends on the downstream. ffdshow's choice is to keep connection as long as it is possible even by outputting unckecked color space. It's not violating the manner of DirectShow at all.
ffdshow had code to reject that strictly, which is currently disabled (TffdshowDecVideo::setOutputMediaType etc). It was Milan's choice and I completely agree with him.

[xy]

I know ffdshow can return an error on QuerryAccept. But QuerryAccept may be called for an inevitable reason (for example, the hardware can no longer accept the prior color space), in that case, rejecting may result the application stop working. What happens after rejection depends on the downstream. ffdshow's choice is to keep connection as long as it is possible even by outputting unckecked color space. It's not violating the manner of DirectShow at all.
ffdshow had code to reject that strictly, which is currently disabled (TffdshowDecVideo::setOutputMediaType etc). It was Milan's choice and I completely agree with him.

Ah, that's news to me. Although I'm not really understand the technic point, (for COREAVC returns an error on QuerryAccept. Or think about it in another way, if ffdshow is queried for some formats it doesnot implement, then it still needs to reject. The unchecked types can be seen as unimplemented types.) I'm OK with this answer.

[haruhiko_yamagata]

Ah, that's news to me. Although I'm not really understand the technic point, (for COREAVC returns an error on QuerryAccept. Or think about it in another way, if ffdshow is queried for some formats it doesnot implement, then it still needs to reject. The unchecked types can be seen as unimplemented types.) I'm OK with this answer.ffdshow rejects connection if the media type is not supported. There are not too may formats that ffdshow can connect.const TcspFcc cspFccs[]= {
_l("YV12") ,FOURCC_YV12,FF_CSP_420P|FF_CSP_FLAGS_YUV_ADJ,false,true,
_l("I420/IYUV"),FOURCC_I420,FF_CSP_420P|FF_CSP_FLAGS_YUV_ADJ|FF_CSP_FLAGS_YUV_ORDER,false,true,
_l("YUY2") ,FOURCC_YUY2,FF_CSP_YUY2,false,true,
_l("YVYU") ,FOURCC_YVYU,FF_CSP_YVYU,false,true,
_l("UYVY") ,FOURCC_UYVY,FF_CSP_UYVY,false,true,
_l("VYUY") ,FOURCC_VYUY,FF_CSP_VYUY,false,true,
_l("RGB32") ,FOURCC_RGB3,FF_CSP_RGB32,true,true,
_l("RGB24") ,FOURCC_RGB2,FF_CSP_RGB24,true,true,
_l("RGB555") ,FOURCC_RGB5,FF_CSP_RGB15,true,true,
_l("RGB565") ,FOURCC_RGB6,FF_CSP_RGB16,true,true,
_l("CLJR") ,FOURCC_CLJR,FF_CSP_CLJR,false,false,
_l("Y800") ,FOURCC_Y800,FF_CSP_Y800,false,true,
_l("NV12") ,FOURCC_NV12,FF_CSP_NV12,false,false,
_l("P016") ,FOURCC_P016,FF_CSP_P016,false,false,
_l("P010") ,FOURCC_P010,FF_CSP_P010,false,false,
_l("P210") ,FOURCC_P210,FF_CSP_P210,false,false,
_l("P216") ,FOURCC_P216,FF_CSP_P216,false,false,
_l("AYUV") ,FOURCC_AYUV,FF_CSP_AYUV,false,false,
_l("Y416") ,FOURCC_Y416,FF_CSP_Y416,false,false,
NULL,0
};

[madshi]

ffdshow handles soft-telecine internally if detected. It average timestamps and output the frame as progressive. So video renderers do not have to take care of soft-telecine. In theory...
Please make sure "Soft telecine" is checked in "Decoder options" page. And enable OSD "Frame timestamps" and "Frame duration".
ffdshow might be failing to detect soft-telecine. In that case, please send me the sample.
By the way, current MPEG2 decoders in ffdshow doesn't seem to be stable...
Thanks, I didn't know that "soft telecine" option in the decoder options. That option seems to work ok if the whole stream is soft-telecined. But if the stream is a mixture of soft- and hard-telecine (I mean if it switches between soft- and hard-telecine all the time), it fails to do IVTC properly. That probably was to be expected, so it's not a bug. Doesn't matter, anyway, cause I'm working on my own IVTC algorithm. So I've disabled that "soft telecine" option in ffdshow. After I did that, things looked better, but there's still something wrong. With the "soft telecine option" disabled, here are the flags madVR receives from ffdshow:

168: top field first: -, repeat first field: +
169: top field first: +, repeat first field: -
170: top field first: +, repeat first field: +
171: top field first: -, repeat first field: -
172: top field first: -, repeat first field: +
173: top field first: +, repeat first field: -
174: top field first: +, repeat first field: -
175: top field first: +, repeat first field: -
176: top field first: +, repeat first field: -
177: top field first: +, repeat first field: -
178: top field first: +, repeat first field: -
179: top field first: -, repeat first field: -
180: top field first: -, repeat first field: -
181: top field first: -, repeat first field: +
182: top field first: +, repeat first field: -
183: top field first: +, repeat first field: +
184: top field first: -, repeat first field: -
185: top field first: -, repeat first field: +
For comparison, here are the correct flags, output by ffmpeg/libav directly:

168: top field first: -, repeat first field: +
169: top field first: +, repeat first field: -
170: top field first: +, repeat first field: +
171: top field first: -, repeat first field: -
172: top field first: -, repeat first field: +
173: top field first: +, repeat first field: -
174: top field first: +, repeat first field: -
175: top field first: +, repeat first field: -
176: top field first: +, repeat first field: -
177: top field first: +, repeat first field: -
178: top field first: +, repeat first field: -
179: top field first: +, repeat first field: +
180: top field first: -, repeat first field: -
181: top field first: -, repeat first field: +
182: top field first: +, repeat first field: -
183: top field first: +, repeat first field: +
184: top field first: -, repeat first field: -
185: top field first: -, repeat first field: +
You can see that the video switches from soft-telecine to hard-telecine in frame 173. Then it switches back to soft-telecine in frame 179. But ffdshow doesn't output the correct flags for frame 179. This results in my IVTC algorithm detecting a break in the 3:2 cadence. With the correct flags there's no cadence break detected, and my algorithm walks right through the soft->hard->soft telecine switch.

[haruhiko_yamagata]

But if the stream is a mixture of soft- and hard-telecine (I mean if it switches between soft- and hard-telecine all the time), it fails to do IVTC properly.Yeah, there are such difficult streams. I have not looked into the code detail, but I can imagine it's failing to detect the switching. I have too much to do, please wait.

[madshi]

Yeah, there are such difficult streams. I have not looked into the code detail, but I can imagine it's failing to detect the switching. I have too much to do, please wait.
Please don't misunderstand me. I couldn't care less about whether ffdshow's internal IVTC algorithm works or not. The only thing that bothers me is that if I tell ffdshow to *NOT* try to do IVTC, then it outputs wrong flags. The fix for that should be pretty easy. In this configuration ffdshow should not even try to detect the switching. It should just plain and simply output the video bitstream flags as they are. Nothing should be simpler than that.

[Blight]

Thank you for testing that filter. I've been thinking of removal of the registration, but if you have any plan to use it, I'll fix it.

Hi,
I'm not sure what you mean by "removal of the registration".
I allow users to choose between FFDShow and VobSub for subtitle rendering in ZP.
I'm rewriting all the stream-selection code for v8.1 and encountered this bug.

[Reino]

http://img847.imageshack.us/img847/4470/ffdshowrev4142.th.jpg (http://img847.imageshack.us/img847/4470/ffdshowrev4142.jpg)

Caused by Rev.4142? Rev.4127 didn't have this.


Btw, when I'm calling forth FFDShow's cubic interpolation deinterlacing filter through Avisynth;ffdshow(options="isDeinterlace=1,deinterlaceAlways=1,deinterlaceMethod=2") it works flawlessly in AvsP (GUI for Avisynth) and in any DirectShow player, but NOT in MPC-HC. Script error: there is no function named "ffdshow" is what I'm being shown. Are you developers familiar with this? (perhaps I should post this in MPC-HC's thread as well, because it initially concerns MPC-HC of course)

[Reino]

VC1 crash was fixed yesterday. It still randomly crashes while closing the player though.I thought MPC-HC's code and FFDShow were pretty much identical, or at least have a lot simularities, but when I'm testing a 1280x720 60fps WMV[VC-1+WMA9.2]-file with MPC-HC's internal VC-1 decoder my cpu is @ ±10% utilization and plays absolutely smooth, while with the FFDShow DXVA Video Decoder it's @ ±50% and a bit choppy every now and then.

[haruhiko_yamagata]

Hi,
I'm not sure what you mean by "removal of the registration".
I allow users to choose between FFDShow and VobSub for subtitle rendering in ZP.
I'm rewriting all the stream-selection code for v8.1 and encountered this bug.
I have fixed the crash issue and dialog problem at rev 4137-4138.

[Thunderbolt8]

when playing some VC-1 videos with the WMV DecoderDMO and ffdshow set to raw video (and LAVsplitter), the screen remains dark and playback doesnt start. it works fine though when deactivating ffdshow. why is this?

heres an example: http://www.mediafire.com/?vhxgz1qwxmc2u6b

[ryrynz]

Haruhiko, regarding the bug I posted earlier,

If you create a preset under ffdshow raw that does not have the same name as a preset under normal ffdshow then there is no default selected (nothing in bold) This is as I would expect.

If you click on create a new profile from selected, ffdshow crashes with an error in rundll32 and exits instead of throwing up an error that no profile is selected.

Also if you click on codecs while no preset is selected the rest of the menu items disappear.

[fano]

Its not possible because none of the "HD" codecs have a free encoder available. You should rather go debug your audio setup, its certainly possible to stop windows from messing with it.

I'll try to use an example:
Yesterday I was playing (using Foobar it should be the best audio player, right?) one of these free to use flac multichannel audio clip:
http://www.2l.no/hires/index.html

then I decide to browse a little... Firefox I don't why likes to do a little "click" :(
... foobar is in the trash... and of the suber-uber audio session if it does "click" it's unuseful.

I do know there is a thing know as "Kernel Streaming" that should bypass windows mixer et all but... foobar after installing the KS plugin says that "I can't open device" :angry:

The only way to play a song in peace it's to use ffdshow or reclock "AC3 encode mode"... you agree it's pretty ridiculous to compress an HD lossless track to no hear the "click" :sly:

[haruhiko_yamagata]

http://img847.imageshack.us/img847/4470/ffdshowrev4142.th.jpg (http://img847.imageshack.us/img847/4470/ffdshowrev4142.jpg)

Caused by Rev.4142? Rev.4127 didn't have this.
A Microsoft's DirectShow filter "AVI/WAV File Source" can somehow process avs file and output raw formats, but it cannot connect directly to a video renderer. I don't know if it is a intended feature by the AviSynth project or just a user's hack.
A week ago (http://forum.doom9.org/showthread.php?p=1543126#post1543126), I didn't believe that YV12 does not connect to a video renderer. This time I found the truth. As an intermediate filter, ffdshow or Microsoft's color space converter filter is needed.
I think All filters that can directly work with a video renderer can handle stride changes. Unfortunately AVI/WAV File Source cannot handle stride changes.
I hope this is the only exception that require dirty workaround. The code for this has been written (not committed yet).

[haruhiko_yamagata]

Haruhiko, regarding the bug I posted earlier,

If you create a preset under ffdshow raw that does not have the same name as a preset under normal ffdshow then there is no default selected (nothing in bold) This is as I would expect.

If you click on create a new profile from selected, ffdshow crashes with an error in rundll32 and exits instead of throwing up an error that no profile is selected.

Also if you click on codecs while no preset is selected the rest of the menu items disappear.
I see. The crash is reproduced.

[Blight]

haruhiko_yamagata:
Thank you for the fix.

[Blight]

Bug Report:
When using the VobSub COM interface with the "putParamStrW(IDFF_subFilename,FileName)", it doesn't update the IAMStreamSelect interface.
I expect it to only list the specified file, or add the specified subtitle file to the existing stream list (preferable).
Note that I'm using "putParam(IDFF_subAutoFlnm,False)" to enable the user-selected external sub-file.

More details:
If no auto-sub file is found by the ffdshow sub filter and one is manually loaded by the functions above, the IAMStreamSelect interface returns no streams whatsoever.

P.S.
The RAW and Subtitle filter instances seem to share the same registry location to save their settings. Is this intentional?

[haruhiko_yamagata]

when playing some VC-1 videos with the WMV DecoderDMO and ffdshow set to raw video (and LAVsplitter), the screen remains dark and playback doesnt start. it works fine though when deactivating ffdshow. why is this?

heres an example: http://www.mediafire.com/?vhxgz1qwxmc2u6bThe freeze is reproduced.
I don't know why though.

[haruhiko_yamagata]

Btw, when I'm calling forth FFDShow's cubic interpolation deinterlacing filter through Avisynth;ffdshow(options="isDeinterlace=1,deinterlaceAlways=1,deinterlaceMethod=2") it works flawlessly in AvsP (GUI for Avisynth) and in any DirectShow player, but NOT in MPC-HC. Script error: there is no function named "ffdshow" is what I'm being shown. Are you developers familiar with this? (perhaps I should post this in MPC-HC's thread as well, because it initially concerns MPC-HC of course)
I can reproduce. Old MPC works fine.

[clsid]

AviSynth plugin loading issues can be solved by adding the plugin dir to %PATH%.

[haruhiko_yamagata]

Please don't misunderstand me. I couldn't care less about whether ffdshow's internal IVTC algorithm works or not. The only thing that bothers me is that if I tell ffdshow to *NOT* try to do IVTC, then it outputs wrong flags. The fix for that should be pretty easy. In this configuration ffdshow should not even try to detect the switching. It should just plain and simply output the video bitstream flags as they are. Nothing should be simpler than that.OK, but as you can see, I'm buried too deeply in too many bugs. Please wait.

[madshi]

OK, but as you can see, I'm buried too deeply in too many bugs. Please wait.
I'm not in a hurry, take all the time you need... :)

[Reino]

AviSynth plugin loading issues can be solved by adding the plugin dir to %PATH%.ffavisynth.avsi:
try { Load_Stdcall_Plugin("C:\Program Files\Media\AviSynth 2.5\plugins\ffavisynth.dll") }
catch(err_msg) { NOP() }Confirmed! Still funny though, again this only affects MPC-HC, unlike Zoom Player and alike.

Btw, haruhiko_yamagata, thanks for your time.

[Thunderbolt8]

The freeze is reproduced.
I don't know why though.
I got it to work by unticking the internal MPEG PS/TS/PVA filter in MPC-HC (also updated to the latest test version of LAVfilters, not sure whether this had an effect though).

and the bottom of the loaded filter list in MPC-HC, theres a filter called "File Source (Async)" loaded now as well. got no idea what for though.

[egur]

Lately I'm getting a lot of runtime errors from libavcodec under WMC 64 bit.
WMC spawns a lot of ffdshow instances in order to create thumbnails for media files.
The error is that memory is written past the area allocated to the av context. Happens when this line is called (TvideoCodecLibavcodec.cpp):
libavcodec->av_free(avctx);
Running Parallel Inspector (memory checker) didn't reveal anything and looking at the code didn't point me to the problem. Looks like a memory overrun from somewhere in the code.
The above error is followed by a second one - the pointer sent to RtlFreeHeap (Ntdll.dll) is bad.
Commenting the above line removes all the runtime errors.

BTW, due to lazyness, I didn't compile the ffmpeg dll, I used the one from the last clsid build from SourceForge.

This can also happen when opening a file in WMC and skipping a few times.
The crash always happen then libavcodec is decoding video. Crashed on h264 content among others.

Can someone reproduce?

[haruhiko_yamagata]

I got it to work by unticking the internal MPEG PS/TS/PVA filter in MPC-HC (also updated to the latest test version of LAVfilters, not sure whether this had an effect though).

and the bottom of the loaded filter list in MPC-HC, theres a filter called "File Source (Async)" loaded now as well. got no idea what for though.
I'm not sure if this is a bug of ffdshow or not, but as far as I can observe, ffdshow is not called an after successful call to IPin::NewSegment. It doesn't look like a dead lock in ffdshow. There's little hint to fix this in ffdshow.
Please submit a request to MPC-HC project and ask if they can help us.

[haruhiko_yamagata]

Bug Report:
When using the VobSub COM interface with the "putParamStrW(IDFF_subFilename,FileName)", it doesn't update the IAMStreamSelect interface.
I expect it to only list the specified file, or add the specified subtitle file to the existing stream list (preferable).
Note that I'm using "putParam(IDFF_subAutoFlnm,False)" to enable the user-selected external sub-file.

More details:
If no auto-sub file is found by the ffdshow sub filter and one is manually loaded by the functions above, the IAMStreamSelect interface returns no streams whatsoever.I'll take a look later.

P.S.
The RAW and Subtitle filter instances seem to share the same registry location to save their settings. Is this intentional?
I might have thought that it was unnecessary to separate the settings. On second thought, it may be better to separate.

[haruhiko_yamagata]

Lately I'm getting a lot of runtime errors from libavcodec under WMC 64 bit.
WMC spawns a lot of ffdshow instances in order to create thumbnails for media files.
The error is that memory is written past the area allocated to the av context. Happens when this line is called (TvideoCodecLibavcodec.cpp):
libavcodec->av_free(avctx);
Running Parallel Inspector (memory checker) didn't reveal anything and looking at the code didn't point me to the problem. Looks like a memory overrun from somewhere in the code.
The above error is followed by a second one - the pointer sent to RtlFreeHeap (Ntdll.dll) is bad.
Commenting the above line removes all the runtime errors.

BTW, due to lazyness, I didn't compile the ffmpeg dll, I used the one from the last clsid build from SourceForge.

This can also happen when opening a file in WMC and skipping a few times.
The crash always happen then libavcodec is decoding video. Crashed on h264 content among others.

Can someone reproduce?I have not looked into the issue yet. Did you try a new binary? New version is available from XvidVideo.RU (http://www.xvidvideo.ru/x264-video-codec).
Binary compatibility of libavcodec.dll is not guaranteed between versions.

[oddball]

Any idea on that logo away issue? I can't mask out the very edges of a logo that are right up to the edges of the video.

[Blight]

haruhiko_yamagata:
I have a very weird ffdshow subtitle renderer behavior.
I've written an automatic subtitle stream-selection code based on Language ID, Name, etc.
When I'm enabling a stream matching the user params right after the graph is built, depending on what appears to be a race condition, it seems ffdshow is selecting a different (external file) subtitle stream after I specify the stream I want (one of several embedded streams) using the IAMStreamSelect interface.

If I enable 'give embedded priority over subtitle files', it seems to fix the issue, but I haven't tested it against enough content and other splitter filters.
Can you disable FFDShow from selecting a subtitle stream itself if the IAMStreamSelect interface was issued a call to enable a stream?

Another cosmetic glitch:
If you have both the FFDShow Video decoder and the FFDShow Subtitle filter in the same graph, the FFDShow video decoder's IAMStreamSelect interface contains duplicate streams (The vid decoder grabs the stream list from the sub-filter).
You need to blacklist other ffdshow filters when building the stream list.

Screenshot:
http://t.inmatrix.com/ffdshowglitch.png

[haruhiko_yamagata]

haruhiko_yamagata:
I have a very weird ffdshow subtitle renderer behavior.
I've written an automatic subtitle stream-selection code based on Language ID, Name, etc.
When I'm enabling a stream matching the user params right after the graph is built, depending on what appears to be a race condition, it seems ffdshow is selecting a different (external file) subtitle stream after I specify the stream I want (one of several embedded streams) using the IAMStreamSelect interface.

If I enable 'give embedded priority over subtitle files', it seems to fix the issue, but I haven't tested it against enough content and other splitter filters.
Can you disable FFDShow from selecting a subtitle stream itself if the IAMStreamSelect interface was issued a call to enable a stream?

Another cosmetic glitch:
If you have both the FFDShow Video decoder and the FFDShow Subtitle filter in the same graph, the FFDShow video decoder's IAMStreamSelect interface contains duplicate streams (The vid decoder grabs the stream list from the sub-filter).
You need to blacklist other ffdshow filters when building the stream list.

I'm not familiar with that part, but I'll have to deal with it to complete my work related to subtitles. Please wait.

[haruhiko_yamagata]

I'm not in a hurry, take all the time you need... :)
It is hopefully fixed at rev 4145. Please try the latest version.

[haruhiko_yamagata]

Haruhiko, regarding the bug I posted earlier,

If you create a preset under ffdshow raw that does not have the same name as a preset under normal ffdshow then there is no default selected (nothing in bold) This is as I would expect.

If you click on create a new profile from selected, ffdshow crashes with an error in rundll32 and exits instead of throwing up an error that no profile is selected.

Also if you click on codecs while no preset is selected the rest of the menu items disappear.
The crash has been fixed at rev 4146. The active preset should be saved separately for video/audio decoder and raw filters. The work is in progress.

[haruhiko_yamagata]

Any idea on that logo away issue? I can't mask out the very edges of a logo that are right up to the edges of the video.
I have never used that filter. How do you use the filter? Settings, etc.
Please send me the sample and the "Logo image", if you have one.

[madshi]

It is hopefully fixed at rev 4145. Please try the latest version.
There's something wrong, I don't get *any* repeatfirstfield flags, anymore, now. See "AM_VIDEO_FLAG_REPEAT_FIELD" here:

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

[egur]

I have not looked into the issue yet. Did you try a new binary? New version is available from XvidVideo.RU (http://www.xvidvideo.ru/x264-video-codec).
Binary compatibility of libavcodec.dll is not guaranteed between versions.

Looks like the 4052 build had a bad ffmpeg.dll build (x64).
The 4147 build from XvidVideo.RU works great - no memory corruption :) --with resפect to my tests anyway.

[mkanet]

This affect's all ffdshow versions as far as I know. I'm currently using: ffdshow_rev4150_20111215_clsid

I am trying to playback mpeg2 videos which switch between soft and hard telecine using ffdshow's internal mpeg2 decoder + avisynth IVTC/deinterlace.

The problem is that the internal “ffdshow_source” source filter that is used to get frames from ffdshow into AviSynth is not honoring soft pulldowns when fed to the avisynth IVTC plugin (TIVTC or Decomb). It needs to behave the same way as if the video was fed from DGDecode (or any avisynth mpeg2 decoder would).

Could someone PLEASE enhance the existing "ffdshow_source" source filter to honor soft pulldowns in the same fashion when DGDecode does? I'm hopeful this will be fixed in the next beta release.

Normally, I wouldn't make a big deal about this. However, this type of mix soft/hard telecine video is extremely common in America; as, it's the encoding format used by many cableTV content providers like HBO, Showtime, Cinemax, etc; played back by millions of people (mostly on STB cableboxes).

PS: I have "Detect soft telecine and average frame durations" disabled in ffdshow in order for the IVTC plugin in Avisynth to remove 3:2 pulldown correctly to 23.976fps.

Below are some video clips to test against. Each have hard and soft telecine in them at 1080i.

Here they are:
http://www.megaupload.com/?d=8D8Q1Q5G
http://www.megaupload.com/?d=D8X708QK
http://www.megaupload.com/?d=P827WH5F

Thank you for all your hard work guys!
MKANET

[haruhiko_yamagata]

This affect's all ffdshow versions as far as I know. I'm currently using: ffdshow_rev4150_20111215_clsid

I am trying to playback mpeg2 videos which switch between soft and hard telecine using ffdshow's internal mpeg2 decoder + avisynth IVTC/deinterlace.

The problem is that the internal “ffdshow_source” source filter that is used to get frames from ffdshow into AviSynth is not honoring soft pulldowns when fed to the avisynth IVTC plugin (TIVTC or Decomb). It needs to behave the same way as if the video was fed from DGDecode (or any avisynth mpeg2 decoder would).

Could someone PLEASE enhance the existing "ffdshow_source" source filter to honor soft pulldowns in the same fashion when DGDecode does? I'm hopeful this will be fixed in the next beta release.

Normally, I wouldn't make a big deal about this. However, this type of mix soft/hard telecine video is extremely common in America; as, it's the encoding format used by many cableTV content providers like HBO, Showtime, Cinemax, etc; played back by millions of people (mostly on STB cableboxes).

PS: I have "Detect soft telecine and average frame durations" disabled in ffdshow in order for the IVTC plugin in Avisynth to remove 3:2 pulldown correctly to 23.976fps.

Below are some video clips to test against. Each have hard and soft telecine in them at 1080i.

Here they are:
http://www.megaupload.com/?d=8D8Q1Q5G
http://www.megaupload.com/?d=D8X708QK
http://www.megaupload.com/?d=P827WH5F

Thank you for all your hard work guys!
MKANET
Thanks for your report and samples. I'll take a look later.

[haruhiko_yamagata]

There's something wrong, I don't get *any* repeatfirstfield flags, anymore, now. See "AM_VIDEO_FLAG_REPEAT_FIELD" here:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd373499%28v=vs.85%29.aspx
Sorry for that. I reverted rev 4145 at rev 4153.
By the way, is it MPEG-2, VC1 or H.264? Does libmpeg2 or libavcodec matter?

[madshi]

Sorry for that. I reverted rev 4145 at rev 4153.
By the way, is it MPEG-2, VC1 or H.264? Does libmpeg2 or libavcodec matter?
No worries. I had tested with MPEG2 libavcodec. But now I've retested and the same problems occur with libmpeg2 and h264 libavcodec, too. I tested with 4145, though.

Edit: It is most important for MPEG2, but it would be good to have working for h264, too. It's not so important for other codecs because it's mostly only broadcasts which are affected, and those are all either MPEG2 or h264. Ok, some Blu-Ray content may be affected, too, and that in theory could be VC-1, but I've not yet seen such content (affected VC-1 content, I mean).

[clsid]

Everyone please give the latest build some thorough testing. All known regressions have now been fixed I think.

Stuff that needs some extra attention during testing:
- DXVA
- 10-bit colorspace handling. Test in combination with madVR.
- The various processing filters with 10-bit input. Be aware that most are not compatible with those colorspaces, so the expected behavior for those filter is "no effect". Crashes and messed up video are bugs.
- There have been some major audio changes in Libav, so test all audio decoders.
- Intel QuickSync decoder, if you have an Intel Sandy Bridge processor.

Everyone who has recently reported a bug that hasn't been fixed yet, please add it to the bugtracker if you haven't done so already. That way it won't be forgotten.

[haruhiko_yamagata]

- The various processing filters with 10-bit input. Be aware that most are not compatible with those colorspaces, so the expected behavior for those filter is "no effect". Crashes and messed up video are bugs.
Currently only resize (10 to 10) and RGB conversion (10 to 8) supports native 10-bit processing. All other image filters converts 10-bit to 8-bit and apply the filter.
10-bit raw input is not supported. Of course it's useless unless we add more 10-bit native filter.
Yadif is a candidate for 10-bit native processing. If you think it's cool, please provide a 10-bit interlaced sample to motivate me.

[Reino]

- There have been some major audio changes in Libav, so test all audio decoders.Crash when trying to open:
- http://samples.mplayerhq.hu/A-codecs/amr/sample.amr (http://samples.mplayerhq.hu/A-codecs/amr/sample.amr)
- http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.tta (http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.tta)

Decoding failure:
- DVD-Audio-testfile (ARAW;24bit,96000Hz,4608Kbs).mka (http://www.mediafire.com/?km42s999u8rgfcc)
Demuxing the WavPack Audio from the Matroska container and trying to play that fails too.

I believe it's been reported before, but anyway:
- http://media.nero.com/Standard720x576_1MBit.mp4 (http://media.nero.com/Standard720x576_1MBit.mp4)
AAC Audio part decoding failure with libavcodec. No problem though with libfaad2.

[mkanet]

Thank you so much. I've waited a long time for someone to be able to have a realtime hard/soft pulldown IVTC solution in ffdshow.

I know this has been asked many times, but I will ask anyway... adding full IVTC support (hard and soft telecine) natively in ffdshow would be ideal.

However, I'm guessing it would be less hassle to get soft/hard IVTC switching to work correctly in ffdshow -->avisynth.

Thanks for your report and samples. I'll take a look later.

[clsid]

I believe it's been reported before, but anyway:
- http://media.nero.com/Standard720x576_1MBit.mp4 (http://media.nero.com/Standard720x576_1MBit.mp4)
AAC Audio part decoding failure with libavcodec. No problem though with libfaad2.Fixed.

[clsid]

Crash when trying to open:
- http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.tta (http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.tta)Fixed.

[clsid]

Decoding failure:
- DVD-Audio-testfile (ARAW;24bit,96000Hz,4608Kbs).mka (http://www.mediafire.com/?km42s999u8rgfcc)
Demuxing the WavPack Audio from the Matroska container and trying to play that fails too.Fixed.

[clsid]

Crash when trying to open:
- http://samples.mplayerhq.hu/A-codecs/amr/sample.amr (http://samples.mplayerhq.hu/A-codecs/amr/sample.amr)Fixed.

[TheShadowRunner]

Clsid, maybe you remember the FLV4/VP6 cropping issue.
Nev has found a solution (http://code.google.com/p/lavfilters/source/detail?r=859e3bcc3aa6) for LAV Video Dec, could it be implemented in FFDshow too?

[ryrynz]

The crash has been fixed at rev 4146. The active preset should be saved separately for video/audio decoder and raw filters. The work is in progress.

I tested with 4158 and the crash still occurs, also if I just highlight any preset and exit whilst it's highlighted (when a raw preset is set to default)
it crashes as well, same error in rundll32, thanks for looking into it though, I know it's not terribly important.
Did you happen to look into the problem with Avisynth scripts carrying over in the export registry file by chance?

[haruhiko_yamagata]

I tested with 4158 and the crash still occurs, also if I just highlight any preset and exit whilst it's highlighted (when a raw preset is set to default)
it crashes as well, same error in rundll32, thanks for looking into it though, I know it's not terribly important.
Did you happen to look into the problem with Avisynth scripts carrying over in the export registry file by chance?I cannot reproduce. If I enter random value to "activePreset" in registry, the highlight is lost. ffdshow still does not crash.
But I think loss of highlight won't happen with 4155.
Avisynth script exporting: Not yet. I'll do it later.

[ryrynz]

I think a reboot might have helped because now when I select a default in raw the default in normal ffdshow is not changed and it remains in bold, thanks!
I've always thought it would be nice to be able to access the raw config by shortcut, is this possible?

[haruhiko_yamagata]

I've always thought it would be nice to be able to access the raw config by shortcut, is this possible?
Copy the short cut for video decoder and replace "configure" with "configureRaw".

[Midzuki]

Copy the short cut for video decoder and replace "configure" with "configureRaw".

It would be nice if the installer itself created those shortcuts that "nobody uses" :rolleyes: :)

[ryrynz]

LOL, thanks for the backup there Midzuki, I don't want to seem too demanding, he's already fixed a bug I've put up with for years I think.
If he fixes the other one I be a happy chappy. It's great having a developer getting stuck in and moving ffdshow forward.

[haruhiko_yamagata]

It would be nice if the installer itself created those shortcuts that "nobody uses" :rolleyes: :)
It would be one line, but it depends on the needs. More items in the start menu may confuse the beginners.
clsid, what do you think?

[clsid]

There is no and will be no shortcut for the raw filter because it is not a filter that is used automatically. It is a filter that must be manually inserted by an application, and that app is responsible for access to its config. Apps that use it for the purpose it was designed for do typically provide a way to access its settings. Be it by a config button or otherwise. In MPC the config can be accessed by double-clicking on the filter name in the external filters dialog window.

It is a filter for expert users. It is not for the average joe. Adding it to the start menu will make people mess with its settings, without them understanding the purpose of the filter, making them complain about it not working as they might expect.

I suspect some here are also misusing the filter. In most cases the regular ffdshow video filter should be used with raw video enabled.

[clsid]

Clsid, maybe you remember the FLV4/VP6 cropping issue.
Nev has found a solution (http://code.google.com/p/lavfilters/source/detail?r=859e3bcc3aa6) for LAV Video Dec, could it be implemented in FFDshow too?A similar solution was used for a short while in past, but it is not a proper solution for ffdshow because ffdshow has filters that can change the dimensions of the video (resize,crop,letterbox). Such changes must be taking into account when sending cropping info downstream. Fixing it in ffdshow is thus less trivial.

[TheShadowRunner]

A similar solution was used for a short while in past, but it is not a proper solution for ffdshow because ffdshow has filters that can change the dimensions of the video (resize,crop,letterbox). Such changes must be taking into account when sending cropping info downstream. Fixing it in ffdshow is thus less trivial.
Arg, that's what I feared ^^;
Thanks for your reply.

[Midzuki]

@ clsid: Thanks for making things clear :thanks:

[ryrynz]

It is a filter for expert users. It is not for the average joe. Adding it to the start menu will make people mess with its settings, without them understanding the purpose of the filter, making them complain about it not working as they might expect.

I suspect some here are also misusing the filter. In most cases the regular ffdshow video filter should be used with raw video enabled.

I was thinking the reason behind this was along these lines, perhaps it could be an option selected under components when installing? Anyway it's rather trivial and Haruhiko has already provided a solution. I have always accessed it in when it was functioning through the player.

I am curious as to how one could misuse the filter.

[cyberbeing]

Libavcodec still decodes AC3 4ch (Front Left, Front Right, Front Center, Back Center) with the incorrect channel mapping. Only Liba52 and LAV Audio get that uncommon mapping correct.

See the sample JEEB posted a couple weeks ago:
http://forum.doom9.org/showpost.php?p=1543336&postcount=14270

[clsid]

LAV Audio is also not doing it correctly I think. It indicates a channel mask of 0x3f as input, which is the standard 5.1 mapping. It is just a coincidence that the three channels that contain sound in jeebs sample are at the same positions in both mappings.

[nevcairiel]

LAV Audio is also not doing it correctly I think. It indicates a channel mask of 0x3f as input, which is the standard 5.1 mapping. It is just a coincidence that the three channels that contain sound in jeebs sample are at the same positions in both mappings.

Thats a bug on the status page, the actual layout of the file is 0x107, which you can see if you turn off "Convert Output to Standard Channel Layouts" (also, fixed the bug)

[JEEB]

Libavcodec still decodes AC3 4ch (Front Left, Front Right, Front Center, Back Center) with the incorrect channel mapping. Only Liba52 and LAV Audio get that uncommon mapping correct.

See the sample JEEB posted a couple weeks ago:
http://forum.doom9.org/showpost.php?p=1543336&postcount=14270
This also reminds me that the sample I originally posted had no audio on the BC channel, which would make check-ups harder >_>

This (http://www.cccp-project.net/beta/test_files/4ch_ac3sample_with_bc.mka) one actually has that as well.

[clsid]

Fixed at 4172.

[Reino]

I believe it's been reported before, but anyway:
- http://media.nero.com/Standard720x576_1MBit.mp4 (http://media.nero.com/Standard720x576_1MBit.mp4)
AAC Audio part decoding failure with libavcodec. No problem though with libfaad2.Fixed.Although I can confirm the other 3 issues have indeed been fixed, I have to say this one still persists.

Btw, with your latest rev, clsid, the About-tab still reports rev4127.

[hoborg]

BTW, what about "removing FFDshow DXVA decoder from graph (http://www.youtube.com/watch?v=KZreMRTsuXk)" crash? It is still there. It make it nearly useless in LiveTV applications :/
Anyone interested to fix it?

Maybe this crash is connected with FFDShow DXVA video decoder icon which remaining in systray after playback, until hower cursor over it.

This issue is still active, so i added it to bug tracker (https://sourceforge.net/tracker/?func=detail&aid=3462373&group_id=173941&atid=867360).

[hoborg]

- this h.264 sample (http://hobring.esero.net/saf/samples/ffdshow_dxva_freeze.zip) have still problem with FFDShow DXVA decoder - picture freeze, but sound continue to play. This doesnot happend with MPC-HC DXVA decoder. Strange.

Still here. Added to bugtracker (https://sourceforge.net/tracker/?func=detail&aid=3462376&group_id=173941&atid=867360).

[clsid]

@CoRoNe
It works fine here with Haali splitter and LAV Splitter. Those are the only splitters I care about. Also, I have already done everything I can to fix it.

@hoborg
I get no crash. I can't fix it.

Has the DXVA seek issue existed forever, or did it work in an older revision?

[Dstruct]

This file gives incorrect display aspect ratio (1:1 Pixel) in WMP11 and MPC-HC via ffdshow rev4170 DXVA:

General
Format : AVI
Format/Info : Audio Video Interleave
File size : 1.29 GiB
Duration : 1h 59mn
Overall bit rate : 1 551 Kbps
Writing library : VirtualDub build 32839/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : H264
Duration : 1h 59mn
Bit rate : 1 346 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.130
Stream size : 1.12 GiB (87%)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1h 59mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 164 MiB (12%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.60 video frame)
Interleave, preload duration : 504 ms


Proper display aspect ratio in Media Player Classic HC 1.5.3.3899 via internal MPC DVXA decoder!

[Dstruct]

"Info & CPU" tab also doesn't display any values from the video stream. "Surface Overlay" post processing option in ffdshow's DXVA decoder makes the videos go black or non-working here.


NVIDIA GeForce GTS 450

[hoborg]

@hoborg
I get no crash. I can't fix it.


If you drag and drop h.264 video in Graphstudio - does you have FFDshow DXVA video decoder + EVR (VMR9) chain by default?
The merit of EVR (VMR9) needs to be changed first.

[szabi]

Hi

Some avi video were recorded with ffdshow. Encoder set HuffYUV (FFmpeg variant).
When i insert them to an avisynth script as avisource this is the result: couldn't locate a decompressor for fourcc ffds
How could i solve this?

bye
szabi

[Reino]

szabi, you could use FFVideoSource() (http://avisynth.org/mediawiki/FFmpegSource) (preferred), or alternatively DirectShowSource().

@CoRoNe
It works fine here with Haali splitter and LAV Splitter. Those are the only splitters I care about. Also, I have already done everything I can to fix it.That's really odd. I'm using the latest LAV Splitter and I've tried your rev4174 and xvidvideo.ru's, but with libavcodec, unlike libfaad2, the issue still persists. I'll keep an eye on it.

[Eliminateur]

since rev >4142 i'm experiencing crashes on MPC-HC whenever i try to open big hi10p 1080p MKV files.

i have 5 of them in one directory and they all crash on open directly, if i force LAV decoder in the mpc-hc preferences, it works ok. Same if i use the internal filters.

i've updated to clsid r4174 and it's the same.

i'm using all x64 versions with haali splitter.
no DXVA -all soft decode-, RGB32 output, HQ YV12 conversion.
Latest mpc-hc r3903, was usin r3887 before(it crashed the same)

Builds i also tested:
4150 crash
4158 crash

[Snowknight26]

r4174 crashes when trying to play a lossless H.264 stream encoded with x264, but only when --output-csp (output colorspace) is specified as 'rgb'. 'i420', 'i422', and 'i444' all work correctly.

[ageback]

When compiling ICL12 version it always fail on IntelQuickSyncDecoder project, since rev.4150.
Here's the error log:

1>src\QuickSyncExports.cpp(63): error : expression must have (pointer-to-) function type
strcpy(ver, QS_DEC_VERSION " by Eric Gur. Compiled using " COMPILER " " COMPILER_VER " (" __DATE__ " " __TIME__ ")");
^

1>src\QuickSyncExports.cpp(63): error : expected a ";"
strcpy(ver, QS_DEC_VERSION " by Eric Gur. Compiled using " COMPILER " " COMPILER_VER " (" __DATE__ " " __TIME__ ")");

1>icl : error #10298: problem during post processing of parallel object compilation
TimeManager.cpp
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\Intel Parallel Composer 2011\Microsoft.Cpp.Win32.Intel Parallel Composer 2011.targets(196,5): error MSB6001: “icl.exe”的命令行开关无效(translation by me:Command line swich invalid)。参数“path”的长度不能为零(translation by me:The length of parameter "path" cannot be 0.)。

[clsid]

r4174 crashes when trying to play a lossless H.264 stream encoded with x264, but only when --output-csp (output colorspace) is specified as 'rgb'. 'i420', 'i422', and 'i444' all work correctly.
Sample file needed.

[clsid]

since rev >4142 i'm experiencing crashes on MPC-HC whenever i try to open big hi10p 1080p MKV files.

i have 5 of them in one directory and they all crash on open directly, if i force LAV decoder in the mpc-hc preferences, it works ok. Same if i use the internal filters.

i've updated to clsid r4174 and it's the same.

i'm using all x64 versions with haali splitter.
no DXVA -all soft decode-, RGB32 output, HQ YV12 conversion.
Latest mpc-hc r3903, was usin r3887 before(it crashed the same)

Builds i also tested:
4150 crash
4158 crash
Hi10p plays fine here in GraphStudio x64.
What is the crashing module?
Does x86 version crash as well?

[clsid]

If you drag and drop h.264 video in Graphstudio - does you have FFDshow DXVA video decoder + EVR (VMR9) chain by default?
The merit of EVR (VMR9) needs to be changed first.
I have located the bug, but I don't know why it crashes or how to fix it yet. If anyone want to give it a try, look here for details:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/codecs/TvideoCodecLibavcodecDxva.h?r1=4177&r2=4176&pathrev=4177

[Eliminateur]

Hi10p plays fine here in GraphStudio x64.
What is the crashing module?
Does x86 version crash as well?

no idea which is the crashing module, how do i find out?.

haven't tested with x32 at all, and i've played hi10p but small sizes (under 1GB) and it doesn't crash, it only happened with these 5 big movies (smallest one 2.6GB)

[hoborg]

I have located the bug, but I don't know why it crashes or how to fix it yet. If anyone want to give it a try, look here for details:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/codecs/TvideoCodecLibavcodecDxva.h?r1=4177&r2=4176&pathrev=4177
:thanks:

[egur]

When compiling ICL12 version it always fail on IntelQuickSyncDecoder project, since rev.4150.
Here's the error log:

I'll fix it ASAP. Had some setup problems with ICL12, so I didn't check the compilation so far...

[DigitalDeviant]

I'm getting a lot of crashes on Blu-ray subtitles displaying more than one subtitle on the screen at a time. I've tried in MPC-HC and PotPlayer and with the MPC splitter and LAV filter. It doesn't occur every time but the more multiple lines you have the more it happens. The example below crashes more often than not.

http://www.megaupload.com/?d=24ZO2T1Y

[haruhiko_yamagata]

I'm getting a lot of crashes on Blu-ray subtitles displaying more than one subtitle on the screen at a time. I've tried in MPC-HC and PotPlayer and with the MPC splitter and LAV filter. It doesn't occur every time but the more multiple lines you have the more it happens. The example below crashes more often than not.

http://www.megaupload.com/?d=24ZO2T1Y
Crash confirmed.:thanks:

[Snowknight26]

Sample file needed.

x264.x64.exe --qp 0 -o output.mkv --output-csp rgb input.mkv
http://stfcc.org/misc/H.264 High 4.4.4 Predictive RGB.mkv

[clsid]

no idea which is the crashing module, how do i find out?.

haven't tested with x32 at all, and i've played hi10p but small sizes (under 1GB) and it doesn't crash, it only happened with these 5 big movies (smallest one 2.6GB)
You can find the crash module name in the error dialog of the crash.
Please test x86 because MPC-HC x64 tends to be buggy.
When does the crash occur? Right at the start, or after a while during playback.
Next time provide all essential information in you initial bug report. That saves everyone from wasting time.

[alexins]

egur, in the file QuickSyncExports.cpp use of incorrect parameters "define".
define COMPILER_VER "ICL" and define COMPILER_VER "MSVC 2010".

Index: QuickSyncExports.cpp
===================================================================
--- QuickSyncExports.cpp (revision 6)
+++ QuickSyncExports.cpp (working copy)
@@ -41,11 +41,11 @@
# elif __INTEL_COMPILER >= 1000
# define COMPILER "ICL 10"
# else
-# define COMPILER_VER "ICL"
+# define COMPILER "ICL"
# endif
#elif defined(_MSC_VER)
# if _MSC_VER==1600
-# define COMPILER_VER "MSVC 2010"
+# define COMPILER "MSVC 2010"
# elif _MSC_VER==1500
# define COMPILER "MSVC 2008"
# else

[egur]

egur, in the file QuickSyncExports.cpp use of incorrect parameters "define".
define COMPILER_VER "ICL" and define COMPILER_VER "MSVC 2010".


Fixed at revision 4183. Finally got my ICL setup, so this shouldn't happen again. Using the latest ICL ffdshow didn't compile. fixed that too.

[alexins]

egur, now there is a problem, you can't build projects VS2010, the problem is in the IntelQuickSyncDecoder svn rev.6 (QuickSyncExports.cpp).

Here is the contents of the file QuickSyncExports.cpp svn rev.6:

#ifdef __INTEL_COMPILER
# if __INTEL_COMPILER >= 1200
# define COMPILER "ICL 12" It is correct!
# elif __INTEL_COMPILER >= 1100
# define COMPILER "ICL 11" It is correct!
# elif __INTEL_COMPILER >= 1000
# define COMPILER "ICL 10" It is correct!
# else
# define COMPILER_VER "ICL" This is wrong!
# endif
#elif defined(_MSC_VER)
# if _MSC_VER==1600
# define COMPILER_VER "MSVC 2010" This is wrong!
# elif _MSC_VER==1500
# define COMPILER "MSVC 2008" It is correct!
# else
# define COMPILER "MSVC" It is correct!
# endif
#else
# define COMPILER "Unknown and not supported compiler"
#endif

#ifndef _M_X64
# define ARCH "x86"
#else
# define ARCH "x64"
#endif

IQuickSyncDecoder* __stdcall createQuickSync()
{
return new CQuickSync();
}

void __stdcall destroyQuickSync(IQuickSyncDecoder* p)
{
delete (CQuickSync*)(p);
}

void __stdcall getVersion(char* ver, const char** license)
{
static const char s_Version[] = QS_DEC_VERSION " by Eric Gur. " COMPILER ", " ARCH " (" __DATE__ " " __TIME__ ")";
strcpy_s(ver, 100, s_Version);
*license = "(C) 2011 Intel\xae Corp.";
}

[egur]

I tried compiling ffmpeg myself and ran into a problem (ffdshow rev4183).
I tried both under cmd and mingw shell.
ffdshow crashes when loading ffmeg.dll right after it tries to load pthreadgc2.dll.
Using dependency walker, I saw that the ffmpeg.dll shipped with ffdshow doesn't link to pthreads. instead it's linked to user32.dll.

The FAQ didn't reveal anything. Also din't find an answer in previous posts...

Can anyone help?

Also, build_script.bat refuses to find the InnoSetup executable (default install location). This line causes an error:
'REG QUERY "%U_%\Inno Setup 5_is1" /v "Inno Setup: App Path"2^>Nul^|FIND "REG_"') do (

[egur]

egur, now there is a problem, you can't build projects VS2010, the problem is in the IntelQuickSyncDecoder svn rev.6 (QuickSyncExports.cpp).


One should never commit before a meeting :(
Fixed in rev4184.
alexins, I only noticed one of the issues, the latter will be fixed with other changes.

[clsid]

r4174 crashes when trying to play a lossless H.264 stream encoded with x264, but only when --output-csp (output colorspace) is specified as 'rgb'. 'i420', 'i422', and 'i444' all work correctly.Fixed in r4185.
ffdshow will now reject connection, allowing another filter to do the decoding, such as LAV Video.

@Haruhiko
Is 4:4:4 RGB p8/9/10 input already fully supported? If so, can you make mappings for libav/ffmpeg PIX_FMT_GBRP(9/10)? Then I could enable decoding of these formats.

[clsid]

Eric,
ffdshow (and MPC-HC) require static-pthreads.
Here is a msys/mingw package that will work properly for ffdshow:
http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=

[egur]

Eric,
ffdshow (and MPC-HC) require static-pthreads.
Here is a msys/mingw package that will work properly for ffdshow:
http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=

Works great. Thanks. Maybe it should be in the build docs...

[nevcairiel]

You should really ditch pthreads and use the w32threads libav has now. :p
Works just great for LAV

[clsid]

There was some mention of it being a bit slower in the MPC topic. Dunno if that is true.

[nevcairiel]

Thats because of MPC-HCs broken version of ffmpeg
... which they take from ffdshow, so you're probably broken as well. :p

[alexins]

Lav+w32threads has a speed of decoding higher than ffdshow+pthreads

[SamuriHL]

I can definitely confirm that on 2 of my machines.

[madshi]

You should really ditch pthreads and use the w32threads libav has now. :p
Works just great for LAV
Is w32threads better than pthreads for ffmpeg?

[nevcairiel]

Is w32threads better than pthreads for ffmpeg?

It seems to have equal performance and it gets rid of one dependency, thats better in my book.
Rather use native threading then pthreads on windows.

LAV has been using it for a while already (ever since the new w32threads implementation was added in october), and it seems to work just fine.

[clsid]

ffdshow uses w32pthreads as well now. Trivial patch.

[madshi]

It seems to have equal performance and it gets rid of one dependency, thats better in my book.
Rather use native threading then pthreads on windows.

LAV has been using it for a while already (ever since the new w32threads implementation was added in october), and it seems to work just fine.
Good to know, thx.

[Eliminateur]

You can find the crash module name in the error dialog of the crash.
Please test x86 because MPC-HC x64 tends to be buggy.
When does the crash occur? Right at the start, or after a while during playback.
Next time provide all essential information in you initial bug report. That saves everyone from wasting time.

i'd need to download ffdshow x86 as well as i'm using only x64.

it crashes on open, it doesn't even starts playing it resizes the window and crashes, it doesn't tells me any module, the crash is "mpc-hc has stopped working windows will try to find a solution"

[egur]

It seems to have equal performance and it gets rid of one dependency, thats better in my book.
Rather use native threading then pthreads on windows.

LAV has been using it for a while already (ever since the new w32threads implementation was added in october), and it seems to work just fine.

Out of curiosity, do you know which part of pthreads caused the slowness?
* Thread creation/destruction
* Synchronization objects

BTW, did anyone try replacing malloc by a faster implementation that's more suited for multithreaded apps (e.g. Google's malloc or TBB's malloc)?

[nevcairiel]

Out of curiosity, do you know which part of pthreads caused the slowness?

What slowness?


BTW, did anyone try replacing malloc by a faster implementation that's more suited for multithreaded apps (e.g. Google's malloc or TBB's malloc)?

I did some testing with the "normal" malloc, and as long as you don't start going into the virtual cores of hyper threading, performance is linear when doing excessive multi threaded allocations. (ie. 4x times the work load gets done by 4 cores at the same time then 1 core does 1x the work)
The problem people usually experienced with multi-core and allocations were mostly in the early days of multi-cores on linux. I didnt test there, but i assume its better as well.

[ageback]

I have Intel Parallel Composer 2011 installed and I could compile ICL12 version before.
But now I can't build ICL12 version.
Which Intel Compiler should I install?

[alexins]

ffdshow uses w32pthreads as well now. Trivial patch.
ffdshow 4186 x86, if the use of multithreading in Windows XP (libavcodec), then when playing a video H264, an error occurs and hang-up!

[egur]

What slowness?

What parts of pthread were slower than using win32 API?

I did some testing with the "normal" malloc, and as long as you don't start going into the virtual cores of hyper threading, performance is linear when doing excessive multi threaded allocations. (ie. 4x times the work load gets done by 4 cores at the same time then 1 core does 1x the work)
The problem people usually experienced with multi-core and allocations were mostly in the early days of multi-cores on linux. I didnt test there, but i assume its better as well.
Even in single threaded applications Google and TBB performed much better than libc malloc on Linux about 2 years ago when I benchmarked a large application.
Performance was 3x faster (!) using either malloc replacement. Both replacement used more memory than malloc.
The application (and 3rd party libraries) allocated and deallocated huge amounts of memory (many GB) either directlly or implicitly via various STL containers (and strings). Over time malloc's (original) internal database became very fragmented and malloc/free operations became very slow. One work load caused malloc to return a small buffer after 5 seconds instead of a few micro seconds after running for several minutes.

FFDshow uses large buffers mostly and should work about the same speed. If a lot of STL is used (or boost), it's worth checking it out.

[nevcairiel]

What parts of pthread were slower than using win32 API?

I never said it was slower, i just said its good to get rid of a dependency and use native threading.

[haruhiko_yamagata]

important bug report:

It seems that ffdshow does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2. Broadcasts and DVDs often switch between soft-telecine and hard-telecine. So they will look like a wild mix of 3:2 and 2:2, which will make it hard to perform a proper IVTC.

FWIW, LAV Video Decoder sets this flag correctly.
I think it was delay of soft telecine detection. I have fixed at rev 4178. Please try rev 4185 (4188 doesn't work for me).

[haruhiko_yamagata]

Fixed in r4185.
ffdshow will now reject connection, allowing another filter to do the decoding, such as LAV Video.

@Haruhiko
Is 4:4:4 RGB p8/9/10 input already fully supported? If so, can you make mappings for libav/ffmpeg PIX_FMT_GBRP(9/10)? Then I could enable decoding of these formats.
OK, I'll take a look later.

[haruhiko_yamagata]

I'm getting a lot of crashes on Blu-ray subtitles displaying more than one subtitle on the screen at a time. I've tried in MPC-HC and PotPlayer and with the MPC splitter and LAV filter. It doesn't occur every time but the more multiple lines you have the more it happens. The example below crashes more often than not.

http://www.megaupload.com/?d=24ZO2T1YI have fixed at rev 4189.

[dann23]

I have one problem and a feature request. The problem is with vobsub subtitles in mkv files. After some time they won't appear anymore. This happes after some time, maybe one minute or less.
And the feature request is about Info Tab in ffdshow. Is it possible to make it show the type of subtitles?

[DigitalDeviant]

I have fixed at rev 4189.

Thanks. I'll test it out as soon as a build is available and I have a few minutes.

[Eliminateur]

i'd need to download ffdshow x86 as well as i'm using only x64.

it crashes on open, it doesn't even starts playing it resizes the window and crashes, it doesn't tells me any module, the crash is "mpc-hc has stopped working windows will try to find a solution"

i've updated to 4191 as well and done some tests, the option that makes it crash is setting the primary output colorspace as RGB32 and using the "high quality yv12 to RGB" converter, the exact moment that checkbox is set, the mpchc hang/crashes (no module crash, generic "[program] has stopped working".

and it only happens with BIG hi10p files

[clsid]

I doubt the size is relevant. Those files were probably just encoded differently. The problem seems to be in the colorspace conversion code of ffdshow. Cut a 20MB sample with DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip) and upload it to MediaFire (http://www.mediafire.com). Then Haruhiko should be able to fix it.

[clsid]

ffdshow 4186 x86, if the use of multithreading in Windows XP (libavcodec), then when playing a video H264, an error occurs and hang-up!Try with a clean build of 4191.

[alexins]

try with a clean build of 4191.

The problem is solved, all works well!
Thank You!

[Eliminateur]

I doubt the size is relevant. Those files were probably just encoded differently. The problem seems to be in the colorspace conversion code of ffdshow. Cut a 20MB sample with DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip) and upload it to MediaFire (http://www.mediafire.com). Then Haruhiko should be able to fix it.

thanks clsid, indeed must be something about the encode, the chunk has the same effect.
this is the sample: http://www.mediafire.com/?4242856581wdn8b

[gendouhydeist]

There was an error on Commie - UN-GO at Y416 colorspace output.
The instruction at 0x54fb913d referenced memory at 0x0e321000. The memory could not be written.

It was crashing on MadVR, tried also on EVR it doesn't crash but there's no video output.

using latest svn revision of ffdshow on xvidvideo.ru

[hoborg]

Hi.
I have problem to play this video (http://hobring.esero.net/saf/samples/ffdshow_bad_playback.zip) with FFDshow video decoder.
LAV/MPC-HC video decoders working fine.

EDIT:
rev. 4174 is OK
rev. 4183 have broken playback.

[andybkma]

Just upgraded to ffdshow_rev4191_20111221_xvidvideo-ru_x86_icl12 and using the raw video filter to post process I get a thick green border on the right side of the video. I don't have this problem with the previous version I was using which is ffdshow_rev3984_20110922....

[haruhiko_yamagata]

thanks clsid, indeed must be something about the encode, the chunk has the same effect.
this is the sample: http://www.mediafire.com/?4242856581wdn8b
It works fine for me.
I have tested MPC-HC x64, graphstudio64 with RGB32 output, with "High quality YV12 to RGB conversion" checked.
Can anybody else reproduce the crash?

[haruhiko_yamagata]

Just upgraded to ffdshow_rev4191_20111221_xvidvideo-ru_x86_icl12 and using the raw video filter to post process I get a thick green border on the right side of the video. I don't have this problem with the previous version I was using which is ffdshow_rev3984_20110922....
Which decoder is connected to ffdshow's input pin? What is the color space? What are the dimensions?

[haruhiko_yamagata]

There was an error on Commie - UN-GO at Y416 colorspace output.Please write in plain English. I cannot understand "Commie - UN-GO at ".

The instruction at 0x54fb913d referenced memory at 0x0e321000. The memory could not be written.

It was crashing on MadVR, tried also on EVR it doesn't crash but there's no video output.

using latest svn revision of ffdshow on xvidvideo.ru
I can't reproduce.

[SamuelMaki]

I doubt the size is relevant. Those files were probably just encoded differently. The problem seems to be in the colorspace conversion code of ffdshow. Cut a 20MB sample with DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip) and upload it to MediaFire (http://www.mediafire.com). Then Haruhiko should be able to fix it.

Sorry for OT, but I would prefer multiupload... It has free direct download and you can use whatever fileserver you want:) Oh, and it is faster too...
http://www.multiupload.com/

[gendouhydeist]

@haruhiko_yamagata
it's an anime show called UN-GO sub by Commie
you can get the torrent here http://commiesubs.com/un-go-10/

[szabi]

szabi, you could use FFVideoSource() (http://avisynth.org/mediawiki/FFmpegSource) (preferred), or alternatively DirectShowSource().

Thnx, it worked. ;)

bye
szabi

[hoborg]

Hi.
I have problem to play this video (http://hobring.esero.net/saf/samples/ffdshow_bad_playback.zip) with FFDshow video decoder.
LAV/MPC-HC video decoders working fine.

EDIT:
rev. 4174 is OK
rev. 4183 have broken playback.

Fixed in 4192 :)

[andybkma]

Which decoder is connected to ffdshow's input pin? What is the color space? What are the dimensions?

Decoder: WMVideo Decoder DMO

Color Space: YUY2, 8 bit, 4:2:2

Dimensions: 720,576

Thank you...

[alexins]

haruhiko_yamagata, ffdshow r4196 (check output buffer size) - broken video output with the use of "NV12".

[haruhiko_yamagata]

haruhiko_yamagata, ffdshow r4196 (check output buffer size) - broken video output with the use of "NV12".
Thank you for finding the bug. Fixed at rev 4200.

[alexins]

Thank you for finding the bug. Fixed at rev 4200.

Thanks to you for the quick fix of the problem.
:)

[haruhiko_yamagata]

Decoder: WMVideo Decoder DMO

Color Space: YUY2, 8 bit, 4:2:2

Dimensions: 720,576

Thank you...
Does the DMO output YUY2? I don't have any 4:2:2 wmv sample. Please send me a sample.

[haruhiko_yamagata]

Thanks to you for the quick fix of the problem.
:)
Please wait, AYUV seems to be broken.

Edit: It's OK now (rev 4201).

[andybkma]

Does the DMO output YUY2? I don't have any 4:2:2 wmv sample. Please send me a sample.

Hi, pm'd you links to two samples that give me the green border on the right side. Thanks...

[ryrynz]

Haruhiko, build 4142 and above cause a green line to appear on the right side of the screen when playing back a DVD with the MS DTV-DVD decoder and passing through ffdshow RAW.

[pandy]

Hi Guys, quick question - ICL12 build is patched against bad dispatcher for AMD CPU's or not? (or should i use MSVC2010 version for AMD CPU's?).

btw

Is there any chance to restore MPEG encoder - 10 bit precision for DCT, interlace support, I frame - MJPEG is fine however there is lack for such small things (i believe that there is no standardization how to implement such features in MJPEG and MPEG-2 syntax seems to be tempting)

[Dstruct]

Hi Guys, quick question - ICL12 build is patched against bad dispatcher for AMD CPU's or not? (or should i use MSVC2010 version for AMD CPU's?).

I don't know what a bad dispatcher is. But here I need to use MSVC builds on my AMD CPU (no SSE2). ICL12 builds (xvidvideo.ru) don't let me open the config windows.


Also the "IntelQuickSyncDecoder.dll" is shown as "not found" in "Version details" with AMD CPU here (although the DLL is there)!

[gendouhydeist]

Thank you for finding the bug. Fixed at rev 4200.

This also fix the crash that I'm encountering on Y416 output thanks!!

[haruhiko_yamagata]

This also fix the crash that I'm encountering on Y416 output thanks!!
Yes, it was fixed. Thanks for letting me know.

[pandy]

I don't know what a bad dispatcher is.
http://www.agner.org/optimize/blog/read.php?i=49#49

[egur]

...

Also the "IntelQuickSyncDecoder.dll" is shown as "not found" in "Version details" with AMD CPU here (although the DLL is there)!

It's not a bug it's a feature. It will only work on Intel CPUs + GPU.

[haruhiko_yamagata]

Haruhiko, build 4142 and above cause a green line to appear on the right side of the screen when playing back a DVD with the MS DTV-DVD decoder and passing through ffdshow RAW.
I can reproduce this. I have fixed the problem in my working copy. I'll commit it to the SVN in a few days.

[ryrynz]

Great work, thank you Haruhiko.

[djchristian]

Why aren't there a installguide for ffshow and media player classic HC???

[pulbitz]

I'm sorry. I don't speak English very well.

ffdshow video decoder configuration | Output | Stream settings
Check "Set interlaced flag in output media type"

- libavcodec
perfect smooth playback of 1080i content. (double framerate)

- Intel QuickSync
motion is steppier. (poor)

Is this a bug? Or QuickSync decoder limitation?

[clsid]

@Haruhiko
There is a bug in ffdshow that causes a freeze with Haali video renderer.
4174 = ok
4183 = broken

[egur]

I'm sorry. I don't speak English very well.

ffdshow video decoder configuration | Output | Stream settings
Check "Set interlaced flag in output media type"

- libavcodec
perfect smooth playback of 1080i content. (double framerate)

- Intel QuickSync
motion is steppier. (poor)

Is this a bug? Or QuickSync decoder limitation?

You need a SandyBridge (or newer) to enjoy the HW acceleration used in the QuickSync decoder.
Please specify which renderer was use as well other setup (driver version, OS version, 32/64 bit, player, display is connected to iGPU or dGPU, etc). If you can post a part of the clip (10-20 seconds) that would help development.
This thread is very busy so please report issues at the QuickSync decoder thread:
http://forum.doom9.org/showthread.php?t=162442

[Midzuki]

r4206: raw video filter FAILS again :rolleyes:

the annoying vertical green bar (http://forum.doom9.org/showthread.php?p=1547005#post1547005) has disappeared, BUT the aspect ratio gets screwed -.-

Going back to r4052.

[haruhiko_yamagata]

@Haruhiko
There is a bug in ffdshow that causes a freeze with Haali video renderer.
4174 = ok
4183 = broken
I have fixed at rev 4207. Please confirm.

[haruhiko_yamagata]

the annoying vertical green bar (http://forum.doom9.org/showthread.php?p=1547005#post1547005) has disappeared, BUT the aspect ratio gets screwed -.-

It works for me. How can I reproduce?

[ryrynz]

4206 is working fine for me, cheers.

[Midzuki]

It works for me. How can I reproduce?

Try using a *real* MPEG-2 decoder (Mainconcept, Cyberlink, ArcSoft).

[clsid]

I have fixed at rev 4207. Please confirm.Fix confirmed. Thanks.

[haruhiko_yamagata]

Try using a *real* MPEG-2 decoder (Mainconcept, Cyberlink, ArcSoft).
Mainconcept decoder crashes in MPC-HC, whatever the file is. I don't know what is real. ffdshow is not related.
It works in graphstudio and ffdshow raw filter is OK with it.
Cyberlink decoder (PDVD8 or 11) and ffdshow raw works fine.
I don't have ArcSoft.

[Midzuki]

Mainconcept decoder crashes in MPC-HC, whatever the file is. I don't know what is real. ffdshow is not related.
It works in graphstudio and ffdshow raw filter is OK with it.
Cyberlink decoder (PDVD8 or 11) and ffdshow raw works fine.
I don't have ArcSoft.

Thanks for checking. I will try to find the actual source of the problem. :confused: :confused: :confused:

[ E D I T ]

ffdshow's MPEG decoder was not affected by the new raw video filter.
ArcSoft is not affected neither.
Downgraded from PDVD9 to PDVD7, the problem remains :(
Moving house to r4127.

[Dstruct]

It's not a bug it's a feature. It will only work on Intel CPUs + GPU.

Why do I see it here then (Intel CPU without Intel GPU)?


FIXED (rev4218)

[Midzuki]

INFO UPDATE (re: r4206's video processor)

DVD-Navigator ++ Cyberlink decoder ++ ffdshow rvf == OK

720x480@16:9 MPG file ++ Cyberlink decoder ++ ffdshow rvf == deformed picture

HTH :helpful:

[haruhiko_yamagata]

INFO UPDATE (re: r4206's video processor)

DVD-Navigator ++ Cyberlink decoder ++ ffdshow rvf == OK

720x480@16:9 MPG file ++ Cyberlink decoder ++ ffdshow rvf == deformed picture

HTH :helpful:
I still cannot reproduce. What is the application? What is the source/splitter filter? What is the video renderer?
Would you check the pin info if possible?

[Midzuki]

1) MPC, MPC-HC

2) File Source Async,

MpegSplitter.ax / Mainconcept splitter (mcspmpeg.DLL)

3) VMR7 (Windowed)

4) please wait :o

[Eliminateur]

what's the difference between chosing libfaad2 or libavcodec for AAC?
or libmad/libavcodec for mp3/2/1 for that matter as well

[haruhiko_yamagata]

3) VMR7 (Windowed)

Thanks. That's it. In the MPC-HC's video renderers, VMR9 renderless or later (in the order listed in dialog box) works, others do not. I'll look into it.

[haruhiko_yamagata]

@Midzuki
fixed at rev 4029. When I coded rev 4203, I replaced rcSource with rcTarget. At that time, I missed one.:stupid:

[ryrynz]

He meant 4209 ^_^

[Midzuki]

Yay, r4210 is working as it should :)

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

[adam777]

Hello all,
A quick question - I'm using FFDShow in raw mode, only in order to utilize the matrix function.
When the filter is inserted between LAV audio that takes care of the decoding and the audio renderer, is the channel conversion "lossless"?
Meaning, if LAV audio is passing, for example, a 5.1 32 bit FP audio, FFDShow will just send the channels according to the matrix in order to make it 2.0 but keep the data 32 bit FP without any further modification (aside from volume level and normalization, should I chose the latter)?
Same goes for any other format (16 bit etc.).
Thanks, Adam.

[NiFa]

Hey.

I have feature request, not sure if it's possible, but anyway here it is.

Is it possible to get "night mode" to audio decoder? I mean, could we have options to set how audio decoder handles multichannel tracks at specified time at day, lets say like 22.00-6.00.
There could be options like, mix LFE to front speakers, dynamic compression, time when night mode is used. Other way could be possibility to set in preset settings a time when specified profile should be used.

This feature would be great for night use because, it would be automatic so you won't have to manually disable LFE or shut the subwoofer off, because at example in my receiver (RX-V757) doesn't have possibility to turn subwoofer off.

[_xxl]

Happy New Year !

[Sebastiii]

Happy New Year too :)

[EpsilonX]

Happy New Year all...
And unfortunately, a bug report... :D

MadVR Macrovision error with DVD, ZoomPlayer 8...
It seems it only affects ICL12 build, all generic (MSVC2010) build works fine...
Latest working build from XvidVideo.ru was rev4185, and broken in the next rev4191...
Looking at the commit logs, maybe 4186/4188..? :rolleyes:
Thanx...

[ryrynz]

Has anyone benchmarked Quick Sync vs LAV CUVID?

[nevcairiel]

Quick Sync is faster because Intels Hardware Decoder is just faster, however for playback that rarely matters. :p

[dann23]

@nev
do you plan to implement quick sync in lav?

[haruhiko_yamagata]

Happy New Year all...
And unfortunately, a bug report... :D

MadVR Macrovision error with DVD, ZoomPlayer 8...
It seems it only affects ICL12 build, all generic (MSVC2010) build works fine...
Latest working build from XvidVideo.ru was rev4185, and broken in the next rev4191...
Looking at the commit logs, maybe 4186/4188..? :rolleyes:
Thanx...
ICL or MSVC is not relevant. Both does not work for me. A debug build by MSVC works though. It is random. It is more related to madVR. I'm not sure but not likely a bug of ffdshow.

[betaking]

rev.4218 compile failed
1>c:\ffdshow\src\codecs\intelquicksyncdecoder\src\quicksyncutils.h(149): error C2220: 警告被视为错误 - 没有生成“object”文件
1>c:\ffdshow\src\codecs\intelquicksyncdecoder\src\quicksyncutils.h(149): warning C4714: 标记为 __forceinline 的函数“struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> __thiscall CQsThreadSafeQueue<struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> >::Pop(void)”未内联
1>c:\ffdshow\src\codecs\intelquicksyncdecoder\src\quicksyncutils.h(149): warning C4714: 标记为 __forceinline 的函数“struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> __thiscall CQsThreadSafeQueue<struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> >::Pop(void)”未内联
1>c:\ffdshow\src\codecs\intelquicksyncdecoder\src\quicksyncutils.h(149): warning C4714: 标记为 __forceinline 的函数“struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> __thiscall CQsThreadSafeQueue<struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> >::Pop(void)”未内联
1>c:\ffdshow\src\codecs\intelquicksyncdecoder\src\quicksyncutils.h(149): warning C4714: 标记为 __forceinline 的函数“struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> __thiscall CQsThreadSafeQueue<struct std::pair<struct QsFrameData,class CQsAlignedBuffer *> >::Pop(void)”未内联
1>已完成生成项目“C:\ffdshow\src\codecs\IntelQuickSyncDecoder\IntelQuickSyncDecoder.vcxproj”(build 个目标)的操作 - 失败。

生成失败。

[egur]

Why do I see it here then (Intel CPU without Intel GPU)?

Should be fixed at 4217. Added check for SSE4.1 as well as existance of either driver or Media SDK SW DLL (beta4) for devs.

[egur]

Strangely, code compiled on my home system didn't compile in other systems. A function refused to inline causing a warning that turned into an error.
Fixed at 4222. No ffdshow code change.

[betaking]

Strangely, code compiled on my home system didn't compile in other systems. A function refused to inline causing a warning that turned into an error.
Fixed at 4222. No ffdshow code change.

Thanks!

[egur]

Has anyone benchmarked Quick Sync vs LAV CUVID?

Yes, look here:
http://forum.doom9.org/showthread.php?t=163110

I also ran the 10 clips on my own PC (i7-2600) with a newer version of ffdhsow-quicksync:
http://forum.doom9.org/showthread.php?p=1548192#post1548192

[ryrynz]

Very nice, thanks!

[Dstruct]

Should be fixed at 4217. Added check for SSE4.1 as well as existance of either driver or Media SDK SW DLL (beta4) for devs.

Confirmed. Thanks!

[Dstruct]

Should be fixed at 4217. Added check for SSE4.1 as well as existance of either driver or Media SDK SW DLL (beta4) for devs.

Still a bit weird on AMD CPU (rev.4218):

AMD CPU (without SSE2):
QuickSync DLL: not found (ffdshow -> About page -> Version details)


Intel CPU (without Intel GPU):
QuickSync DLL: Version properly shown (ffdshow -> About page -> Version details)



Why is the DLL not "found" on AMD system? I know it doesn't work on AMD but the DLL itself should be listed under About page -> Version details!

[LigH]

Maybe the loading of the DLL already fails due to CPU instruction restrictions, so executing the version request function fails too?

[egur]

Still a bit weird on AMD CPU (rev.4218):

AMD CPU (without SSE2):
QuickSync DLL: not found (ffdshow -> About page -> Version details)


Intel CPU (without Intel GPU):
QuickSync DLL: Version properly shown (ffdshow -> About page -> Version details)



Why is the DLL not "found" on AMD system? I know it doesn't work on AMD but the DLL itself should be listed under About page -> Version details!

Don't know. I don't have AMD HW to check. Well, it's not relevant anyway.

[Midzuki]

Why is the DLL not "found" on AMD system? I know it doesn't work on AMD


but the DLL itself should be listed under About page -> Version details!

I second that. On my very-old Pentium 4, ffdshow r4210 still is "unable to find" xvidcore.dll (even though this seems to be loaded anyway whenever requested) :confused:

[Dstruct]

Don't know. I don't have AMD HW to check. Well, it's not relevant anyway.

Ok, no big problem!

[fano]

My system is this:
http://www.asrock.com/nettop/overview.asp?Model=Core%20100HT#Specifications

and I'm having big problems to use my new AVR Sony STR-DN1020:
http://www.sony.co.uk/product/hcs-home-cinema-receiver/str-dn1020/tab/technicalspecs


EAC3, Dolby True HD and DTS-MA don't bitstreaming... ffdshow seems to think my AVR is SPDIF connected? Sometime it decodes a multichannel LPCM track! But if it0s set to unmolest the audio?
Intel QuickSync should work, right? It's a system based on the Intel HM55 platform, it MUST support it! I can select QuickSync but ffdshow likes to use libavacod instead... it's unmodificable :mad:


In particular see this MediaInfo report file:


General
ID : 0 (0x0)
Complete name : D:\Torrenti\Fantasia.1940.BD.RU\BDMV\STREAM\00125.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 35.1 GiB
Duration : 2h 4mn
Overall bit rate mode : Variable
Overall bit rate : 40.3 Mbps
Maximum Overall bit rate : 48.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=12
Codec ID : 27
Duration : 2h 4mn
Bit rate mode : Variable
Bit rate : 27.2 Mbps
Maximum bit rate : 27.5 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.546
Stream size : 23.6 GiB (67%)
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 #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Muxing mode : Stream extension
Codec ID : 134
Duration : 2h 4mn
Bit rate mode : Variable
Bit rate : 4 759 Kbps / 1 510 Kbps
Channel(s) : 8 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Muxing mode : Stream extension
Codec ID : 134
Duration : 2h 4mn
Bit rate mode : Variable
Bit rate : 2 722 Kbps / 1 510 Kbps
Channel(s) : 8 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy

Audio #3
ID : 4354 (0x1102)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : 130
Duration : 2h 4mn
Bit rate mode : Constant
Bit rate : 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 1.31 GiB (4%)

There are 6 more AUDIO tracks

Text #1
ID : 4609 (0x1201)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 2h 4mn
Delay relative to video : 7s 674ms

Text #2
ID : 4610 (0x1202)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144

Text #3
ID : 4615 (0x1207)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144

There are 14 more AUDIO tracks :scared:


The DTS-MA tracks are NOT present in the ffdshow Stream Switcher so it's clear NOW why they are not played :mad:

[Snowknight26]

Is there any way for ffdshow to honor the full range flag in H.264 videos if it's specifically set? I encoded a few videos and specifically set the full range flag but regardless of whether I choose Auto or Standard for the output range, it's still outputting limited range. I'm hoping there's an alternative to selecting Full Range each time those videos are played.

The more I think about it, the more certain I am that the tooltip for Auto is unclear whether the H.264 full range flag is honored or not.

[haruhiko_yamagata]

Is there any way for ffdshow to honor the full range flag in H.264 videos if it's specifically set? I encoded a few videos and specifically set the full range flag but regardless of whether I choose Auto or Standard for the output range, it's still outputting limited range. I'm hoping there's an alternative to selecting Full Range each time those videos are played.

The more I think about it, the more certain I am that the tooltip for Auto is unclear whether the H.264 full range flag is honored or not.
ffdshow is supposed to honor the flag if "Auto" is selected as "Input levels". If it is not working, it's a bug. I'll take a look.

[dukey]

I have a FFDshow feature request
Can ffdshow render subtitles to a secondary pin ?

Like this
http://i.imgur.com/f1U4I.png

If it acted as a pass through filter for the video we could support DXVA this way, which is a big plus. The secondary pin can just output RGBA no need to worry about all the hundreds of different colour spaces. Can be more efficient too since only need to update the subtitle image when the text needs to change, rather than composite it every frame.

[haruhiko_yamagata]

I have a FFDshow feature request
Can ffdshow render subtitles to a secondary pin ?

If it acted as a pass through filter for the video we could support DXVA this way, which is a big plus. The secondary pin can just output RGBA no need to worry about all the hundreds of different colour spaces. Can be more efficient too since only need to update the subtitle image when the text needs to change, rather than composite it every frame.I have been thinking about it. At least it is a lot of work. It's a long term TODO, which I can't promise implementation.

[dukey]

I can't see it being a huge amount of work, although I've not really studied the FFDShow source.

I might be able to assist. I am actually a c++ programmer. Specialise in opengl, but I know directshow. Written an opengl renderer in dshow ;p Im guessing you would need a new pin type for pass through, since it would be reading the sample type, for video size but not altering it.

[haruhiko_yamagata]

I can't see it being a huge amount of work, although I've not really studied the FFDShow source.

I might be able to assist. I am actually a c++ programmer. Specialise in opengl, but I know directshow. Written an opengl renderer in dshow ;p Im guessing you would need a new pin type for pass through, since it would be reading the sample type, for video size but not altering it.
Welcome to ffdshow development. Of course it's a good idea to have that feature.
Subtitles rendering is not pass through nor just alpha blending bitmaps. The input pin accepts text or coded bitmap and rasterize/decode them. And finally blend to the video. The output stage may be issued to a video renderer. It is not easy. None the less, you can do it ;).
I hope you have patience huge enough to deal with the messy existing code.

[haruhiko_yamagata]

Is there any way for ffdshow to honor the full range flag in H.264 videos if it's specifically set? I encoded a few videos and specifically set the full range flag but regardless of whether I choose Auto or Standard for the output range, it's still outputting limited range. I'm hoping there's an alternative to selecting Full Range each time those videos are played.

The more I think about it, the more certain I am that the tooltip for Auto is unclear whether the H.264 full range flag is honored or not.
fixed at rev 4230-4231. :thanks:

[betaking]

rev.4231 compile failed
http://i42.tinypic.com/2dvt06c.jpg
:helpful:

[obieobieobie]

In rev4225, post processing with automatic quality control enabled is broken at least for XVID content. Works in rev3984.

[hoborg]

BUG?
Hi.
I noticet if there is a "hi quality yv12 to RBG conversion" enabled in RGB convesion, 10-bit encoded videos make Graphstudio (FFDshow) to crash.
Just tested by "ffdshow tryouts project, svn 4236 (x86) - MSVC2010" on "i444compressed.mkv" sample.

[Snowknight26]

fixed at rev 4230-4231. :thanks:

Works beautifully, thanks.

[haruhiko_yamagata]

BUG?
Hi.
I noticet if there is a "hi quality yv12 to RBG conversion" enabled in RGB convesion, 10-bit encoded videos make Graphstudio (FFDshow) to crash.
Just tested by "ffdshow tryouts project, svn 4236 (x86) - MSVC2010" on "i444compressed.mkv" sample.
It works for me. What is the video renderer and the video card (Radeon HD 6750?)?

[hoborg]

It works for me. What is the video renderer and the video card (Radeon HD 6750?)?

Yes, 6750 + EVR

Edit:
The same problem on my HTPC with Radeon 6450 + VMR9 FSE.

Edit2:
I reset FFDshow setting and it is working now. Must be some registry entry in "HKEY_CURRENT_USER\Software\GNU\ffdshow\default" causing the crash.

[haruhiko_yamagata]

Yes, 6750 + EVR

Edit:
The same problem on my HTPC with Radeon 6450 + VMR9 FSE.

Edit2:
I reset FFDshow setting and it is working now. Must be some registry entry in "HKEY_CURRENT_USER\Software\GNU\ffdshow\default" causing the crash.
You found out very important thing.
Do you have any back up of the crashing settings? If you have one, please send it to me.

[hoborg]

You found out very important thing.
Do you have any back up of the crashing settings? If you have one, please send it to me.
Yes, here it is (http://hobring.esero.net/saf/ffdshow/10-bit_crash.zip).

[haruhiko_yamagata]

Yes, here it is (http://hobring.esero.net/saf/ffdshow/10-bit_crash.zip).
Thank you. It was crashing because dithering was unchecked.
I have fixed at rev 4240.

[haruhiko_yamagata]

What should be the default output color space to EVR for 10-bit 4:2:0 video?
For most (all?) PC, EVR does not accept P010/P016. Currently ffdshow use YV12 to connect with EVR.
It's lossy. I think RGB32 is less lossy. It's a bit slower though.
A small patch can change this.

Index: src/imgFilters/ffImgfmt.cpp
===================================================================
--- src/imgFilters/ffImgfmt.cpp (revision 4238)
+++ src/imgFilters/ffImgfmt.cpp (working copy)
@@ -1154,6 +1154,10 @@
FF_CSP_P216 ,
FF_CSP_444P10,
FF_CSP_Y416 ,
+ FF_CSP_BGR32,
+ FF_CSP_RGB32,
+ FF_CSP_BGR24,
+ FF_CSP_RGB24,
FF_CSP_420P ,
FF_CSP_NV12 ,
FF_CSP_YUY2 ,
@@ -1167,10 +1171,6 @@
FF_CSP_410P ,
FF_CSP_ABGR ,
FF_CSP_RGBA ,
- FF_CSP_BGR32,
- FF_CSP_RGB32,
- FF_CSP_BGR24,
- FF_CSP_RGB24,
FF_CSP_BGR16,
FF_CSP_RGB16,
FF_CSP_BGR15,

[nevcairiel]

IMHO the default should be to output a format as close to the original as possible, and upsampling chroma is not close at all. If 10-bit doesn't work, provide properly dithered 8-bit.

[clsid]

If P010/P016 can't be used, then best order of preference would probably be RGB > NV12 > YV12.

[madshi]

I definitely agree with nevcairiel here.

[haruhiko_yamagata]

IMHO the default should be to output a format as close to the original as possible, and upsampling chroma is not close at all. If 10-bit doesn't work, provide properly dithered 8-bit.
The video renderer has to up-sample chroma anyway unless the PC is connected to YCbCr analog TV.
The up-sampling without extra 2 bits is lossy. If up-sampling is done in ffdshow, it can utilize the 2 bits.
The video renderer may be able to use better interpolation while ffdshow use bilinear.
Which will produce better result? Is interpolation method more important than native conversion?

[madshi]

haruhiko, there's one thing missing in your argument, namely that RGB output is only 8bit. So let's collect arguments:

RGB output:
+ chroma upsampling and color conversion can make use of the original 10bit data
- after color conversion everything must be converted down to 8bit
- chroma upsampling algorithm is lower quality than what good renderers do
- user has to configure ffdshow's RGB output to match the display's level requirements (TV vs. PC levels)

NV12/YV12 output:
- video must be downconverted to 8bit right away
+ video renderer doesn't have to downconvert to 8bit after color conversion
+ chroma upsampling algorithm is higher quality
+ ffdshow doesn't have to care about PC vs. video levels

Please note that YCbCr -> RGB color conversion results in floating point data. So basically ffdshow has to dither the floating point RGB data down to 8bit integer. When using YV12/NV12, the video renderer doesn't have to do that, it can perform the color conversion in floating point and then maintain a much higher bitdepth in its internal processing chain.

[haruhiko_yamagata]

Thank you for your opinion.

- after color conversion everything must be converted down to 8bit

Currently most people do not have 10-bit enabled display. If they want to make use of full 10-bit, they must use madVR anyway. If EVR is used, I think we should target 8-bit display. In that case, the RGB32 output of ffdshow is the final output to display. Usually no further processing is required.

For now, it's a rare setting to have 10-bit monitor. It may change in the future, but until then, EVR would have supported P016/P010.

- chroma upsampling algorithm is lower quality than what good renderers do

Is the difference of upsampling algorithm more important than native conversion? I think you know how much is lost if 10-bit YCbCr is converted to 8-bit YCbCr and then to RGB32.

- user has to configure ffdshow's RGB output to match the display's level requirements (TV vs. PC levels)

This may be the weak point. People who use projectors have to configure the option.


+ video renderer doesn't have to downconvert to 8bit after color conversion
This is true only if it has high bit monitor.

Please note that YCbCr -> RGB color conversion results in floating point data. So basically ffdshow has to dither the floating point RGB data down to 8bit integer. When using YV12/NV12, the video renderer doesn't have to do that, it can perform the color conversion in floating point and then maintain a much higher bitdepth in its internal processing chain.
Well, 10-bit to 8-bit YCbCr conversion is very lossy and NV12 to RGB32 conversion is lossy again. The video renderer has to dither the output to 8-bit RGB unless the PC has high bit monitor.

What are expected in video renderer's processing chain? Resize is done in 8-bit anyway either in RGB32 or NV12. Deinterlacing is the biggest problem, but I have never encountered an interlaced high bit material.

After all, EVR must support P010/P016!

[nevcairiel]

A 10-bit -> 8-bit conversion may be lossy, but with proper dithering its "visually lossless", you don't see it. A forced RGB conversion may be visible, depending on what the renderer would do better with the raw YUV data.

[madshi]

@haruhiko_yamagata:

I agree that it would be ideal if EVR supported P010/P016. I'm not sure if that is something Microsoft would have to implement, or maybe the media player devs could do that with a custom mixer? Don't really know...

I don't think that 10bit to 8bit YCbCr is "very" lossy. If you apply proper dithering the loss should be small.

You're saying that the ffdshow RGB output will be the final output with no further processing. This may be true in many cases, but not in all. E.g. users may use the video renderer to scale the image. In my projection setup (CIH, Cinemascope) I always have to scale 16:9 and 4:3 movies. So even with 1080p content and 1080p displays scaling may still be necessary sometimes. Then there are color changes, brightness/contrast changes, level changes, calibration, gamma adjustments. These are all things that the video renderer may perform. If you take all that into account, you can't be sure that the ffdshow RGB output will see no further processing.

You do have a valid point, though: *If* ffdshow's RGB output is the final output without any further processing being done by the video renderer, then having ffdshow output RGB would minimize bitdepth losses.

At the end of the day I don't really care much, because all of this applies to EVR/VMR, only. So if you prefer RGB output in this situation, that's just fine with me.

[haruhiko_yamagata]

OK, I understand 10-bit YCbCr to 8-bit YCbCr conversion isn't too lossy. I'll keep it as it is.

[haruhiko_yamagata]

In rev4225, post processing with automatic quality control enabled is broken at least for XVID content. Works in rev3984.
I can't reproduce. I don't have many XVID samples that post processing is effective. Could you send us a sample?
Please pack exported settings with it.

[ikarad]

1)Problem with rgb32 output and ffdshow

With this video ffdshow doesn't work if I select rgb32 in output. If I check nv12 or p010 video works with mpc-hc and ffdshow.
video here: http://www.nyaa.eu/?page=torrentinfo&tid=270934

I tried with ffdshow 4238 and ffdshow 4079 there is the same problem.

edit: it's the same problem with all 10bit video and rgb24 output

edit2: If I use lav video and select only rgb32 output in lav video, video works well.

2) other problem.
a) If I turn on subtitles in ffdshow. If I open 10 bit video, ffdshow switch to rgb32 output and video do'esnt work (mpc and ffdshow open and close immediately like said in 1))
b) If I turn off subtitles in ffdshow. If I open 10 bit video, ffdshow swith to po10 output and video works. during the video, I can turn on subs and it works and subs are displayed.

There is a problem with turn on or turn off subs to select output color space when video start

3) question: When can I expect implementation of \t subs ? you have told 1 or 2 months in november.

[obieobieobie]

I can't reproduce. I don't have many XVID samples that post processing is effective. Could you send us a sample?
Please pack exported settings with it.

For me, it happened in every XVID file. The symptom was for the quality slider to go to the lowest value at once when automatic quality control was enabled no matter what quality the XVID file had. Usually the quality slider fluctuates.

I will try and get you a sample, though.

Edit: Hm, I can't reproduce either. I will get back to you if I encounter it again. Just put this out of mind. Sorry. :)

[haruhiko_yamagata]

Just one other thing, I've never managed to ever import my Avisynth code from the ffdshow exported settings without going viewing the exported file and manually copying the code for each preset, I documented that here.

http://sourceforge.net/tracker/index.php?func=detail&aid=3149428&group_id=53761&atid=471489
Fixed at rev 4243.
I cannot close the tracker because you posted the report to the original project.

[haruhiko_yamagata]

1)Problem with rgb32 output and ffdshow

With this video ffdshow doesn't work if I select rgb32 in output. If I check nv12 or p010 video works with mpc-hc and ffdshow.
video here: http://www.nyaa.eu/?page=torrentinfo&tid=270934

I tried with ffdshow 4238 and ffdshow 4079 there is the same problem.

edit: it's the same problem with all 10bit video and rgb24 output

edit2: If I use lav video and select only rgb32 output in lav video, video works well.

2) other problem.
a) If I turn on subtitles in ffdshow. If I open 10 bit video, ffdshow switch to rgb32 output and video do'esnt work (mpc and ffdshow open and close immediately like said in 1))
b) If I turn off subtitles in ffdshow. If I open 10 bit video, ffdshow swith to po10 output and video works. during the video, I can turn on subs and it works and subs are displayed.

There is a problem with turn on or turn off subs to select output color space when video start
Please try rev 4240 or newer.
3) question: When can I expect implementation of \t subs ? you have told 1 or 2 months in november.Sorry, maybe after the next release. It will take another two months at least.

[Midzuki]

Where can I download 4240 or newer because on official ffdshow website or xvidvideo.ru 4238 is the last version?

Try Xhmikosr's (http://xhmikosr.1f0.de/index.php) web site

[ikarad]

Try Xhmikosr's (http://xhmikosr.1f0.de/index.php) web site

Thanks


Sorry, maybe after the next release. It will take another two months at least.

I hope that you haven't give up the idea to improve sub renderer.

Please try rev 4240 or newer.

I just try (thanks to midzuki to find ffdshow 4242) and it doesn't work.

With 4238 if dithering box is checked, it works but with 4242 even with dithering box checked, it doesn't work

[haruhiko_yamagata]

With 4238 if dithering box is checked, it works but with 4242 even with dithering box checked, it doesn't workWhat does "doesn't work" mean?

[Stephen R. Savage]

Can anyone comment on whether it is possible to configure Avisynth processing in ffdshow to perform IVTC with, e.g. TIVTC? I have tried the following fragment:


TFM()
TDecimate()


I remember this working in some version long ago, but when I try this, I just end up with combed frames and incorrect decimation.

[asasadad_1]

how about add support for some dv files（avdv dv5p dvh5 dvpp）?
sample here : http://www.mediafire.com/?beorfvgaz02m9gn, ffplay ok.

[mandarinka]

It seems that ffdshow doesn't expect mkv chapters with the leading chapter entry set as hidden. If you open such file and right-click ffdshow's tray icon, ffdshow will crash.

This sample should be able to reproduce the crash: http://www.mediafire.com/?2053dzjwvis9j21
(Open file and right-click on ffdshow's try icon.)
This probably "works" with any video if muxed with chapters like these: http://pastebin.com/

[ryrynz]

Fixed at rev 4243.
I cannot close the tracker because you posted the report to the original project.

Cheers for that, it's very much appreciated.

[LigH]

@ Stephen: Just an uneducated guess ... precede with AssumeTFF() or AssumeBFF(), does that change the result?

[haruhiko_yamagata]

2) other problem.
a) If I turn on subtitles in ffdshow. If I open 10 bit video, ffdshow switch to rgb32 output and video do'esnt work (mpc and ffdshow open and close immediately like said in 1))
b) If I turn off subtitles in ffdshow. If I open 10 bit video, ffdshow swith to po10 output and video works. during the video, I can turn on subs and it works and subs are displayed.

There is a problem with turn on or turn off subs to select output color space when video start
Except the crash, providing you unchecked YV12 and NV12, it's the spec.

With 4238 if dithering box is checked, it works but with 4242 even with dithering box checked, it doesn't work
I found ICL12 builds are crashing. MSVC builds are working. I'll take a look.

[haruhiko_yamagata]

It seems that ffdshow doesn't expect mkv chapters with the leading chapter entry set as hidden. If you open such file and right-click ffdshow's tray icon, ffdshow will crash.

This sample should be able to reproduce the crash: http://www.mediafire.com/?2053dzjwvis9j21
(Open file and right-click on ffdshow's try icon.)
This probably "works" with any video if muxed with chapters like these: http://pastebin.com/
Crash confirmed.

[JoeH]

One of the "holy grails" of Windows HTPC has always been simultaneous output of audio out multiple formats - for example, bitstreaming audio out the HDMI and SPDIF, while outputting a stereo remix of that same audio out the headphones out, all at the same time. It is something that standalone DVD players and Blu-ray players have done since their conception, and I believe Apple handles relatively well as well, but on Windows has basically always been impossible. A Google search brings up hundreds of forum threads on this topic, with no real answers that I've been able to find.

Is this something that could be added into FFDShow as a feature, or is it simply impossible with the current Windows architecture?

[ikarad]

What does "doesn't work" mean?

mpc open and close immediately

[ikarad]

Except the crash, providing you unchecked YV12 and NV12, it's the spec.
.

Excuse me (I am not good in english) but I don't understand your answer.

[clsid]

The subtitle renderer does not support P010. So if you enable it, a colorspace conversion will take place.

[e-t172]

Can anyone comment on whether it is possible to configure Avisynth processing in ffdshow to perform IVTC with, e.g. TIVTC? I have tried the following fragment:


TFM()
TDecimate()


I remember this working in some version long ago, but when I try this, I just end up with combed frames and incorrect decimation.

Be sure to provide Avisynth with enough buffers in ffdshow's configuration (0/12 seems to be the right amount). Your example works fine on my system.

One of the "holy grails" of Windows HTPC has always been simultaneous output of audio out multiple formats - for example, bitstreaming audio out the HDMI and SPDIF, while outputting a stereo remix of that same audio out the headphones out, all at the same time. It is something that standalone DVD players and Blu-ray players have done since their conception, and I believe Apple handles relatively well as well, but on Windows has basically always been impossible. A Google search brings up hundreds of forum threads on this topic, with no real answers that I've been able to find.

Is this something that could be added into FFDShow as a feature, or is it simply impossible with the current Windows architecture?

There's a fundamental hardware problem when playing an audio stream over multiple sound outputs: clock mismatch. There are possible solutions, like on-the-fly resampling to compensate for clock drift (à la ReClock), but they're not easy to implement. Also, simultaneous audio output should be a feature of the player (e.g. MPC-HC) or the audio renderer, not ffdshow.

[ikarad]

The subtitle renderer does not support P010. So if you enable it, a colorspace conversion will take place.

Thanks.

[kc7bfi]

We are having trouble decoding video from an Axis Q7606 blade H.264 encoder. After running for about an hour the video dramatically degrades. The video appears to "melt". Stopping and restarting the video fixes the problem until it happens again. This problem does not seem to happen with VLC or using the Microsoft decoder. One other thing I notice is that, when using ffdshow, my effective frame rate is around 8fps when the actual frame rate is 20fps. Also, when using the Microsoft decoder (that comes with Windows7) the effective frame rate always matches the expected frame rate. The decoded SDP for the video is as follows.

v=0
o=- 1326387995092752 1326387995092752 IN IP4 192.168.25.200
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:50000
t=0 0
a=control:rtsp://192.168.25.200/axis-media/media.amp?videocodec=h264
a=range:npt=0.000000-
m=video 0 RTP/AVP 96
b=AS:50000
a=framerate:20.0
a=transform:1,0,0;0,1,0;0,0,1
a=control:rtsp://192.168.25.200/axis-media/media.amp/trackID=1?videocodec=h264
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0IAKeKQFge2BqwYBBuHiRFQ,aM48gA==

RTSP: source is live
video fcc: H264
RTPHandler, video subtype 875967048 [34363248]
created Handler for: Video, H264, width: 0, height: 0, bitDepth: 0, fps: 20.0 de.humatic.dsj.src.rtp.h@7d206f0
sps 67 42 00 29 e2 90 16 07 b6 06 ac 18 04 1b 87 89 gB.)............
11 50 .P

pps 68 ce 3c 80 h.<.

H264, subtype switch set: 1
profile_idc: 66
const_set0: 0
const_set1: 0
const_set2: 0
level_idc: 41
sps_id: 0
log2maxFrame: 0
pic_order_cnt_type: 0
log2_pic_max_order_cnt: 9
num_ref_frames: 1
gaps_in_frame_num_allowed: 0
pic_width_in_mbs: 43 (704)
pic_height_in_mbs: 29 (480)
frame_mbs_only_flag: 1
direct_8x8_inference_flag: 1
frame_cropping_flag: 0
vui_parameter_present: 0


Any ideas what may be going wrong? Could there be some configuration setting that needs to be changed? Any ideas of how to further debug this issue?

Thanks, David

[kc7bfi]

We are having trouble decoding video from an Axis Q7606 blade H.264 encoder. After running for about an hour the video dramatically degrades. The video appears to "melt". Stopping and restarting the video fixes the problem until it happens again. This problem does not seem to happen with VLC or using the Microsoft decoder. One other thing I notice is that, when using ffdshow, my effective frame rate is around 8fps when the actual frame rate is 20fps. Also, when using the Microsoft decoder (that comes with Windows7) the effective frame rate always matches the expected frame rate. The decoded SDP for the video is as follows.

v=0
o=- 1326387995092752 1326387995092752 IN IP4 192.168.25.200
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:50000
t=0 0
a=control:rtsp://192.168.25.200/axis-media/media.amp?videocodec=h264
a=range:npt=0.000000-
m=video 0 RTP/AVP 96
b=AS:50000
a=framerate:20.0
a=transform:1,0,0;0,1,0;0,0,1
a=control:rtsp://192.168.25.200/axis-media/media.amp/trackID=1?videocodec=h264
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0IAKeKQFge2BqwYBBuHiRFQ,aM48gA==

H264, subtype switch set: 1
profile_idc: 66
const_set0: 0
const_set1: 0
const_set2: 0
level_idc: 41
sps_id: 0
log2maxFrame: 0
pic_order_cnt_type: 0
log2_pic_max_order_cnt: 9
num_ref_frames: 1
gaps_in_frame_num_allowed: 0
pic_width_in_mbs: 43 (704)
pic_height_in_mbs: 29 (480)
frame_mbs_only_flag: 1
direct_8x8_inference_flag: 1
frame_cropping_flag: 0
vui_parameter_present: 0

Any ideas what may be going wrong? Could there be some configuration setting that needs to be changed? Any ideas of how to further debug this issue? Thanks, David

[clsid]

There is a massive leak of system handles when using ffdshow in combination with Haali renderer.

tested builds:
r4174 = working
r4183 = freeze
r4207 = leak

[haruhiko_yamagata]

We are having trouble decoding video from an Axis Q7606 blade H.264 encoder. After running for about an hour the video dramatically degrades. The video appears to "melt". Stopping and restarting the video fixes the problem until it happens again. This problem does not seem to happen with VLC or using the Microsoft decoder. One other thing I notice is that, when using ffdshow, my effective frame rate is around 8fps when the actual frame rate is 20fps. Also, when using the Microsoft decoder (that comes with Windows7) the effective frame rate always matches the expected frame rate. The decoded SDP for the video is as follows.


Any ideas what may be going wrong? Could there be some configuration setting that needs to be changed? Any ideas of how to further debug this issue? Thanks, David
I guess ffdshow calculates wrong timestamps (just a random guess though). If I can get testing environment, I'll take a look.

[haruhiko_yamagata]

There is a massive leak of system handles when using ffdshow in combination with Haali renderer.

tested builds:
r4174 = working
r4183 = freeze
r4207 = leak
I can see the leaks, but isn't it more related to color space conversion (HQ RGB) rather than Haali renderer?

// EDIT
fixed at rev 4247. Please confirm.

[clsid]

Fix confirmed.

[Snowknight26]

Has there been any thought of moving to Google Code, even if it's solely to get rid of the 2 minute page load time for viewing the change log? ;)

[clsid]

No.

But you can use this link to quickly see the latest revision:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision
There is a Next/Previous button to skip through revisions, so you easily check the latest few.

[kc7bfi]

I guess ffdshow calculates wrong timestamps (just a random guess though). If I can get testing environment, I'll take a look.

Thanks, what we also see is that, when the video "melts" the frame rate reported in the ffdshow info window grows well beyond what the encoder is sending. For example, the encoder is sending 15fps but ffdshow can report frame rates as high as 50fps. Also, the current frame value "bounces" around between zero and and the frame count.

If useful I could post a wireshark of the video stream for when the video is degrading.

Thanks again, David

[Reino]

I believe it's been reported before, but anyway:
- http://media.nero.com/Standard720x576_1MBit.mp4 (http://media.nero.com/Standard720x576_1MBit.mp4)
AAC Audio part decoding failure with libavcodec. No problem though with libfaad2.Fixed.FFDShow has already abandoned libfaad2, but now (since rev3962 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=3962)) MPC-HC has done so too.
Because, with the latest FFDShow and LAV Filters versions, the aac audio stream of this particular video is still incorrectly being decoded here, I was wondering if it could be a WinXP-only issue.
Could everyone on WinXP 32bit see if the audio-track of this video is properly decoded with libavcodec please?

[nevcairiel]

I can confirm that it works on Win7 at least. However, i don't think that the decoder actually behaves differently on XP vs 7, that would be quite odd. Windows XP however has some issues with float audio, maybe thats the issue, because avcodec decodes to that? Could try turning off float in ffdshow/LAV, and see if that helps?

[Px]

Because, with the latest FFDShow and LAV Filters versions, the aac audio stream of this particular video is still incorrectly being decoded here, I was wondering if it could be a WinXP-only issue.
Could everyone on WinXP 32bit see if the audio-track of this video is properly decoded with libavcodec please?
Is LAV filters necessary to reproduce? Haali+ffdshow is not enough?

[haruhiko_yamagata]

Thanks, what we also see is that, when the video "melts" the frame rate reported in the ffdshow info window grows well beyond what the encoder is sending. For example, the encoder is sending 15fps but ffdshow can report frame rates as high as 50fps. Also, the current frame value "bounces" around between zero and and the frame count.

If useful I could post a wireshark of the video stream for when the video is degrading.

Thanks again, David
The stream may help. Please post it.
But perhaps I also need a compatible upper stream filter to reproduce.
Thanks.

[Reino]

I've never touched float. Output is always integer here, in case of FFDShow as well as LAV Audio.

I don't use Haali. At least LAV Filters or MPC-HC's internal MP4 Splitter doesn't make a difference.

[haruhiko_yamagata]

This affect's all ffdshow versions as far as I know. I'm currently using: ffdshow_rev4150_20111215_clsid

I am trying to playback mpeg2 videos which switch between soft and hard telecine using ffdshow's internal mpeg2 decoder + avisynth IVTC/deinterlace.

The problem is that the internal “ffdshow_source” source filter that is used to get frames from ffdshow into AviSynth is not honoring soft pulldowns when fed to the avisynth IVTC plugin (TIVTC or Decomb). It needs to behave the same way as if the video was fed from DGDecode (or any avisynth mpeg2 decoder would).

I have read documentation of AviSynth API (http://avisynth.org/mediawiki/User:Wilbert/Filter_SDK), but I couldn't find necessary information for it. Could anyone help?

[haruhiko_yamagata]

Clsid, maybe you remember the FLV4/VP6 cropping issue.
Nev has found a solution (http://code.google.com/p/lavfilters/source/detail?r=859e3bcc3aa6) for LAV Video Dec, could it be implemented in FFDshow too?
Done at rev 4256.
Off course the credit goes to nevcairiel.

[haruhiko_yamagata]

It seems that ffdshow doesn't expect mkv chapters with the leading chapter entry set as hidden. If you open such file and right-click ffdshow's tray icon, ffdshow will crash.

This sample should be able to reproduce the crash: http://www.mediafire.com/?2053dzjwvis9j21
(Open file and right-click on ffdshow's try icon.)
This probably "works" with any video if muxed with chapters like these: http://pastebin.com/
fixed at rev 4257. :thanks:

[mandarinka]

fixed at rev 4257. :thanks:

Thanks :)

[ryrynz]

I experience corruption with Quick Sync enabled along with ffdshow raw with this sample. I experience no problems with any other decoder or with raw disabled.

20MB sample below.

http://www.mediafire.com/?0s68s1yjojkj9wc

[Px]

I've never touched float. Output is always integer here, in case of FFDShow as well as LAV Audio.

I don't use Haali. At least LAV Filters or MPC-HC's internal MP4 Splitter doesn't make a difference.
Tested at my work PC today, all works fine with haali/internal splitters and int16/int32/float32 output. XP SP3.

[Reino]

That's really weird. I'm also running WinXP SP3, but the decoded audio is completely distorted no matter the source filter or output settings.
AAC(libavcodec)_decode-error.tak (www.degeelebosch.nl/reino/AAC(libavcodec)_decode-error.tak) to be precise (the first 25 seconds of Standard720x576_1MBit.mp4 its distorted audio stream recorded as stereomix with Audacity the way I hear it).
I can't believe it's a soundcarddriver- or dependency-issue, or is it?
I've also tested Standard720x576_1MBit.mp4 on a family member's Win7 laptop. All fine with libavcodec.

Having music in the background (foobar or even MPC-HC) while playing Standard720x576_1MBit.mp4 also badly affects the music.

[Px]

I can't believe it's a soundcarddriver- or dependency-issue, or is it?
Maybe, but - have you tried to reset ffdshow audio decoder settings?

[hoborg]

@clsid:
Can you please update FFDshow DXVA decoder to latest MPC-HC one? To support Interlaced VC-1.
Thanks.

[clsid]

Done.

[THEAST]

Using build 4253, I'm still getting the same green bar as I reported before:

http://forum.doom9.org/showpost.php?p=1542980&postcount=14241

Is there a chance we'd get a fix for this?

[kc7bfi]

The stream may help. Please post it.
But perhaps I also need a compatible upper stream filter to reproduce.
Thanks.

I've attached a wireshark of when the H.264 video from and Axis camera is "melting". A quick glance at it looks fine to me but I'm sure you will be better at analyzing it. I hope this helps.

[haruhiko_yamagata]

Using build 4253, I'm still getting the same green bar as I reported before:

http://forum.doom9.org/showpost.php?p=1542980&postcount=14241

Is there a chance we'd get a fix for this?
fixed at rev 4261. :thanks:

[haruhiko_yamagata]

haruhiko_yamagata:
I have a very weird ffdshow subtitle renderer behavior.
I've written an automatic subtitle stream-selection code based on Language ID, Name, etc.
When I'm enabling a stream matching the user params right after the graph is built, depending on what appears to be a race condition, it seems ffdshow is selecting a different (external file) subtitle stream after I specify the stream I want (one of several embedded streams) using the IAMStreamSelect interface.

If I enable 'give embedded priority over subtitle files', it seems to fix the issue, but I haven't tested it against enough content and other splitter filters.
Can you disable FFDShow from selecting a subtitle stream itself if the IAMStreamSelect interface was issued a call to enable a stream?

fixed at rev 4263. :thanks:

[THEAST]

fixed at rev 4261. :thanks:
Great, thank you, it's working flawlessly now! :thanks:

[betaking]

@clsid:mpc-hc svn3981 Fix : VC1 DXVA Decoder decodes some Progressive streams with lots of artifacts/distortion and green macroblocks; ticket #111;
can you update for ffdshow?

[wanezhiling]

@clsid:mpc-hc svn3981 Fix : VC1 DXVA Decoder decodes some Progressive streams with lots of artifacts/distortion and green macroblocks; ticket #111;
can you update for ffdshow?

http://forum.doom9.org/showthread.php?p=1552284#post1552284
This?

[CharlieCL]

Download ffdshow_rev4225_20120105_clsid.exe. I have uninstalled old ffdshow and install this new one. Performance have great improvement. One problem is that there is no sound for some .ts files after the installation. Select Microsoft's codec still not work. I can hear the sound on old version before.

[haruhiko_yamagata]

Download ffdshow_rev4225_20120105_clsid.exe. I have uninstalled old ffdshow and install this new one. Performance have great improvement. One problem is that there is no sound for some .ts files after the installation. Select Microsoft's codec still not work. I can hear the sound on old version before.
What was the "old ffdshow"?

[LigH]

And what was the audio format? - Often MediaInfo helps, but ffdshow has an info page too.

[CharlieCL]

What was the "old ffdshow"?

The old ffdshow is ffdshow_rev3233_20100128_xxl

I uninstalled new one and reinstalled old one the sound recovered.
Then I removed the old one and reinstalled new one the sound still worked fine.

In the case without sound the subtitle was displayed in mess code.
In the case with sound there was no subtitle.

[gendouhydeist]

There was a huge slowdown in Resample filter libsamplerate sinc high quality at 192000Hz (audio unsync), video lag tremendously.

Is this normal? or I have to provide a sample for you.

[kc7bfi]

We are playing live video from an Optelecom H.264 encoder using the 64-bit version of the ffdshow decoder. Because of our requirement to support PTZ along with viewing we are trying to run with minimal buffering by our player. However, when we do the video plays very choppy, almost like it is only processing I-Frames. However, if I set a 800ms internal buffer the video plays fine. Unfortunately, this introduces too much delay for PTZ control. The 32-bit version of ffdshow does not have this same behavior, it plays fine with minimal buffering. Is there any configuration options in ffdshow that will help play H.264 video smoothly with minimal buffering? Thanks, David

[Delerue]

Subtitles aren't selected automatically; you have to go here and click to enable it:

http://img.photobucket.com/albums/v256/Delerue/FFDShow_subtitle.png

I'm using rev 4279 + MPC 3997.

[haruhiko_yamagata]

Subtitles aren't selected automatically; you have to go here and click to enable it:

Oops, fixed at rev 4280.

[kc7bfi]

I am trying to play H.264 video from a Cohu H.264 camera. Revision 3982 plays the video fine but revision 4257 crashes. I am using the 64 bit version of the filters. Any thoughts on what the problem is or how to debug the problem? Thanks, David

[kc7bfi]

We are experiencing some issues with ffdshow and H.264 from live encoders. Is there any options for paid support with this project? David

[Delerue]

Oops, fixed at rev 4280.

Thanks! ;)

[haruhiko_yamagata]

This affect's all ffdshow versions as far as I know. I'm currently using: ffdshow_rev4150_20111215_clsid

I am trying to playback mpeg2 videos which switch between soft and hard telecine using ffdshow's internal mpeg2 decoder + avisynth IVTC/deinterlace.

The problem is that the internal “ffdshow_source” source filter that is used to get frames from ffdshow into AviSynth is not honoring soft pulldowns when fed to the avisynth IVTC plugin (TIVTC or Decomb). It needs to behave the same way as if the video was fed from DGDecode (or any avisynth mpeg2 decoder would).

Could someone PLEASE enhance the existing "ffdshow_source" source filter to honor soft pulldowns in the same fashion when DGDecode does? I'm hopeful this will be fixed in the next beta release.

Normally, I wouldn't make a big deal about this. However, this type of mix soft/hard telecine video is extremely common in America; as, it's the encoding format used by many cableTV content providers like HBO, Showtime, Cinemax, etc; played back by millions of people (mostly on STB cableboxes).

PS: I have "Detect soft telecine and average frame durations" disabled in ffdshow in order for the IVTC plugin in Avisynth to remove 3:2 pulldown correctly to 23.976fps.

If you want ffdshow to behave like DGIndex with "Honor Pulldown Flags" option enabled, use 3:2 Pulldown "Apply pulldown" option in ffdshow's dialog. It serves hard telecined frames if the input is soft telecined.

It works if "Detect soft telecine and average frame durations" is unchecked.

[kc7bfi]

We are having issues with H.264 video and ffdshow. Is there any options for paid support with ffdshow? David

[Liisachan]

To devs:
Even after the fix in 4240, I think ffdshow crashes while doing the high-quality conversion to RGB when dithering is disabled, if the source is 8-bit. (No crash if 10-bit).

[haruhiko_yamagata]

To devs:
Even after the fix in 4240, I think ffdshow crashes while doing the high-quality conversion to RGB when dithering is disabled, if the source is 8-bit. (No crash if 10-bit).
Hi, Liisachan. Nice to see you again.
It works for me. Maybe there are more conditions needed?

[Liisachan]

Thanks, haruhiko.
Perhaps this simply means my PC is too old. On my XP Pro SP3 (Pentium4/NVIDIA Quadro FX), the crash seems to occur for any input with ffdshow RGB32 output (i.e. uncheck YV12 etc., or select RGB32 as Primary output color space), if hq-conv is used without dithering. The crash happens with MPC, MPC-HC, mplayer2, or GraphEdit. Everything is okay, though, once dithering is enabled.

The problem is, I can't reproduce the crash myself on another old (but slightly less old) XP Home SP3 machine (Core2 Duo/NVIDIA GeForce), using the exact same settings (exported and imported as .reg). Testing 4281 on both. So apparently the problem more or less depends on HW, or, as you suspected, some subtle conditions. I hope someone can reproduce this problem.

PS
rev3925 (20110709) doesn't have the above problem.

[haruhiko_yamagata]

Thanks, Pentium 4 isn't too old.
I have Pentium　4-HT, I'll try on it on Monday.

[Liisachan]

I did some more tests:
*rev4106 (2011-12-03) and before = no problem
*rev4119 (2011-12-04) and after = crash for me, if hq-conv to rgb32 is used without dithering

[haruhiko_yamagata]

I found it was crashing on single CPU (m_thread_count == 1).
fixed at rev 4285. :thanks:

[Liisachan]

Fix confirmed; it's working again in 4285 (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-4285-x86-x64.html). Thank you :)

[Reino]

haruhiko_yamagata, if you can find some time, can you please have a look at the following tickets?

- Volume levels animation glitch on WavPack audio (http://sourceforge.net/tracker/?func=detail&aid=3458213&group_id=173941&atid=867360)
- Vorbis audio input bitrate incorrectly being reported (http://sourceforge.net/tracker/?func=detail&aid=3458218&group_id=173941&atid=867360)
- Feature Request: Output colorspace as-is (http://sourceforge.net/tracker/?func=detail&aid=3458249&group_id=173941&atid=867363)

[Midzuki]

haruhiko_yamagata, if you can find some time, can you please have a look at the following tickets?

- Volume levels animation glitch on WavPack audio (http://sourceforge.net/tracker/?func=detail&aid=3458213&group_id=173941&atid=867360)
- Vorbis audio input bitrate incorrectly being reported (http://sourceforge.net/tracker/?func=detail&aid=3458218&group_id=173941&atid=867360)
...

As he said some pages ago...

Sorry, I'm not interested in the audio part.

[haruhiko_yamagata]

- Feature Request: Output colorspace as-is (http://sourceforge.net/tracker/?func=detail&aid=3458249&group_id=173941&atid=867363)
I replied at SourceForge.
Sorry, my motivation for audio part has not been changed.

[haruhiko_yamagata]

I have found and reported (http://software.intel.com/en-us/forums/showthread.php?t=102671) a bug of ICL12.
I modified ffdshow slightly and x64 by ICL12 is now available.

[nevcairiel]

Everytime i read about ICL12 i can't help but wonder who really paid for it, and who just uses a pirated version....
You know, that thing isn't cheap (and the benefits of using it are questionable at best)

[alexins]

...(and the benefits of using it are questionable at best)
Here is a comparison of the performance of ffdshow msvc2010 and ffdshow icl12:

http://s018.radikal.ru/i500/1201/92/c31d359f1064t.jpg (http://radikal.ru/F/s018.radikal.ru/i500/1201/92/c31d359f1064.png.html)
http://s57.radikal.ru/i155/1201/b4/b1ac6ed35262t.jpg (http://radikal.ru/F/s57.radikal.ru/i155/1201/b4/b1ac6ed35262.png.html)

P.S
LAV Video Decoder 0.44 x86 MSVC2010/GCC4.63pre

http://s018.radikal.ru/i521/1201/2a/4f9361c846b9t.jpg (http://radikal.ru/F/s018.radikal.ru/i521/1201/2a/4f9361c846b9.png.html)

[nevcairiel]

So the average difference is 0.1-0.2%, in other words - worthless. :p

[_xxl]

Critical parts of the code are hand optimized.... so only some unoptimized and non-critical parts would benefit from compiler version.

[haruhiko_yamagata]

Formerly, icl9 was much better than MSVC2003(7.1).
Regarding performance, MSVC has been improved.
Old comparison (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/htmlhelp/html/en/images/benchmark.png?revision=1138&pathrev=2089).
Please try filters. Let's see how much MSVC improved.

[clsid]

It has been benched many times in the past. ICL is only faster for a few of the processing filters in ffdshow. For pure decoding it has no benefit.

@alexins
Part of the reason why LAV is faster in benchmark is because it uses more threads by default. 1.5x cores instead of 1.0x cores.

[amtm]

The only real benefits to buying the Intel compiler suite is if you like the performance tuning and static analysis tools that come with it. From having played with them in the trial version, they are kind of nice but definitely not something that can't be replaced and matched by cheaper tools. Intel's marketing only uses a single, synthetic benchmark to prove the "great" performance of their compiler, and even then they only show a 9% to 12% gain over GCC on Linux for example, so one should definitely take it with grand helpings of salt. Most likely their performance benefits are due to the synthetic benchmark doing computation that Intel can target lots of optimizations at rather than being a true accurate gauge of real world applications.

[oddball]

I am having issues with ffdshow (any build as far as I can tell) hanging when playing back MKV with AAC audio. Sometimes it plays fine and other times MPC-HC (Latest xvidvideo.ru builds) just hangs with the video and audio still playing but you cannot pause, stop or exit the player. I have to end it in task manager and it ends with the audio continuing for a second like it's a stuck CD going really fast on stuck sample. This only just started with recent builds and I don't know what to make of it other than to try rolling back MPC-HC, ffdshow and MadVR, I also use ReClock with WASAPI. But never had this issue until recently. I use a extrernal USB soundcard but never had issues with that until now either.

[haruhiko_yamagata]

I am having issues with ffdshow (any build as far as I can tell) hanging when playing back MKV with AAC audio. Sometimes it plays fine and other times MPC-HC (Latest xvidvideo.ru builds) just hangs with the video and audio still playing but you cannot pause, stop or exit the player. I have to end it in task manager and it ends with the audio continuing for a second like it's a stuck CD going really fast on stuck sample. This only just started with recent builds and I don't know what to make of it other than to try rolling back MPC-HC, ffdshow and MadVR, I also use ReClock with WASAPI. But never had this issue until recently. I use a extrernal USB soundcard but never had issues with that until now either.Thanks for report, but we need more information (http://forum.doom9.org/showthread.php?p=930663#post930663)to reproduce.

[oddball]

Nevermind it appears to be a switching but when going fullscreen on my HDTV. Going from 60Hz to 24Hz in conjunction with ReClock appears to be the culprit.

[ryrynz]

Haruhiko, I can reproduce another Rundll32 error. Simply rename any default preset and press enter, DO NOT click apply, then press ALT + F4.

[ipanema]

Some time between rev 3914 (Jun 29 2011) and rev (4291 Jan 31 2012) there seems to have been a bug introduced in the timestamps of the first decoded frame for the H.264/AVC decoder.

For example the older rev 3914 produces output frames with these start and end timestamps:
5575666 5575667
5909333 5909333
6243000 6243001
6576666 6576667

The difference is always correctly 333666, and the end timestamp is always 1 greater then the start timestamp.

But the newer rev 4291 gives these output timestamps:
0 399999
5909333 5909334
6243000 6243001
6576666 6576667

The timestamp of the first frame is way too low and much less than the input sample timestamps. Then there's a large jump to the timestamp values of the second frame which seems to be correct (as are all subsequent frames).

This causes a glitch or error when fed to downstream filters.

I don't know at what rev this problem first appeared, but at least rev 3914 works fine.

Is it possible to get this fixed ?

Thanks.


EDIT: I've just gone through all the previous versions of ffdshow-tryouts in

http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/generic%20builds/

and the problem seems to have been introduced at rev 4194. The previous rev 4174 seems to be OK (first frame has correct timestamps).

Hope that helps.

[kc7bfi]

I just installed ffdshow_rev4291_20120131_clsid_x64.exe and now, when trying to play a video I get a popup ffdshow error window saying it failed to load ffmpeg.dll. I am running Windows7 64-bit. Thanks, David

[clsid]

A fresh working x64 build will be available shortly.

[kc7bfi]

Here is a cell phone video (http://dl.dropbox.com/u/37804952/2012-02-01_16-17-41_209.3gp) taken of our attempt to play H.264 video from an Optelecom encoder. It appears that only I-frames are being decoded. Any thoughts what the problem might be? I am running Windows7 64-bit and ffdshow ffdshow_rev4293_20120201_clsid_x64. Thanks, David

[CruNcher]

you trying to playback the raw bitstream, what is the parser ?
though your chances arent high that it will work flawlessly as ffdshow isn't meant for this use case :)

[haruhiko_yamagata]

Haruhiko, I can reproduce another Rundll32 error. Simply rename any default preset and press enter, DO NOT click apply, then press ALT + F4.
I can reproduce the crash. Thanks.

[haruhiko_yamagata]

Some time between rev 3914 (Jun 29 2011) and rev (4291 Jan 31 2012) there seems to have been a bug introduced in the timestamps of the first decoded frame for the H.264/AVC decoder.

I think it's rev 4179.
Would you provide the sample?

[Pat357]

I 've just updated my FFDshow from rev3972 to rev4291.
When setting up FFDshow DXVA, I noticed that there is currently only support for H264 and VC1, no option to choose MPEG2 anymore !
What has happened to the MPEG2 HW acceleration ?
This is really a pitty because I used it often with my GTX 570 (full MPEG2 HW decoding support).
Do we we also loose the HW vector adaptive deinterlacing for all MPEG2 streams ? Like for TV recordings, DVD movies, ..?
I know we have Yadiff and other softw. based options but none comes even close to HW deinterlacing (quality wise),
not to mention the extra load on the CPU.:(
Can anyone please enlighten me ?
Will the option be back in the near future versions ?

[nevcairiel]

Deinterlacing through the renderer is not related to DXVA decoding, it should work equally well with software decoding as long as the decoder is setting the flags properly.

[ipanema]

I think it's rev 4179.
Would you provide the sample?

Do you mean the MTS file that produced the timestamps I quoted? If so where do I provide it?

[clsid]

I 've just updated my FFDshow from rev3972 to rev4291.
When setting up FFDshow DXVA, I noticed that there is currently only support for H264 and VC1, no option to choose MPEG2 anymore !
What has happened to the MPEG2 HW acceleration ?
This is really a pitty because I used it often with my GTX 570 (full MPEG2 HW decoding support).
Do we we also loose the HW vector adaptive deinterlacing for all MPEG2 streams ? Like for TV recordings, DVD movies, ..?
I know we have Yadiff and other softw. based options but none comes even close to HW deinterlacing (quality wise),
not to mention the extra load on the CPU.:(
Can anyone please enlighten me ?
Will the option be back in the near future versions ?
There never has been such an option. There are also no plans to add it.
You should use LAV Video instead. That provides CUVID HW acceleration with HW deinterlacing.

[clsid]

Do you mean the MTS file that produced the timestamps I quoted? If so where do I provide it?You can upload it to for example:
http://www.mediafire.com

If the file is very large and you want to cut a sample, then use DGSplit:
http://neuron2.net/dgsplit/dgsplit12.zip

[kc7bfi]

Here is a cell phone video (http://dl.dropbox.com/u/37804952/2012-02-01_16-17-41_209.3gp) taken of our attempt to play H.264 video from an Optelecom encoder. It appears that only I-frames are being decoded. Any thoughts what the problem might be? I am running Windows7 64-bit and ffdshow ffdshow_rev4293_20120201_clsid_x64. Thanks, David

I have confirmed that the problem with the Optelecom H.264 video was created somewhere between version 4174 and 4194. Version 4174 plays the video fine but 4194 seems to only be playing I-frames. Any ideas what may have changed in those versions? If there are any intermediate Windows 64 bit installs I can also test them to try and narrow down the exact revision that caused the problem. Just let me know if they are available. Any help in resolving this issue would be greatly appreciated. David

[clsid]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.

Everyone please review this changelog for omissions and mistakes:

(revision 3154 to 4296)

Bugfixes:
* Lots of updates for libavcodec that bring bug fixes, performance enhancements, and security fixes.
* Disable "Detect soft telecine and average frame durations" if 3:2 pulldown is being applied in AviSynth filter.
* IAMStreamSelect: fix duplicated subtitle list in case of multiple ffdshow instances
* If a matroska container had hidden leading chapter and Haali's splitter was used and tray icon was right-clicked, ffdshow crashed.
* Various fixes regarding input mediatype handling, strides, and pin re-connection.
* Various fixes regarding H.264 SPS parsing
* Fixed decoding of 96khz 32bit audio with libavcodec
* Fixed decoding of AAC audio with libavcodec when extradata is missing
* Better handling of non-mod4 resolutions
* Workaround for freeze in Powerpoint 2010
* AC3 encoder was producing improper bitstream when connected to file writer filter
* Various fixes for audio bitstreaming

New and improved features:
* Support for H.264 10-bit 4:2:0/4:2:2/4:4:4/RGB
* Support for H.264 8-bit 4:2:2/4:4:4/RGB, 4:2:0 was already supported
* Support for various 10-bit and 16-bit colorspaces
* Optimized YV12 to NV12 conversion
* Enabled high quality RGB32 conversion by default
* Added option to select a preferred output colorspace
* Added Intel QuickSync decoder. This provides hardware acceleration decoding of H.264, VC-1 and MPEG-2. Requires the integrated GPU of Intel Sandy Bridge processors.
* Added DXVA video filter for hardware accelerated decoding. Supports H.264 and VC-1 video. Also includes subtitle support.
* Various additions to the application blacklist and whitelist
* Added support for Blu-ray PGS subtitles
* Removed support for USF subtitles
* Various improvements for the handling of ASS/SSA subtitles. More tags are supported now, but not yet all of them.
* Various improvements for the rendering of text-based subtitles
* By default now only subtitle files are shown that match the video filename. This behavior can be adjusted through an
option on the "Try, dialog & Paths" page in ffdshow settings.
* Created new format option in ffdshow audio decoder for the QT PCM variants (such as TWOS). They were previously part if the Uncompressed audio option.
* ffmpeg-mt has been merged into libavcodec
* Multi-threaded decoding is now used by default for H.264, MPEG-1/2, FFV1, and DV video.
* Added decoding support for Indeo 4 and Indeo 5 video
* Floating point output for libavcodec AAC, AC3, E-AC3, DTS, Vorbis, and Nellymoser decoders.
* Added option to disable jitter correction for audio decoder
* Improved performance of Deband filter
* Removed some encoders for which the interface that ffdshow provided was outdated and unmaintained, such as Xvid and
H.264. You should use the official codecs instead.
* Removed some encoders that were considered obsolete or unstable.

Updates:
* Updated Boost library to v1.48
* Updated zlib library to v1.2.6
* Updated minilzo library to v2.06
* Updated unrar library to v4.10
* Updated libsamplerate to v0.1.8
* Removed mp3lib
* Removed xvidcore

[ipanema]

You can upload it to for example:
http://www.mediafire.com

If the file is very large and you want to cut a sample, then use DGSplit:
http://neuron2.net/dgsplit/dgsplit12.zip

Thanks. I have just been doing some more checks for 3 MTS files chosen at random and they all have similar output timestamp problems which were not present in the older revisions of ffdshow tryouts. And it isn't just the timestamp of the first frame. There are some very strange timestamp values jumping forward and then backward (this is the output remember), and the end timestamp value is sometimes strange aswell. In comparison, the older revisions always produce correct values with the end timestamp always 1 greater than the start.

Here are the start and end timestamps for the 3 files I tried. The input timestamps are shown, followed by the "correct" output timestamps from the older revision 4174, followed by the weird values produced by the newer revision.

File 1

Input Timestamps
5575666 5575667
4908333 4908334
5242000 5242001
6576666 6576666
5909333 5909334
6243000 6243001
7577666 7577667
6910333 6910334
7244000 7244001
8578666 8578667
7911333 7911334
8245000 8245001

Output Timestamps from revision 4174
5575666 5575667
6576666 6576667
6910333 6910334
7244000 7244001
7577666 7577667
7911333 7911334

Weird Output Timestamps from newer revision
0 399999
6576666 6576667
6910333 6910334
7244000 7244001
7644000 8043999
7911333 7911334


File 2

Input Timestamps
2918111 2918112
2118111 2118112
2518111 2518112
3718111 3718112
3318111 3318112
4518111 4518112
4118111 4118112
5318111 5318112
4918111 4918112
6118111 6118112
5718111 5718112
6918111 6918112
6518111 6518112

Output Timestamps from revision 4174
2118111 2118112
2518111 2518112
2918111 2918112
3318111 3318112
3718111 3718112
4118111 4118112
4518111 4518112
4918111 4918112
5318111 5318112
5718111 5718112
6118111 6118112

Weird Output Timestamps from newer revision
2118111 2118112
3718111 3718112
4118111 4518110
3318111 3318112
3718111 3718112
5318111 5318112
4518111 4518112
6118111 6118112
5318111 5318112
6918111 6918112
6118111 6118112


File 3

Input Timestamps
7770333 7770334
7103000 7103001
7436666 7436667
8771333 8771334
8104000 8104001
8437666 8437667
9772333 9772334
9105000 9105001
9438666 9438667
10773333 10773333
10106000 10106001
10439666 10439667
11774333 11774334
11107000 11107001
11440666 11440667
12775333 12775334
12108000 12108001
12441666 12441667
13776333 13776334
13109000 13109001
13442666 13442666

Output Timestamps from revision 4174
7770333 7770334
8771333 8771334
9105000 9105001
9438666 9438667
9772333 9772334
10106000 10106001
10439666 10439667
10773333 10773334
11107000 11107001
11440666 11440667
11774333 11774334
12108000 12108001
12441666 12441667
12775333 12775334
13109000 13109001

Weird Output Timestamps from newer revision
0 399999
8771333 8771334
9438666 9438667
10773333 10773334
11173333 11573332
10439666 10439667
10439666 10439667
10773333 10773334
11107000 11107001
12775333 12775334
13175333 13575332
12441666 12441667
12441666 12441667
12841666 13241665
13109000 13109001


Given that all 3 of the files I selected at random show the problem within the first few frames, I would think that you would be able to reproduce this quite easily using one of your own files (all 3 were from different AVCHD camcorders).

However, if you still think you need an example file, let me know and I will upload one for you.

[haruhiko_yamagata]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.

Everyone please review this changelog for omissions and mistakes:Good log.
One thing I want for the next release is fast "Accurate rounding" in resize filter. Actually it's a regression.

[haruhiko_yamagata]

Given that all 3 of the files I selected at random show the problem within the first few frames, I would think that you would be able to reproduce this quite easily using one of your own files (all 3 were from different AVCHD camcorders).

However, if you still think you need an example file, let me know and I will upload one for you.
Finally I found one, but it was hard...
With one file, in combination with Haali's splitter.

[haruhiko_yamagata]

ipanema, please upload the file anyway. The file I mentioned above has the same timestamp as the older build.
Which source/splitter filter do you use?

[haruhiko_yamagata]

Madagascar.avi 1280x720
Average of about 2760 frames (QueryPerformanceCounter, which is high resolution time. Smaller number is faster.).
Image filter only, not overall frame rate.

RGB conversion (HQ, dithering enabled)
MSVC x86: 5,415
ICL x86: 5,488
MCVC x64: 4,856
ICL x64: 4,961

Denoise 3D HQ
MSVC x86: 36,047
ICL x86: 31,716
MSVC x64: 419,569
ICL x64: 32,220

Denoise 3D Normal
MSVC x86: 25,618
ICL x86: 18,753
MSVC x64: 16,917
ICL x64: 18,715

As you can see, ICL is faster only in special cases.
ICL is faster by 36.6% for Denoise 3D normal x86. This filter is useless because it's quality is too low. Denoise 3D HQ should be used.
ICL is 13 times faster for Denoise 3D HQ x64. MSVC does not support MMX intrinsics for x64. ICL seems to be OK.

EDIT
Core2 Quad Q9550 2.83GHz
Windows 7 Professional sp1
GeForce 7900 GS
ffdshow rev 4298

[khagaroth]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.
Up to update the Czech translation I guess. What a pity it's such a pain to find changed/new strings, it would be great if the whole thing got gettextized. As probability of that ever happening is pretty low, it would be nice if this ticket (http://sourceforge.net/tracker/?func=detail&aid=3360019&group_id=173941&atid=867363) was followed.

[nevcairiel]

MSVC does not support MMX intrinsics for x64. ICL seems to be OK.

So rewrite them using SSE2, its really just the same commands with 128-bit instead 64... :)

[haruhiko_yamagata]

So rewrite them using SSE2, its really just the same commands with 128-bit instead 64... :)
That's a bother.:p
That's something compilers must do. MSVC is simply inferior to ICL in that regard.

[haruhiko_yamagata]

Up to update the Czech translation I guess. What a pity it's such a pain to find changed/new strings, it would be great if the whole thing got gettextized. As probability of that ever happening is pretty low, it would be nice if this ticket (http://sourceforge.net/tracker/?func=detail&aid=3360019&group_id=173941&atid=867363) was followed.
Tags such as <translate> in the svn log may help. I think it's a good idea.
As far as I can find,

Image buffer: in Subtitles::Text page
Primary output color space: in Output page

Both have tool-tip hint.

[ipanema]

ipanema, please upload the file anyway. The file I mentioned above has the same timestamp as the older build.
Which source/splitter filter do you use?

Sorry you've had some problems finding a file - it seemed to do this to all 3 files that I examined. Perhaps this does have something to do with the splitter. The splitter being used is the Microsoft MPEG-2 Demux that is part of Windows which works fine with all decoders I've tried, including ffdshow - but it's just the recent ffdshow revs that cause the problem. The Microsoft splitter produces fixed sized 8192 byte samples, where only the sample which STARTS a frame carries a start/end timestamp - all other samples have no timestamp. Also the sample at the end of a frame may be less than 8192 bytes in size.

Here's a sample file - it's pretty small but is enough to show the problem. It is the "File 3" in my previous message.

http://www.mediafire.com/?88db0kvuw83ubh5

[haruhiko_yamagata]

Thanks for the sample.
The splitter being used is the Microsoft MPEG-2 Demux that is part of Windows
Is it "MPEG-2 Demultiplexer" or "MPEG-2 Splitter"?
What is the OS?
"MPEG-2 Demux" isn't installed on my PC.

[egur]

@clsid
The QS check doesn't work on non-SandyBridge machines. It fails on my 9400T (Penryn) which is capable of QS. I'm afraid it will also fail on IvyBridge.
Please remove the existing check untill a new one is found.
If it makes sense to you, I can export a check function from my dll.

If these checks are too complicated or time consuming (from you), please remove them altogether or at least make them pass on all Intel processors.

[clsid]

@clsid
The QS check doesn't work on non-SandyBridge machines. It fails on my 9400T (Penryn) which is capable of QS. I'm afraid it will also fail on IvyBridge.
Please remove the existing check untill a new one is found.
If it makes sense to you, I can export a check function from my dll.

If these checks are too complicated or time consuming (from you), please remove them altogether or at least make them pass on all Intel processors.A simple check function in the DLL would be fine. Let it return for example a DWORD with a bitmask of capabilities.

[ipanema]

Thanks for the sample.

Is it "MPEG-2 Demultiplexer" or "MPEG-2 Splitter"?
What is the OS?
"MPEG-2 Demux" isn't installed on my PC.

Sorry, it's the "MPEG-2 Demultiplexer" http://msdn.microsoft.com/en-us/library/dd390715%28v=vs.85%29.aspx

OS is Windows 7. I haven't checked other versions of Windows.

[khagaroth]

Updated Czech translation (http://www.mediafire.com/?wam72ztnbc6q6ii).

[egur]

A simple check function in the DLL would be fine. Let it return for example a DWORD with a bitmask of capabilities.

OK, I'll add a simple check with a DWORD bitmask. First version will have 2 properties - HW support and SW support (Media SDK installed).

Update:
Done at r4301.

[haruhiko_yamagata]

Sorry, it's the "MPEG-2 Demultiplexer" http://msdn.microsoft.com/en-us/library/dd390715%28v=vs.85%29.aspx

OS is Windows 7. I haven't checked other versions of Windows.
I cannot use "MPEG-2 Demultiplexer". There is the filter but it requires a source filter.
I tried "TS File Source". It connects but the screen is black whatever the decoder is.
Any other source filters I have do not connect.
How do you use the filter? Would you tell me the application and the source filter?

EDIT
I gave up MPEG-2 Demultiplexer. I tried DVBViewer and reproduced the problem.

[Liisachan]

@haruhiko_yamagata
About r4303: if it's not too much trouble could you please make this optional? Maybe "Frame timestamps" (original one) and "Frame timestamps (friendly)" (new format), or perhaps "Frame timestamps" (new format) and "Raw frame timestamps" (old format) in the "OSD" menu? I sometimes want to see the frame time stamp down to rt (or even ns), and the old feature in ffdshow was quite handy.

[haruhiko_yamagata]

@haruhiko_yamagata
About r4303: if it's not too much trouble could you please make this optional? Maybe "Frame timestamps" (original one) and "Frame timestamps (friendly)" (new format), or perhaps "Frame timestamps" (new format) and "Raw frame timestamps" (old format) in the "OSD" menu? I sometimes want to see the frame time stamp down to rt (or even ns), and the old feature in ffdshow was quite handy.
OK, then I'll create a new item.

[ipanema]

MPEG-2 demultiplexer can be a little tricky to set up. The output media type must be set manually. It's part of a test environment here which I think has its own source filter (I didn't write it).

I tried DVBViewer and reproduced the problem.

Great. :)

[haruhiko_yamagata]

@ipanema,
It has been fixed at rev 4302. Please try the latest build.

[haruhiko_yamagata]

To fix the regression of performance of resize filter with Accurate rounding checked, I changed the base of ffdshow's libswscale from FFmpeg to Libav.
The performance is OK with Libav's libswscale plus ffdshow's custom multithreading.
As we are preparing for the next release, this kind of big change should be avoided if possible. But because it was a regression, I couldn't help...
Please test new builds.
x86 (http://www.ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4306_20120206_libswscale-Libav.exe)
x64 (http://www.ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4306_20120206_libswscale-Libav_x64.exe)
patch (http://www.ffdshow-tryout.sourceforge.net/doom9/libsws.patch)

EDIT
The patch reverts rev 4156 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&sortby=date&revision=4156).
Accurate rounding is enabled by default. The new builds and current SVN builds use a different registry value for "Accurate rounding". So please be careful if you compare performance or quality.

[ipanema]

@ipanema,
It has been fixed at rev 4302. Please try the latest build.

That was quick - thanks. I've just tried 4305 and it does seem to be fixed now. Great work.

A side issue, but I noticed that the decoder still does not output the leading B frames which other decoders manage to do. It's a bug report from 2009

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

For example, my FILE3 begins with the following input start timestamps

7770333
7103000 > B frame
7436666 > B frame
8771333
8104000
8437666
9772333
9105000
9438666

and Microsoft and Mainconcept decoders both output all the frames

7103000 > B frame
7436666 > B frame
7770333
8104000
8437666
8771333
9105000
9438666
9772333

but the ffdshow decoder outputs

7770333
8104000
8437666
8771333
9105000
9438666
9772333

note the missing B frames at the beginning.

[nevcairiel]

Thats quite normal, ffdshow will try to not output frames that show corruption, and a B frame needs more then the first I frame to be decodable without corruption.

[ipanema]

OK, but the leading B frames output by the Microsoft and Mainconcept decoders never show any corruption.

[Blight]

Hi,
I have a serious issue with recent builds (tested builds upto 4303) of ffdshow's audio decoder when the "Connect as PCM first" setting is disabled.
For some reason, when playing certain audio files (tested with AC3/DTS), the audio decoder exposes two media types.
One with major type "Audio" (and DTS/AC3 subtype) and a second with major type "stream" and sub-type "none":
http://t.inmatrix.com/ffdshowmediatype.gif

The problem is, my DSP filter is first presented with the "Stream" media type first and when it's rejected with "VFW_E_TYPE_NOT_ACCEPTED", the second media type (major type audio) isn't presented to my DSP filter at all.
If I enable "Connect as PCM first" or disable pass-through to S/PDIF, the problem disappears.

My question is,
Why is there a second media type with these values?
If it's an important feature for some conditions, can you make it optional and possibly default it to off?

[kc7bfi]

I have confirmed that the problem with the Optelecom H.264 video was created somewhere between version 4174 and 4194. Version 4174 plays the video fine but 4194 seems to only be playing I-frames. Any ideas what may have changed in those versions? If there are any intermediate Windows 64 bit installs I can also test them to try and narrow down the exact revision that caused the problem. Just let me know if they are available. Any help in resolving this issue would be greatly appreciated. David

I have verified that this was "broke" in version 4176. Version 4175 plays the Optelecom H.264 fine but version 4176 seems to only play I-frames. Any ideas what might have been changed? I looked through the code but I am far from understanding it. Thanks, David

[clsid]

I have verified that this was "broke" in version 4176. Version 4175 plays the Optelecom H.264 fine but version 4176 seems to only play I-frames. Any ideas what might have been changed? I looked through the code but I am far from understanding it. Thanks, DavidI need a sample file to reproduce the problem.

[kc7bfi]

I have verified that this was "broke" in version 4176. Version 4175 plays the Optelecom H.264 fine but version 4176 seems to only play I-frames. Any ideas what might have been changed? I looked through the code but I am far from understanding it. Thanks, David

Here is the DebugView from 4175
00000172 1.17888844 [10352] TffdshowDecVideo::Run thread=10896
00000173 1.41790235 [10352] TimgFilterOutput::process V-RAM access is Direct, t_indirect = 50000, t_direct = 50000
00000174 1.88360322 [10352] no frame!
00000175 2.71864915 [10352] no frame!
00000176 3.55155683 [10352] no frame!
00000177 4.38556004 [10352] no frame!
00000178 5.21953058 [10352] no frame!
00000179 6.05361080 [10352] no frame!
00000180 6.70131016 [10352] TffdshowDecVideo::Stop thread=8348
00000181 6.70138931 [10352] TffdshowDecVideoOutputPin::DeliverEndOfStream
00000182 6.70144272 [10352] TffdshowDecVideoOutputPin::Inactive
00000183 6.79012012 [10352] Removed from filter graph
00000184 6.79810095 [10352] TffdshowDecVideo::Destructor
00000185 6.79825163 [10352] TffdshowDecVideoOutputPin::Destructor

Here is the DebugView from 4176
00000172 1.21519601 [1428] TffdshowDecVideo::Run thread=9688
00000173 1.33532727 [1428] Missing reference picture
00000174 1.33536828 [1428] decode_slice_header error
00000175 1.33587193 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000176 1.34136713 [1428] Frame num gap 2 0
00000177 1.34260333 [1428] Frame num gap 3 1
00000178 1.35833633 [1428] Frame num gap 4 2
00000179 1.35930073 [1428] Frame num gap 5 3
00000180 1.36132705 [1428] Frame num gap 6 4
00000181 1.36357117 [1428] Frame num gap 7 5
00000182 1.36568916 [1428] Frame num gap 8 6
00000183 1.39263272 [1428] Frame num gap 9 7
00000184 1.45666087 [1428] Frame num gap 10 8
00000185 1.46278739 [1428] Frame num gap 11 9
00000186 1.49258065 [1428] Frame num gap 12 10
00000187 1.52566409 [1428] Frame num gap 13 11
00000188 1.52720392 [1428] TimgFilterOutput::process V-RAM access is Direct, t_indirect = 50000, t_direct = 30000
00000189 1.56086862 [1428] Frame num gap 14 12
00000190 1.59262443 [1428] Frame num gap 15 13
00000191 1.62587583 [1428] Missing reference picture
00000192 1.62593484 [1428] decode_slice_header error
00000193 1.62600315 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000194 1.65942085 [1428] mmco: unref short failure
00000195 1.65982413 [1428] Missing reference picture
00000196 1.65985489 [1428] decode_slice_header error
00000197 1.65990770 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000198 1.69238532 [1428] mmco: unref short failure
00000199 1.69255745 [1428] Frame num gap 2 0
00000200 1.72563791 [1428] Frame num gap 3 1
00000201 1.72627270 [1428] Frame num gap 4 2
00000202 1.72825873 [1428] Frame num gap 5 3
00000203 1.82658899 [1428] Frame num gap 6 4
00000204 1.85965872 [1428] Frame num gap 7 5
00000205 1.89266777 [1428] Frame num gap 8 6
00000206 1.92944741 [1428] no frame!
00000207 1.99259627 [1428] Missing reference picture
00000208 1.99266315 [1428] decode_slice_header error
00000209 1.99328876 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000210 2.02658963 [1428] Frame num gap 2 0
00000211 2.05956984 [1428] Frame num gap 4 2
00000212 2.06051445 [1428] Frame num gap 5 3
00000213 2.12658978 [1428] Frame num gap 6 4
00000214 2.19343543 [1428] Frame num gap 8 6
00000215 2.22663951 [1428] Frame num gap 9 7
00000216 2.25960851 [1428] Frame num gap 10 8
00000217 2.32662439 [1428] Frame num gap 12 10
00000218 2.35958147 [1428] Frame num gap 13 11
00000219 2.39361620 [1428] Frame num gap 14 12
00000220 2.46083927 [1428] Missing reference picture
00000221 2.46089482 [1428] decode_slice_header error
00000222 2.46102023 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000223 2.49345899 [1428] mmco: unref short failure
00000224 2.49374795 [1428] Missing reference picture
00000225 2.49380755 [1428] decode_slice_header error
00000226 2.49390459 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000227 2.52646852 [1428] mmco: unref short failure

Both versions are playing the same video. Any ideas? David

[kc7bfi]

I need a sample file to reproduce the problem.

Here is a wireshark capture:
http://dl.dropbox.com/u/37804952/Optelecom.pcap

Here is a Matroska recording
http://dl.dropbox.com/u/37804952/Optelecom.mkv

This is a live encoder. If it would be helpful I could also put our encoder in the Internet so you could access it.

Thanks for the help. David

[Liisachan]

OK, then I'll create a new item.

Thanks! Your awesome work, especially in Subtitles, is always appreciated :)

[haruhiko_yamagata]

Here is a wireshark capture:
http://dl.dropbox.com/u/37804952/Optelecom.pcap

Here is a Matroska recording
http://dl.dropbox.com/u/37804952/Optelecom.mkv

This is a live encoder. If it would be helpful I could also put our encoder in the Internet so you could access it.

Thanks for the help. David
I tried the mkv file. If LAV Splitter Source is used, and the decoder is either LAV Video Decoder or ffdshow, it does not work. Microsoft DTV decoder works.
If Haali's splitter is used, it is OK. nevcairiel, if you are reading this, would you take a look?

@kc7bfi,
As the example above shows, the source/splitter filter is the key. I can't debug anything or help you unless you provide the source/splitter filter.

[nevcairiel]

nevcairiel, if you are reading this, would you take a look?

That file is odd, whatever muxed it is a broken application.
It muxed an AnnexB stream into MKV, which in itself is not wrong, BUT it created MP4 style extradata. Either you mux in AnnexB mode, or in MP4 mode, combining the two is .... weird. Horrible. :)

I can probably fix it in the splitter, though.

[haruhiko_yamagata]

That file is odd, whatever muxed it is a broken application.
It muxed an AnnexB stream into MKV, which in itself is not wrong, BUT it created MP4 style extradata. Either you mux in AnnexB mode, or in MP4 mode, combining the two is .... weird. Horrible. :)

I agree it's horrible and broken. Thanks for your time.

I can probably fix it in the splitter, though.
Only if you have extra time.

[nevcairiel]

After fixing the source, LAV Video in software mode still cannot decode it, must be a problem in libav/ffmpeg itself. If i run it though CUDA or the Intel decoder, it works just fine.

For the record, it never worked with Haali for me either.

Edit:
I actually fixed it, the file is just muxed very badly. It doesn't work 100% from the start .. but it works, kind of.

[kc7bfi]

That file is odd, whatever muxed it is a broken application.
It muxed an AnnexB stream into MKV, which in itself is not wrong, BUT it created MP4 style extradata. Either you mux in AnnexB mode, or in MP4 mode, combining the two is .... weird. Horrible. :)

I can probably fix it in the splitter, though.

I must confess that I am not very familiar with the finer points of H.264 video nor its packaging. Also, it may be possible that something went wrong woth the MKV file creation, but I have a few questions:

1) Do you see the same "muxed" issues in the wireshark?
2) Would this explain the DebugView log I included in a previous message?
3) Would there have been something changed between revisions 4175 and 4176 that would have caused this problem?

It it would be helpful I could create a small program that will play the video from the encoder (over the Internet) using the ffdshow filter for decoding. Just let me know. David

[haruhiko_yamagata]

I must confess that I am not very familiar with the finer points of H.264 video nor its packaging. Also, it may be possible that something went wrong woth the MKV file creation, but I have a few questions:

1) Do you see the same "muxed" issues in the wireshark?

How can I analyze it? I won't read bit-stream using binary editor. I'm not a computer.

2) Would this explain the DebugView log I included in a previous message?

The debug log indicates the stream is broken. Or it may be indicating the bug of the source/splitter filter or ffdshow.

3) Would there have been something changed between revisions 4175 and 4176 that would have caused this problem?

Rev 4176 changes the way of calculation of NAL unit size. As the mkv file shown, the upper stream filter must not use start code "00 00 01" if the container is mkv or mp4. It must use NAL unit size instead. Microsoft's guideline (http://msdn.microsoft.com/en-us/library/windows/desktop/dd757808%28v=vs.85%29.aspx). Does simply changing the FOURCC work? If your source is RTSP, I don't know how NAL unit size is handled in DirectShow. I think the guideline still should be followed. If I'm wrong, please correct me.

It it would be helpful I could create a small program that will play the video from the encoder (over the Internet) using the ffdshow filter for decoding. Just let me know. David
That would help a lot. I'll wait for it.

[mandarinka]

I tried enabling software scaling, but it seems to me the aspect ratio handling might not be working as expected.

I tried to play a 16/9 movie on a 16/10 LCD (1680x1050), so I followed the instructions here: http://ffdshow-tryout.sourceforge.net/wiki/video:resize_aspect

(That means, "specify horizontal and vertical size" enabled, set to: 1680x1050, "keep original aspect ratio" enabled, "process pixel aspect ratio internally" enabled. At the same time, I disabled "keep aspect ratio" in mpc as the help entry suggests.)

If I understand the help properly, this should scale the image, keeping the aspect ratio, until width or height hits the specified dimensions. However, ffdshow will also pad the image with black bars to meet the specified resolution on top of that, it will expand 4:3 or 16:9 frame to the full 16/10 of the LCD.
This has two weird consequences: subtitle positioning is changed, and if you switch the player to window, the black bars padding will affect the windowed display.

Is this how it is supposed to work, or am I missing something? I'm afraid don't recall how the function behaved in the past, so I have no idea if this is actually a regression or standard behaviour...

(revision tested: 4296, x86 MSVC buld from xvidvideo.ru; windows XP sp3 home, MPC-HC 1.5.3.3819)

P.S. If the padding is intentional, I'd like to suggest adding an option to disable it. It would make the scaling more useful if ASS subtitles that rely on positioning are used.

[clsid]

As the documentation says: If you specify both height and width, then ffdshow will resize to that exact resolution. Padding is required if the aspect ratio of the video differs from your target resolution.

If you don't want padding you need to create two profiles:
aspect < 16/10 -> specify height
aspect >= 16/10 -> specify width

Disabling that option in MPC should not be needed.

[nevcairiel]

the upper stream filter must not use start code "00 00 01" if the container is mkv or mp4. It must use NAL unit size instead.

Thats not true, MKV is fine with start-code based H264, that particular file has just mixed both solutions into one.

The stream itself works fine with various hardware decoders i tried, it seems to be an issue with the software decoder.
I do actually get an image now with LAV, but the first few frames are missing.

[haruhiko_yamagata]

Thats not true, MKV is fine with start-code based H264
Thanks for the info. I didn't know.

[haruhiko_yamagata]

@kc7bfi,
How does your filter feed SPS/PPS to ffdshow?
Is it given as codec private data on connection? or is it given to IMemInputPin::Receive?
How NAL unit size is handled for SPS/PPS?

[betaking]

to h_yamagata: can not compile last ffdshow svn
1>C:\ffdshow\src\ffmpeg/libswscale/swscale.h(157): error C2371: “SwsVector”: 重定义；不同的基类型
c:\ffdshow\src\ffmpeg\Tlibavcodec.h(18) : 参见“SwsVector”的声明
1>C:\ffdshow\src\ffmpeg/libswscale/swscale.h(165): error C2371: “SwsFilter”: 重定义；不同的基类型
c:\ffdshow\src\ffmpeg\Tlibavcodec.h(17) : 参见“SwsFilter”的声明
TDXVADecoderH264.cpp
TDXVADecoderVC1.cpp
ffdshow_converters.cpp
ffImgfmt.cpp
image.cpp
Tconvert.cpp
1>C:\ffdshow\src\ffmpeg\libswscale/swscale.h(157): error C2371: “SwsVector”: 重定义；不同的基类型
C:\ffdshow\src\ffmpeg\Tlibavcodec.h(18) : 参见“SwsVector”的声明
1>C:\ffdshow\src\ffmpeg\libswscale/swscale.h(165): error C2371: “SwsFilter”: 重定义；不同的基类型
C:\ffdshow\src\ffmpeg\Tlibavcodec.h(17) : 参见“SwsFilter”的声明
1>c:\ffdshow\src\ffmpeg\libavutil\bswap.h(75): warning C4244: “参数”: 从“uint64_t”转换到“uint32_t”，可能丢失数据
TrgbPrimaries.cpp
Tswscale.cpp
1>C:\ffdshow\src\ffmpeg\libswscale/swscale.h(157): error C2371: “SwsVector”: 重定义；不同的基类型
C:\ffdshow\src\ffmpeg\Tlibavcodec.h(18) : 参见“SwsVector”的声明
1>C:\ffdshow\src\ffmpeg\libswscale/swscale.h(165): error C2371: “SwsFilter”: 重定义；不同的基类型
C:\ffdshow\src\ffmpeg\Tlibavcodec.h(17) : 参见“SwsFilter”的声明
dither.cpp
fftsg.cpp
firfilter.cpp
mixer.cpp
TaudioFilter.cpp
TaudioFilterChannelSwap.cpp
TaudioFilterConvolver.cpp
TaudioFilterCrystality.cpp
TaudioFilterDelay.cpp
TaudioFilterDenoise.cpp
TaudioFilterDolbyDecoder.cpp
TaudioFilterEQ.cpp
TaudioFilterEQsuper.cpp
1>c:\ffdshow\src\audiofilters\supereq.h : warning C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失
TaudioFilterFIR.cpp
TaudioFilterFreeverb.cpp
TaudioFilterHeadphone.cpp
TaudioFilterLFEcrossover.cpp
1>src\audioFilters\TaudioFilterLFEcrossover.cpp(98): warning C4244: “=”: 从“double”转换到“float”，可能丢失数据
1>src\audioFilters\TaudioFilterLFEcrossover.cpp(100): warning C4244: “=”: 从“double”转换到“float”，可能丢失数据
1>src\audioFilters\TaudioFilterLFEcrossover.cpp(147): warning C4244: “=”: 从“double”转换到“float”，可能丢失数据
1>src\audioFilters\TaudioFilterLFEcrossover.cpp(149): warning C4244: “=”: 从“double”转换到“float”，可能丢失数据
1>src\audioFilters\TaudioFilterLFEcrossover.cpp(155): warning C4244: “=”: 从“double”转换到“float”，可能丢失数据
TaudioFilterMixer.cpp
TaudioFilterOSD.cpp
TaudioFilterOutput.cpp
TaudioFilterResample.cpp
TaudioFilters.cpp
TaudioFilterVolume.cpp
TaudioFilterWinamp2.cpp
TsampleFormat.cpp
Twinamp2.cpp
revmodel.cpp
resample2.cpp
TffProcAudio.cpp
TencStats.cpp
TffdshowEnc.cpp
Tffvfw.cpp
Tmuxer.cpp
TmuxerFile.cpp
Tacm.cpp
CSSauth.cpp
CSSscramble.cpp
DeCSSInputPin.cpp
Tfilter.cpp
Tfilters.cpp
TOSDprovider.cpp
amfilter.cpp
combase.cpp
dllentry.cpp
dllsetup.cpp
mtype.cpp
outputq.cpp
pstream.cpp
strmiids.cpp
transfrm.cpp
wxdebug.cpp
wxlist.cpp
wxutil.cpp
1>已完成生成项目“C:\ffdshow\ffdshow_2010.vcxproj”(build 个目标)的操作 - 失败。

[haruhiko_yamagata]

Compilation fixed.
I found x64 version's color is broken for 10-bit video. Please wait.

[betaking]

Compilation fixed.
I found x64 version's color is broken for 10-bit video. Please wait.

:thanks: i wait now!

[haruhiko_yamagata]

I have fixed my working copy. I'll commit tomorrow.

[betaking]

I have fixed my working copy. I'll commit tomorrow.

OK! thanks again!

[haruhiko_yamagata]

I have committed as rev 4314. Hope there are not too many regressions...

[kc7bfi]

How can I analyze it? I won't read bit-stream using binary editor. I'm not a computer.

The debug log indicates the stream is broken. Or it may be indicating the bug of the source/splitter filter or ffdshow.

Rev 4176 changes the way of calculation of NAL unit size. As the mkv file shown, the upper stream filter must not use start code "00 00 01" if the container is mkv or mp4. It must use NAL unit size instead. Microsoft's guideline (http://msdn.microsoft.com/en-us/library/windows/desktop/dd757808%28v=vs.85%29.aspx). Does simply changing the FOURCC work? If your source is RTSP, I don't know how NAL unit size is handled in DirectShow. I think the guideline still should be followed. If I'm wrong, please correct me.

That would help a lot. I'll wait for it.

Thanks for looking into this. I understand moving video via RTSP but when it comes to the bits and bytes of video my knowledge drops off exponentially. The following link has a program that will replay a wireshark capture indicating the problem. Just unpack it and run the run.bat program. Let me know if you have trouble. Thanks, David
http://dl.dropbox.com/u/37804952/H264replay.zip

[haruhiko_yamagata]

Thanks for looking into this. I understand moving video via RTSP but when it comes to the bits and bytes of video my knowledge drops off exponentially. The following link has a program that will replay a wireshark capture indicating the problem. Just unpack it and run the run.bat program. Let me know if you have trouble. Thanks, David
http://dl.dropbox.com/u/37804952/H264replay.zip
Thanks, but the playback does not start.
"Source IP" (192.168.111.12) doesn't look like a valid address.
I inserted "C:\Program Files (x86)\Java\jre6\bin\" before "java" in run.bat. Was it OK? Otherwise, which "java" should I use?
It looks like it is trying to load x64 dll.

http://ffdshow-tryout.sourceforge.net/doom9/vicads.png

[kc7bfi]

Thanks, but the playback does not start.
"Source IP" (192.168.111.12) doesn't look like a valid address.
I inserted "C:\Program Files (x86)\Java\jre6\bin\" before "java" in run.bat. Was it OK? Otherwise, which "java" should I use?
It looks like it is trying to load x64 dll.

http://ffdshow-tryout.sourceforge.net/doom9/vicads.png

Yes this is a 64 bit program. It is a Java program that includes an interface to the DirectShow system. If you want to use a 32 bit Java, try using this dsj.dll instead of the one I previously sent.
http://dl.dropbox.com/u/37804952/dsj.dll

David

[haruhiko_yamagata]

A progress, it tries to connect, but fails.

C:\ff\rtsp>"C:\Program Files (x86)\Java\jre6\bin\java" -Xmx512m -cp .;dsj.jar;Vicads-DsjPlayer-4.0.jar;orci-commons-logging-1.0.jar;orci-commons-lang-1.0.jar;log4j-1.2.16.jar;packer-2.0.jar;javahelp-2.0.02.jar com.orci.vicads.PCAPReplay.MainApp
log4j:WARN No appenders could be found for logger (com.orci.vicads.PCAPReplay.MainApp).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Source: Connect
Closing
Closed
de.humatic.dsj.DSJException: RTPSource could not resolve streams, no data received
at de.humatic.dsj.src.RTPSource.createGraph(SourceFile:594)
at com.orci.vicads.PCAPReplay.MainFrame.startReplay(MainFrame.java:219)
at com.orci.vicads.PCAPReplay.MainFrame.access$300(MainFrame.java:49)
at com.orci.vicads.PCAPReplay.MainFrame$5.actionPerformed(MainFrame.java:179)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

[kc7bfi]

A progress, it tries to connect, but fails.

C:\ff\rtsp>"C:\Program Files (x86)\Java\jre6\bin\java" -Xmx512m -cp .;dsj.jar;Vicads-DsjPlayer-4.0.jar;orci-commons-logging-1.0.jar;orci-commons-lang-1.0.jar;log4j-1.2.16.jar;packer-2.0.jar;javahelp-2.0.02.jar com.orci.vicads.PCAPReplay.MainApp
log4j:WARN No appenders could be found for logger (com.orci.vicads.PCAPReplay.MainApp).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Source: Connect
Closing
Closed
de.humatic.dsj.DSJException: RTPSource could not resolve streams, no data received
at de.humatic.dsj.src.RTPSource.createGraph(SourceFile:594)
at com.orci.vicads.PCAPReplay.MainFrame.startReplay(MainFrame.java:219)
at com.orci.vicads.PCAPReplay.MainFrame.access$300(MainFrame.java:49)
at com.orci.vicads.PCAPReplay.MainFrame$5.actionPerformed(MainFrame.java:179)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)


Hmmm. works here. Try this new zip. It adds some logging. The log will be in your user directory named PCAPReplay.log. Make sure not to change any of the parameters on the form. They should be set correctly. David

http://dl.dropbox.com/u/37804952/H264replay2.zip

[Reino]

Do you people really have to fully quote every successive post?!

[haruhiko_yamagata]

Still not working on x64 Java.

C:\ff\rtsp>"C:\Program Files\Java\jre6\bin\java" -Xmx512m -cp .;dsj.jar;Vicads-DsjPlayer-4.0.jar;orci-commons-logging-1.0.jar;orci-commons-lang-1.0.jar;log4j-1.2.16.jar;packer-2.0.jar;javahelp-2.0.02.jar com.orci.vicads.PCAPReplay.MainApp
0 [main] INFO com.orci.vicads.PCAPReplay.MainApp - Create main frame...
90 [main] WARN com.orci.vicads.PCAPReplay.MainFrame - ViewerFrame: Unable to load logo image file /images/vicads_app_icon.gif: java.lang.NullPointerException
183 [main] WARN com.orci.vicads.PCAPReplay.MainFrame - Could not load helpset: javax.help.HelpSetException: Could not parse
Got an IOException (null)
Parsing failed for null
2919 [AWT-EventQueue-0] INFO com.orci.vicads.PCAPReplay.MainFrame - pcap=Optelecom.pcap
2919 [AWT-EventQueue-0] INFO com.orci.vicads.PCAPReplay.MainFrame - srcIp=192.168.111.12
2919 [AWT-EventQueue-0] INFO com.orci.vicads.PCAPReplay.MainFrame - destIp=224.0.111.12:50000
2919 [AWT-EventQueue-0] INFO com.orci.vicads.PCAPReplay.MainFrame - sdp=Optelecom.sdp
2978 [AWT-EventQueue-0] INFO stdout - Source: Connect
3028 [AWT-EventQueue-0] INFO stdout - Graph error: Cannot add filter
17942 [Timer-0] INFO stdout - Closing
17996 [Timer-0] INFO stdout - Closed
23129 [AWT-EventQueue-0] ERROR stderr - de.humatic.dsj.DSJException: RTPSource could not resolve streams, no data received
23129 [AWT-EventQueue-0] ERROR stderr - at de.humatic.dsj.src.RTPSource.createGraph(SourceFile:594)
23130 [AWT-EventQueue-0] ERROR stderr - at com.orci.vicads.PCAPReplay.MainFrame.startReplay(MainFrame.java:223)
23130 [AWT-EventQueue-0] ERROR stderr - at com.orci.vicads.PCAPReplay.MainFrame.access$300(MainFrame.java:49)
23130 [AWT-EventQueue-0] ERROR stderr - at com.orci.vicads.PCAPReplay.MainFrame$5.actionPerformed(MainFrame.java:179)
23130 [AWT-EventQueue-0] ERROR stderr - at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
23130 [AWT-EventQueue-0] ERROR stderr - at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
23131 [AWT-EventQueue-0] ERROR stderr - at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
23131 [AWT-EventQueue-0] ERROR stderr - at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
23131 [AWT-EventQueue-0] ERROR stderr - at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
23131 [AWT-EventQueue-0] ERROR stderr - at java.awt.Component.processMouseEvent(Unknown Source)
23131 [AWT-EventQueue-0] ERROR stderr - at javax.swing.JComponent.processMouseEvent(Unknown Source)
23132 [AWT-EventQueue-0] ERROR stderr - at java.awt.Component.processEvent(Unknown Source)
23132 [AWT-EventQueue-0] ERROR stderr - at java.awt.Container.processEvent(Unknown Source)
23132 [AWT-EventQueue-0] ERROR stderr - at java.awt.Component.dispatchEventImpl(Unknown Source)
23132 [AWT-EventQueue-0] ERROR stderr - at java.awt.Container.dispatchEventImpl(Unknown Source)
23132 [AWT-EventQueue-0] ERROR stderr - at java.awt.Component.dispatchEvent(Unknown Source)
23133 [AWT-EventQueue-0] ERROR stderr - at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
23133 [AWT-EventQueue-0] ERROR stderr - at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
23133 [AWT-EventQueue-0] ERROR stderr - at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
23133 [AWT-EventQueue-0] ERROR stderr - at java.awt.Container.dispatchEventImpl(Unknown Source)
23133 [AWT-EventQueue-0] ERROR stderr - at java.awt.Window.dispatchEventImpl(Unknown Source)
23134 [AWT-EventQueue-0] ERROR stderr - at java.awt.Component.dispatchEvent(Unknown Source)
23134 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
23134 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventQueue.access$000(Unknown Source)
23134 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventQueue$1.run(Unknown Source)
23134 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventQueue$1.run(Unknown Source)
23135 [AWT-EventQueue-0] ERROR stderr - at java.security.AccessController.doPrivileged(Native Method)
23135 [AWT-EventQueue-0] ERROR stderr - at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
23135 [AWT-EventQueue-0] ERROR stderr - at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
23135 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventQueue$2.run(Unknown Source)
23135 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventQueue$2.run(Unknown Source)
23136 [AWT-EventQueue-0] ERROR stderr - at java.security.AccessController.doPrivileged(Native Method)
23136 [AWT-EventQueue-0] ERROR stderr - at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
23136 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventQueue.dispatchEvent(Unknown Source)
23136 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
23136 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
23137 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
23137 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
23137 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
23137 [AWT-EventQueue-0] ERROR stderr - at java.awt.EventDispatchThread.run(Unknown Source)

EDIT
I tried regsvr32 dsj.dll, which resulted error. I think I need the source/splitter filter.ax.

[Snowknight26]

FPS1 -> NV12 conversion results in wrong colors. Example. (http://stfcc.org/pics/i/fdd3ea6f828a7dff2805e9bca9c0e8e1.png)
FPS1 -> * is fine. Example. (http://stfcc.org/pics/i/2ed44b4ab9a96899cd03a77fe3726bf7.png)

Sample. (http://stfcc.org/misc/ffdshow.fraps.colors.zip)

[haruhiko_yamagata]

FPS1 -> NV12 conversion results in wrong colors. Example. (http://stfcc.org/pics/i/fdd3ea6f828a7dff2805e9bca9c0e8e1.png)
FPS1 -> * is fine. Example. (http://stfcc.org/pics/i/2ed44b4ab9a96899cd03a77fe3726bf7.png)

Sample. (http://stfcc.org/misc/ffdshow.fraps.colors.zip)Thanks, I can reproduce.
Perhaps RGB->YCbCr conversion is currently broken.
(This issue is not related to the migration of libswscale.)

[ryrynz]

Dunno if you would care Haruhiko but I'd like to mention Pastebin as being a great place to store debug outputs and such which you could link to thus helping keep the thread tidy this would help fix up the reply issue Corone mentioned.

[kc7bfi]

I tried regsvr32 dsj.dll, which resulted error. I think I need the source/splitter filter.ax.

Not sure why its not working there. It works fine here, although I'm using 64bit. You should not need anything other filters. The key message is "RTPSource could not resolve streams, no data received" which seems to indicate that it could not read/process the video information from the PCAP file (a wireshark capture). Maybe you need wireshark installed. I'll ask the guy who wrote our wireshark replay service. Thanks. David

[egur]

Please note my last commit:

Modified/fixed TtelecineManager class (in TvideoCodec.cpp + .h). Changed behavior to produce exactly 23.976 fps when entering film mode. Previous behavior was not producing smooth playback. In film mode time stamps are calculated from the first frame of the film sequence.

Playback wasn't smooth on many clips. averaging time stamps is not a good concept... Now it's much better with less code :)

Re-added an initialization from SPS header (H264) of the pictIn variable used for codec initialization. Need to check if this is actually used since no one complained.

[haruhiko_yamagata]

Currently ffdshow use libswscale to convert RGB24 to YV12.
Neither Libav nor FFmpeg supports color matrix configuration. BT.601-TV is simply hard coded. That's why FPS1 -> NV12 conversion is failing.
Everyone, please give me an advice, from which project to import. A converter that has good scaler and supports configuration of matrix and range is wanted.

[haruhiko_yamagata]

Please note my last commit:

Modified/fixed TtelecineManager class (in TvideoCodec.cpp + .h). Changed behavior to produce exactly 23.976 fps when entering film mode. Previous behavior was not producing smooth playback. In film mode time stamps are calculated from the first frame of the film sequence.

Playback wasn't smooth on many clips. averaging time stamps is not a good concept... Now it's much better with less code :)
Thanks for fix.
I've broken something when I changed the code to check only one repeat first field flag to enter film mode.
Formerly, it checked 4 frames (10 fields) and buffered them to calculate the average.
Is it safe enough to assume 23.976 fps just by detecting only one repeat first field flag?

Re-added an initialization from SPS header (H264) of the pictIn variable used for codec initialization. Need to check if this is actually used since no one complained.

In my working copy for the next commit, it needs to get frame rate from SPS.
That function is now very robust and won't crash anymore. Please keep it.

[clsid]

There is a function called sws_setColorspaceDetails in swscale. That might be useful.

[haruhiko_yamagata]

There is a function called sws_setColorspaceDetails in swscale. That might be useful.
I have already tried that. It doesn't help.
As far as I can see, it works only for 8-bit YCbCr to RGB conversion.

[CruNcher]

haruhiko_yamagata did you saw that ? :)

https://forum.doom9.org/showpost.php?p=1557391&postcount=16

[haruhiko_yamagata]

haruhiko_yamagata did you saw that ? :)

https://forum.doom9.org/showpost.php?p=1557391&postcount=16
Thanks for the link. I'll consider importing next time I can spare time for subtitles.

[haruhiko_yamagata]

Thats quite normal, ffdshow will try to not output frames that show corruption, and a B frame needs more then the first I frame to be decodable without corruption.
No, that two B frames are dropped unintentionally.
Any pictures decoded after an IDR picture should be displayed even if the POC is earlier than the IDR picture.
I don't know where the bug is, ffdshow or libavcodec. Not likely in ffdshow, but not sure...

[nevcairiel]

The point remains that a B-frame is bi-predictive, which means it needs two reference frames. avcodec itself will not decode a B-frame if it doesn't have two references yet, unless you set a special flag to blindly decode everything.

[Vincent Vega]

guys, scary story: i use 2002 via kle133 mobo with trident blade3d 8mb graphics on xp, can only handle 16bit color at 1280x1024. i output rgb from ffdshow to have control over conversion coefficients. after rev3765 even though theres no explicit rgb16 output option, ffdshow still connects normally in rgb16 to vmr7 (with rgb32/24-only checked in settings). but with directvobsub in between ffdshow and vmr7, it outputs rgb32/24, and following conversion rgb32/24->rgb16 in directvobsub produces unwatchable messed up picture. i didnt have much luck using ffdshow's own subtitler either on this computer.

so i need rgb16 option back or i'll be stuck with r3764 foreva -)

[egur]

guys, scary story: i use 2002 via kle133 mobo with trident blade3d 8mb graphics on xp, can only handle 16bit color at 1280x1024. i output rgb from ffdshow to have control over conversion coefficients. after rev3765 even though theres no explicit rgb16 output option, ffdshow still connects normally in rgb16 to vmr7 (with rgb32/24-only checked in settings). but with directvobsub in between ffdshow and vmr7, it outputs rgb32/24, and following conversion rgb32/24->rgb16 in directvobsub produces unwatchable messed up picture. i didnt have much luck using ffdshow's own subtitler either on this computer.

so i need rgb16 option back or i'll be stuck with r3764 foreva -)
Funny :D

[mandarinka]

guys, scary story: i use 2002 via kle133 mobo with trident blade3d 8mb graphics on xp, can only handle 16bit color at 1280x1024. i output rgb from ffdshow to have control over conversion coefficients. after rev3765 even though theres no explicit rgb16 output option, ffdshow still connects normally in rgb16 to vmr7 (with rgb32/24-only checked in settings). but with directvobsub in between ffdshow and vmr7, it outputs rgb32/24, and following conversion rgb32/24->rgb16 in directvobsub produces unwatchable messed up picture. i didnt have much luck using ffdshow's own subtitler either on this computer.

so i need rgb16 option back or i'll be stuck with r3764 foreva -)

This might not work but it's worth to try it:
Open directvobsub setitngs, and on the tab with list of preferred colorspaces, move rgb565 all the way up. Maybe that makes directvobsub to negotiate a 16bit connection. Too bad you can't remove colorspaces from the list, to make vsfilter not accept them...

[Vincent Vega]

thanks i tried that before too, same result. those i think are preferences for output colorspace (vobsub->renderer)

[haruhiko_yamagata]

The point remains that a B-frame is bi-predictive, which means it needs two reference frames.
I think it is not illegal for B-frames to have only one reference frame.
See ITU-T Recommendation, Advanced video coding for generic audiovisual services, 3.8 B slice.
avcodec itself will not decode a B-frame if it doesn't have two references yet, unless you set a special flag to blindly decode everything.
In my opinion, it's a bug. I would admit if there are different opinions, but ffdshow already has way to drop unnecessary frames. Double check is unwanted.
What is the special flag called?

[kc7bfi]

Not sure why its not working there. It works fine here, although I'm using 64bit. You should not need anything other filters. The key message is "RTPSource could not resolve streams, no data received" which seems to indicate that it could not read/process the video information from the PCAP file (a wireshark capture). Maybe you need wireshark installed. I'll ask the guy who wrote our wireshark replay service. Thanks. David

Sorry, I don't know why it is not working there. The only other thing I can think of is if your machine has two active NICs. The replay reads the video packets from the PCAP file and re-broadcasts them on the multicast address. If for some reason the multicast traffic gets bound to a different NIC than your primary there there can be an issue. But that's a long shot. Thanks anyway for looking at it. I still have the problem but will need to look at another way to reproduce it. David

[clsid]

In my opinion, it's a bug. I would admit if there are different opinions, but ffdshow already has way to drop unnecessary frames. Double check is unwanted.
What is the special flag called?CODEC_FLAG2_SHOW_ALL, but it is only used in FFmpeg, not in Libav.

[haruhiko_yamagata]

@kc7bfi,
How does your filter feed SPS/PPS to ffdshow?
Is it given as codec private data on connection? or is it given to IMemInputPin::Receive?
How NAL unit size is handled for SPS/PPS?
This is an important question. Can anyone in your company answer?

[haruhiko_yamagata]

CODEC_FLAG2_SHOW_ALL, but it is only used in FFmpeg, not in Libav.
Thanks. I'm reading Libav. It's not easy...

[hoborg]

Hi.
Is there a way how to force FFDshow installer to deploy quicksync decoder even if my Intel HD Graphics 2000 GPU is disabled right now?

[gendouhydeist]

There's seems to be a problem with the latest revision of ffdshow whenever I play a h264 file. The player just keep crashing on Y416 output, It doesn't happen on 4319 though.

[CruNcher]

It seems SPP doesn't work with ffdshow-quicksync http://www.mediafire.com/?0n9f62ih6f5chn4 it works externally though

[clsid]

That has nothing to do with QS. PP is skipped when decoding H.264.

[CruNcher]

But why restricting it to any format and this isn't H.264 but Mpeg-2 and it doesn't work ?

Here it's working when forcing it externaly http://www.mediafire.com/?op1aegifswodc8p

[kc7bfi]

We are playing video from a Bosch H.264 encoders and getting the following error in DebugView:

"illeagle short term buffer state detected"

Any idea what this means? Thanks, David

[haruhiko_yamagata]

But why restricting it to any format and this isn't H.264 but Mpeg-2 and it doesn't work ?

Here it's working when forcing it externaly http://www.mediafire.com/?op1aegifswodc8p
It has been asked again and again (http://forum.doom9.org/showthread.php?p=1230269#post1230269).

[haruhiko_yamagata]

We are playing video from a Bosch H.264 encoders and getting the following error in DebugView:

"illeagle short term buffer state detected"

Any idea what this means? Thanks, David
Most likely, SPS and PPS are not properly sent. Please replay to my question (http://forum.doom9.org/showthread.php?p=1557000#post1557000).

[haruhiko_yamagata]

A side issue, but I noticed that the decoder still does not output the leading B frames which other decoders manage to do. It's a bug report from 2009

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

Fixed at rev 4325. Thanks.

[kc7bfi]

@kc7bfi,
How does your filter feed SPS/PPS to ffdshow?
Is it given as codec private data on connection? or is it given to IMemInputPin::Receive?
How NAL unit size is handled for SPS/PPS?

This is from the company doing our Java to DirectShow bridge. I hope this answers your question.

SPS/PPS is both in the OutputPin's media type pbFormat field and
inserted into the stream before keyframes. You should see the first on the mediatype when ffdshow connects and the second in Receive. The stream itself will be startcode not size prefixed.

[hoborg]

Hi.
If i enable resize (default settings) durning FLV media playback, ffdshow will crash.
version: ffdshow_rev4323_20120214_xvidvideo-ru_x86-msvc2010.zip

It was introduced in ffdshow_rev4320_20120213_xvidvideo-ru_x86-msvc2010.zip, ffdshow_rev4314_20120210_xvidvideo-ru_x86-msvc2010.zip is OK.

[jabloomf1230]

libavcodec includes the Avid's open source codec DNxHD (VC3). For example:

http://ffmpeg.org/doxygen/trunk/libavcodec_2dnxhddec_8c-source.html

It is possible to decode and encode these files with ffmpeg and ffmbc. Since this codec is becoming more popular, has there been any thought given to adding it to ffdshow? At present, other than buying a commercial 3rd party DirectShow filter, the only way that I know of accessing DNxHD files is via Quicktime.

[nevcairiel]

libavcodec includes the Avid's open source codec DNxHD (VC3). For example:

http://ffmpeg.org/doxygen/trunk/libavcodec_2dnxhddec_8c-source.html

It is possible to decode and encode these files with ffmpeg and ffmbc. Since this codec is becoming more popular, has there been any thought given to adding it to ffdshow? At present, other than buying a commercial 3rd party DirectShow filter, the only way that I know of accessing DNxHD files is via Quicktime.

My LAV Video Decoder supports decoding DNxHD already.

[jabloomf1230]

My LAV Video Decoder supports decoding DNxHD already.

Thanks. It worked, but I experienced some strange peripheral behavior. If installed the x64 version of LAV under Win 7 x64, it worked fine with GraphEdit x64. But if I installed just the x86 version of LAV, when I went to open the DirectShow branch in GraphEdit x86 to insert ANY filter into the graph, GraphEdit would crash. If I uninstalled just the LAV video codecs, the crash stopped. I must have a conflict with another codec, somewhere I guess. I wouldn't worry about it, since I searched around about LAV and I didn't see an issue like that. The same for your issues list.

[nevcairiel]

That's a bug in graph edit, it crashes when any filter registers more then 100 types. I suggest using an alternative like graphstudio

[jabloomf1230]

Hah! You're right. Adding your codecs put me over the limit. Thanks.

[haruhiko_yamagata]

It's a stack overflow. Use editbin.exe to change the stack size of graphedt.exe to 4MB.

[haruhiko_yamagata]

This is from the company doing our Java to DirectShow bridge. I hope this answers your question.

SPS/PPS is both in the OutputPin's media type pbFormat field and
inserted into the stream before keyframes. You should see the first on the mediatype when ffdshow connects and the second in Receive. The stream itself will be startcode not size prefixed.
VICADS PCAP Replayer suddenly began to work. Sorry, I probably missed something when I tried before.
SPS is size prefixed in MPEG2VIDEOINFO::dwSequenceHeader. ffdshow is OK with it.
The stream use startcode "00 00 01". Because your AM_MEDIA_TYPE::subtype is MEDIASUBTYPE_AVC1, it is wrong. Please read this (http://msdn.microsoft.com/en-us/library/windows/desktop/dd757808%28v=vs.85%29.aspx) and fix it.
But just fixing it doesn't seem to fix the problem. I'll dig deeper.

[haruhiko_yamagata]

@kc7bfi,
Please use MEDIASUBTYPE_H264.
Is it possible to insert Access unit delimiter? Current ffdshow requires it before every access unit if you use start code. Please remember to add it before the first SPS/PPS.
Alternative is to pretend to be mp4 source/splitter filter. You can use MEDIASUBTYPE_AVC1 and send whole access unit at a time with size prefixed.
Otherwise ffdshow has to implement full access unit parsing. It is in the long term TODO. I know what to do, but it's just too hard. You can't expect too much.

EDIT
Also please add access unit delimiter at the end of the stream.

[roytam1]

It's a stack overflow. Use editbin.exe to change the stack size of graphedt.exe to 4MB.

Confirmed. For my system, I use 1MB stack size is enough.

[cihub]

Can anyoune explain what exactly "alignment" at Placement tab does?
Also, at the moment scaling of VobSubs (BluRay & DVD tab) is aligned to the top left corner, i.e. scaling makes them grow to the bottom right corner. Is that ok? Shouldn't they scale around image center?

[haruhiko_yamagata]

Can anyoune explain what exactly "alignment" at Placement tab does?
To write reply correctly, I have to read the source code. I'm afraid I can't afford time for that.

Also, at the moment scaling of VobSubs (BluRay & DVD tab) is aligned to the top left corner, i.e. scaling makes them grow to the bottom right corner. Is that ok? Shouldn't they scale around image center?
VobSub support in ffdshow is quite incomplete. Please do not expect too much.

[DMD]

Good day.

I want to report a compatibility problem using the latest release (rev4323_20120213_clsid) with HD files.

The problem is that MPCHC crashes, with the H.264/AVC codec disabled (without ffdsshow everything is ok)
By performing regression testing version that works without this problem is the rev4206_20111227_clsid.

Always with the relase rev4323_20120213_clsid enabling the libavcodec audio codec = H.264/AVC vine often broken.

this is the medianfo of the file
Generale
Unique ID : 223122554487135209948533311599677810400 (0xA7DBD744ED58CBEEB8F3F7B5635426E0)
Complete name : E:\17- Filmati_Demo_HD\Formato mkv\Demo Video AVC - Audio dts HRA 2047Kbps 8ch.mkv
Format : Matroska
Format version : Version 2
File size : 197 Mb
Duration : 1min 0s
Overall bit rate mode : Variabile
Overall bit rate : 27,4 Mbps
Encoded date : UTC 2011-02-08 21:01:36
Writing application : mkvmerge v4.5.0 ('Speed of Light') built on Feb 1 2011 02:10:32
Writing library : libebml v1.2.0 + libmatroska v1.1.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Si
Format settings, ReFrames : 4 fotogrammi
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 1min 0s
Bit rate mode : Variabile
Bit rate : 24,8 Mbps
Maximum bit rate : 31,5 Mbps
Width : 1 920 pixel
Height : 1 088 pixel
Original height : 1 080 pixel
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate : 23,976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressivo
Bits/(Pixel*Frame) : 0.495
Stream size : 178 Mb (91%)
Default : Si
Forced : No
colour_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 : DTS
Format/Info : Digital Theater Systems
Format profile : HRA / Core
Muxing mode : Header stripping
Codec ID : A_DTS
Duration : 1min 0s
Bit rate mode : Costante
Bit rate : 2 047 Kbps / 1 510 Kbps
Channel(s) : 8 canali / 6 canali
Channel positions : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48,0 KHz
Bit depth : 24 bits
Stream size : 14,7 Mb (7%)
Title : dts 7.1
Language : Italiano
Default : Si
Forced : Si



THANKS

[Atak_Snajpera]

upload sample

[DMD]

This is the file test MKV HD (AVC - 8ch 2047Kbps Audio dts HRA)
http://www.mediafire.com/?3dyji3xei3xyy19

In FFDshow Raw video=all supported

Thank you for your interest.

[haruhiko_yamagata]

Works for me with or without ffdshow's H.264 decoder. Works with or without ffdshow raw video decoder.
What are the upper stream and down stream filters?
Is ffdshow's DXVA decoder enabled?

[DMD]

These are the filters MPCHC
http://img545.imageshack.us/img545/1286/settingb.png (http://imageshack.us/photo/my-images/545/settingb.png/)

These are the codecs in ffdshow
http://img80.imageshack.us/img80/2968/screenshot007ni.png (http://imageshack.us/photo/my-images/80/screenshot007ni.png/)

[haruhiko_yamagata]

Still cannot reproduce. Is it the video filters? Does it still crash if you disable deinterlacing, resize and sharpen?

[DMD]

The problem exists even disabling all filtering and selecting only Raw video=all supported, otherwise ffdshow is not entered.

However, what you see in the screenshot is not profile related to HD file.
the profile is this.

http://img684.imageshack.us/img684/6585/screenshot001yb.png (http://imageshack.us/photo/my-images/684/screenshot001yb.png/)

[haruhiko_yamagata]

The problem exists even disabling all filtering and selecting only Raw video=all supported, otherwise ffdshow is not entered.

However, what you see in the screenshot is not profile related to HD file.
the profile is this.
Would you "Export all settings" and send us the reg file?
Does it change anything if you uncheck "Automatic preset loading"?

[DMD]

She has Reason!

I tried rev4323_20120213_clsid without invoking the custom settings and everything works fine again!

There must be something wrong with the custom settin that I keep in my reg file.
And each faces that I install a new version install the reg file that will always keep my settings.
Maybe the problem is localized in the reg file, but what?

Thank you for your interest

[haruhiko_yamagata]

Thanks for the file, but last time the approval took a week or more. Please upload the file somewhere else.

[DMD]

Here's the reg file

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

[haruhiko_yamagata]

Sorry, still cannot reproduce.
I installed ffdshow_rev4323_20120213_clsid_x64.exe and imported the reg file. I run mpc-hc64 and build the graph as you posted.
I think this is exactly what you are doing. Maybe depends on hardware or device driver?
Can you reproduce the problem on another PC?

[kc7bfi]

@kc7bfi,
Please use MEDIASUBTYPE_H264.


Here is an updated JAR that uses the H264 subtype. It does make a great improvement. However, if you try this with the previous code and clip I sent, about 13 seconds into the video you see what I refer to as the "melty" video. Where there is motion buy the images do not seem to properly update. Is there still something wrong with how I am sending video to ffdshow? Thanks.

http://dl.dropbox.com/u/37804952/dsj.jar

[jmartinr]

I also had 100% crashes with versions above 4307 (4314 crashed, I couldn't find compiled versions between these two). Looking a bit further I fiddled around with the settings and after checking and unchecking NV12 and RGB24 output color spaces all is now fine and dandy.

Maybe a problem with the retained configuration settings between versions/installations?

[ryrynz]

Haruhiko,

current ffdshow has bug in interaction with avisynth that results in often crashes on stop of MT scripts. It does not affect playback itself.


Is this something that can be looked into? I often get crashes loading the next file if the previous file hasn't played a sufficient amount before it starts to read the next one.

[DMD]

Sorry, still cannot reproduce.
I installed ffdshow_rev4323_20120213_clsid_x64.exe and imported the reg file. I run mpc-hc64 and build the graph as you posted.
I think this is exactly what you are doing. Maybe depends on hardware or device driver?
Can you reproduce the problem on another PC?
The problem is strange.
I performed the test on 2 computers with different hardware
uninstalling and reinstalling ffdshow, without importing the settings from reg file

Achieving the same result.

codec H.264/AVC = libavcodec, works regularly
codec H.264/AVC = disabled, MPCHC crashes
To resolve I had to disable MPCHC, H264/AVC (DXVA) and H264/AVC (ffmpeg)

Then, using W7, the codec by default which is inserted in the chain directshow is Microsoft DVT-DVD Video Decoder

http://img706.imageshack.us/img706/7093/screenshot001ls.png (http://imageshack.us/photo/my-images/706/screenshot001ls.png/)

[haruhiko_yamagata]

To resolve I had to disable MPCHC, H264/AVC (DXVA) and H264/AVC (ffmpeg)
Then, it's a bug of MPC-HC.

In file MPCVideoDecFilter.cpp in MPC-HC,
// We crash inside this function
// In swscale.c: Function 'simpleCopy'
// Line: 1961 - Buffer Overrun
// This might be ffmpeg fault or more likely mpchc is not reinitializing ffmpeg correctly during display change (moving mpchc window from display A to display B)
sws_scale(m_pSwsContext, m_pFrame->data, srcStride, 0, m_pAVCtx->height, dst, dstStride);
It's crashing in the code above. It seems to be a known issue.
Some versions of ffdshow are lucky and some are not. It's not a bug of ffdshow.:rolleyes:

[haruhiko_yamagata]

Here is an updated JAR that uses the H264 subtype. It does make a great improvement. However, if you try this with the previous code and clip I sent, about 13 seconds into the video you see what I refer to as the "melty" video. Where there is motion buy the images do not seem to properly update. Is there still something wrong with how I am sending video to ffdshow? Thanks.

http://dl.dropbox.com/u/37804952/dsj.jar
Thanks for the update. I can reproduce the "melt". I'll report you back if I find something.

[haruhiko_yamagata]

I also had 100% crashes with versions above 4307 (4314 crashed, I couldn't find compiled versions between these two). Looking a bit further I fiddled around with the settings and after checking and unchecking NV12 and RGB24 output color spaces all is now fine and dandy.

Maybe a problem with the retained configuration settings between versions/installations?
If the problem is not the same as DMD's, please provide all necessary information and files to reproduce.

[haruhiko_yamagata]

Haruhiko,
Is this something that can be looked into? I often get crashes loading the next file if the previous file hasn't played a sufficient amount before it starts to read the next one.
I'm not sure if I can fix it.
Would you post a bug report on SourceForge bug tracker so that we can remember it?

[Midzuki]

Yet another regression (or something):

r4326, decoder = VC-1, problem =

pixel-aspect-ratio ignored when renderer = EVR (under Windows XP)

[jmartinr]

If the problem is not the same as DMD's, please provide all necessary information and files to reproduce.

I can't reproduce anymore, sorry.

[Dstruct]

Yet another regression (or something):

r4326, decoder = VC-1, problem =

pixel-aspect-ratio ignored when renderer = EVR (under Windows XP)

Might be related to my bug report: http://forum.doom9.org/showthread.php?p=1545917#post1545917

This file gives incorrect display aspect ratio (1:1 Pixel) in WMP11 and MPC-HC via ffdshow rev4170 DXVA:

General
Format : AVI
Format/Info : Audio Video Interleave
File size : 1.29 GiB
Duration : 1h 59mn
Overall bit rate : 1 551 Kbps
Writing library : VirtualDub build 32839/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : H264
Duration : 1h 59mn
Bit rate : 1 346 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.130
Stream size : 1.12 GiB (87%)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1h 59mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 164 MiB (12%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.60 video frame)
Interleave, preload duration : 504 ms


Proper display aspect ratio in Media Player Classic HC 1.5.3.3899 via internal MPC DVXA decoder!

[DMD]

Then, it's a bug of MPC-HC.

In file MPCVideoDecFilter.cpp in MPC-HC,
// We crash inside this function
// In swscale.c: Function 'simpleCopy'
// Line: 1961 - Buffer Overrun
// This might be ffmpeg fault or more likely mpchc is not reinitializing ffmpeg correctly during display change (moving mpchc window from display A to display B)
sws_scale(m_pSwsContext, m_pFrame->data, srcStride, 0, m_pAVCtx->height, dst, dstStride);
It's crashing in the code above. It seems to be a known issue.
Some versions of ffdshow are lucky and some are not. It's not a bug of ffdshow.:rolleyes:
Sometimes it is hard to find the cause of the problem depends on whether the player or ffdshow.

However, I repeat that with regression testing up to version rev4206_20111227,
all works regularly and there is no problem, then from this release onwards, the problems begin.
So I do not think that the whole responsibility be attributed to MPCHC.

greetings

[haruhiko_yamagata]

Sometimes it is hard to find the cause of the problem depends on whether the player or ffdshow.
That's why I compiled MPC-HC x64 and ascertain the cause.

However, I repeat that with regression testing up to version rev4206_20111227,
all works regularly and there is no problem, then from this release onwards, the problems begin.
So I do not think that the whole responsibility be attributed to MPCHC.

greetings
I still think it's 100% MPC-HC.

[haruhiko_yamagata]

@DMD,
In the code above, dstStride[0] is 1934. It should be 1920, because BITMAPINFOHEADER::biWidth in ffdshow's input media type is 1920. This is definitely a bug of MPC-HC.

[DMD]

Thank you for your inquiry on the issue,
at this point to point out also the question in the thread of MPCHC

THANKS

[haruhiko_yamagata]

Here is an updated JAR that uses the H264 subtype.
...
I have added some debug print. Here's the log.
frame_num increases one-by-one until it reaches 8. This is OK.
There's four slices for frame 8. Is this intended?
Next frame is frame 6. Is this correct?
I don't know how redundant pictures are managed. It may be correct and libavcodec just cannot decode such stream...
[5860] nal_unit_type 9 // AU delimitter
[5860] nal_unit_type 7 // SPS
[5860] nal_unit_type 8 // PPS
[5860] no frame! // no problem
[5860] nal_unit_type 9
[5860] nal_unit_type 6 // SEI
[5860] nal_unit_type 6
[5860] nal_unit_type 5 // IDR slice
[5860] frame_num 0
[5860] nal_unit_type 9
[5860] nal_unit_type 1 // slice of none IDR picture
[5860] frame_num 1
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 2
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 3
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 4
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 5
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 6
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 7
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 6 // problematic?
[5860] Frame num gap 6 4
[5860] Increasing reorder buffer to 5

[kc7bfi]

frame_num increases one-by-one until it reaches 8. This is OK.
There's four slices for frame 8. Is this intended?
Next frame is frame 6. Is this correct?
I don't know how redundant pictures are managed. It may be correct and libavcodec just cannot decode such stream...
[/code]

Interesting. I would guess that the last frame 6 might also be a duplicate?! I'm a bit ignorant at this but is there a limit to the frame number (is it limited at 8)? It is multicast video so they might be out of order but not sure why they would be duplicated. I'll check into it further. Thanks, David

[haruhiko_yamagata]

Interesting. I would guess that the last frame 6 might also be a duplicate?! I'm a bit ignorant at this but is there a limit to the frame number (is it limited at 8)? It is multicast video so they might be out of order but not sure why they would be duplicated. I'll check into it further. Thanks, David
According to the spec,
because redundant_pic_cnt_present_flag in your PPS is zero, any duplicated slices should not exist.
Because log2_max_frame_num_minus4 in your SPS is 0, allowed frame_num is 0 to 15. This is handled correctly. No problem.

[kc7bfi]

According to the spec,
because redundant_pic_cnt_present_flag in your PPS is zero, any duplicated slices should not exist.
Because log2_max_frame_num_minus4 in your SPS is 0, allowed frame_num is 0 to 15. This is handled correctly. No problem.

Looks like the problem may be related to our PCAP replayer. I tried a live feed and it played fine but the PCAP Playback had problems. David

[andybkma]

Hi, where can I get the latest tryout builds? This page here (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/) seems to have stopped providing the newest builds as the latest is from over 7 days ago....

[Midzuki]

2 andybkma:

r4332 @ http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

[andybkma]

2 andybkma:

r4332 @ http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

Thanks for the link. But am curious, the link you provided me with shows revision 4332 as a xhmikosr build yet here ( http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log ) it shows 4332 as a clisd2 build. Can you please explain why that is and what's the difference? Thanks much :)

[nevcairiel]

The revision (4332) is just the version from the SVN, who made the change and who builds it is unrelated.

[LigH]

Well, different people who build the software from the same source revision might use different compilers, enable or disable different compiling options, maybe include or exclude different libraries ... theoretically. In this case, there is probably very little difference.

[haruhiko_yamagata]

Yet another regression (or something):

r4326, decoder = VC-1, problem =

pixel-aspect-ratio ignored when renderer = EVR (under Windows XP)Would you send us a sample?

[Midzuki]

Would you send us a sample?

Nope :p

( just kidding :) )

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

[haruhiko_yamagata]

Nope :p

( just kidding :) )

http://forum.doom9.org/showthread.php?t=162221
The latest version works. clsid, did you fix it?:D

[haruhiko_yamagata]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.

Everyone please review this changelog for omissions and mistakes:
Let's go.

[Midzuki]

The latest version works. clsid, did you fix it?:D

What is your latest version? r4335 ???

FYI, r4332 is still b0rked, VC-1~wise -.-

Please upload and share your "latest" builds, then. :rolleyes:

[haruhiko_yamagata]

What is your latest version? r4335 ???

FYI, r4332 is still b0rked, VC-1~wise -.-

Please upload and share your "latest" builds, then. :rolleyes:
libavcodec works. I think you use "wmv9".

[betaking]

What is your latest version? r4335 ???

FYI, r4332 is still b0rked, VC-1~wise -.-

Please upload and share your "latest" builds, then. :rolleyes:

download my build at here
http://www.mediafire.com/?tao9vzs8ah5qodp

[Midzuki]

libavcodec works. I think you use "wmv9".

Please define what you mean by "it works".
The samples on my Skydrive folder are NOT resized to 960x540 by ffdshow when MPC-HC uses EVR.

[Midzuki]

download my build at here
http://www.mediafire.com/?tao9vzs8ah5qodp

:goodpost: AND :thanks: :thanks: :thanks:

@ Yamagata:

with r4335, wmv9 is okay, but libavcodec is still broken.

P.S.: Take a look at the source-code of LAV Video,
I'm sure nevcairiel won't mind :) :p :D

P.P.S.: With Solveig's Matroska Splitter, ffdshow sets the wrong aspect ratio through BOTH libavcodec and the DMO decoder :confused:

[Midzuki]

Hmmm, apparently it's a matter of *output color space* :rolleyes:

The DMO decoder works correctly with YV12.

The libav VC-1 decoder works correctly with NV12 and YUY2.

Hope this helps :helpful:

[haruhiko_yamagata]

Midzuki,
For which file, what is the correct AR?
zz-mcr-nsqr.mkv 16:9
zz-mcr-sqr.mkv 4:3
zz-ms-first.mkv 16:9
zz-ms-sekond.mkv 16:9
Is this correct?

[Midzuki]

Midzuki,
For which file, what is the correct AR?
zz-mcr-nsqr.mkv 16:9
zz-mcr-sqr.mkv 4:3
zz-ms-first.mkv 16:9
zz-ms-sekond.mkv 16:9
Is this correct?

Yes, yess, yesss, and yessss. :)

[haruhiko_yamagata]

libavcodec wrapper was somewhat buggy, I have fixed at rev 4336.
After that, zz-ms-sekond.mkv is 4:3. It's the same as LAV decoder.

The DMO wrapper depends on the container SAR. All (Haali, MPC, LAV) works fine for me. I don't know Solveig's.

[betaking]

To Midzuk download last build 4336 at here
http://www.mediafire.com/?s2x2nf9he71fs1c
PS:thanks haruhiko_yamagata fix it!

[Midzuki]

libavcodec wrapper was somewhat buggy, I have fixed at rev 4336.

Does that mean the *EVR++color~space* "feature" :rolleyes: :) has been fixed? :confused:

The DMO wrapper depends on the container SAR.

I wasn't aware of that, :thanks: for the important info.

All (Haali, MPC, LAV) works fine for me. I don't know Solveig's.

http://forum.doom9.org/showthread.php?t=154055&page=14

[Midzuki]

To Midzuki download last build 4336 at here
http://www.mediafire.com/?s2x2nf9he71fs1c
PS:thanks haruhiko_yamagata fix it!

Many big THANKS :thanks: again.

[Midzuki]

Does that mean the *EVR++color~space* "feature" :rolleyes: :) has been fixed? :confused:

Seemingly improbable. :rolleyes:

[haruhiko_yamagata]

Hmmm, apparently it's a matter of *output color space* :rolleyes:

Seemingly improbable. I can't reproduce.
EDIT
Check the settings of MPC-HC in vies->video frame. Make sure the video renderer is not broken.
Can you reproduce the problem on another PC?

[Midzuki]

EDIT
Check the settings of MPC-HC in vies->video frame.

No, thanks. :)

Make sure the video renderer is not broken.

How would I do that ??? :confused:

P.S.: Also, why both MPCVideoDec.ax and LAV Video apparently have no issues with EVR under Windows XP ?????

[haruhiko_yamagata]

Then please tell me the fully detailed way to reproduce. Please try it on another PC so that you can explain what is needed to reproduce.

[Midzuki]

WTF --- just for seeing "what happens" :rolleyes: ,

I un-ticked the checkbox
Set interlaced flag in output media type
and voilà, finally the libavcodec's VC-1 decoder stopped trolling :p

[haruhiko_yamagata]

I un-ticked the checkbox
Set interlaced flag in output media type
and voilà, finally the libavcodec's VC-1 decoder stopped trolling :p
Then it's a bug in your video driver. My nvidia 7900GS works fine. Thanks for the report anyway.

Please report the bug to the maker of your video driver. It would help many people.

[haruhiko_yamagata]

Here's a build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4345_20120228_branch.exe) from the parser branch. It uses AVCodecParser and parses access units for H.264 and MPEG-1 and 2.
It was easier than I expected. I think the branch can be merged before next release.
Some broken frames at the start of MPEG-2 playback has gone away.

Additionally it can decode H.264 stream erroneously flagged MPEG-2　(just a harmless prank). libavcodec must be used for MPEG-2 for the trick to work.

[Midzuki]

Then it's a bug in your video driver. My nvidia 7900GS works fine. Thanks for the report anyway.

Again, many :thanks: for the constant attention. :)

Please report the bug to the maker of your video driver. It would help many people.

Unnecessary. I'm pretty sure they will say to me,

"Go buy an up-to-date computer and an up-to-date video card!"

And this time they will be right =^.^=

[nevcairiel]

How can it be a video driver bug if the problem only occurs with ffdshow, and not with other decoders? :confused:
LAV Video will also set interlaced flags in the output type, yet AR still works.

[haruhiko_yamagata]

How can it be a video driver bug if the problem only occurs with ffdshow, and not with other decoders? :confused:
LAV Video will also set interlaced flags in the output type, yet AR still works.
ffdshow also works here. Is ffdshow failing for you?
I don't know if Midzuki has tested the same output color space with LAV.

[Midzuki]

...
I don't know if Midzuki has tested the same output color space with LAV.

Midzuki :uglylol:s http://forum.videohelp.com/attachments/2671-1279232225/uglylol.gif himself. :p :D

Yes you are right,
if I set LAV Video to "Force Deinterlacing" and limit the output color space to "YV12",

then LAV Video behaves as badly as ffdshow :scared:

Time for a major hardware upgrade definitely, no one will want to write new drivers for obsolete video cards :o

[Dstruct]

To Midzuk download last build 4336 at here
http://www.mediafire.com/?s2x2nf9he71fs1c
PS:thanks haruhiko_yamagata fix it!

Why is xvidcore.dll missing in this build?

[Dstruct]

Build 4336:

rightclick a ffdshow dll in Windows Explorer and look for the Copyright:


Example:

ff_unrar.dll says "Copyright ?Alexander Roshal 1993-2012"

while original unrar.dll says "Copyright © Alexander Roshal 1993-2012"


You see, the © character is just displayed as question mark on ffdshow DLLs.


FIXED (4354)

[betaking]

Why is xvidcore.dll missing in this build?

compile xvidcore.dll is optional, and compile default ffdshow build is not compile xvidcore.dll!:rolleyes:
Example:

ff_unrar.dll says "Copyright ?Alexander Roshal 1993-2012"

while original unrar.dll says "Copyright © Alexander Roshal 1993-2012"
i use windows7 english and set regional and language options to chinses rpc! so if not set regional and language options to chinses rpc! I would like to not have this problem!

[Midzuki]

Why is xvidcore.dll missing in this build?

SFAIK, ffdshow doesn't include an xvidcore.dll since *many* moons ago.

Besides, even if I place an xvidcore.dll into ffdshow's folder or into %system32%, ffdshow will keep saying:

xvidcore.dll not found

[obieobieobie]

SFAIK, ffdshow doesn't include an xvidcore.dll since *many* moons ago.

Besides, even if I place an xvidcore.dll into ffdshow's folder or into %system32%, ffdshow will keep saying:

xvidcore.dll not found

64 bit OS? Put xvidcore.dll into syswow64 instead, maybe.

[andybkma]

Just curious to know if there are any plans to have Nvidia hardware acceleration CUVID work with ffdshow? Reason being I use avisynth plugin script "Limited Sharpen Faster" to greatly enhance lower bitrate files I watch on my projector along with using madVR as my renderer. LAV Filters while having CUVID doesn't have avisynth plugin capability as far as I know so what to do? How is it possible to use hardware decoding for AVC/H264 material but still have the ability to use avisynth script and madVR? Cheers for any advice....

[the_weirdo]

Besides, even if I place an xvidcore.dll into ffdshow's folder or into %system32%, ffdshow will keep saying:

xvidcore.dll not found

Try this xvidcore.dll (http://www.mediafire.com/download.php?m18m1jda7wajj1j) (32-bit).

[nevcairiel]

Just curious to know if there are any plans to have Nvidia hardware acceleration CUVID work with ffdshow? Reason being I use avisynth plugin script "Limited Sharpen Faster" to greatly enhance lower bitrate files I watch on my projector along with using madVR as my renderer. LAV Filters while having CUVID doesn't have avisynth plugin capability as far as I know so what to do? How is it possible to use hardware decoding for AVC/H264 material but still have the ability to use avisynth script and madVR? Cheers for any advice....

Just use LAV for decoding and ffdshow as a post-processor.

[andybkma]

Just use LAV for decoding and ffdshow as a post-processor.

Did some testing with that configuration you suggested (LAV CUVID plus ffdshow raw video filter) but the result equals about the same CPU usage as using ffdshow as a software decoder alone (along with avisynth) which is much much higher obviously than using just the LAV CUVID hardware decoder by itself. Plus had many dropped and delayed frames on some files. The goal is to lower my CPU usage with a hardware decoder plus post process with avisynth. Darn, really wish ffdshow could incorporate CUVID or LAV Filters could incorporate a way to use avisynth scripts. Perhaps then I could get hardware acceleration and avisynth script to play nice together...

[haruhiko_yamagata]

You see, the © character is just displayed as question mark on ffdshow DLLs.
Fixed at rev 4348. :thanks:

[ipanema]

A side issue, but I noticed that the decoder still does not output the leading B frames which other decoders manage to do. It's a bug report from 2009

http://sourceforge.net/tracker/index...41&atid=867360


Fixed at rev 4325. Thanks.

Sorry for the delay in replying. I just checked version 4342 using a couple of AVCHD MTS files chosen at random, and it seems to be the same as before. The leading B frames are output if streaming starts at the start of the file, but if streaming starts at an I frame further into the file, the leading B frames are not output. I checked again with Mainconcept and Elecard H.264 decoders and they always output the leading B frames.

[betaking]

rev.4348 compile failed
http://oi44.tinypic.com/14tq3k3.jpg

[clsid]

@haruhiko
There are some sync issues after your recent changes. Sometimes after seeking audio is a bit out of sync. Happens with H.264 in MKV. Caused by one of these revisions: 4325/4326/4329.

Edit: can you also look into porting this MPC change:
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=4110

[betaking]

last svn setup.exe compile failed
http://i42.tinypic.com/karz8l.png
:(

[haruhiko_yamagata]

Sorry for the compilation errors.
clsid, thank you for the fix.

[haruhiko_yamagata]

@haruhiko
There are some sync issues after your recent changes. Sometimes after seeking audio is a bit out of sync. Happens with H.264 in MKV. Caused by one of these revisions: 4325/4326/4329.
I'm not sure if I'm reproducing the issue, but hopefully fixed at rev 4354.
EDIT: seems not to be fixed...
EDIT2: fixed at rev 4355

Edit: can you also look into porting this MPC change:
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=4110
Someday after the next release, please wait.

[haruhiko_yamagata]

if streaming starts at an I frame further into the file, the leading B frames are not output.
If it is an IDR picture, it is possible to decode B pictures before the IDR.
But if it is I frame, it is impossible to use the B pictures before the I frame. H.264 does not allow seeking to I frames. ffdshow permits it as a workaround for some broken streams.
I don't know which your case is.

[Dstruct]

Fixed at rev 4348. :thanks:

Thanks! Fine now.


Rev4354:

-> delete the xvidcore.dll from ffdshow folder
-> go to Codecs and you'll see that "Xvid" is still listed as available decoder


Expected: "Xvid" not listed as decoder if xvidcore.dll isn't found!

[Alanz]

So basically i've been waiting for about 5 days so i can finally post this question about this problem i'm having (to see whether this is a bug or not)

First of all here's my setup:

1. Using LAV Filters (for splitter only)
2. Using FFdshow to decode video and audio
3. Using MadVR (i doubt this has anything to do with it)
4. Using MPC HC SVN

Here's the problem:

When i'm using ffdshow version above 3984 (i still have it on my hdd) and using Libavcodec to decode AC3 or DTS, and then see the volume level using the volume section of ffdshow (sometimes i do this to increase the Voice level). I saw that Back Left (BL) and Back Right (BR) channel are being delivered as Side Left and Side Right

Here's the screenshot tested using (from lowest to highest) and also reset all ffdshow setting to default to see whether the problem is caused by my old ffdshow configuration:
- ffdshow_rev4194_20111223_clsid
- ffdshow_rev4257_20120115_clsid
- ffdshow_rev4291_20120131_clsid
- ffdshow_rev4323_20120213_clsid
- ffdshow_rev4326_20120216_xvidvideo-ru_x86-MSVC2010
- ffdshow_rev4332_20120220_xvidvideo-ru_x86-MSVC2010
- ffdshow_rev4360_20120301_xvidvideo-ru_x86-MSVC2010

Using Libavcodec to decode AC3 and DTS

http://i.imgur.com/gpJqX.png

Using Lib A52 to Decode AC3 and LibDTS to decode DTS

http://i.imgur.com/xPjsx.png

Once again there's no problem when using Libavcodec on FFDshow R3984 ( ffdshow_rev3984_20110922_clsid ) to decode both AC3 or DTS. It delivers the correct channel (BL to BL and BR to BR) not to SL and SR

Thanks for your answer :)

[clsid]

^ Fixed ^

[Dstruct]

Thanks! Fine now.


Rev4354:

-> delete the xvidcore.dll from ffdshow folder
-> go to Codecs and you'll see that "Xvid" is still listed as available decoder


Expected: "Xvid" not listed as decoder if xvidcore.dll isn't found!


"Xvid" still listed in Decoder column caused by xvidcore.dll found in Windows\System32 folder. Comes with Xvid 1.3.2 (Koepi's build).


I think that's a bit confusing.


Suggestions:

1. Don't search for xvidcore.dll in System32 folder (%PATH% folders) at all.

OR

2. List the DLL as found in "Version Details"

[Dstruct]

Rev4362:

-> open Video Configuration
-> set MPEG2 format to "libavcodec" decoder
-> OK
-> delete the libmpeg2_ff.dll DLL from ffdshow folder

-> open Video Configuration again


Result: "MPEG2" format decoder set to "Disabled".

Expected: "MPEG2" format decoder still set to "libavcodec"!

[haruhiko_yamagata]

Rev4362:

-> open Video Configuration
-> set MPEG2 format to "libavcodec" decoder
-> OK
-> delete the libmpeg2_ff.dll DLL from ffdshow folder

-> open Video Configuration again


Result: "MPEG2" format decoder set to "Disabled".

Expected: "MPEG2" format decoder still set to "libavcodec"!
I cannot reproduce. If I set MPEG2 to either libavcodec or libmpeg2 and delete libmpeg2_ff.dll, it is set to libavcodec for me.

[haruhiko_yamagata]

1. Don't search for xvidcore.dll in System32 folder (%PATH% folders) at all.

This should be done, after the next release. That kind of change requires a lot of testing. It should not be done before the next release.

[Alanz]

^ Fixed ^

Thanks for the fix :)

[Dstruct]

I cannot reproduce. If I set MPEG2 to either libavcodec or libmpeg2 and delete libmpeg2_ff.dll, it is set to libavcodec for me.

Not here. Here it's set to "disabled" if I delete libmpeg2_ff.dll. No chance to save it with "libavcodec". Always reverts back to "disabled" (rev4365). I'm on WinXP SP3 if this matters.

[ryrynz]

Revision 4368 - revert the changes in the IntelQuickSyncDecoder project

How come?

[khagaroth]

Updated Czech translation (http://www.mediafire.com/?ic7a5ixqix2xvd9).

@haruhiko_yamagata: thanks for marking l10n changes in the SVN log.

[egur]

haruhiko & clsid,
Some (all?) of the image processing features are single threaded, hurting performance.
A simple solution would be to use OpenMP to parallelize loops. The issue with OpenMP is that it requires linking with the DLL version of the CRT instead of libc as done today (due to a bug in OpenMP or libc). OpenMP will crash on DLL unload if it was linked with the static CRT library.
Linking with the DLL version means that ffdshow will only work if the VC2010 redistributables are installed.

Can I make the change?

Another issue is the use of the csimd family of inline functions. They wrap intrinsic functions and work extremely slow in debug builds. Using the intrinsic functions directly will remove the overhead and allow easier debug. These functions are widely used in post processing and mpeg2lib. I think these wrappers should go or at least be replaced with macros if possible (some are overloaded).

[clsid]

Any improvement is very much welcome. But please use PPL instead of OpenMP, to avoid additional dependencies.

[egur]

Any improvement is very much welcome. But please use PPL instead of OpenMP, to avoid additional dependencies.

Sure, PPL it is.

[HeReSY]

Hi,

I posted on the sf forum, but than i remembered that i had to postet here.

So my question is: is it possible to start the installer with dxva support enabled by default? If yes which parameter do i have to use.

Thanks in advance

HeReSY

[v0lt]

DD 5.1, DTS 5.1
liba52 and libdts send the sound to the rear speakers.
libavcodec sends the sound to the side speakers.
Who is right?

(I checked in the ffdshow audio decoder->Volume)

[Dstruct]

I cannot reproduce. If I set MPEG2 to either libavcodec or libmpeg2 and delete libmpeg2_ff.dll, it is set to libavcodec for me.

Same on different machine (WinXP SP3). Deleting libmpeg2_ff.dll causes MPEG2 decoder setting to "disabled".


Maybe on your machine you have another libmpeg2_ff.dll under System32 folder or so? Does the dropdown menu really only lists "libavcodec" and "disabled" on your machine if you delete libmpeg2_ff.dll?

[haruhiko_yamagata]

Updated Czech translation (http://www.mediafire.com/?ic7a5ixqix2xvd9).

Committed as rev 4370. Thank you.

[haruhiko_yamagata]

Another issue is the use of the csimd family of inline functions. They wrap intrinsic functions and work extremely slow in debug builds. Using the intrinsic functions directly will remove the overhead and allow easier debug. These functions are widely used in post processing and mpeg2lib. I think these wrappers should go or at least be replaced with macros if possible (some are overloaded).
They are convenient to create MMX and SSE2 functions from one template function. It will be more useful with the advent of AVX2.
What should we use as an alternative?

[haruhiko_yamagata]

Some (all?) of the image processing features are single threaded, hurting performance.
A simple solution would be to use OpenMP to parallelize loops. The issue with OpenMP is that it requires linking with the DLL version of the CRT instead of libc as done today (due to a bug in OpenMP or libc). OpenMP will crash on DLL unload if it was linked with the static CRT library.
Linking with the DLL version means that ffdshow will only work if the VC2010 redistributables are installed.

Can I make the change?

Your help is very much welcome.
Resize (part of libswscale) and Yadif are written in C and both are multi-threaded.
RGB conversion is written in C++ and use boost::threadpool. It is multi-threaded.

Not too many image filters are good candidate for mulch-threading by ppl or threadpool. Among them, sharpen filter is a good place to begin.

[haruhiko_yamagata]

@egur,
Since rev 4364, I'm having debug assertion error on exit of ffdshow. I think the error occurs just because ffdshow.ax is loaded. I disabled instantiation of DirectShow filters of ffdshow, still the error occurs. I rolled back to rev 4363 where the error disappears and updated TvideoCodecQuickSync.h and TvideoCodecQuickSync.cpp to rev 4364, then the error is reproduced.

http://ffdshow-tryout.sourceforge.net/doom9/debugAssertion.png

[haruhiko_yamagata]

@egur,
Please test this patch and if it is OK, please commit.
Index: src/codecs/TvideoCodecQuickSync.cpp
===================================================================
--- src/codecs/TvideoCodecQuickSync.cpp (revision 4370)
+++ src/codecs/TvideoCodecQuickSync.cpp (working copy)
@@ -49,8 +49,6 @@
return ((TvideoCodecQuickSync*)obj)->DeliverSurface(frameData);
}

-static CMemAllocator g_FakeAllocator("", NULL, NULL);
-
TvideoCodecQuickSync::TvideoCodecQuickSync(IffdshowBase *Ideci,IdecVideoSink *IsinkD, int codecID) :
Tcodec(Ideci),
TcodecDec(Ideci,IsinkD),
@@ -60,7 +58,8 @@
destroyQuickSync(NULL),
m_QuickSync(NULL),
m_Dll(NULL),
- m_MediaSample(_l("Fake Media Sample"), &g_FakeAllocator, NULL, NULL, 0)
+ m_FakeAllocator("", NULL, NULL),
+ m_MediaSample(_l("Fake Media Sample"), &m_FakeAllocator, NULL, NULL, 0)
{
ok = false;
m_Dll = new Tdll(dllname,config);
Index: src/codecs/TvideoCodecQuickSync.h
===================================================================
--- src/codecs/TvideoCodecQuickSync.h (revision 4370)
+++ src/codecs/TvideoCodecQuickSync.h (working copy)
@@ -39,6 +39,7 @@
CCritSec m_csLock;
Tdll* m_Dll;
IQuickSyncDecoder* m_QuickSync;
+ CMemAllocator m_FakeAllocator;
CMediaSample m_MediaSample;
};



Otherwise, global class initialization is done through CFactoryTemplate. You can find examples in TffDecoder_reg.cpp.

[pururin]

May I ask some questions regarding ffdshow audio (processor) :o

- Does "Swap channels" filter doing any digital processing to the sound? Or is it just remapping channels
(like just swap the speakers wire without touching the actual signals)?
As I try enabling and disabling bit depth options in the "allowed sample formats for sound processing" (in 'processing' tab)
but, unlike most others filters, found no impact on the final output.


- When up-convert audio bit depth in ffdshow, like 16->24 bit or 16->32 bit integer
it's just adding zero bits, which is a lossless operation, do I understand correctly?

Also I heard that 16-bit and 24-bit Integer can be stored in float without losing any data, hence int → float conversion is lossless too?

-When down-converting audio bit depth(like select only 16 bit int for the output format while source or processed audio is higher)
ffdshow use dithering, rounding or just truncating?


Thanks you very much.

[egur]

@egur,
Please test this patch and if it is OK, please commit.
...
Otherwise, global class initialization is done through CFactoryTemplate. You can find examples in TffDecoder_reg.cpp.

It didn't assert in my code that's why I committed, are you sure the patch solves the issue?
I'll test it today and commit along with a small enhancement.

[haruhiko_yamagata]

It didn't assert in my code that's why I committed, are you sure the patch solves the issue?
I'll test it today and commit along with a small enhancement.
Well, of course you are using debug build. It's MSVC.
The assert does not always pop up, but it's 50% or more.
Yes, it solve the issue. If it works, please commit it.

[egur]

Well, of course you are using debug build. It's MSVC.
The assert does not always pop up, but it's 50% or more.
Yes, it solve the issue. If it works, please commit it.

Fixed @r4371

[oddball]

Anyone know how the hell I get 'On sampling frequency match' to work? I want anything under 48000Hz to use a different profile.

[wanezhiling]

http://forum.doom9.org/showthread.php?p=1564276#post1564276
:)

[innocenat]

I cannot make ffdshow connect to P010/P210 RAW input. Is this a bug, or this feature is not implemented yet? Even if I set into to exclusive P010, the ffdshow raw video filter still not connect to LAV Filter set to P010 only.

[dansrfe]

Bug report:

I've been having problems with ffdshow mpeg2 dvd decoding since the March builds started coming out. I'm using the latest madVR, MPC-HC and LAV Filters. I'm using dslibdvdnav 0.2.4 as a replacement for MS DVD Navigator. Please look into this as it's preventing me from updating to the latest ffdshow builds. Thanks.

http://sourceforge.net/projects/dslibdvdnav/files/

[agustin9]

Bug report:

I've been having problems with ffdshow mpeg2 dvd decoding since the March builds started coming out. I'm using the latest madVR, MPC-HC and LAV Filters. I'm using dslibdvdnav 0.2.4 as a replacement for MS DVD Navigator. Please look into this as it's preventing me from updating to the latest ffdshow builds. Thanks.

http://sourceforge.net/projects/dslibdvdnav/files/
I'm having problem too, using libavcodec, with libmpeg2 seems fine

[haruhiko_yamagata]

Bug report:

I've been having problems with ffdshow mpeg2 dvd decoding since the March builds started coming out. I'm using the latest madVR, MPC-HC and LAV Filters. I'm using dslibdvdnav 0.2.4 as a replacement for MS DVD Navigator. Please look into this as it's preventing me from updating to the latest ffdshow builds. Thanks.

http://sourceforge.net/projects/dslibdvdnav/files/
The freeze issue has been fixed at rev 4375. Thanks.
For me (on Win7 x64), if madVR is used, the playback doesn't start because of "Macrovision Fail" though.

[ryrynz]

Haruhiko, the following file only diplays the first subtitle and then doesn't update, it plays fine with MPC internal subtitle renderer and VSfilter.

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

[haruhiko_yamagata]

Haruhiko, the following file only diplays the first subtitle and then doesn't update, it plays fine with MPC internal subtitle renderer and VSfilter.

http://www.mediafire.com/?5t0rcoc08jxqr0a
As repeated many times, vobsub support is very incomplete. I'm not motivated to improve it now. Even considering the removal.

[ryrynz]

No worries, hadn't seen you mention it. Cheers.

[ipanema]

If it is an IDR picture, it is possible to decode B pictures before the IDR.
But if it is I frame, it is impossible to use the B pictures before the I frame. H.264 does not allow seeking to I frames. ffdshow permits it as a workaround for some broken streams.
I don't know which your case is.

I've taken a closer look at this, and although Mainconcept and other H.264 decoders do output the leading B frames there is always a small amount of blocky corruption in them (except for the B frames at the start of the file). I'm guessing that it is not possible to reliably construct these B frames but these decoders always have a good try, except ffdshow which decides not to output them at all - which is fine.

I unpacked several AVCHD mts files and they all seem to begin with an IDR picture at the start of the file. All other frames in the file are non-IDR pictures. But you can reliably seek throughout the file.

Incidentally I noticed that Mainconcept and Elecard decoders always identify primary_pic_type of 0 as an "I" frame. But the ffdshow decoder identifies it as a "P" frame the same as a primary_pic_type of 1. Is there a reason for this?

[haruhiko_yamagata]

I've taken a closer look at this, and although Mainconcept and other H.264 decoders do output the leading B frames there is always a small amount of blocky corruption in them (except for the B frames at the start of the file). I'm guessing that it is not possible to reliably construct these B frames but these decoders always have a good try, except ffdshow which decides not to output them at all - which is fine.

I unpacked several AVCHD mts files and they all seem to begin with an IDR picture at the start of the file. All other frames in the file are non-IDR pictures. But you can reliably seek throughout the file.
Usually IDR pictures are found every 2 to 3 seconds. Some streams have very few IDR pictures. IDR pictures are not always necessary for seeking. In that case, recovery point SEI message is used to define entry point. The SEI message explicitly defines which frame to start showing.
Some broken streams (including streams that are cut too short) has neither IDR nor recovery point SEI. That's why ffdshow (and most decoders) allow to seek to I pictures. The problem is I pictures are often found before more appropriate entry points.

Incidentally I noticed that Mainconcept and Elecard decoders always identify primary_pic_type of 0 as an "I" frame. But the ffdshow decoder identifies it as a "P" frame the same as a primary_pic_type of 1. Is there a reason for this?
primary_pic_type is not used to determine I or P. slice_type is used instead.

[betaking]

To:CLSID
http://forum.doom9.org/showthread.php?p=1564475#post1564475
LAST MPC-HC fix this issue! but ffdshow not! can you fix it?

[Nya_Su]

Hello,

I think I may have found a bug... so here are the answers to the bug reporting's questions:

1).operating system (OS)
> Windows 7 SP1 (64 bits)

2).ffdshow version, rev, compiler, ansi or unicode
> ffdshow_rev4375_20120311_xhmikosr

3).ffdshow settings and used filters, ex:queue, resize, sharpening, noise, levels...
> ffdshow raw video filter with
Deband (Threshold 1.2, Radius 16)
OSD (Remaining time)

4).media player used and settings ex: mpc, media player2, wmplayer...
> MPC-HC_r4138_x86 from xhmikosr's site. Settings are from this guide: http://wp.me/PrgSo-b1. The only difference is that I don't use JanWillem32's fork of MPC-HC.

5).output colorspaces "YUY2", "YV12", "RGB32", "RGB24"...
> YV12

6).internal/external splitters ex: Haali Media Splitter, Gabest's Splitters...
> As suggested from this guide: http://wp.me/PrgSo-b1

7).video renderers ex:Haali renderer, Overlay Mixer, VMR9, VMR7, EVR...
> madVR 0.82.4

8).video/audio samples <10MB
> http://www.mediafire.com/?pzpw6iv91oom7us

9).what you were trying to accomplish, the problem you encountered...anything else that could be useful in reproducing that bug.
> When I try to play a video with 688×512 resolution (yes, a “broken 4:3"), MPC crashes (idem with PotPlayer). The only way to play it is to block ffdshow raw video filter.

From what I tryed, it looks like it crashes with whatever codec and container are being used (see test files).

Note: it's the same with 528x384 videos (yes, also a "broken 4:3").

[haruhiko_yamagata]

@Nya_Su,
Thanks for your detailed report. The crashes confirmed. I'll take a look.

[haruhiko_yamagata]

@Nya_Su,
I have fixed NV12 to YV12 conversion for test 1 in my working copy. I'll commit to SVN soon.
Test 2 invokes RGB24 to planar YCbCr 4:4:4. I have fixed the crash, but I need to check if the color is correct. Please wait.

[ryrynz]

Haruhiko, have you ever considered a version with has the audio and video decoders removed?

[haruhiko_yamagata]

@Nya_Su,
fixed at rev 4382. Thanks.

[haruhiko_yamagata]

Haruhiko, have you ever considered a version with has the audio and video decoders removed?
Nope.
You can disable a filter from its dialog, DirectShow control -> Multiple ffdshow instances: "none disabled".
I think it is possible to register filters separately by some code change, although I have no plan. You might ask clsid for an opinion.

[Nya_Su]

@Nya_Su,
fixed at rev 4382. Thanks.

Thanks a lot!

[VipZ]

Nope.
You can disable a filter from its dialog, DirectShow control -> Multiple ffdshow instances: "none disabled".
I think it is possible to register filters separately by some code change, although I have no plan. You might ask clsid for an opinion.

If you interested I have made a patch previously to do just that, I just replicated the option code for DXVA to all the other filters. Just like DXVA code, if the registry value isn't set its as if there is no change.

Patch, http://www.mediafire.com/file/5i0rhls7cxh8fsi/dllregpatch.patch

The above isn't tested to latest SVN, last time I used this was against 3985.

[kasper93]

Could you look at this sample http://dl.dropbox.com/u/16282309/LAV/AR.2.ts at beginning AR is 4:3 and than AR is 16:9. It crash whole player on aspect ratio change point with ffdshow video decoder. Works fine with Microsoft DTV-DVD Video Decoder.

[haruhiko_yamagata]

Could you look at this sample http://dl.dropbox.com/u/16282309/LAV/AR.2.ts at beginning AR is 4:3 and than AR is 16:9. It crash whole player on aspect ratio change point with ffdshow video decoder. Works fine with Microsoft DTV-DVD Video Decoder.
Crash confirmed. I'll take a look.

[haruhiko_yamagata]

Could you look at this sample http://dl.dropbox.com/u/16282309/LAV/AR.2.ts at beginning AR is 4:3 and than AR is 16:9. It crash whole player on aspect ratio change point with ffdshow video decoder. Works fine with Microsoft DTV-DVD Video Decoder.
The crash has been fixed at rev 4389. But sorry, it just avoid crashing.
Libav says, "Width/height/bit depth/chroma idc changing with threads is not implemented. Update your Libav version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented."
So if you set "Number of decoding threads:" 1, everything is fine.

[haruhiko_yamagata]

To fix the linker warnings saying that the TargetPath doesn't match with OutputFile, I have written a patch (http://ffdshow-tryout.sourceforge.net/doom9/Target_path.patch).
The warning goes away but more files appear in bin directory.
Is this OK? More files may be a bit annoying...

[FlashGordon]

I think I've found some odd behavior using ffdshow build 4332. Using libmpeg2 as decoder and opening a specific PAL DVD with mpc-hc, there are certain specific parts where the decoder seems to drop frames. For me, the "glitch" is 100% reproducible under the same conditions, it is always the same times that drop these frames. Here's the odd part: opening just the VOB and playing these parts with libmpeg2 doesn't produce the 'glitch'. Opening the full DVD but using libavcodec for mpeg2 will also play fine. The filter chain when this happens includes the MS DVD navigator (all the others seem to not affect it).

Wish I could get a working sample, but like I said, the individual VOB plays fine with libmpeg2, this only happens when the MS DVD navigator is in use.

Is there any reason why libmpeg2 would be glitching at these parts and libavcodec plays them fine?

[haruhiko_yamagata]

Is there any reason why libmpeg2 would be glitching at these parts and libavcodec plays them fine?
I don't know.
I think libavcodec is better as MPEG-2 decoder. For example, color space conversion matrix is decoded by libavcodec. libavcodec is faster on current CPU. etc...
Currently libmpeg2 is not maintained. In my opinion, there is no point in maintaining libmpeg2. Recently Intel Quick Sync decoder has been added. Three is too many choice for users.
If no objection, I would remove it.

[FlashGordon]

I see. Would the IDCT options under "decoder options" affect this? libmpeg2 doesn't use these settings, right? So I'm thinking maybe the DVD company transferred the film badly and libavcodec somehow deals with these glitches better...

Right now I have IDCT on 'auto', workaround encoder bugs on 'autodetect', error recognition on 'careful' and error concealment on 'guess MVS + deblock'. Are these recommended settings?

[haruhiko_yamagata]

I see. Would the IDCT options under "decoder options" affect this? libmpeg2 doesn't use these settings, right? libmpeg2 does not use the settings.

Right now I have IDCT on 'auto', workaround encoder bugs on 'autodetect', error recognition on 'careful' and error concealment on 'guess MVS + deblock'. Are these recommended settings?The default settings for Error recognition is "very aggressive". I have not tried various options for that though.

[haruhiko_yamagata]

Because current GPU prefer NV12 to YV12, I have written a patch to prefer NV12 as an output color space.
It doesn't affect image filters except the output filter.
Index: src/imgFilters/ffImgfmt.cpp
===================================================================
--- src/imgFilters/ffImgfmt.cpp (revision 4388)
+++ src/imgFilters/ffImgfmt.cpp (working copy)
@@ -420,6 +420,13 @@
*rank = 200;
return outPrimaryCSP|(inCSP&~FF_CSPS_MASK);
}
+
+ // prefer YV12 to NV12 conversion for the final output. Currently rank is set only for the final output.
+ if (rank && (inCSP & FF_CSPS_MASK) == FF_CSP_420P && (wantedCSPS & FF_CSP_NV12)) {
+ *rank = 101;
+ return FF_CSP_NV12|(inCSP&~FF_CSPS_MASK);
+ }
+
uint64_t outCSP=inCSP&wantedCSPS&FF_CSPS_MASK;
if (outCSP) {
if (rank) {
@@ -1182,8 +1189,8 @@
FF_CSP_P216 ,
FF_CSP_444P10,
FF_CSP_Y416 ,
+ FF_CSP_NV12 ,
FF_CSP_420P ,
- FF_CSP_NV12 ,
FF_CSP_YUY2 ,
FF_CSP_UYVY ,
FF_CSP_YVYU ,

[FlashGordon]

The default settings for Error recognition is "very aggressive". I have not tried various options for that though.

Is there a reason why that is the default? According to the wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:decoder_options), it states that valid parts may be detected as errors... would this decrease image quality?

[haruhiko_yamagata]

Is there a reason why that is the default?
Looks like a bug.

[CruNcher]

I don't know.
I think libavcodec is better as MPEG-2 decoder. For example, color space conversion matrix is decoded by libavcodec. libavcodec is faster on current CPU. etc...
Currently libmpeg2 is not maintained. In my opinion, there is no point in maintaining libmpeg2. Recently Intel Quick Sync decoder has been added. Three is too many choice for users.
If no objection, I would remove it.

What ?

in my experience Libmpeg2 is still one of the fastest Single threaded Software decoder (and it can keep very low latency @ the same time), and especially Gabest Decoder used in MPC-HC shows this to it's full potential on Windows especially if you pressure it to the extreme and combine iqualitycontrol with it :)

and im on Sandy Bridge see https://forum.doom9.org/showpost.php?p=1565630&postcount=9946

Lav Videos used avcodec has no chance it stucks and halts so heavily and due to the multithreading it's latency seems severely higher, and without multithreading i couldn't reach the speeds of libmpeg2 in singlethreaded performance

[clsid]

Because current GPU prefer NV12 to YV12, I have written a patch to prefer NV12 as an output color space.
It doesn't affect image filters except the output filter.Preferring NV12 output is fine with me.

[clsid]

To fix the linker warnings saying that the TargetPath doesn't match with OutputFile, I have written a patch (http://ffdshow-tryout.sourceforge.net/doom9/Target_path.patch).
The warning goes away but more files appear in bin directory.
Is this OK? More files may be a bit annoying...
I rather have a warning than a mess of files.

[haruhiko_yamagata]

What ?

in my experience Libmpeg2 is still one of the fastest Single threaded Software decoder (and it can keep very low latency @ the same time), and especially Gabest Decoder used in MPC-HC shows this to it's full potential on Windows especially if you pressure it to the extreme and combine iqualitycontrol with it :)

and im on Sandy Bridge see https://forum.doom9.org/showpost.php?p=1565630&postcount=9946

Lav Videos used avcodec has no chance it stucks and halts so heavily and due to the multithreading it's latency seems severely higher, and without multithreading i couldn't reach the speeds of libmpeg2 in singlethreaded performance
Who has single core CPU? I don't think ffdshow should work on Atom. Single threaded performance has no meaning to me.
The latency is higher with frame based multithreading. But what's the inconvenience with it?
The point is that the maintenance is hard. I want to drop it unless the merit is big enough.

// EDIT
As for the dropped frames, I doubt that the performance is relevant. More likely, timestamps are wrong. If frames are dropped using ffdshow, please send me the sample.
IQualityControl: How is it used? It wouldn't be necessary for MPEG-2 at least on Sandy Bridge.

[CruNcher]

I cant do this test with ffdshow because i cant activate SPP to pressure 1 core completely this is just ffdshow used as PP after the decoding and displaying the latency stats of the PP (OSD,SPP overhead distributed to 1 virtual core (25%), while decoding on the same). Also if you say you not interested in Single threading then you should boost some of the PP stuff to Multi threading.

[haruhiko_yamagata]

I cant do this test with ffdshow because i cant activate SPP to pressure 1 core completely this is just ffdshow used as PP after the decoding and displaying the latency stats of the PP (OSD,SPP overhead distributed to 1 virtual core (25%), while decoding on the same). Also if you say you not interested in Single threading then you should boost some of the PP stuff to Multi threading.
Multitheading of PP may be a good feature if I have time to implement.
In my opinion, just single thread performance is not worth for maintenance effort. ffdshow has too many features to maintain. Please understand it is important to drop old stuffs.

[haruhiko_yamagata]

I rather have a warning than a mess of files.
No problem.:)

[haruhiko_yamagata]

@clsid,
Rev 4390 fixes the dialog, but current libavcodec is more complicated.
/**
* Error recognition; may misdetect some more or less valid parts as errors.
* - encoding: unused
* - decoding: Set by user.
*/
int err_recognition;
#define AV_EF_CRCCHECK (1<<0)
#define AV_EF_BITSTREAM (1<<1)
#define AV_EF_BUFFER (1<<2)
#define AV_EF_EXPLODE (1<<3)

#define AV_EF_CAREFUL (1<<16)
#define AV_EF_COMPLIANT (1<<17)
#define AV_EF_AGGRESSIVE (1<<18)
This cannot be implemented as a combo box. We need six check boxes (not seven, because AV_EF_CAREFUL is not used). But even if we implement six check boxes, who can use them correctly?
AV_EF_CRCCHECK seems to do CRC check for AC3, TTA and wavpack. I don't know what other stuffs do.
I would suggest two options:

Remove the option completely
One check box to enable all error recognition (disabled by default)

[haruhiko_yamagata]

Index: src/settings/filters/TdeinterlaceSettings.h
===================================================================
--- src/settings/filters/TdeinterlaceSettings.h (revision 4390)
+++ src/settings/filters/TdeinterlaceSettings.h (working copy)
@@ -32,7 +32,7 @@
int deinterlaceAlways;
int swapfields;
int cfgId;
- static const int cfgIdDef=2;
+ static const int cfgIdDef=14; // yadif
static const TmethodProps &getMethod(int cfgId);
int tomsmocompSE,tomsmocompVF;
char_t dscalerFlnm[MAX_PATH];

Do you agree?

[fastplayer]

I would suggest two options:

Remove the option completely
One check box to enable all error recognition (disabled by default)

I can't speak for clsid, but please remove it from the GUI and leave it at ffmpeg's/libav's default setting. It is a usability catastrophe.

[haruhiko_yamagata]

I can't speak for clsid, but please remove it from the GUI and leave it at ffmpeg's/libav's default setting. It is a usability catastrophe.
Yes, basically it shouldn't be exposed to users. I don't know what the default is.
Here's copy from "avplay -h".
-err_detect <flags> set error detection flags
crccheck verify embedded CRCs
bitstream detect bitstream specification deviations
buffer detect improper bitstream length
explode abort decoding on minor error detection

So perhaps explode shouldn't be the default.
CRC check is ideal but eats CPU time.
bitstream and buffer are optional :confused:

[nevcairiel]

Just don't touch the value at all when creating the context, and it'll remain whatever is the default.

[clsid]

I am fine with removing obscure options. Less is better. Both error recognition and concealment could be removed. Perhaps also the greyscale option.

[Midzuki]

@ haruhiko:

Could you please confirm (or infirm, why not) the problem described in the post

http://forum.doom9.org/showthread.php?p=1565971#post1565971 ?

...
Besides:

In VirtualDub ++ the latest QuickTime plugin,

ffdshow (r4382) w/ wmv9 decoder shows only a sequence of black frames :confused:

ffdshow w/ libavcodec, && "easy" vc-1,
first frame = green

ffdshow w/ libavcodec, && "difficult" vc-1,
VirtualDub crashes

[haruhiko_yamagata]

@ haruhiko:

Could you please confirm (or infirm, why not) the problem described in the post

http://forum.doom9.org/showthread.php?p=1565971#post1565971 ?
VC1 isn't supposed to be handled in VFW, is it? I won't fix anything about VC1 in VitualDub.
What is VirtualDub ++?

I would appreciate it, if you write more kind and easy to read report. It is hard to understand for which file, what you do, what you experience and how your computer is set up.

[haruhiko_yamagata]

I am fine with removing obscure options. Less is better. Both error recognition and concealment could be removed. Perhaps also the greyscale option.
Simply removed at rev 4396.

[Midzuki]

VC1 isn't supposed to be handled in VFW, is it?

According to the VfW applet of ffdshow,
the answer is *YES*, sir.

It is hard to understand for which file, what you do, what you experience and how your computer is set up.

I don't think so.

[LigH]

LigH offers two cups of Earl Grey to calm down the nerves on both sides...

[haruhiko_yamagata]

Thanks, LigH.
According to the VfW applet of ffdshow,
the answer is *YES*, sir.

VC1 as well as H.264 are listed there. But sorry, we do not guarantee that they work. They may or may not work.
If you stuff VC1 or H.264 into AVI container forcibly, it may or may not work. VFW dialog is similar stuff.

[FlashGordon]

So perhaps explode shouldn't be the default.
CRC check is ideal but eats CPU time.
bitstream and buffer are optional :confused:

http://web.archiveorange.com/archive/v/4q4Bhg28didl1agye0kh according to that, maybe AV_EF_CAREFUL is meant only for CRC checks?

[Midzuki]

^
^ Okay, let's just hope:

1) fccHandler wants to improve his QT-input plugin ;

2) an "inertial patch" :rolleyes: by means of an updated Libav will eventually happen ;

[ !-- end of discussion -- ]

[haruhiko_yamagata]

http://web.archiveorange.com/archive/v/4q4Bhg28didl1agye0kh according to that, maybe AV_EF_CAREFUL is meant only for CRC checks?
Thanks for the link. Yes, but the topic applies to FFmpeg.
Libav does not use AV_EF_CAREFUL at all. Most part of ffdshow's libavcodec is based on Libav.
Rev 4396 does not change the behavior related to CRC checking because the commit does not affect audio part.

[ryrynz]

Haruhiko, I can reproduce another Rundll32 error. Simply rename any default preset and press enter, DO NOT click apply, then press ALT + F4.

I can reproduce the crash. Thanks.

Did you want me to file a bug report for this? I know it's minor but it's still there.

[haruhiko_yamagata]

Did you want me to file a bug report for this? I know it's minor but it's still there.
Yes. I tried to fix, but it wasn't so easy.

[CruNcher]

https://forum.doom9.org/showpost.php?p=1566483&postcount=19119

im still trying to get a higher resolution of the problem @ work here but it seems just that ffdshow gets prefetched causes this problem it doesn't need to be inside the graph @ all just getting called (on graph buildup once) seems to cause this Black Screen (the question is why). This made me almost crazy i really wondered why i always got a black screen i thought it was the splitters fault but now it shows to be ffdshow :) and very clearly

i will try to make a clearer chain and a video showing this strange issue :)

so if anyone in MPC-HC gets a mysterious black screen (especially with DXVA involved in the rendering chain) and doesn't know why (playback continues but video rendering stays black then try to block ffdshow (even if you don't have uncompressed rendering active) it might be the answer)

PS: Another test disabled all decoder in ffdshow still black screen if it's in the preferred status on the external filter list, no matter above or bellow the main decoder (Cyberlink) for the current active stream (preferred) :(, reseted MPC-HC and the whole custom chain doing more tests.

Yep same 2 filter in the external list setting ffdshow to preferred causes the black screen

[haruhiko_yamagata]

https://forum.doom9.org/showpost.php?p=1566483&postcount=19119

Where should I start reading in the thread?

[wanezhiling]

http://forum.doom9.org/showthread.php?p=1566513#post1566513
Same is ffdshow DXVA.

[clsid]

@all
Build 4399 will be available in a moment. Consider it as a release candidate for the pending release.

[Atak_Snajpera]

Clsid let's wait for nice 4400 :)

[ryrynz]

Haruhiko, will vobsub support be dropped before release, considering the state it's in?

[CruNcher]

Where should I start reading in the thread?

Its more here https://forum.doom9.org/showthread.php?p=1551696#post1551696

i looked 1 step deeper into this issue and it slowly becomes clearer what happens ;)

Video of the issue = http://www.mediafire.com/?4sqg9u447hy6env

[LigH]

Rev. 4396:
Remove three Libavcodec options.
Gray scale
Error recognition
Error concealment

Because noone was able to explain them (http://forum.doom9.org/showthread.php?t=156693), anyway?

[haruhiko_yamagata]

Haruhiko, will vobsub support be dropped before release, considering the state it's in?
I think this is a sensible suggestion, but the timing is too late.
Removing is not very easy. After removing, we have to test for a while. And then we'll get another bug report...
Once we decided to release rev 4399, we'll release it unless a regression is reported. Otherwise we can't release forever.
Vobsub will be removed (or replaced with the one from guliverkli/MPC-HC) after next release, when I have time.

[haruhiko_yamagata]

Clsid let's wait for nice 4400 :)
Some updated translations are welcome.:)

[haruhiko_yamagata]

Its more here https://forum.doom9.org/showthread.php?p=1551696#post1551696

i looked 1 step deeper into this issue and it slowly becomes clearer what happens ;)

Video of the issue = http://www.mediafire.com/?4sqg9u447hy6env
Thanks. I'll get a new machine. After that, I'll try to reproduce the problem.

[haruhiko_yamagata]

Because noone was able to explain them (http://forum.doom9.org/showthread.php?t=156693), anyway?
So to speak. :D

[clsid]

Eric needs to fix a few things in his QS code. Hopefully that will be done next week, so that we can release next weekend.

[mandarinka]

Some updated translations are welcome.:)

Why 4400 when you can have 4444 :cool:

[wanezhiling]

http://forum.doom9.org/showpost.php?p=1567003&postcount=10099
PS: MPC-HC DXVA and ffdshow DXVA failed on deinterlacing.

[Joniii]

Is there some unfixed VC-1 bug in ffdshow? I havent been able to use VC-1 DXVA for a long time, dunno when it broke. Player crashes or is unable to play video when trying to play MKV/TS/M2TS files with VC-1, crash happens at both WMP and WMC. Normal VC-1 works, just DXVA crashes.

[clsid]

VC-1 DXVA works fine here.

[egur]

clsid and haruhiko,
I've committed a patch to fix the WMC+FSE+QS failure.
Unfortunately it's not 100% what I want :(
I now check within the proxy class for the executable name (for WMC's exe name) and allow SW emulation to work. This is the only change within ffdshow.

This is the only way I can pass the media type checks without having the D3D9 device manager at construction/init time in FSE.
Actual HW init comes later on, during the first call to decode.

The only downfall for this approach is that Intel's SW decoder will operate for clips that the HW doesn't support and only within WMC.
Here're the media types:
h264,mpg2,vc1,wmv9: h>1080 or w>1920
wmv9: all resolutions on current drivers. New drivers (some already leaked) support HW wmv9.

IvyBridge will play everything in HW.

Note that some profiles are not supported in HW at all (>8 bit, 4:2:2, 4:4:4). These will fail the media type check and fallback to ffdshow's SW decoders.

Fallback code exist in two places:
TvideoCodec @101 - QS fails media type checks (e.g. profile is 10 bit)
TffdshowVideoInputPin.cpp @444 - QS is under WMC's thumbnail creator - no way to create HW device.

Please review the defaults I used and change them to your liking.

[ryrynz]

Moving ffmpeg.dll out of the directory does not show version 'not found' in version details, though removal does cause an issue even with only using ffdshow raw.
No a big deal if it's a required component, just wondering why I would require it for ffdshow raw? I'm not using any of the decoders.

[pururin]

Is the audio department still developing? Like sample format conversions, Hi-q sound processing , dithering, noise shaping etc.

[haruhiko_yamagata]

Please review the defaults I used and change them to your liking.
Thank you for your work. You did your best, how can I do better than you?
Let's release rev 4407.

[haruhiko_yamagata]

Moving ffmpeg.dll out of the directory does not show version 'not found' in version details, though removal does cause an issue even with only using ffdshow raw.
No a big deal if it's a required component, just wondering why I would require it for ffdshow raw? I'm not using any of the decoders.ffmpeg.dll consists of libavcodec, libswscale, libpostproc, libavfilter and libavutil. Resize, yadif, postprocessing and some minor color space conversion depends on ffmpeg.dll. It is required anyway.
ffdshow won't try to work without it, although some feature of the raw filter may work.

[haruhiko_yamagata]

Is the audio department still developing? Like sample format conversions, Hi-q sound processing , dithering, noise shaping etc.
Audio decoders are maintained by clsid.
As for audio filters, we need a new developer.

[egur]

Thank you for your work. You did your best, how can I do better than you?
Let's release rev 4407.

I used libavcodec as the fallback for H264. libmpeg2 for mpeg2 and libwmv9 for vc1/wmv3. As far as I know this is the most stable SW setup.

[haruhiko_yamagata]

libmpeg2 for mpeg2
libmpeg2 is going to be removed. It's much slower than libavcodec on multicore CPUs. As for stability, libmpeg2 was better in the past. But now, libavcodec and its wrapper has been improved a lot. Do you know any issue regarding libavcodec MPEG-2?

And please don't worry about the fall back. I'll change it to libavcodec.

[Midzuki]

...
Do you know any issue regarding libavcodec MPEG-2?
...

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

also,

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

[nevcairiel]

Those issues are related to subtitles, not the mpeg decoder.

[Midzuki]

Those issues are related to subtitles, not the mpeg decoder.

Yes, but they appear ONLY WHEN the MPEG-2 decoder is used for DVD-playback, so yes, someone should peruse the source-code of DScaler 5 :p

[Midzuki]

UPDATE:

FWIW,

MPlayer Sherpya-SVN-r34401-4.6.2 does not have that problem anymore :cool: :cool: :cool:

However I'd like to know why the :devil: it replaces the original yellow text-images with white ones :rolleyes:

[haruhiko_yamagata]

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

also,

http://sourceforge.net/tracker/?func=detail&aid=3066506&group_id=173941&atid=867360I think libavcodec or libmpeg2 is not relevant. They will be discussed in each tracker.

[Midzuki]

I think libavcodec or libmpeg2 is not relevant. They will be discussed in each tracker.

Unfortunately, the Sourceforge user nsm-x1 lost his password, therefore...

Originally posted by h_yamagata http://forum.doom9.org/images/buttons/lastpost.gif (http://sourceforge.net/tracker/?func=detail&aid=3066506&group_id=173941&atid=867360)

I think the pin connects because it is asked to.
It is possible to add an option to reject the connection, but if it
rejects, DVD playback may fail.
I don't want to expose such an option to users.
I think the creation of the graph is the responsibility of the DVD
application.

Well, *perhaps* these posts will change your point-of-view... ;)

http://forum.doom9.org/showthread.php?p=1417904#post1417904

http://forum.doom9.org/showthread.php?p=1447384#post1447384

[CruNcher]

Midzuki this behaviour looks familiar to me it looks like this http://forum.doom9.org/showpost.php?p=1566633&postcount=14905 :)
it fails connection to the Video Renderer due to ffdshow intercepting even if it is told todo nothing, though it only happens when preferring it in MPC-HC in a automatic chain it doesn't happen (ffdshow not forced).

[Midzuki]

Midzuki this behaviour looks familiar to me it looks like this http://forum.doom9.org/showpost.php?p=1566633&postcount=14905 :)
it fails connection to the Video Renderer due to ffdshow intercepting even if it is told todo nothing, though it only happens when preferring it in MPC-HC in a automatic chain it doesn't happen (ffdshow not forced).

:thanks: for the insight. FWIW, and IIRC:

method 1) real merit of the video processor = 00200000, MPC-HC setting = preferred

--> this forces the use of the "Text" input pin, even when ffdshow is told to NOT handle any type of subs at all ;

method 2) real merit of the video processor >= 00800000, MPC-HC setting = N/A

--> two possibilities:

a) merit of the MPEG-2 decoder < merit of ffdshow's video processor, THEN the DVD-subpictures are sent to this latter :(

b) merit of the MPEG-2 decoder > merit of ffdshow's video processor, THEN this latter is not used at all :confused:

Apparently ffdshow sees no difference between uncompressed video and subtitles :rolleyes:

[haruhiko_yamagata]

even if it is told todo nothing
You can't tell ffdshow raw filter to do nothing. If you add it to the graph, it must handle DVD menu and the subtitles. If you don't like this, you don't add it to the graph. It's the spec, at this point.
If ffdshow does not handle DVD menu and subtitles, and ffdshow apply resize, the graph won't work.
It's a bug if it connects to audio, though...

[Midzuki]

You can't tell ffdshow raw filter to do nothing. If you add it to the graph, it must handle DVD menu and the subtitles. If you don't like this, you don't add it to the graph. It's the spec, at this point.

Spec??? Please say which one :confused:

If ffdshow does not handle DVD menu and subtitles, and ffdshow apply resize, the graph won't work.

IMHO that's a serious design flaw. If I UN-tick all checkboxes in the audio processor, yes it remains in the graph and (apparently at least) *does nothing*. So,

¿ why the "logic" of the so-called raw video filter has to be different ?

:confused: :confused: :confused: :confused: :confused:

++++++++++++++++

P.S.: If I build a graph manually in Graphstudio, the raw video filter CAN change the "picture properties" WITHOUT messing with the DVD-subpictures --- and yes, it will "do nothing" if I un-tick all of its checkboxes......

[haruhiko_yamagata]

Do you mean it still connects if you set "Raw video" to disable? Then it's a bug.

P.S.: If I build a graph manually in Graphstudio, the raw video filter CAN change the "picture properties" WITHOUT messing with the DVD-subpictures --- and yes, it will "do nothing" if I un-tick all of its checkboxes......
Then it's OK. The building of the graph is mainly responsibility of the application. ffdshow raw processor basically don't want to join the DVD graph without getting menu and subtitles, unless manually forced.

[TheShadowRunner]

A strange issue, "FFDShow Audio Decoder" refuses to connect to "FLACSource" filter.
FLACSource presents subtype {1541C5C0-CDDF-477D-BC0A-86F8AE7F8354} on its output pin and of course FLAC is set to Libavcodec in FFDshow Audio Dec.
Is it a bug, expected behavior?

On the other hand, when a FLAC stream is present in a MKV for exemple, it connects to FFDShow Audio Dec without problems using the same subtype {1541C5C0-CDDF-477D-BC0A-86F8AE7F8354}.

Why does FFDShow Audio Dec. refuse to connect to FLACSource specifically?

[Šabović Adis]

Hi there!
Is there any possibility to get the VC-1 stream through ffdshow, but without stuttering :)
I just don't like using the DXVA dec.


XP pro x64 SP2; Core 2 Quad Q6600 2,4 GHz; 4094 MB RAM DDR2 SDRAM; ATI Radeon HD 3450, 256 MB, ATI Catalist 12.3

Thanks in advance, Šabović Adis

[wanezhiling]

http://forum.doom9.org/showpost.php?p=1568418&postcount=19206
Same is ffdshow DXVA.

Edit: Sorry, my fault.. no problem now.

[clsid]

A new official stable build has been released. The version is 1.2.4422

Download links:
32-bit (http://sourceforge.net/projects/ffdshow-tryout/files/Official%20releases/generic%20build%20%28stable%29/ffdshow_rev4422_20120409.exe/download)
64-bit (http://sourceforge.net/projects/ffdshow-tryout/files/Official%20releases/64-bit/ffdshow_rev4422_20120409_x64.exe/download)

Changes since r3154:

Bugfixes:
* Lots of updates for libavcodec that bring bug fixes, performance enhancements, and security fixes.
* Disable "Detect soft telecine and average frame durations" if 3:2 pulldown is being applied in AviSynth filter.
* IAMStreamSelect: fix duplicated subtitle list in case of multiple ffdshow instances
* If a matroska container had hidden leading chapter and Haali's splitter was used and tray icon was right-clicked, ffdshow crashed.
* Various fixes regarding input mediatype handling, strides, and pin re-connection.
* Various fixes regarding H.264 SPS parsing
* Fixed decoding of 96khz 32bit audio with libavcodec
* Fixed decoding of AAC audio with libavcodec when extradata is missing
* Better handling of non-mod4 resolutions
* Workaround for freeze in Powerpoint 2010
* AC3 encoder was producing improper bitstream when connected to file writer filter
* Various fixes for audio bitstreaming

New and improved features:
* Support for H.264 10-bit 4:2:0/4:2:2/4:4:4/RGB
* Support for H.264 8-bit 4:2:2/4:4:4/RGB, 4:2:0 was already supported
* Support for various 10-bit and 16-bit colorspaces
* Optimized YV12 to NV12 conversion
* Enabled high quality RGB32 conversion by default
* Added option to select a preferred output colorspace
* Added Intel QuickSync decoder. This provides hardware acceleration decoding of H.264, VC-1 and MPEG-2. Requires the integrated GPU of Intel Sandy Bridge processors.
* Added DXVA video filter for hardware accelerated decoding. Supports H.264 and VC-1 video. Also includes subtitle support.
* Various additions to the application blacklist and whitelist
* Added support for Blu-ray PGS subtitles
* Removed support for USF subtitles
* Various improvements for the handling of ASS/SSA subtitles. More tags are supported now, but not yet all of them.
* Various improvements for the rendering of text-based subtitles
* By default now only subtitle files are shown that match the video filename. This behavior can be adjusted through an option on the "Try, dialog & Paths" page in ffdshow settings.
* Created new format option in ffdshow audio decoder for the QT PCM variants (such as TWOS). They were previously part if the Uncompressed audio option.
* ffmpeg-mt has been merged into libavcodec
* Multi-threaded decoding is now used by default for H.264, MPEG-1/2, FFV1, and DV video.
* Added decoding support for Indeo 4 and Indeo 5 video
* Floating point output for libavcodec AAC, AC3, E-AC3, DTS, Vorbis, and Nellymoser decoders.
* Added option to disable jitter correction for audio decoder
* Improved performance of Deband filter
* Removed some encoders for which the interface that ffdshow provided was outdated and unmaintained, such as Xvid and H.264. You should use the official codecs instead.
* Removed some encoders that were considered obsolete or unstable.

Updates:
* Updated Boost library to v1.49
* Updated zlib library to v1.2.6
* Updated minilzo library to v2.06
* Updated unrar library to v4.10
* Updated libsamplerate to v0.1.8
* Removed mp3lib
* Removed xvidcore

[ryrynz]

Great stuff. Any chance of having the release version number 1.2.4422 reflected on the download page for consistency?

[TheShadowRunner]

Thank you for this new "Official" build 4422!
I tried again the FLAC oddity as it could have been corrected (extensive changelog!).
It turns out that no, Flacsource.ax can connect to LAV Audio Dec, but FFDShow Audio Dec still doesn't accept the connection.
See you,

TSR

[Reino]

Just two, I think easy to fix, old bug-reports:
- Volume levels animation glitch on WavPack audio (http://sourceforge.net/tracker/?func=detail&aid=3458213&group_id=173941&atid=867360)
- Vorbis audio input bitrate incorrectly being reported (http://sourceforge.net/tracker/?func=detail&aid=3458218&group_id=173941&atid=867360)

I would very much appreciate it if anyone could have a look at it.


- Feature Request: Dedicated DTS-in-WAV-decoder (http://sourceforge.net/tracker/?func=detail&aid=3516107&group_id=173941&atid=867363)
Playing DTS in WAV without the need to set the Uncompressed format to "All supported" (or "16-bit integer").

[Midzuki]

Originally posted by h_yamagata

I have never encountered half-D1 DVD. Would you send us a sample?

Here it goes:
HalfD1demo.iso @ https://skydrive.live.com/?cid=5ACF098E0EBAE8D5&id=5ACF098E0EBAE8D5%21126

[Blight]

clsid:
Can I get a bulid 4429 installer?

everyone:
Anyone knows why 'xvidvideo.ru' stopped generating the latest builds automatically?

[LigH]

Because it is not done automatically, but a human has to launch the compiler. And he might be on vacation.

[Midzuki]

@ Blight:

Xhmikosr has built it already,

http://xhmikosr.1f0.de/ffdshow/

[EDIT]

xvidvideo.ru has been updated,

http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-4429-x86-x64.html

[haruhiko_yamagata]

Here it goes:
HalfD1demo.iso @ https://skydrive.live.com/?cid=5ACF098E0EBAE8D5&id=5ACF098E0EBAE8D5%21126
Thanks I've got the file. I'll take a look when I have time.

[Joniii]

There are some problems with ffdshow DXVA. external .srt subtitles wont show with VC-1 (DXVA), file mkv/vc-1/dts. It works on ffdshow_rev4224_20120105_xvidvideo-ru_x64-MSVC2010 but is broken on all builds after 4307, there weren't builds between those in xvidvideo.ru so don't know exactly when it broke. I'm using LAV splitter, ffdshow x64 DXVA and Radeon 7750.

There was also problem that I've had couple of months on latest builds. With Haali media splitter and ffdshow DXVA + subtitles I get error on player when trying to play the file (mkv/vc1/dts). With LAV splitter and ffdshow DXVA + srt subtitles all is fine. I don't know when this broke since I've moved to LAV splitter but might be related to the first bug.

These both are only with mkv files containing VC-1 video, player I used is WMP12 and Media Center.

[Blight]

Midzuki, LigH:
Thanks :)

[egur]

I've noticed that the XvidVideo.ru site is building ffmpeg with a pre-release version of GCC (according to their web site). This is usually not a good idea...

[nevcairiel]

I've noticed that the XvidVideo.ru site is building ffmpeg with a pre-release version of GCC (according to their web site). This is usually not a good idea...

They've always been doing that. Who knows why.
Just get builds here:
http://xhmikosr.1f0.de/ffdshow/

Build with latest stable GCC (4.7.0)

[egur]

They've always been doing that. Who knows why.
Just get builds here:
http://xhmikosr.1f0.de/ffdshow/

Build with latest stable GCC (4.7.0)

FYI, this site is fire walled by Intel's IT.

[Joniii]

There are some problems with ffdshow DXVA. external .srt subtitles wont show with VC-1 (DXVA), file mkv/vc-1/dts. It works on ffdshow_rev4224_20120105_xvidvideo-ru_x64-MSVC2010 but is broken on all builds after 4307, there weren't builds between those in xvidvideo.ru so don't know exactly when it broke. I'm using LAV splitter, ffdshow x64 DXVA and Radeon 7750.

There was also problem that I've had couple of months on latest builds. With Haali media splitter and ffdshow DXVA + subtitles I get error on player when trying to play the file (mkv/vc1/dts). With LAV splitter and ffdshow DXVA + srt subtitles all is fine. I don't know when this broke since I've moved to LAV splitter but might be related to the first bug.

These both are only with mkv files containing VC-1 video, player I used is WMP12 and Media Center.

To clarify, VC-1 on WMP12 refused to play and on Media Center I got "Microsoft Visual C++ Runtime Library, Runtime Error!" when started playback. If I swap to LAV splitter then these errors disappear and everything is fine except no DXVA subs on VC-1. 4229 ffdshow_rev4224_20120105_xvidvideo-ru_x64-MSVC2010 is the last working build.

[clsid]

You should try r4431 and post a sample file if it doesn't work.

[Joniii]

You should try r4431 and post a sample file if it doesn't work.

Same with r4431. This is weird as I would think others would have had the same problems too, I've had these problems for months. I thought it was something at my end and was lazy to format, then I build a new computer and still having the same problems so i'm fairly certain it's a bug. Clean W7 SP1 64-bit install, installed all updates, Catalyst 12.3, haali media splitter, ffdshow x64 and set up subtitles and DXVA for VC-1 and H.264. Used the Win7DSFilterTweaker_5_2 to disable media foundation and changed the preferred decoders to ffdshow DXVA. For playback I used 64-bit WMP12 or WMC.

Problems:
Haali splitter + ffdshow DXVA > r4224, error playing VC-1 mkv or m2ts. (WMP12 doesn't play the file, WMC gives some C++ error)
LAV splitter + ffdshow DXVA > r4224, files play fine but no subtitles on files containing VC-1.

Sample (https://skydrive.live.com/redir.aspx?cid=2260ad7bb5710cd9&resid=2260AD7BB5710CD9!126&parid=root)

[nevcairiel]

DXVA subtitles in ffdshow are a ugly hack anyway, i'm actually surprised it worked as good as it does without causing massive corruptions. You cannot paint subtitles onto a frame which is still used as a reference frame in the decoder. :p

[clsid]

r4257 is working, r4291 is not
I get no crash or errors at all with my own builds, so try the builds from sf.net.
The splitter also shouldn't matter since you are using an external subtitle file.

@Haruhiko
Could the subtitle issue perhaps be related to r4263/4268?

[haruhiko_yamagata]

r4257 is working, r4291 is not
I get no crash or errors at all with my own builds, so try the builds from sf.net.
The splitter also shouldn't matter since you are using an external subtitle file.

@Haruhiko
Could the subtitle issue perhaps be related to r4263/4268?
I'll take a look when I have time.

[Blight]

I'm getting user-reports that clsid's build 4431 breaks 10bit decoding.
Can anyone confirm?

[nevcairiel]

I'm getting user-reports that clsid's build 4431 breaks 10bit decoding.
Can anyone confirm?

It should not only break, but crash.
The issue was fixed in 4432, it was a problem from libav, which was fixed there.

[Blight]

Thanks for the info nev!

clsid:
Any chance you can create a 4432+ build?
I noticed you mentioned other (xvidvideo.ru?) build suffer from some issues.

[adam777]

4432 is available at XhmikosR's - http://xhmikosr.1f0.de/ffdshow/

[aufkrawall]

Why aren't the input levels set to Auto?
It's working fine for me. Correctly flagged streams get correctly treated.
I guess that's what LAV is doing by default and you can't even change this in the GUI.
I suggest to make Auto default. :)

It also seems that this option is broken anyway or I haven't understood what it is doing exactly.
I extracted a frame of a source with both TV and PC input levels and both frames were bit exact.
That's why I think it is broken.

But no need to fix it, IMHO it can be entirely removed and set to Auto.

[egur]

Why aren't the input levels set to Auto?
It's working fine for me. Correctly flagged streams get correctly treated.
I guess that's what LAV is doing by default and you can't even change this in the GUI.
I suggest to make Auto default. :)

It also seems that this option is broken anyway or I haven't understood what it is doing exactly.
I extracted a frame of a source with both TV and PC input levels and both frames were bit exact.
That's why I think it is broken.

But no need to fix it, IMHO it can be entirely removed and set to Auto.

For normal systems "levels" should be off. It would make sense to use in order to transcode a poorly encoded file.

[aufkrawall]

For normal systems "levels" should be off. It would make sense to use in order to transcode a poorly encoded file.
Could you explain to me what you mean?
Are we talking about the same thing? :)
http://www.ld-host.de/uploads/thumbnails/40f7ff07d0b9d8c80f9b7965b98c34e1.jpg (http://www.ld-host.de/show/40f7ff07d0b9d8c80f9b7965b98c34e1.jpg)

[betaking]

Hi,last ffdshow svn have a bug! when i Enabled mpeg2 by libavcodec!after I Re-open ffdshow Video decoder configuration mpeg2 still Disabled! is this a bug?
download screen recoder files! After seeing this I think you should understand!
http://www.mediafire.com/?w8aw6vbhi1mej44

[Midzuki]

Hi,last ffdshow svn have a bug! when i Enabled mpeg2 by libavcodec!after I Re-open ffdshow Video decoder configuration mpeg2 still Disabled! is this a bug?
download screen recoder files! After seeing this I think you should understand!
http://www.mediafire.com/?w8aw6vbhi1mej44

Strange, that problem doesn't happen over here ( r4436, XP Pro w/ SP3 )

:confused:

[haruhiko_yamagata]

Why aren't the input levels set to Auto?
It's working fine for me. Correctly flagged streams get correctly treated.

OK, let's change it.


It also seems that this option is broken anyway or I haven't understood what it is doing exactly.
I extracted a frame of a source with both TV and PC input levels and both frames were bit exact.
That's why I think it is broken.

It is used for RGB conversion. If you grab in jpeg or some YCbCr output, it doesn't affect.

[betaking]

Strange, that problem doesn't happen over here ( r4436, XP Pro w/ SP3 )

:confused:

No! XP PRO SP3 have this problem too!

[Octo-puss]

One of you is wrong :P

[haruhiko_yamagata]

If I un-install and re-install, I can reproduce.

[Midzuki]

Hmmm... anyway, that glitch is not relevant to me, I'll keep using CLvsd.ax until the DVD-subpics problem gets fixed :sly:

[aufkrawall]

It is used for RGB conversion. If you grab in jpeg or some YCbCr output, it doesn't affect.
Ok, now I got it.
I've checked with 8 bit x264 I444 videos (PC.601, Rec601, PC.709, Rec709) if it works correctly with Auto and it does so. :)

[Dstruct]

Hi,last ffdshow svn have a bug! when i Enabled mpeg2 by libavcodec!after I Re-open ffdshow Video decoder configuration mpeg2 still Disabled! is this a bug?
download screen recoder files! After seeing this I think you should understand!
http://www.mediafire.com/?w8aw6vbhi1mej44

Related bug: http://forum.doom9.org/showthread.php?p=1562572#post1562572

[aufkrawall]

What is the reason why Lagarith isn't supported, please?

[hoborg]

Hi.
ffdshow_rev4430_20120415_xvidvideo-ru_x86-msvc2010.zip is crashing on "i444compressed.mkv" sample. Is that a known issue?

EDIT:
ffdshow_rev4437_20120426_xhmikosr.exe working fine.

[Milardo]

Hi, can one still compile latest revisions of ffdshow and include the removed vfw codecs? I would like to do that if possible.

[clsid]

Not possible. Also they have been removed for good reasons. There are better VFW codecs available. Use those.

[egur]

Committed new version of QS decoder - some small fixes mostly for broken files.
No ffdshow code changes.

[Blight]

Hi,
Looking at the change list for build 4437, I see "remove vobsub support (except DVD sub)." listed.
What does this mean? Is backward compatibility with vobsub broken somehow?

[clsid]

VobSub support has always been incomplete/buggy.

[haruhiko_yamagata]

Whichever ffdshow version is, you shouldn't let ffdshow handle vobsub.

[Sebastiii]

Hi,
I just posted the this report issue but from Nevcairiel, it seems related to ffdshow :

I get a crash in ffmpeg.dll (ffdshow) when LAV Video is in graph with NV12 output checked. I get it on my HTPC Win7 32 bits with my Nvidia GTX460 and only when ffdshow video decoder was as Post Process filter with resize function enable.

I cut a little sample that show up the issue on my HTPC :
(http://dl.dropbox.com/u/10536084/lav/Sample/LesI.avi)

It surely related to ffdshow but if i use another video decoder it didn't crash.
If i keep NV12 + rezise OFF -> no crash.
If i uncheck NV12 + resize ON -> no crash
If i enable NV12 + rezise ON -> it crash

I have test on clean setting from LAV and/or ffdshow.

Thanks.

[Sebastiii]

I have build latest SVN version but i can't get call stack like it crash in ffmpeg.dll.

> ffmpeg.dll!072e7e70()
[Frames below may be incorrect and/or missing, no symbols loaded for ffmpeg.dll]
ffmpeg.dll!07273c76()
ffmpeg.dll!07274e24()
ffmpeg.dll!0727abd7()

[clsid]

I can confirm the crash.

[Sebastiii]

cool thanks :)

[the6thday]

Rev4362:

-> open Video Configuration
-> set MPEG2 format to "libavcodec" decoder
-> OK
-> delete the libmpeg2_ff.dll DLL from ffdshow folder

-> open Video Configuration again


Result: "MPEG2" format decoder set to "Disabled".

Expected: "MPEG2" format decoder still set to "libavcodec"!

I can confirm this behavior in rev. 4444.

As soon as i put any file (even an empty txt file) with name "libmpeg2_ff.dll" in the ffdshow folder its correctly set to libavcodec

[clsid]

@the6thday
I have fixed that bug

@Haruhiko
Can you have a look at this bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=3524019&group_id=173941&atid=867360
It think setting dwControlFlags may give problems with some renderers. LAV Video decoder only sets it when connected to for madVR, since that is the only one that actually uses the info. It also performs a reconnect when the value changes.

[nevcairiel]

As far as i know, at least Haalis Renderer and the Overlay Mixer have issues with the dwControlFlags values.

[vvicked]

Hi,

I'm new to the forum. I just posted a bug report about DXVA decoder crashing when fast forwarding media playing from a network share. Is the problem description adequate? Do I need to provide any additional information to help debug the issue?

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

[clsid]

Try mapping the network share to a drive letter.

[clsid]

@haruhiko
There is a small bug with soft telecine detection.
https://sourceforge.net/projects/ffdshow-tryout/forums/forum/597594/topic/5247253/index/page/1

[TheShadowRunner]

Sorry to re-post about this, but it was completely ignored:
A strange issue, "FFDShow Audio Decoder" refuses to connect to MPCHC's "FLACSource" filter.
FLACSource presents subtype {1541C5C0-CDDF-477D-BC0A-86F8AE7F8354} on its output pin and of course FLAC is set to Libavcodec in FFDshow Audio Dec.

On the other hand, when a FLAC stream is present in a MKV for exemple, it connects to FFDShow Audio Dec without problems using the same subtype {1541C5C0-CDDF-477D-BC0A-86F8AE7F8354}.

Why does FFDShow Audio Dec. refuse to connect to FLACSource specifically?
(LAV Audio Dec. connects and works perfectly fine with FLACSource btw)
Thanks for any info.

[Reino]

Confirmed. Accepts MPC Audio Decoder and LAV Audio Decoder as decoder for FLAC, but doesn't accept FFDShow Audio Decoder somehow.

[clsid]

The problem isn't connection. It fails to decode when connected to that splitter. The problem seems extradata related. It won't be fixed unless someone submits a patch.

[vvicked]

Try mapping the network share to a drive letter.

I just tried that and it did not have any effect. I actually did some more testing and the crashing occurs when the "Surface Overlay" option in DXVA is enabled. When I tested the network share media files using DXVA and "Surface Overlay" disabled, there was no crashing. If I disable surface overlay, I lose my subtitles and ffdshow OSD messages. Is there any other way to view subtitles when the ffdshow DXVA decoder is active and surface overlay is disabled?

[wanezhiling]

http://forum.doom9.org/showpost.php?p=1574375&postcount=19549
FYI :)

[RealSnoopyDog]

In the latest builds, the VC1 DXVA decoder does not show embedded subtitles anymore. H.264 DXVA does. I went back all the builds i found on my HD: in build 4257 (15.01.2012) it's still working, in (e.g.) 4436 (22.04.2012) it does not work.

[clsid]

VC1 DXVA + subs got broken somewhere between r4257 and r4291. If someone pinpoints the exact revision, then maybe it can get fixed. But otherwise don't expect a fix anytime soon. There are no developers that are actively working on ffdshow.

[RealSnoopyDog]

Hm in your builds list, i only find these two 4257 and 4291. You need it more accurate (?)

[ryrynz]

@RealSnoopyDog

http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/stranitsa-3.html

That should help you pinpoint it.