ffdshow tryouts project: Discussion & Development

[tal.aloni]

Shouldn't the last 4 be 3?

Oops, Sorry about that.

Here is an updated patch:
http://iknowu.net/files/public/ffdshow/Grab/2309-BGR24-RC2.zip

build:
http://iknowu.net/files/public/ffdshow/Grab/ffdshow_rev2309_20081105-BGR24-RC2.exe

[STaRGaZeR]

More MPEG-2 files than I have expected have wrong flags. In my opinion, the flags are not reliable "at all".
In H.264 flags are much more reliable, but still there are some files that have wrong flags (rare, ignorable).
It's just my opinion, discussion is welcome.

That's why I was suggesting an option that works "agressively", flagging everything that we're not sure it's progressive: every MPEG-2 stream without Progressive_sequence=1 (the only reliable method) would get the flags, and all PAFF/MBAFF streams in H.264 will get them too. What do you guys think? Would this be 100% reliable, even if we flag some progressive material as interlaced?

[haruhiko_yamagata]

That's why I was suggesting an option that works "agressively", flagging everything that we're not sure it's progressive: every MPEG-2 stream without Progressive_sequence=1 (the only reliable method) would get the flags,Currently, libmpeg2 in ffdshow does this except if the pictures has "repeat first field flag" + "Picture" progressive flag and it indicates telecined film.
libavcodec flags progressive if "Picture" progressive flag is set.
libmpeg2 works better for me, but as tal.aloni has pointed, my samples have been gathered from weird places.
and all PAFF/MBAFF streams in H.264 will get them too.
This is wrong. H.264 has better flags: "Picture timing SEI message", which I submitted a patch to (and now part of) FFmpeg.
What do you guys think? Would this be 100% reliable, even if we flag some progressive material as interlaced?There is no reliable method, especially for MPEG-2.

[clsid]

Haruhiko, could you update our copy of libswscale? There have been lots of changes to it in the past few months, including several bug fixes. There is some custom code in it from you, and you know about the code than the other devs.

[Snowknight26]

That's how it was at rev. 2222 too (the oldest one I have), and this is how it should work as far as I know, I think it's better this way.

Would it be possible to reimplement? I find it useful on occasion.

[haruhiko_yamagata]

Oops, Sorry about that.

Here is an updated patch:
http://iknowu.net/files/public/ffdshow/Grab/2309-BGR24-RC2.zip

build:
http://iknowu.net/files/public/ffdshow/Grab/ffdshow_rev2309_20081105-BGR24-RC2.exe

case FF_CSP_BGR24 :
safe_packed_conv(
(uint8_t*)src, src_stride, image->y, image->u, image->v,
edged_width, edged_width2, width, height,
interlacing?(jpeg?TpackedFuncPtrRGB<JPEG>::rgbi_to_yv12:TpackedFuncPtrRGB<CCIR>::abgri_to_yv12) :(jpeg?TpackedFuncPtrRGB<JPEG>::abgr_to_yv12:TpackedFuncPtrRGB<CCIR>::rgb_to_yv12),
interlacing?(jpeg?TpackedFuncPtrRGB<JPEG>::rgbi_to_yv12_c:TpackedFuncPtrRGB<CCIR>::abgri_to_yv12_c):(jpeg?TpackedFuncPtrRGB<JPEG>::abgr_to_yv12_c:TpackedFuncPtrRGB<CCIR>::rgb_to_yv12_c), 3);
Shouldn't some abgr be rgb?

By the way, I found a mess.
FF_CSP_RGB24 = PIX_FMT_BGR24
FF_CSP_RGB32 = PIX_FMT_BGR32
RGB and BGR is upside down in ffdshow. FF_CSP seems to be wrong.
Of course this is not related to your patch.

[yesgrey]

I have updated my ffdshow to rev 2301.
Two things:
1-The "Process frames flagged as progressive" check box only works when the "Deinterlacing" check box is checked, right?
If it's this way, I think it should be placed inside the "Deinterlacing" group box, and not side-by-side with the "Deinterlacing" word over the group box line...
2-In the Presets dialog, when we rename a preset there is a little bug. We cannot change the case of a word. I have created a "dvd" preset, then I wanted to change it to "DVD" but it always appeared as "dvd". I renamed it to "ddd" and then to "DVD", and then it accepted it.

[STaRGaZeR]

Currently, libmpeg2 in ffdshow does this except if the pictures has "repeat first field flag" + "Picture" progressive flag and it indicates telecined film.
libavcodec flags progressive if "Picture" progressive flag is set.
libmpeg2 works better for me, but as tal.aloni has pointed, my samples have been gathered from weird places.

Yes, this is good as it is (libmpeg2 I mean). libavcodec should have it too, don't you think?

This is wrong. H.264 has better flags: "Picture timing SEI message", which I submitted a patch to (and now part of) FFmpeg.

Yes, but picture timing SEI messages can also be wrong, and that means problems. Take a look at "anixe.hd.ts" in the x264 site. The beggining is interlaced, but the SEI indicates it's progressive, so it doesn't get any deinterlacing. And this stream is actually broadcasted, not a weird one to test the decoder decisions, so anybody that watch that channel or a similar one will encounter problems if you go by the the SEI.

There is no reliable method, especially for MPEG-2.

I agree, everything can be bad flagged. But the goal is to find the most reliable method. In MPEG-2 it's progressive_sequence, that is good as it is now in libmpeg2. But for H.264 the SEI messages, while more detailed and reliable than MPEG-2 flags, are not 100% reliable either. You can do nothing if interlaced material is not flagged as PAFF/MBAFF, but you can guarantee that if the stream has PAFF/MBAFF identifiers is because there is interlaced video at some point, and thus flagging all of them will solve 99,999999% of the issues. What I suggest is a separate option like "Force bob", not to include this in the auto detection method, just to clarify.

[tal.aloni]

Shouldn't some abgr be rgb?

You are correct,
here is an updated patch:
http://iknowu.net/files/public/ffdshow/Grab/2312-BGR24-RC3.zip


By the way, I found a mess.


Yea, it is a mess, RGB was already called BGR,
so I called the BGR routines RGB.

I can "make it right", if you prefer it that way, but it will be a very long patch, and it would change dozens of files.
(at first that's what I did, but when I saw the magnitude of the change, I was afraid it won't be accepted)


Tal

[haruhiko_yamagata]

Yea, it is a mess, RGB was already called BGR,
so I called the BGR routines RGB.

I can "make it right", if you prefer it that way, but it will be a very long patch, and it would change dozens of files.
(at first that's what I did, but when I saw the magnitude of the change, I was afraid it won't be accepted)
Sooner or later, we have to fix it.
Please wait, not now, as I'm updating libswscale.
It would cause too much conflicts with my local copy.

[tal.aloni]

FF_CSP seems to be wrong.
you are right, it is the FF_CSP that's wrong, see here:


struct TimgExportBMP :public TimgExport
{
virtual int requiredCSP() {return FF_CSP_RGB24|FF_CSP_FLAGS_VFLIP;}

BMP is actually BGR24.


struct TimgExportPNG :public TimgExportLibavcodec
{
virtual int requiredCSP() {return FF_CSP_BGR24;}

PNG is actually RGB24.


Please wait, not now, as I'm updating libswscale.

OK.

Tal

[DigitalDeviant]

I have a sample here with a few interlaced frames that don't seem to be getting flagged as interlaced. They appear to be flagged correctly in DGIndex.

sample (http://www.mediafire.com/?2mycmgyzmym)

Sorry to bump but can anyone tell me if this is a ffdshow bug, an operator bug or is there something wrong with the stream?

[tal.aloni]

Sorry to bump but can anyone tell me if this is a ffdshow bug, an operator bug or is there something wrong with the stream?

None of my Auto-Deinterlacers (software / hardware) deinterlaced this stream properly, so it must be a badly flagged stream.

[DigitalDeviant]

None of my Auto-Deinterlacers (software / hardware) deinterlaced this stream properly, so it must be a badly flagged stream.

I run it through DGIndex and it looks like the interlaced frames are flagged as interlaced though. I don't know a better way to check.

[STaRGaZeR]

I run it through DGIndex and it looks like the interlaced frames are flagged as interlaced though. I don't know a better way to check.

DGIndex is correct. Deinterlacers need a small amount of time to start deinterlacing. If you have only 2 interlaced frames between progressive frames like this sample, they probably won't get deinterlaced because deinterlacers don't have time to start. This is one of the reasons to add that option I've been talking about in my last posts. It would consider all frames of that stream as interlaced (progressive_sequence is 0), avoiding those changes between prog-int. You'd loss a bit of detail though. It would be your choice to activate it or not.

For MPEG2 --> Everything that is not progressive_sequence=1 (even if it is soft telecined, at some point it may have interlaced frames like that sample).
For H.264 --> Every PAFF/MBAFF stream, regardless of picture timing SEI.
For VC-1 --> I can't find the specification.

I really think lots of people would find this option useful. A more refined "force bob" and "Process frames flagged as progressive".

[tal.aloni]

DGIndex is correct.
I don't believe that the video is flagged correcly, If you claim it is, please introduce me to the tools who shows this information.

Deinterlacers need a small amount of time to start deinterlacing
That's not true, many deinterlacers (linear blending for example) will deinterlace immediately.

[LoRd_MuldeR]

I don't believe that the video is flagged correcly, If you claim it is, please introduce me to the tools who shows this information.


That's not true, many deinterlacers (linear blending for example) will deinterlace immediately.

Any proper deinterlacer should be able to deinterlace immediately. Even a "smart" deinterlacer/bobber should be able to do so.
In the very first frame, when there's no previous frame to compare against, simply all pixels need to be interpolated...

[DigitalDeviant]

I don't believe that the video is flagged correcly, If you claim it is, please introduce me to the tools who shows this information..

I used DGindex's preview to step through the stream and the frames that show interlacing were reported in the information window as interlaced. Is there something incorrect with this?

[tal.aloni]

Is there something incorrect with this?
Yes, here DGIndex clearly shows that there many interlaced frames flagged as progressive:
http://iknowu.net/files/public/ffdshow/BadStream-IgnorePulldown.jpg

Any proper deinterlacer should be able to deinterlace immediately. Even a "smart" deinterlacer/bobber should be able to do so.

Well, all of the deinterlacers in ffdshow gets the matching "interlaced flag" with the destined frame.
I'm not familiar with any delayed deinterlacing issue, and I think we have none.

Deinterlacers need a small amount of time to start deinterlacing. If you have only 2 interlaced frames between progressive frames like this sample, they probably won't get deinterlaced because deinterlacers don't have time to start.
Wrong. Kernel bob / Linear Blending (which are the ones I use) will be applied immediately,
again, I'm pretty sure most of the others will too, but I'm not familiar with them.

[DigitalDeviant]

Wow, that's not what I get. http://img517.imageshack.us/img517/5601/bad1el0.png

I also checked it ignoring the pulldown flags since I thought that was closer to the behavior of ffdshow anyway and still it came out as interlaced http://img517.imageshack.us/img517/8388/bad2wo8.png

I wonder what the discrepancy is since the version of DGindex I'm using seems to get it right?

[tal.aloni]

I also checked it ignoring the pulldown flags since I thought that was closer to the behavior of ffdshow

I was mistaken when I took the first screen shot, but it's still wrongly flagged when I activate "ignore pulldown". (I have updated the picture in my previous post)

I'm not familiar with your settings / plugins, But I use DGIndex 1.4.9, all of the programs I used confirms that the stream is wrongly flagged.

[DigitalDeviant]

I'm using 1.5.3 and I'm checking on another PC and it shows what appears to be correct flagging still. The frame you posted says it's frame #7 though it looks like what shows on mine as frame #8 (see the pic in my last post). Frame #7 on mine looks like this http://img408.imageshack.us/my.php?image=bad3qy2.png so there is still a discrepancy. I went back and tried 1.4.9 and sure enough, it showed the same results as yours. So either there is a bug in 1.5.3 or both 1.4.9 and ffdshow. If the bug is in the newer DGindex can you please introduce the bug to ffdshow :p

[STaRGaZeR]

I don't believe that the video is flagged correcly, If you claim it is, please introduce me to the tools who shows this information

Use DGIndex v1.5.3 (lastest one). Use Ignore Pulldown flags or Force film. I've checked both and there were 0 errors, progressive frames are all shown as progressive, and interlaced as interlaced.

Wrong. Kernel bob / Linear Blending (which are the ones I use) will be applied immediately,
again, I'm pretty sure most of the others will too, but I'm not familiar with them.

Please use this sample: http://www.megaupload.com/?d=DLJZJYFZ

There are two interlaced frames between a progressive sequence, just when the pink haired girl appears. Tell me if any of the ffdshow deinterlacers can properly deinterlace them. They will show at least the first interlaced frame with combing (no deinterlace applied) if you go frame by frame. If you play the stream normally, you'll clearly notice it. If you want a longer sample to check if your "viewing experience" with those single frames every now and then is good, use this one (http://forum.doom9.org/showpost.php?p=1205547&postcount=4683), it's the same but larger, and also the credits at the end are at 29.97 interlaced, check the transition between the episode and credits to see the same single frame that doesn't get deinterlacing. And of course disable "Process frames flagged as progressive" or "force bob" if you use hardware.

Any proper deinterlacer should be able to deinterlace immediately. Even a "smart" deinterlacer/bobber should be able to do so.

Check the same samples as above please.

Also both of you can check the mixed.m2v sample in ffdshow, and you'll clearly see that combing is visible for the same reason as my own sample. Go frame by frame to see it. The very first frame of an interlaced sequence doesn't get deinterlaced, depending of the deinterlacer it may be two frames instead of one.

That or ffdshow has a bug that only affects that single frame. I see two solutions: find what is causing this problem and fix it, or flag the entire sequence as interlaced. The lastest can be done with "Process frames flagged as progressive" or "force bob", but with that you also flag progressive sources. Hence my suggestion of a new agressive option.

[Snowknight26]

Interesting tidbit:
Sometimes when I'm looking at the volume levels in ffdshow, the volume levels are shown when Volume is unchecked but Show current volume levels is.
The other times, the volume levels aren't shown. Seems to be pretty random. Only surefire way to show the current volume levels is to have both checked.

[tal.aloni]

since Media player classic internal auto-deinterlacer shows the same results as ffdshow and DGIndex 1.4.9,
I have to assume this is not an ordinary clip, and I'm not going to waste any more time on the subject.

but I do get the same results with 1.5.3 as you.

Edit:
It seems that libavcodec does flag the stream correctly, and the issue lies within libmpeg2,
which is also used by media player classic. you can try to contact libmpeg2 developers.

[CruNcher]

CoreAVC 1.8.5 User: 5s, kernel: 0s, total: 5s, real: 45s, fps: 681.0, dfps: 77.8
ffdshow-mt 2311 (3 threads) User: 6s, kernel: 0s, total: 6s, real: 77s, fps: 515.8, dfps: 45.3
ffdshow-mt 2311 (1 thread) User: 118s, kernel: 0s, total: 118s, real: 118s, fps: 29.7, dfps: 29.6
ffdshow 2309 (3 threads) User: 8s, kernel: 0s, total: 8s, real: 110s, fps: 396.1, dfps: 31.7


come on :D just + 170 fps and it's done ;)

[Inventive Software]

Am I correct in assuming that if I leave that option unchecked, deinterlacing will only be used on frames flagged as interlaced?

Correct. Works on DivX and Xvid files marked the same too. :)

[haruhiko_yamagata]

Yes, this is good as it is (libmpeg2 I mean). libavcodec should have it too, don't you think?Difficult to decide.
Elecard MPEG-2 decoder seems to have the same behavior as libavcodec.

Yes, but picture timing SEI messages can also be wrong, and that means problems. Take a look at "anixe.hd.ts" in the x264 site. The beggining is interlaced, but the SEI indicates it's progressive, so it doesn't get any deinterlacing. And this stream is actually broadcasted, not a weird one to test the decoder decisions, so anybody that watch that channel or a similar one will encounter problems if you go by the the SEI.

I agree, everything can be bad flagged. But the goal is to find the most reliable method. In MPEG-2 it's progressive_sequence, that is good as it is now in libmpeg2. But for H.264 the SEI messages, while more detailed and reliable than MPEG-2 flags, are not 100% reliable either. You can do nothing if interlaced material is not flagged as PAFF/MBAFF, but you can guarantee that if the stream has PAFF/MBAFF identifiers is because there is interlaced video at some point, and thus flagging all of them will solve 99,999999% of the issues. What I suggest is a separate option like "Force bob", not to include this in the auto detection method, just to clarify.
Even though there are some files that have wrong flags, flans in H.264 are much more reliable than that of MPEG-2.
Whoever the encoder is, it is wrong to flag in that manner as anixe.hd.ts.
I won't support flagging like you say in the H.264 decoder. Users can force bob.

[DigitalDeviant]

since Media player classic internal auto-deinterlacer shows the same results as ffdshow and DGIndex 1.4.9,
I have to assume this is not an ordinary clip, and I'm not going to waste any more time on the subject.

but I do get the same results with 1.5.3 as you.

Edit:
It seems that libavcodec does flag the stream correctly, and the issue lies within libmpeg2,
which is also used by media player classic. you can try to contact libmpeg2 developers.

Thank you, that does seem to be the problem. Does anyone know if there is a better place to report bugs to the libmpeg2 developers than their mailing list?

[MatMaul]

Edit:
It seems that libavcodec does flag the stream correctly, and the issue lies within libmpeg2,
which is also used by media player classic. you can try to contact libmpeg2 developers.
and with this build ?
http://www.etud.insa-toulouse.fr/~mvelten/bordel/ffdshow_test_libavcodec.zip

[tal.aloni]

and with this build ?
http://www.etud.insa-toulouse.fr/~mvelten/bordel/ffdshow_test_libavcodec.zip

Exactly the same as the official build.
please note the you uploaded ffdshow.ax,
any changes you made to libavcodec are not with the package you sent.

Tal

[STaRGaZeR]

Edit:
It seems that libavcodec does flag the stream correctly, and the issue lies within libmpeg2,
which is also used by media player classic. you can try to contact libmpeg2 developers.

This is probably correct, but H.264 (libav) does the same. So the problem is not restricted to MPEG-2.

Difficult to decide.
Elecard MPEG-2 decoder seems to have the same behavior as libavcodec.

PowerDVD too. But that doesn't mean it's correct or the best option. The main evidence is that with these decoders combing artifacts can be seen.

Even though there are some files that have wrong flags, flans in H.264 are much more reliable than that of MPEG-2.
Whoever the encoder is, it is wrong to flag in that manner as anixe.hd.ts.
I won't support flagging like you say in the H.264 decoder. Users can force bob.

Not even in an independent option? You can always use presets, that what I'm doing right now. But once you start using ffdshow in different apps with different settings for each it can be a complete mess, and you can always find something wrong. Also, the average user doesn't know how to use ffdshow, let alone its presets. He just installs it and then complains that things don't work and ffdshow doesn't deinterlace and it's buggy and... . The decision is yours, I can only tell you to include it.

[STaRGaZeR]

CoreAVC 1.8.5 User: 5s, kernel: 0s, total: 5s, real: 45s, fps: 681.0, dfps: 77.8
ffdshow-mt 2311 (3 threads) User: 6s, kernel: 0s, total: 6s, real: 77s, fps: 515.8, dfps: 45.3
ffdshow-mt 2311 (1 thread) User: 118s, kernel: 0s, total: 118s, real: 118s, fps: 29.7, dfps: 29.6
ffdshow 2309 (3 threads) User: 8s, kernel: 0s, total: 8s, real: 110s, fps: 396.1, dfps: 31.7


come on :D just + 170 fps and it's done ;)

Those numbers are strange. Between 2309 and 2311 there are no changes to the code. How comes a 100+FPS increase?

[clsid]

The ffmpeg-mt branch has an outdated copy of libavcodec. And maybe the MT add some overhead.

[LoRd_MuldeR]

Those numbers are strange. Between 2309 and 2311 there are no changes to the code. How comes a 100+FPS increase?

I think you have to look at the "dfps" value, not at "fps". On my Q6600 ffdshow-mt has more than 2x throughput than "normal" ffdshow :cool:

[tal.aloni]

I was trying to update ffmpeg-MT, beacuse I feared that the image curruption I reported on was because of bad merging, and I gave up.
it seems that "our ffmpeg" is getting farther away from the ffmpeg project, and I hope one of you, who is more familiar with ffmpeg than I do, could put things into order in the future.

Tal

[STaRGaZeR]

I think you have to look at the "dfps" value, not at "fps". On my Q6600 ffdshow-mt has more than 2x throughput than "normal" ffdshow :cool:

No, no, that's not it. I've somehow read:

ffdshow(-mt) 2309 (3 threads) User: 8s, kernel: 0s, total: 8s, real: 110s, fps: 396.1, dfps: 31.7

The bolded part was in my imagination. Time to go rest I suppose :D

I was trying to update ffmpeg-MT, beacuse I feared that the image curruption I reported on was because of bad merging, and I gave up.

Something like this?:

http://img503.imageshack.us/img503/415/snapshot20081113001923ez8.th.png (http://img503.imageshack.us/img503/415/snapshot20081113001923ez8.png)http://img503.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

[Atak_Snajpera]

@ clsid
Why VC-1 , WMV1/2/3 decoding is disabled by default in setup?

[LoRd_MuldeR]

@ clsid
Why VC-1 , WMV1/2/3 decoding is disabled by default in setup?

Because recent versions of Windows ship with decoders for these formats and older Windows versions get decoders for these formats by installing a recent version of WMP. Hence the average user already has the required decoders installed and only needs these formats enabled in ffdshow, if he/she prefers ffdshow/libavcodec's decoders over Micro$oft's decoders...

[CruNcher]

also Microsofts Decoder supports DXVA that ffdshow doesnt :)

[clsid]

I was trying to update ffmpeg-MT, beacuse I feared that the image curruption I reported on was because of bad merging, and I gave up.
it seems that "our ffmpeg" is getting farther away from the ffmpeg project, and I hope one of you, who is more familiar with ffmpeg than I do, could put things into order in the future.

Tal
Most custom code has a comment around it that says it is custom code. There are also many places where there are little compatibility tweaks for MSVC, but those are easy to spot. But besides this, our code should be up-to-date. I have actually tried to bring it closer to the original. If there are any specific things that you think are unnecessarily different, let me know.

[haruhiko_yamagata]

I think xxl is working (or is going to work) on it.
The amount of the last four commit to the git is large.
Let's wait without speeding him.

[Inventive Software]

Just a heads-up: ffmpeg r15804 breaks H.264 decoding, therefore I would not recommend merging with ffdshow until that's fixed yet.

I'm also following the ffmpeg-devel and ffmpeg-cvslog lists. Some interesting stuff going on with audio (QCELP decoder) and video (various other bits) development. :)

[clsid]

That was already fixed in r15816.

[Thunderbolt8]

I was trying to update ffmpeg-MT, beacuse I feared that the image curruption I reported on was because of bad merging, and I gave up.
it seems that "our ffmpeg" is getting farther away from the ffmpeg project, and I hope one of you, who is more familiar with ffmpeg than I do, could put things into order in the future.
is it already possible to implement ffmpeg-MT into ffdshow / media player classic for me (using libavcodec) ? or is it still something like test status and not available for 'nomal' users who cannot comile?

got a minor playback problem with a baraka blu-ray (VC-1) -> .mkv remux I play with ffdshow (+haali renderer): theres a thin white line at the top of the visible frame (AR 2.20). unfortunately its not on the screenshots I took, but its gone when I switch ffdshow for the WMVideo Decoder DMO for example. is there any way to get rid of it, using ffdshow?Found the problem, its caused by ffdshow's unsharped mask, when I disable it the line is gone. nevertheless, this seems to be the only movie I've experienced this problem with so far, would this be hard to fix for you guys?

heres a sample: http://www.sendspace.com/file/r8mbcn

[tal.aloni]

is it already possible to implement ffmpeg-MT into ffdshow / media player classic for me (using libavcodec) ? or is it still something like test status and not available for 'nomal' users who cannot comile?

you can download ffdshow-mt builds from http://xvidvideo.ru,
it works well for most types of content.
[keep in mind that new features / bug fixes comes to this branch with some delay]

Found the problem, its caused by ffdshow's unsharped mask
I'm not so sure there's something that can be fixed, for all I know this is inevitable part of the unsharped mask job. as to why this is only happen with this video, you can see that it's top border is different to begin with.

[Thunderbolt8]

you can download ffdshow-mt builds from http://xvidvideo.ru,
it works well for most types of content.
[keep in mind that new features / bug fixes comes to this branch with some delay]thanks. do the listed svn numbers correspond to the numbers of 'normal' ffdshow builds made by you guys? what I mean in case I'd have for example 2318 for both builds, will the content of features/bugs of decoders, e.g. libavcodec be exactly the same, or could it be possible that their version are still a little more out of date, despite the same number?

edit: just noticed that theres still the bug which causes rainbow frames in band of brothers EP1 and babel (both AVC) in the lastes ffdshow-mt, while it has already vanished in 22XX of normal ffdshow

edit²: but I can report back positively that ffdshow-mt uses mult. cores on 1080i50 H.264 video streams, while normal ffdshow only primarely uses 1 core on that.

[DeathTheSheep]

Embedded ASS subtitles no longer display in correct location in newest SSE release (as opposed to the last, which was correct). Downgrading fixes this problem. I don't think it has anything to do with my system or settings--I'm simply using the defaults.

[tal.aloni]

do the listed svn numbers correspond to the numbers of 'normal' ffdshow builds made by you guys?

No, revision numbers are given automatically, they correlate to the date of the last update, but it's almost never the same update. (we can add feature at ffdshow only, and fix bug at ffdshow-mt later on the same day, ffdshow-mt will have a higher revision number).
the latest ffdshow-mt correspond to ffdshow 2160.

[haruhiko_yamagata]

Embedded ASS subtitles no longer display in correct location in newest SSE release (as opposed to the last, which was correct). Downgrading fixes this problem. I don't think it has anything to do with my system or settings--I'm simply using the defaults.
I remember I have experienced a similar problem. This time, I can't reproduce for now. Could you send us a sample?

[Frans]

I remember I have experienced a similar problem. This time, I can't reproduce for now. Could you send us a sample?

Btw, I have filled a bug report through sourceforge (at Nov 2nd) about the SRT position bug (which already been fixed since 2319 build), and SSA text overlapping (which still present at the latest build). It is broken since 2270 build (I think when albain do Improvements of SSA subtitles : collisions, position, move, layers). I don't know if your problem is the same as me though. I have included the sample there. I don't know if you guys can reproduce it, but it is certainly consistent whenever I tried build 2270 and up, the SSA problem that I described happen... try 2269 and everything is ok.

And I have filled another bug report on SSA with overlay box (like you make a transparent horizontal box with text in it). It isn't very important though (since not many use it), but nice to have it behave like it meant to be.

Thanks

[MatMaul]

I think I found a bug with flash videos : the video isn't cropped correctly if it is not mod16.
I don't have this problem with internal MPC-HC decoder.
here is a sample :
http://www.etud.insa-toulouse.fr/~mvelten/bordel/12431456.flv

[tal.aloni]

@clsid, xxl, haruhiko

I've updated the definition names in 71 files of "our ffmpeg" to match the current ones (ffmpeg trunk). this will allow for quicker ffmpeg updates (less differences).
I've spoken about it with clsid,
if you have any objection / suggestion before I commit,
let me know.

Tal

patch:
http://iknowu.net/files/public/ffdshow/2326-ffmpeg-Def.patch

[Thunderbolt8]

are the people who work on ffdshow-mt the same ones as those of normal ffdshow? is there also a ffdshow-mt forum here or somewhere else where I could state requests?

[tal.aloni]

are the people who work on ffdshow-mt the same ones as those of normal ffdshow?
yes, ffdshow-mt is identical to the regular ffdshow except that it's including ffmpeg-mt instead of ffmpeg (libavcodec decoding library).

[Thunderbolt8]

I've compared some movies with ffdshow and ffdshow-mt with my C2D and I have to say it's pretty similar.

-AVC and VC-1 performance is about the same
-interlaced H.264 is multithreaded with ffdshow-mt, but not yet with ffdshow
-at the current version ffdshow-mt still creates rainbow frames with some AVC videos, while its already fixed with current ffdshow rev.

comparing the AVC multithreading performance I can say that there have been improvements since the last year. last year I had 2 AVC titles which I couldnt play at 3.2GHz (delay piling up), which now play fluently with 2.8GHz. the usage of both CPUs looks quite balanced in task manager (at least for 2 cores, might be different on quad core systems; might be able to look at that next weekend), there used to be a broader gap back then.

so basically whats left is still some VC-1 multithreading improvement. theres still some gap between both cores which is not really a problem for my system (400x7, 2 cores), but on my fathers C2Q6600 (275x10, 4 cores) for example this difference is much bigger, there is 1 predominantly core with high usage, while the other 3 cores hover with comparably lower load and waste a bit potential. thus, the video does not play smoothly, delay piling up.

heres a screen of my system with VC-1 load: http://thumbnails9.imagebam.com/1843/d7375e18420762.gif (http://www.imagebam.com/image/d7375e18420762)

so I would really appreciate it if a bit more of VC-1 multithreading optimizing could be done.

thank you all so far for your work!!

[LoRd_MuldeR]

Thunderbolt8, something must be wrong with your test. Maybe the performance was bottlenecked by the by renderer!?
Or your sample video simply didn't require more CPU time to run smoothly on the test machine...

My test clearly shows that all four cores get used by ffdshow-mt at ~100% when decoding H.264 footage:

http://img362.imageshack.us/img362/6452/ffdshowmtsp2.th.png (http://img362.imageshack.us/my.php?image=ffdshowmtsp2.png)http://img362.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Also my test (http://forum.doom9.org/showpost.php?p=1211080&postcount=34) has shown that the throughput has more than doubled in ffdshow-mt (which uses all cores), compared to ffdshow (which roughly uses two cores).

[STaRGaZeR]

My test clearly shows that all four cores get used by ffdshow-mt at ~100% when decoding H.264 footage:

Because you're forcing it with a benchmark. If you play actual footage at normal FPS you will get something like what Thunderbolt has (BTW he's talking about VC-1, not H.264). This is not bad, it's the normal operation of the Windows scheduler, balancing the load between cores. As you increase the workload, you'll end with the four cores loaded progressively. If possible, you want core 0 loaded and others sleeping to improve power consumption. If more power is needed, core 1 comes to the rescue, and so on. However, there are times in which Windows loads cores without any logic. You can also see single threaded applications spreaded all over the four cores, never using more than a 25% combined.

Exactly what ffmpeg decoders are multithreaded in ffmpeg-mt? H.264 for sure, any other? I wasn't aware about the VC-1 decoder being multithreaded.

[haruhiko_yamagata]

Exactly what ffmpeg decoders are multithreaded in ffmpeg-mt? H.264 for sure, any other? I wasn't aware about the VC-1 decoder being multithreaded.MPEG-4 decoder is multithreaded. However it is not working yet, not enabled in ffdshow.
Only H.264 is multithreaded in ffdshow for now.

[haruhiko_yamagata]

@clsid, xxl, haruhiko

I've updated the definition names in 71 files of "our ffmpeg" to match the current ones (ffmpeg trunk). this will allow for quicker ffmpeg updates (less differences).
I've spoken about it with clsid,
if you have any objection / suggestion before I commit,
let me know.

Tal

patch:
http://iknowu.net/files/public/ffdshow/2326-ffmpeg-Def.patchI think the patch is OK.
By the way, the safest way to apply updates from FFmpeg is to manually apply the patch (new revision) one by one. I guess this is how clsid and xxl is doing every time, unless they are sure that it is safe to overwrite the file.

[_xxl]

I would prefer to merge trunk in ffmpeg-mt, but starting with an older revision. There are to many diff's.

[Thunderbolt8]

MPEG-4 decoder is multithreaded. However it is not working yet, not enabled in ffdshow.
Only H.264 is multithreaded in ffdshow for now.
what does multithreaded mean here? using more than 1 core? or more than two? because in the picture I added I was using VC-1 and as you can see both cores are carrying load. not completely balanced, but still both are used to a certain extend, when I have features which are clearly not supported by multithreading then 1 core shots up to the sky, while the other crawls at bottom.

next weekend I can try to add screens of our C2Q using H264 stuff and VC-1 with ffdshow and ffdshow-mt.

[Dark Shikari]

what does multithreaded mean here? using more than 1 core? or more than two? because in the picture I added I was using VC-1 and as you can see both cores are carrying load. not completely balanced, but still both are used to a certain extendThe operating system automatically swaps between the cores very quickly, resulting in a 100% CPU singlethreaded process using 50% of both cores. This doesn't improve performance.

[_xxl]

see both cores are carrying load. not completely balanced
Look here:
http://forum.doom9.org/showthread.php?p=923944#post923944
Try process explorer's single aggregate graph, in process properties. Or just set MPC's affinity to one CPU. You'll find the graphs are mostly stable, and all you're seeing is the kernel's habit of tossing threads around in strange fashions. It doesn't really affect performance to execute half-and-half on two cpus instead of one.

[Thunderbolt8]

thanks for that explaination. I guess I then have the problem that I dont have normal (not funny like interlaced) vc-1 stuff that uses more load than that and cannot test what would happen if load really gets higher than 100% on 1 core :S

however, when I use 1 core im slightly below 50% use, with 2 cores slightly above. how can that be, does the balancing between cores takes up load as well? and is only the load of the core listed with % which uses most load of all cores?

[haruhiko_yamagata]

I would prefer to merge trunk in ffmpeg-mt, but starting with an older revision. There are to many diff's.Do you mean merging the update in the git to ffmpeg-mt branch in ffdshow?

Though it would take very long time, I think it's best to check out the diffs in the last four commit in the git and apply manually one line by one line.
And I will wait :) .

[Reimar]

The operating system automatically swaps between the cores very quickly, resulting in a 100% CPU singlethreaded process using 50% of both cores. This doesn't improve performance.

Hm, I haven't paid attention on Windows, but I've never seen that on Linux.
This seems like a very stupid thing to do, especially on AMD processors, since all the data you need probably wouldn't be in the cache anymore each time you switch the CPU (and if there was a scheduler that does this for multiple-socket Opterons then its programmer must have had 80% of his brain removed shortly before).

[leeperry]

not sure whether it's a bug(yes I've disabled the "keyboard control" options), but if I press the "c" key in the Avisynth script filter while playing a movie, ffdshow shuts down.

If I do it while a movie is not playing, it's cool :confused:

PS : also happens with pressing <RETURN>...and the arrow keys simply don't do anything.

[clsid]

I would prefer to merge trunk in ffmpeg-mt, but starting with an older revision. There are to many diff's.
The ffmpeg-mt changes focus just on the core of libavcodec (avcodec.h, utils.c etc.) and the MPEG based video stuff (h264.c, mpegvideo.c etc.). So you would have to compare those parts manually. Other files, such as audio stuff and other video codecs, you could simply overwrite with the versions from trunk. That should save a lot of time.

[ikarad]

What is the difference between ffdshow, ffdshow MMX, ffdshow SSE and ffdshow-mt?
http://www.free-codecs.com/download/FFDshow.htm

[LoRd_MuldeR]

What is the difference between ffdshow, ffdshow MMX, ffdshow SSE and ffdshow-mt?
http://www.free-codecs.com/download/FFDshow.htm

ffdshow-mt was built using the "mt" branch of ffmpeg. This means it uses multi-threaded decoders, which are not in the "main" branch yet. It's experimental, try it at your own risk!
For exmaple ffdshow-mt is able to use all CPU cores for H.264 playback, while the "normal" ffdshow is limited to roughly two cores in that case.

As for the other suffixes like "SSE" or "MMX" it simply means the compiler was instructed to build the binary for CPUs that support the MMX (or SSE) instruction set at least.
There usually is only a small speed improvement in such "CPU optimized" builds (compared to the "generic" ones), as all the important functions are hand-optimized ASM code anyway...

I'd recommend to download the latest build from the official ffdshow-tryouts sourceforge project site:
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416

(You also find "ICL" builds there. These are builds created with Intel's Compiler, resulting in some speed-up for certain filters)

[LoRd_MuldeR]

Because you're forcing it with a benchmark. If you play actual footage at normal FPS you will get something like what Thunderbolt has (BTW he's talking about VC-1, not H.264)

Sure, in normal playback the decoder will use as many CPU time as needed for smooth playback. At the point where the frames are decoded in playback-speed (and the frame cache is full) it won't use any more CPU time for obvious reasons. Therefore you can't play "some" video and then complain that the decoder doesn't utilize all of your cores. In fact you should be happy to get smooth playback at low CPU load. But if you want to test the multi-threading capabilities of a decoder, you must use a benchmark (e.g. TimeCodec) and push the decoder to its maximum throughput. Looking at the CPU load in Taskman/Procexp isn't very useful either. You must compare the actual throughput (e.g. the "dfps" value in TimeCodec). High CPU load alone doesn't indicate good performance...

[Thunderbolt8]

ffdshow-mt was built
For exmaple ffdshow-mt is able to use all cores or more for H.264 playback, while the "normal" ffdshow is limited to roughly two cores in that case.
is the number of decoding threads under encoding options automatically determined by ffdshow for each cpu? is it exactly 1 core = 1 thread? if not, would it make sense to alter that number to achieve better effects?

[LoRd_MuldeR]

is the number of decoding threads under encoding options automatically determined by ffdshow for each cpu? is it exactly 1 core = 1 thread? if not, would it make sense to alter that number to achieve better effects?

Usually "threads = cores" should be correct. It doesn't necessarily apply to all applications (e.g for x264 it's "threads = cores * 3/2"), but for ffdshow-mt/ffmpeg-mt it does apply.

At least that is what my test has shown. Using "threads > 4" or "threads < 4" resulted in less throughput with ffdshow-mt and H.264 video on my Q6600 ...

[STaRGaZeR]

Sure, in normal playback the decoder will use as many CPU time as needed for smooth playback. At the point where the frames are decoded in playback-speed (and the frame cache is full) it won't use any more CPU time for obvious reasons. Therefore you can't play "some" video and then complain that the decoder doesn't utilize all of your cores. In fact you should be happy to get smooth playback at low CPU load. But if you want to test the multi-threading capabilities of a decoder, you must use a benchmark (e.g. TimeCodec) and push the decoder to its maximum throughput. Looking at the CPU load in Taskman/Procexp isn't very useful either. You must compare the actual throughput (e.g. the "dfps" value in TimeCodec). High CPU load alone doesn't indicate good performance...

Exactly.

[haruhiko_yamagata]

I would prefer to merge trunk in ffmpeg-mt, but starting with an older revision. There are to many diff's.
Thank you for your work. Now it plays all H.264 as far as I have tested.

[clsid]

In case anyone is wondering what needs to be done before ffmpeg-mt gets merged into the FFmpeg trunk. Here is the ToDo list of Alexander Strange:
http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt/blobs/master/mt-work%2Ftodo.txt

Of course, once he is done, the code must also go through a review process performed by the head FFmpeg developer.

[tal.aloni]

_xxl, great work, my previously mentioned interlaced files are now playing back smoothly after the last commits!

not pushing or anything, but what is the plan for MLP support in the ffdshow-MT branch? does it require many modifications to the ffmpeg library?

Thanks a lot,
Tal

[_xxl]

This weekend I hope...

[Thunderbolt8]

_xxl, great work, my previously mentioned interlaced files are now playing back smoothly after the last commits!

not pushing or anything, but what is the plan for MLP support in the ffdshow-MT branch? does it require many modifications to the ffmpeg library?

Thanks a lot,
Tal
which version do you talk about? I got the latest clsid 2335, but interlaced h264 is still 1 core there.

btw. why does 1 core h264 stuff clearly looks like 1 core usage with 1 core loaded fully and the 2nd almost not at all, while VC-1 throws it back and forth over the cores?

[tal.aloni]

which version do you talk about? I got the latest clsid 2335, but interlaced h264 is still 1 core there.

I was referring to ffdshow-MT (MT for multi-threading) (you can get the latest from xvidvideo.ru).

[Thunderbolt8]

have it already. I just thought, since people here were talking about merging that those features would have been added to regular ffdshow.

[clsid]

It won't be merged anytime soon. The MT stuff is still unfinished.

[Reino]

There are a couple of things I'd like to talk about concerning FFDShow it's functionality.

First of all; the FPS1 (Fraps) support in FFDShow.
I compared the decoded video image with the original Fraps:
http://img101.imageshack.us/img101/959/frapsvsffdshoweg2.gif
I don't know if it's a totaly different colourspace or just a difference in brightness/gamma...maybe you know (how to fix it).

Secondly, I noticed the Volume Normalization feature has been "patched". Why?
I've been using the Volume Normalization feature for a very long time and never have I had any problems with it!
At the moment I'm using rev.2322 and I can honoustly say that I really dislike the new "patch". Not only have I been using this feature for audio material with too low sound volume, but also for audio files with sound that was too loud!
Right now the amplification never goes below 100%. At moments where it should (too loud audio volume) that's really irritating. But I've also had moments where the amplification stayed at 100% when I was expecting much more (too low audio volume). I've also had moments of amplification 400% the whole time for no special reason at all, the audio was already pretty loud of it self.
Why has this feature been "patched"?

I would also like to make a suggestion.
Within the systemtray-menu you can already select different profiles, subtitle sources, but how about the ability to select a different OSD profile? I often use different OSD profiles, but every time I need to open up the entire Video Decoder Configuration window if I want to switch to another profile. It would be much easier/faster if I could select my profile in the systemtray-menu.

Apart from that...I've been happily using FFDShow for many years now, so keep up the good work!

[bebo]

When can we expect to see MLP capbility in ffdshow? I am trying to play TrueHD in VMC. Video is fine only AC3 streams play. Newer BDs are showing up with the english track only in MLP so for Iron Man, Transformers and Kung Fu Panda I only get French or Spanish in 5.1 WAF is extremely low. Am I doing something wrong? I read that MLP is only active in MPC-HC. I also read somewhere that ffdshow MLP decode doesn't work with Haali? Any enlightenment would be greatly appreciated.

Thanks

[MatMaul]

Secondly, I noticed the Volume Normalization feature has been "patched". Why?
just check "regain volume" and you will have the same behavior as before.

[Leak]

When can we expect to see MLP capbility in ffdshow?
How about "now"?

Download clsid's latest ICL10 build (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=439938), it includes MLP.

np: Duo505 - Tsip Tsap (Late)

[rack04]

Is libavcodec stable with MPEG2? The reason that I ask is because this is not a default selection. Should "Use Speedup Tricks" and "DVD Decoding" be selected?

[tal.aloni]

As MatMaul said, there are now two modes of normalization.
I must apologize, but I never implemented an upgrade path. (and it would be too complicated to do so).


I've been using the Volume Normalization feature for a very long time and never have I had any problems with it!

you mean, besides the occasional overflows, right?
anyway, you should like the new one much more. (regain volume checked)


Right now the amplification never goes below 100%

We decided not to support non-standard files.
(more detailed explanation here: http://forum.cockos.com/showthread.php?p=252076#post252076)

Tal

[LoRd_MuldeR]

Is libavcodec stable with MPEG2?

I use it all day long for DVB playback in DVBViewer and haven't encountered problems yet. So I'd say it's pretty stable ;)

[jos99]

I use it all day long for DVB playback in DVBViewer and haven't encountered problems yet. So I'd say it's pretty stable ;)

Any advantage with it? Also as op noted, do you have "Use Speedup Tricks" and "DVD Decoding" selected?

[bebo]

How about "now"?

Download clsid's latest ICL10 build (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=439938), it includes MLP.

np: Duo505 - Tsip Tsap (Late)

Leak - Much appreciated. Was very excited to see the new options. So far, I've spent an hour trying to get MLP playback in VMC media player (using Media Contol). So far - nada...

Switched over to MPC-HC. Under 'Navigate' I see the MLP stream selected. In 'Codecs' I have AC3-libacodec; OSD-on

I see the MLP track is trying to be decoded but Jitter=31 and FPS=2

total disaster - Can anyone tell me what I am doing wrong. Would prefer to get MLP audio in VMC - only switched to MPC to test.

Thanks

[littleD]

Bebo, probably ffdshow doesnt try to decode with haali spliter. Enabling internal mpeg/ps/ts.. splitter in mpchc should work.

So, download from mpchc sourceforge site newest standalone mpeg splitter, and give it highest merit (if it hasnt already). I didnt tested but may help with other dshow players.

[Ger]

I use it all day long for DVB playback in DVBViewer and haven't encountered problems yet. So I'd say it's pretty stable ;)

I use DVBViewer as well, and there are some channels that needs MPEG2 in FFDshow set to libmpeg2.

I recorded a short sample from a problem channel. Looks fine with MPC-HC internal (libmpeg2 based) decoder and with FFDshow set to libmpeg2, but is more or less unwatchable if I switch to libavcodec.

MPEG2-sample Problem with libavcodec but OK with libmpeg2.ts - 13.95MB (http://www.zshare.net/download/515348831460b2bb/)

I generally only follow the FFDshow and MPC-HC threads here, so if someone wants to forward this to the ffmpeg/libavcodec developers, feel free. :thanks:

[nm]

Any advantage with it?
libavcodec has better error resilience and concealment features than most other MPEG-2 decoders: http://compression.ru/video/codec_comparison/mpeg-2_2006_en.html
This may not be relevant for DVD sources, but it can have a significant effect in DVB-T reception with poor antennas or bad weather.

[nm]

MPEG2-sample Problem with libavcodec but OK with libmpeg2.ts - 13.95MB (http://www.zshare.net/download/515348831460b2bb/)

I generally only follow the FFDshow and MPC-HC threads here, so if someone wants to forward this to the ffmpeg/libavcodec developers, feel free. :thanks:
MPlayer decodes it fine with libavcodec (both with built-in and lavf MPEG-TS demuxers), so the problem seems to be somewhere else.

[fastplayer]

^ libavcodec had some issues with MPEG2 in the past and probably still has. libmpeg2 is a safe bet.
Any advantage with it? Also as op noted, do you have "Use Speedup Tricks" and "DVD Decoding" selected?
- "Use Speedup Tricks" reduces CPU usage at the expense of image quality.
- "DVD Decoding" is needed if you want to watch DVD content.

[Ger]

MPlayer decodes it fine with libavcodec (both with built-in and lavf MPEG-TS demuxers), so the problem seems to be somewhere else.

OK. I Only tested it in a recent build from ffdshow-tryouts trunk (using either MPC-HC or DVBViewer) and also in an older VLC version (0.8.6i because I have problems with the browser plugin in 0.9.x) in Vista. In VLC it failed even worse than in ffdshow/libavcodec (just a black screen in VLC and not the blocking seen with ffdshow).

[bebo]

...download from mpchc sourceforge site newest standalone mpeg splitter, and give it highest merit (if it hasnt already). I didnt tested but may help with other dshow players.[/QUOTE]

Thanks a lot Little D, will try later tonight and report status.

[nm]

^ libavcodec had some issues with MPEG2 in the past and probably still has. libmpeg2 is a safe bet.
Well, MPlayer already switched to libavcodec by default because it is actively maintained and less buggy: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-February/056430.html

There seems to be a problem with multithreading (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-March/056870.html) though, and I'm not sure if it has been fixed yet. ffmpeg-mt might also change things in the future. I tried threads=2 and that does cause image corruption with my MPlayer/libavcodec revision (r27833, I'll need to update to latest SVN). However, this affects all MPEG-2 videos, not just some specific samples, so it is probably unrelated to Ger's problem.

[Reino]

...you mean, besides the occasional overflows, right?
anyway, you should like the new one much more. (regain volume checked)Overflows as in crashes? Never had that.


We decided not to support non-standard files.
(more detailed explanation here: http://forum.cockos.com/showthread.php?p=252076#post252076)I'm actually talking about every audio format FFDShow supports; mp3,aac,vorbis, etc.
I have certain mp3 files where the amplification would have dropped to 70-80% in some cases with the older FFDShow revisions. And like I said; now it doesn't go below 100% anymore.

[Taurus]

...download from mpchc sourceforge site newest standalone mpeg splitter, and give it highest merit (if it hasnt already). I didnt tested but may help with other dshow players.

@Ger and bebo
Yes, might be a problem with the splitter.
I can confirm jaggy playback on Ger's sample with libavcodec and MPC builtin splitter. Haali's Splitter is even worse.
Strange thing: On 2 machines I've got the jags.
1 machine is doing fine. Identical setups as far as I can see.
Will try bebo's suggestion on standalone splitter.

[Ger]

@Taurus

You're actually quoting littleD's suggestion for bebo's MLP problem. This has nothing to do with my sample. Two separate issues. It just looks a little weird because the start quote tag is missing in bebo's last post.

[MatMaul]

about DVD decoding with libavcodec : it doesn't work well at least on my computer.
the video play fast during half a second and then hang half a second, then play fast again half a second etc
no problem with libmpeg2.

this does not happen if I read directly the IFO file containing the film (VTS_01_0.IFO) directly, but it does happen if I read the VIDEO_TS.IFO file (even after loading the main film from the menus).

after checking seems like the problem appears when the majortype is MEDIATYPE_DVD_ENCRYPTED_PACK, no problem when the majortype is MEDIATYPE_Video (so when I directly play VTS_01_0.IFO)

[fastplayer]

about DVD decoding with libavcodec : it doesn't work well at least on my computer.
the video play fast during half a second and then hang half a second, then play fast again half a second etc
no problem with libmpeg2.

this does not happen if I read directly the IFO file containing the film (VTS_01_0.IFO) directly, but it does happen if I read the VIDEO_TS.IFO file (even after loading the main film from the menus).

after checking seems like the problem appears when the majortype is MEDIATYPE_DVD_ENCRYPTED_PACK, no problem when the majortype is MEDIATYPE_Video (so when I directly play VTS_01_0.IFO)
I reported (http://forum.doom9.org/showthread.php?p=1107246#post1107246) about the exact same issue a couple of months ago. Apparently nothing has changed since then...

[littleD]

@Ger and bebo
Yes, might be a problem with the splitter.
I can confirm jaggy playback on Ger's sample with libavcodec and MPC builtin splitter. Haali's Splitter is even worse.
Strange thing: On 2 machines I've got the jags.
1 machine is doing fine. Identical setups as far as I can see.
Will try bebo's suggestion on standalone splitter.

The most recent filter is on xvidvideo.ru site (on the right side). Halli splitter is great, but has problems with new hd audio formats, MLP as Bebo said and LPCM in my case, and probably more. As latest ffdshow finally can decode all hd audio, its quite irritating:p. So i switch between halli and mpc mpeg splitter, but (again) latter has sometimes problems with hd video spliting (no stream visible).. while halli work flawless with it.

BTW, i ve read one day on the forum, that halli is gonna be updated.(?) I hope we wont be waiting much :)

[STaRGaZeR]

I reported (http://forum.doom9.org/showthread.php?p=1107246#post1107246) about the exact same issue a couple of months ago. Apparently nothing has changed since then...

Same here. However libmpeg2 is faster than libav.

[Atak_Snajpera]

However libmpeg2 is faster than libav.
really :)


Source: HDV Canon HV20 - 1440x1080@29.97 - 24MBps

Q6600@3Ghz:
libavcodec -> 166 dfps (2 cores were used)
libmpeg2 -> 116 dfps (only 1 core was used)

Microsoft MPEG-2 decoder -> 174 dfps (2 cores were used)

Microsoft decoder is still unbeaten

ATI MPEG Video Decoder -> 375 dfps (1 core was used + GPU decoding?)

[Mercury_22]

:preally :)


Source: HDV Canon HV20 - 1440x1080@29.97 - 24MBps

Q6600@3Ghz:
libavcodec -> 166 dfps (2 cores were used)
libmpeg2 -> 116 dfps (only 1 core was used)

Microsoft MPEG-2 decoder -> 174 dfps (2 cores were used)

Microsoft decoder is still unbeaten

ATI MPEG Video Decoder -> 375 dfps (1 core was used + GPU decoding?)

Really ? :p how 'bout Cyberlink's Video/SP Decoder (HomeNetwork) and elecard's ?

[Atak_Snajpera]

Really ? how 'bout Cyberlink's Video/SP Decoder (HomeNetwork) and elecard's ?

Here is source:
http://www.mediafire.com/?indmqdxynzm

[Mercury_22]

Here is source:
http://www.mediafire.com/?indmqdxynzm

Yes :thanks: but I don't have the same hardware / CPU :mad:

[STaRGaZeR]

Source: Black Hawk Down Blu-ray, 1920x1080@23,976 MPEG-2 ~27Mbps. E8400@4GHz.

libmpeg2 (1 core was used, ~60% usage) --> User: 153s, kernel: 0s, total: 153s, real: 154s, fps: 171.3, dfps: 170.0

libavcodec (2 cores were used, ~90% usage) --> User: 23s, kernel: 0s, total: 23s, real: 129s, fps: 1120.4, dfps: 202.9

And when playing actual content, not this benchmark, CPU usage is lower with libmpeg2. 5-10% lower, total ~20-25% for libav and ~15-20% for libmpeg2. Also libav has problems with DVD as already stated here and it doesn't correctly flag interlaced content (yet).

For only 1 core libmpeg2 is much faster ;)

[Atak_Snajpera]

For only 1 core libmpeg2 is much faster
Yes we know that :)

[STaRGaZeR]

Yes we know that :)

So for MPEG-2 you'll only need speed in really slow machines. In those cases libmpeg2 is a better option.

[tal.aloni]

Overflows as in crashes? Never had that.

Overflow as in clipping.
The old algorithm was calculated based on average value,
as a result, sometimes the amplification was too high, and caused "overflow" (sound level greater than allowed),
and the sound had to be clipped.

The new algorithm is based on maximum value instead,
and as a result, the sound is much more pleasant to hear,
I demonstrated this earlier using the "Iron man" trailer, the old algorithm gave pretty awful results.
see for yourself:
http://iknowu.net/files/public/ffdshow/Normalization/ffdOldNorm-selection.flac
http://iknowu.net/files/public/ffdshow/Normalization/ffdshowNewRegainVolume-selection.flac


I'm actually talking about every audio format FFDShow supports; mp3,aac,vorbis, etc.
I have certain mp3 files where the amplification would have dropped to 70-80% in some cases with the older FFDShow revisions. And like I said; now it doesn't go below 100% anymore.
The right way of doing Dynamic Range Compression (a.k.a. regain volume) is to amplify the quiet parts, (not reducing the volume from the louder ones! when you're attenuating the volume, you're basically reducing the resolution of the file)

The new algorithm allows you retain much more of the original sound characteristic.

Tal

[Snowknight26]

I just installed ffdshow on my 4x Quad-core Opteron server (16 cores), but it set the number of decoding threads to 16 (even though the maximum is apparently 8). ffdshow wouldn't work until I set the number of decoding threads to 8 or less (so I set it to 4).

[tal.aloni]

I just installed ffdshow on my 4x Quad-core Opteron server (16 cores)

Jesus. http://iknowu.net/files/public/w00t.gif
on a serious note, what do you mean "doesn't work",
can you narrow it down to a decoder / filter?

[Snowknight26]

When I check the bitrate graph in Haali Media splitter, the bitrates fly past at something like 500fps (the graph is 5 minutes wide @ 23.976fps), ffdshow doesn't show anything in the Info & CPU tab, MeGUI/MPC-HC freeze, and sometimes the DirectShowSource from the avs times out.

[tal.aloni]

When I check the bitrate graph in Haali Media splitter, the bitrates fly past at something like 500fps (the graph is 5 minutes wide @ 23.976fps), ffdshow doesn't show anything in the Info & CPU tab, MeGUI/MPC-HC freeze, and sometimes the DirectShowSource from the avs times out.

are we talking about libavcodec? is it ffdshow or ffdshow-MT?

[Snowknight26]

H.264 is set to libavcodec. Just ffdshow.

Point being though, the installer sets it to 16 when the greatest value you can normally type into the box is 8 (goes red otherwise).

[tal.aloni]

H.264 is set to libavcodec. Just ffdshow.

I can see where the problem is:
libavcodec does not allow more than 8 decoding threads, and ffdshow does not allow to select more than 8 decoding threads, but the setup routine set (in the registry) the number of threads to be the number of cores. (in your case, this is an illegal value)

I'll apply a patch to the setup routine soon.
Tal

[clsid]

Already done ;)

[Snowknight26]

Is there any benefit to setting the number of decoding threads to anything higher than 4? Or 2 even?

[LoRd_MuldeR]

Is there any benefit to setting the number of decoding threads to anything higher than 4? Or 2 even?

Depends on your number of cores. Using more threads than cores won't be helpful :p

Also the "ffmpeg-mt" branch, which is available through ffdshow-mt (http://www.xvidvideo.ru/content/category/1/40/30/) builds, benefits much more from multi-threading!
The throughput of the H.264 decoder now scales almost linear with the number of cores/threads :)

Have a look here:
http://forum.doom9.org/showpost.php?p=1214539&postcount=42
(all tests done with 4 threads on Q6600)

[Reino]

...The new algorithm allows you retain much more of the original sound characteristic.Okay, fair enough. Thanks for your explanation.

[Snowknight26]

Depends on your number of cores. Using more threads than cores won't be helpful :p

I'm talking about in the case of ffdshow, with, say, 16 cores.

[LoRd_MuldeR]

I'm talking about in the case of ffdshow, with, say, 16 cores.

Current ffdshow will use exactly two threads/cores for H.264 decoding. And it's not very efficient (you will not get 2x speed-up for 2x CPU usage).
With ffdshow-mt you can use up to eight threads/cores now, which results in a speed-up of roughly 8x compared to a single core/thread.

No idea for other formats/decoders. H.264 should be most important anyway ;)

[jos99]

Current ffdshow will use exactly two threads/cores for H.264 decoding. And it's not very efficient (you will not get 2x speed-up for 2x CPU usage).
With ffdshow-mt you can use up to eight threads/cores now, which results in a speed-up of roughly 8x compared to a single core/thread.

No idea for other formats/decoders. H.264 should be most important anyway ;)

So would it be correct that you don't see any benefit with mt unless you have a triple core and upwards?

[LoRd_MuldeR]

So would it be correct that you don't see any benefit with mt unless you have a triple core and upwards?

Even with a DualCore the "new" multi-threading implementation should be superior to the "old" one ;)

As said before: The "old" multi-threading method (move CABAC to it's own thread) isn't very efficient! Even with 2x CPU load, you won't get 2x speed-up. It's more like 30% speed-up. With the "new" frame-based multi-threading method the throughput scales almost linear with the number of cores/threads. Hence using n threads/cores will roughly multiply the throughput by n. The main reason not to go ffmpeg-mt/ffdshow-mt yet is reduced stability. The ffmpeg-mt branch is a work in progress. Nevertheless ffdshow-mt works fine with my H.264 samples so far. Same for DVBViewer usage...

[Thunderbolt8]

Current ffdshow will use exactly two threads/cores for H.264 decoding. And it's not very efficient (you will not get 2x speed-up for 2x CPU usage).
With ffdshow-mt you can use up to eight threads/cores now, which results in a speed-up of roughly 8x compared to a single core/thread.

No idea for other formats/decoders. H.264 should be most important anyway ;)
nooo, dont forget VC-1 :(. I like AVC better as well, but some studios just do produce VC-1 blu-rays. and x264 encodes are no problem anyway.

[Snowknight26]

Sounds like ffdshow-mt will be pretty awesome once issues such as http://img503.imageshack.us/my.php?image=snapshot20081113001923ez8.png are gone.

[LoRd_MuldeR]

nooo, dont forget VC-1 :(. I like AVC better as well, but some studios just do produce VC-1 blu-rays. and x264 encodes are no problem anyway.

VC-1 is multi-threaded too in ffmpge-mt, I just didn't test it. So I can't tell you how well it scales ;)

Sounds like ffdshow-mt will be pretty awesome once issues such as http://img503.imageshack.us/my.php?image=snapshot20081113001923ez8.png are gone.

Always remember: http://www.ligh.de/pics/this_is_beta.jpg

[cc979]

@tal.aloni

as far as i know of compression, there 2 types

downward compression - compresses above the threshold to make loud parts all equally as loud and then use make-up gain
and upward compression - expands the lower of the threshold, like gamma correction

is it not possible to offer/or combine both styles ?

[STaRGaZeR]

VC-1 is multi-threaded too in ffmpge-mt, I just didn't test it. So I can't tell you how well it scales ;)

http://forum.doom9.org/showthread.php?p=1213627#post1213627

[LoRd_MuldeR]

http://forum.doom9.org/showthread.php?p=1213627#post1213627

So maybe I was mistaken. At least for ffdshow-mt we are limited to multi-threaded H.264 for now...

[STaRGaZeR]

Sounds like ffdshow-mt will be pretty awesome once issues such as http://img503.imageshack.us/my.php?image=snapshot20081113001923ez8.png are gone.

Correct link: http://img503.imageshack.us/img503/415/snapshot20081113001923ez8.png

I messed it up somehow. Blu-ray, obviously 4 slices.

[Thunderbolt8]

Correct link: http://img503.imageshack.us/img503/415/snapshot20081113001923ez8.png

I messed it up somehow. Blu-ray, obviously 4 slices.
nice rainbows :D
although most of them with are gone with normal ffdshow (e.g. band of brothers, freedom series, babel), the within temptation blu-ray (also AVC) shows some artifacting even with the lastest ffdshow version at some places.

edit: or not, seems I forgot that I had -mt installed atm and then the problems showed. but now with normal they are gone again

are such things like sharpening or deinterlacing as well balanced over multiple cores, or are they all single core tasks? would it be possible then at least to alternate them over the different course, e.g. when sharpeing and deinterlacing both are applied then 1 is dropped on cpu0 and the other on cpu1?

[LoRd_MuldeR]

are such things like sharpening or deinterlacing as well balanced over multiple cores, or are they all single core tasks? would it be possible then at least to alternate them over the different course, e.g. when sharpeing and deinterlacing both are applied then 1 is dropped on cpu0 and the other on cpu1?

Since these filters are not part of ffmpeg/libavcodec, they won't become multi-threaded just by going ffmpeg-mt.
It depends on the implementation of the individual filter in ffdshow! However the "Yadif" deinterlace filter in ffdshow-mt is multi-threaded already...

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2333

[tal.aloni]

is it not possible to offer/or combine both styles ?
this in not very practical and not very useful.
as I said, reducing the volume will reduce the track resolution,
nothing good will come of it.

[haruhiko_yamagata]

edit: or not, seems I forgot that I had -mt installed atm and then the problems showed. but now with normal they are gone againDid you try the latest ffmpeg-mt? Recent updates fixed the rainbow for me.

are such things like sharpening or deinterlacing as well balanced over multiple cores, or are they all single core tasks? would it be possible then at least to alternate them over the different course, e.g. when sharpeing and deinterlacing both are applied then 1 is dropped on cpu0 and the other on cpu1?While image filter is being applied on one core, other cores are used for decoding next frames. So we don't have to multithread respective image filter.
Yadif is the exception, it's even heavier than H.264 decoding, if double frame rate is enabled. I would like to push double frame rate and I multithreaded yadif.
Here is an interesting observation. Multhithreading of yadif is 225% faster on Core2 Quad if it is used with single threaded decoder and 150% faster if it is used with H.264/ffmpeg-mt.
I don't know why it is not 300%, advice for further optimization is welcome.

note:Multithreading of yadif is available only in ffmpeg-mt branch.

[haruhiko_yamagata]

I use DVBViewer as well, and there are some channels that needs MPEG2 in FFDshow set to libmpeg2.

I recorded a short sample from a problem channel. Looks fine with MPC-HC internal (libmpeg2 based) decoder and with FFDshow set to libmpeg2, but is more or less unwatchable if I switch to libavcodec.

MPEG2-sample Problem with libavcodec but OK with libmpeg2.ts - 13.95MB (http://www.zshare.net/download/515348831460b2bb/)

I generally only follow the FFDshow and MPC-HC threads here, so if someone wants to forward this to the ffmpeg/libavcodec developers, feel free. :thanks:
libavcodec-mpeg2 in ffdshow requires two (should be one) I frames after seeking to recover. The problem of your sample may be the same issue.
I have tried to fix the seeking issue without success. Patches are welcome.

[Keepitsimple]

Total noob question. I watch movies and dvb with ffdshow. I need to deinterlace the dvb source but not the movies. Is it possible to make a setting so deinterlacing is checked. Or perhaps force it on media with some certain resolution.

[clsid]

Have a look at "Profiles / Preset settings" in ffdshow options.

[tal.aloni]

Total noob question. I watch movies and dvb with ffdshow. I need to deinterlace the dvb source but not the movies. Is it possible to make a setting so deinterlacing is checked. Or perhaps force it on media with some certain resolution.

If the DVB channel is flagged correctly, Deinterlacing can be applied only to frames flagged as interlaced. ("Process frames flaged as progressive" is unchecked), this only applies to recent versions, so make sure you use the latest.

Tal

[bebo]

The most recent filter is on xvidvideo.ru site (on the right side). Halli splitter is great, but has problems with new hd audio formats, MLP as Bebo said and LPCM in my case, and probably more. As latest ffdshow finally can decode all hd audio, its quite irritating:p. So i switch between halli and mpc mpeg splitter, but (again) latter has sometimes problems with hd video spliting (no stream visible).. while halli work flawless with it.

BTW, i ve read one day on the forum, that halli is gonna be updated.(?) I hope we wont be waiting much :)



Folks - I appreciate the support and suggestions. But someone has had to have acheived a solution for this. I now have MLP working great in MPC-HC (by checking the "Mpeg PS/TS/PVA" filter). My objective is to replicate this functionality in VMC by selecting the right standalone filters and setting merits. I have been randomly trying all the Mpeg-2 files in the svn901 standalone filter package (from XvidVideo.ru) and none seem to either "see" or "see and split" the MLP stream from the container.

Which set of files from the standalone filter set acheives the the same functionality as checking the Mpeg PS/TS/PVA box in MPC-HC? Or can the MPC development team post the same exact standalone version of Mpeg PS/TS/PVA for use in VMC. Either way, once I get there I am sure MLP will decode in VMC perfectly.

Thanks in advance Guys...:thanks:

[Snowknight26]

In the Info & CPU tab, the Input bitrate seems to take forever and a day to change. While encoding from an H.264 source, checking Haali Media Splitter shows a wildly fluctuating bitrate, but ffdshow keeps it mostly constant. Did someone use the wrong value when averaging it? :p

[clsid]

@Bebo

MpegSplitter.ax is the correct one.

[bebo]

@Bebo

MpegSplitter.ax is the correct one.

Thanks CLSID!! Sounds like the last piece of the puzzle. Will load it in tonight and report results.:thanks:

[cc979]

@tal.aloni

with any compression up or down, always a loss of dynamic range/resolution

but thanks anyway

ps. with the new yadif deinterlacer, seems i found a problem with interlaced mp4/avc files it crashes mpc when enabled

[Thunderbolt8]

Did you try the latest ffmpeg-mt? Recent updates fixed the rainbow for me.
creenshots from the Freedom series Blu-ray (AVC), EP1, using ffdshow-mt svn 2333:

http://thumbnails9.imagebam.com/1887/014f5a18865317.gif (http://www.imagebam.com/image/014f5a18865317) http://thumbnails13.imagebam.com/1887/b2699118865318.gif (http://www.imagebam.com/image/b2699118865318)
http://thumbnails7.imagebam.com/1887/475f5f18865319.gif (http://www.imagebam.com/image/475f5f18865319)

noticed the other rainbows I had with 'Babel' are gone already with svn2333, but these here are still there, while gone with normal ffdshow

uploaded a 95mb remuxed video sample here: http://www.sendspace.com/file/bipcaq

[LoRd_MuldeR]

uploaded a 95mb remuxed video sample here: http://www.sendspace.com/file/bipcaq

Sorry, the free service is at full capacity.
...upgrade to sendspace Max™ to enable guaranteed slots and instant, fast downloads.

:rolleyes:


[EDIT]

Got the file now. I can confirm the artifacts when using four decoder threads. No problem with one thread though.

We can only hope the ffmpeg-mt developers will fix the remaining issues soon...

[STaRGaZeR]

I already have the sample Lord... try again.

[BatKnight]

Hi,

I've read that the ffdshow-mt is faster on Quad Core CPUs due to the multithreading capabilities. Fine.

But what about a Dual Core CPU? Is ffdshow-mt faster than the ffdshow SVN on 2 threads?

I think that H264 decoding on ffdshow SVN already uses 2 cores. Am I right? If so, then for the owners of Dual Core CPUs, the ffdshow-mt has no benefits over the SVN builds?

Thanks

Bat

[jos99]

Hi,

I've read that the ffdshow-mt is faster on Quad Core CPUs due to the multithreading capabilities. Fine.

But what about a Dual Core CPU? Is ffdshow-mt faster than the ffdshow SVN on 2 threads?

I think that H264 decoding on ffdshow SVN already uses 2 cores. Am I right? If so, then for the owners of Dual Core CPUs, the ffdshow-mt has no benefits over the SVN builds?

Thanks

Bat

Already answered on previous page (http://forum.doom9.org/showthread.php?p=1214860#post1214860) (thanks Mulder BTW:helpful:) - apparently the multi-threading in mt builds is more efficient than in normal ffdshow.

[LoRd_MuldeR]

Already answered on previous page (http://forum.doom9.org/showthread.php?p=1214860#post1214860) (thanks Mulder BTW:helpful:) - apparently the multi-threading in mt builds is more efficient than in normal ffdshow.

Yes, the multi-threading method used in ffdshow-mt is more efficient than the "old" one, even on two cores.
The old method, as currently used in ffdshow, was pretty inefficient and hence never made it into the official ffmpeg repository.
But ffdshow-mt only uses the multi-threaded H.264 decoder from ffmpge-mt. Other decoders are not multi-threaded yet.
And there are still display errors in some videos with ffdshow-mt (see post above).

[LoRd_MuldeR]

Here is another test, some numbers for "ffdshow vs. ffdshow-mt vs. CoreAVC" with different thread counts:

E:\HD\palvik-Clip003 - Copy_001.mp4

[Core AVC v1.8.5]
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 468.2, dfps: 66.2
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 741.3, dfps: 66.5 <-- 435%
User: 0s, kernel: 0s, total: 0s, real: 6s, fps: 741.3, dfps: 66.7

[ffdshow-mt r2333, 4 threads]
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 278.0, dfps: 56.3
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 280.9, dfps: 56.4 <-- 369%
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 242.6, dfps: 56.7

[ffdshow-mt r2333, 2 threads]
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 244.8, dfps: 28.8
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 254.2, dfps: 29.0 <-- 190%
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 218.8, dfps: 29.0

[ffdshow r2335 ICL, 4 threads]
User: 1s, kernel: 0s, total: 2s, real: 18s, fps: 196.2, dfps: 23.0
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 177.9, dfps: 23.6 <-- 154%
User: 1s, kernel: 0s, total: 2s, real: 17s, fps: 202.2, dfps: 23.7

[ffdshow-mt r2333, 1 thread]
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 15.4, dfps: 15.2
User: 26s, kernel: 0s, total: 26s, real: 27s, fps: 15.5, dfps: 15.3 <-- 100%
User: 26s, kernel: 0s, total: 26s, real: 27s, fps: 15.5, dfps: 15.3

Conclusion: ffdshow-mt is significant faster than ffdshow, even on two cores/threads ;)

[BatKnight]

Conclusion: ffdshow-mt is significant faster than ffdshow, even on two cores/threads ;)

Great. Thank you for your explanation. Sorry for bringing the question up again.
I'm going to give ffdshow-mt a try from now on. I'll report any problems I encounter.

Bat

[clsid]

I assume your [ffdshow r2335 ICL] test was done with 2 threads. Otherwise the result is a bit odd. Could you add a result with 1 thread as well?

With 4 threads it is just ~15% slower than CoreAVC :)

[ikarad]

Since these filters are not part of ffmpeg/libavcodec, they won't become multi-threaded just by going ffmpeg-mt.
It depends on the implementation of the individual filter in ffdshow! However the "Yadif" deinterlace filter in ffdshow-mt is multi-threaded already...

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2333

what is Yadif?
is it inverse telecine filter like telecide or just a simple bob/wave deinterlaced filter because there is an big difference between the two methods?

[LoRd_MuldeR]

what is Yadif?
is it inverse telecine filter like telecide or just a simple bob/wave deinterlaced filter because there is an big difference between the two methods?

It's not an inverse telecine (IVTC) filter! It's a "smart" deinterlacer and bobber (depending on the mode selected).

IMHO it's currently one of the best (if not the best) real-time bobber. Some super-slow bobbers interpolate nicer, but they can't work at real-time on an affordable machine ;)

http://guru.multimedia.cx/deinterlacing-filters/

I assume your [ffdshow r2335 ICL] test was done with 2 threads. Otherwise the result is a bit odd. Could you add a result with 1 thread as well?

Nope, I allowed four threads for the "ffdshow r2335 ICL" build, just to be sure. Does that setting apply to the H.264 decoder at all in "current" ffdshow?

Still the overall CPU load was around 30-40%. Using ffdshow-mt and allowing four threads results in ~100% CPU usage, all cores at full load.

That once again proves the ineffectiveness of the "old" multi-threading method. Well, it was better than nothing, back at the time when it was added.

[bebo]

Thanks CLSID!! Sounds like the last piece of the puzzle. Will load it in tonight and report results.:thanks:



clsid:

Thanks for the tip on MpegSplitter.ax. I found MpegSplitter.ax in the standalone filters per your direction. Next I went into GSpot to change the merit of same. Odd thing though...could not see MpegSplitter.ax in GSpot's list of codecs and filters. Tried dropping file in other directories...nothing worked - still couldn't see it. So I couldn't change the merit to prioritize MpegSplitter.ax.

Next I tried some other desperate stuff like deleting ffdshow.ax from ffdshow's directory and renaming MpegSplitter.ax as the "new" ffdshow.ax. All that did was render ffdshow useless and VMC defaulted back to the old default a/v codecs.

So, honestly I feel like a noob here, but how best can I acheive the objective I am going for...BD/HD-Dvd playback in VMC with full HD-audio decoding using ffdshow?

Much appreciated,

Bebo




clsid - got you PM - thanks will try.

[littleD]

To register u should paste this file into system32 directory (but not necessary), and register it, which means drag and drop over regsvr32.exe or choose start>> run>> regsvr32 mpegsplitter.ax :) U will see it in gspot as MPC - Mpeg Splitter (Gabest)

But... the only player which use this splitter (as standalone) issss.... MPC HC.. suuprise :). Windows Media Player and others players refuse to play m2ts tested file (can't connect with mpegsplitter). So we deal with bug here. (?)

[bebo]

To register u should paste this file into system32 directory (but not necessary), and register it, which means drag and drop over regsvr32.exe or choose start>> run>> regsvr32 mpegsplitter.ax :) U will see it in gspot as MPC - Mpeg Splitter (Gabest)

But... the only player which use this splitter (as standalone) issss.... MPC HC.. suuprise :). Windows Media Player and others players refuse to play m2ts tested file (can't connect with mpegsplitter). So we deal with bug here. (?)
Wow - huge downer litteD, but I its better to know I'm beating my head against a wall than to continue trying to make something happen that just ain't gonna...

I guess this means that for TrueHD streams I will have to drop out of my VMC integration project and fire up 'ol Arcsoft TMT using the file structure. A bit clunky when demo-ing the rig but seems like that's it for now.

So, I am out here on the fringe? Has nobody taken VMC player all the way to bright (full SD/HD A/V)? Hmmm...


....well I guess I must continue to bug Mike@haali to update the splitter to support MLP from .mt2s

[clsid]

You can use this registry tweak to force usage of the splitter.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.m2ts]
"Source Filter"="{1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}"

[bebo]

You can use this registry tweak to force usage of the splitter.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.m2ts]
"Source Filter"="{1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}"
...now you're talking! Let's use some reghack power!!

[Thunderbolt8]

It's not an inverse telecine (IVTC) filter! It's a "smart" deinterlacer and bobber (depending on the mode selected).

IMHO it's currently one of the best (if not the best) real-time bobber. Some super-slow bobbers interpolate nicer, but they can't work at real-time on an affordable machine ;)

http://guru.multimedia.cx/deinterlacing-filters/



Nope, I allowed four threads for the "ffdshow r2335 ICL" build, just to be sure. Does that setting apply to the H.264 decoder at all in "current" ffdshow?

Still the overall CPU load was around 30-40%. Using ffdshow-mt and allowing four threads results in ~100% CPU usage, all cores at full load.

That once again proves the ineffectiveness of the "old" multi-threading method. Well, it was better than nothing, back at the time when it was added.
im not familiar with the terms of deinterlacing like bob or real time interlace, interpolace etc.
im just concerned with the quality. ive so far used the ffmpeg deinterlacer, because I felt it has provided the best quality so far. what about yadif is that respect, does he provide a comparable quality as well, or is it primarily only a fast deinterlacer?

[STaRGaZeR]

im not familiar with the terms of deinterlacing like bob or real time interlace, interpolace etc.
im just concerned with the quality. ive so far used the ffmpeg deinterlacer, because I felt it has provided the best quality so far. what about yadif is that respect, does he provide a comparable quality as well, or is it primarily only a fast deinterlacer?

Do you want the best quality? Use hardware deinterlacing if you can. It also has near 0% (if not 0%) CPU usage increment. Yadif is nice, but is a resource hog and in certain scenarios like anime for example the results are far from good.

[tal.aloni]

But... the only player which use this splitter (as standalone) issss.... MPC HC.. suuprise :).

Wrong, I use MPC mpeg splitter with TCMP successfully.
(you have to disable haali mpeg splitter, uninstall and reinstall if needed), also, restart was also required in my case after I registered MpegSplitter.ax. (I can't explain this)
I can also use it with graph edit.

[Thunderbolt8]

Do you want the best quality? Use hardware deinterlacing if you can. It also has near 0% (if not 0%) CPU usage increment. Yadif is nice, but is a resource hog and in certain scenarios like anime for example the results are far from good.
I only have a gefore 7600gt, can I use it? if so, how to enable hardware deinterlacing in ffdshow? I only know about this deinterlacing box, but apparently all those deinterlacing options are for software/cpu deinterlacing

[ikarad]

im not familiar with the terms of deinterlacing like bob or real time interlace, interpolace etc.
im just concerned with the quality. ive so far used the ffmpeg deinterlacer, because I felt it has provided the best quality so far. what about yadif is that respect, does he provide a comparable quality as well, or is it primarily only a fast deinterlacer?

if you want the quality, use Inverse telecine filter like telecide.

[jos99]

Yes, the multi-threading method used in ffdshow-mt is more efficient than the "old" one, even on two cores.
The old method, as currently used in ffdshow, was pretty inefficient and hence never made it into the official ffmpeg repository.
But ffdshow-mt only uses the multi-threaded H.264 decoder from ffmpge-mt. Other decoders are not multi-threaded yet.
And there are still display errors in some videos with ffdshow-mt (see post above).
OK, I just updated from 2307 to 2333 mt as I saw the resource leak was fixed and ffdshow h.264 decoder wouldn't load for h.264 TV on DVBviewer.:scared: ....on the plus side I have been able to test out the latest version of standard ffshow 2338 and, guess what it is giving me slightly lower usage on 1080i h.264 channels - about 3-4% less with VMR9, even less usage with EVR (using 64x2 5000+ XPSP3).

[STaRGaZeR]

I only have a gefore 7600gt, can I use it? if so, how to enable hardware deinterlacing in ffdshow? I only know about this deinterlacing box, but apparently all those deinterlacing options are for software/cpu deinterlacing

It has been a long time since I used a NV card, so I'll tell you the basics, it may work or not in that card. Or maybe not work as desired. In the output section of ffdshow check the "Set interlace flag in output media type", the two options to "Auto". "Force bob" means force deinterlacing always, "Force weave" is the same as no deinterlacing. Try with your current config, and if it doesn't work uncheck everything except NV12 as output colorspaces. Look for interlacing options in the NV control panel and enable them. VMR9 is not recommended as it's famous for displaying the field order incorrectly, however it may work. If nothing works, play with the different options :p

HW deinterlacing is like DXVA, very susceptible, but it produces wonderful quality.

[haruhiko_yamagata]

ps. with the new yadif deinterlacer, seems i found a problem with interlaced mp4/avc files it crashes mpc when enabledPlease recompile libmplayer.dll using GCC 4.2.x. Yadif uses SSE2/SSSE3, which produced surprising performance boost (195% on Core 2). GCC 4.0.x cannot align stack properly.

[roozhou]

Please recompile libmplayer.dll using GCC 4.2.x. Yadif uses SSE2/SSSE3, which produced surprising performance boost (195% on Core 2). GCC 4.0.x cannot align stack properly.

It is not true. In my test SSSE3 is at most 30% faster than original MMX2 on Core 2.

[_xxl]

GCC 4.0.x cannot align stack properly.Version below MINGW GCC 4.2.x should be banned from ffdshow.

[haruhiko_yamagata]

It is not true. In my test SSSE3 is at most 30% faster than original MMX2 on Core 2.
Then I calculated badly. But it's at least 160% faster.
Please remember to subtract decoding time.

rev2303:MMX-EXT
rev2307:SSSE3
rev2333:SSSE3 + 4 threads

On Core2 Quad,

MPEG-2 1080i, libmpeg2 yadif disabled
ffdshow_rev2333_20081117-mt.exe:User: 7s, kernel: 0s, total: 7s, real: 8s, fps: 158.8, dfps: 153.2 6.53ms/frame 0.00ms/yadif

Same file, yadif double frame rate
ffdshow_rev2303_20081106-mt.exe:User: 41s, kernel: 0s, total: 41s, real: 42s, fps: 29.2, dfps: 29.2 34.25ms/frame 27.72ms/yadif -> 100%
ffdshow_rev2307_20081107-mt.exe:User: 28s, kernel: 0s, total: 29s, real: 29s, fps: 42.3, dfps: 42.3 23.64ms/frame 17.11ms/yadif -> 162%
ffdshow_rev2333_20081117-mt.exe:User: 11s, kernel: 0s, total: 11s, real: 18s, fps: 109.3, dfps: 65.6 15.24ms/frame 8.71ms/yadif -> 318%

[_xxl]

@ all ffdshow-tryout developers
I would like to remove from ffdshow's code MSVC7.1, MSVC8 project files, because there are to many and some buggy.

[haruhiko_yamagata]

strcpy_s and some other secure string manipulation functions were added to the CRT at MSVC8.

http://msdn.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx
(http://msdn.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx)
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/coding/317-BSI.html

My next patch will use those functions. I also wrote an alternative functions so that we can do without completely dropping MSVC7.1. However MSVC7.1 is not the recommended compiler. Of course the official CRT is better than my code.
ICL9 and MinGW 4.0.x may be dropped at the same time. Supporting 6 compilers is a mess.
If some of the developers have only MSVC8, it is possible to continue supporting.

[haruhiko_yamagata]

Screenshots from the Freedom series Blu-ray (AVC), EP1, using ffdshow-mt svn 2333:

noticed the other rainbows I had with 'Babel' are gone already with svn2333, but these here are still there, while gone with normal ffdshow

uploaded a 95mb remuxed video sample here: http://www.sendspace.com/file/bipcaq
Thank you. I have sent a mail to the developer.

[Leak]

ICL9 and MinGW 4.0.x may be dropped at the same time. Supporting 6 compilers is a mess.
If some of the developers have only MSVC8, it is possible to continue supporting.
Well, I'm using MSVC8 but I guess I could give VS2008 a try.

But honestly I'd keep the MinGW only build, if only to be able to build ffdshow with 100% free tools...

[fastplayer]

But honestly I'd keep the MinGW only build, if only to be able to build ffdshow with 100% free tools...
So it's not possible to build with the free Visual C++ Express Edition (http://www.microsoft.com/express/vc/)?

[haruhiko_yamagata]

Do you want the best quality? Use hardware deinterlacing if you can. It also has near 0% (if not 0%) CPU usage increment. Yadif is nice, but is a resource hog and in certain scenarios like anime for example the results are far from good.I don't know anime, but are there many interlaced anime?
Yadif does better job than my nvidia 7900GS, if double frame rate is enabled. It's much better for sports.
You just need a better CPU. Buy quad core to play H.264 1080i @ 50fps :sly:.

[haruhiko_yamagata]

So it's not possible to build with the free Visual C++ Express Edition (http://www.microsoft.com/express/vc/)?I don't know. Anyone succeeded?

[haruhiko_yamagata]

if you want the quality, use Inverse telecine filter like telecide.IVTC cannot be used for deinterlacing.
This filter acts on telecined progressive source and attempts to recreate progressive frames. (http://neuron2.net/telecide.html)

[Leak]

So it's not possible to build with the free Visual C++ Express Edition (http://www.microsoft.com/express/vc/)?
Errr... last I checked the Express Editions were free as in beer, not free as in speech...

And you really need MinGW anyway to build a version of ffdshow that doesn't crawl, speedwise.

np: B. Fleischmann - Phones And Machines (The Humbucking Coil)

[haruhiko_yamagata]

And you really need MinGW anyway to build a version of ffdshow that doesn't crawl, speedwise.
Do you mean MinGW creates a fast build?
MinGW 4.0.x cannot compile properly for SSE2. ICL10 does better job in that regard, though it's expensive.

[Leak]

Do you mean MinGW creates a fast build?
MinGW 4.0.x cannot compile properly for SSE2. ICL10 does better job in that regard, though it's expensive.
I was under the impression that several parts of ffdshow needed to be compiled with GCC to use any hand-optimized assembler code in them - did something change in that regard?

np: B. Fleischmann - Part Two (Tmp)

[haruhiko_yamagata]

I was under the impression that several parts of ffdshow needed to be compiled with GCC to use any hand-optimized assembler code in them - did something change in that regard?

np: B. Fleischmann - Part Two (Tmp)I'm talking about ffdshow.ax. I should have explained this earliear.
libavcodec, libmplayer, x264 and xvidcore have to be compiled by GCC 4.2.x or newer.

[Leak]

I'm talking about ffdshow.ax. I should have explained this earliear.
libavcodec, libmplayer, x264 and xvidcore have to be compiled by GCC 4.2.x or newer.
That's what I meant - you need GCC anyway, so why suddenly stop supporting it for compiling the main part?

np: B. Fleischmann - Waiting For You To Come (Welcome Tourist (Disc 1))

[STaRGaZeR]

I don't know anime, but are there many interlaced anime?
Yadif does better job than my nvidia 7900GS, if double frame rate is enabled. It's much better for sports.
You just need a better CPU. Buy quad core to play H.264 1080i @ 50fps :sly:.

Oh yes, lots of DVDs. And the recent Blu-ray releases have commercials that are interlaced.
I don't know about nvidia, but you should try ATI's vector adaptive deinterlacer. Then you will understand my fixation with it. The only situation where it has failed to produce perfect quality is in some F1 races, and in very very small areas unoticeable if you are 1 meter away from your screen. Yadif has too many artifacts (white and black dots) and some combing here and there in anime.
I don't need a faster CPU for now, mine can play H.264 1080i @ 60fps (35Mbps) with yadif enabled in double framerate mode :D

BTW the last ffdshow-mt changes don't solve the sample I sent to you.

[clsid]

There is no specific ICL9 project. All the ICL project files work with both ICL9/10. So no need to remove those.

I am using MSVC7.1 with the Windows Platform SDK 5.1. Shouldn't that support the safe string functions as well?

I prefer MSVC7.1 because it creates binaries that do not depend on those crappy MS runtimes. Perhaps we can statically link in that stuff? Then we could completely switch to VS2008.

[LoRd_MuldeR]

if you want the quality, use Inverse telecine filter like telecide.

Which is completely useless if your source isn't telecined but "true" interlaced :rolleyes:


I only have a gefore 7600gt, can I use it? if so, how to enable hardware deinterlacing in ffdshow? I only know about this deinterlacing box, but apparently all those deinterlacing options are for software/cpu deinterlacing

To enable Hardware Deinterlacing, check "Set interlaced flag in output media type". I also learned that it may be necessary to limit the output colorspace to NV12.
Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though...

I personally am not really satisfied with Hardware Deinterlacing. But you should give it a try and see if it works well for you or not.
Anyway, the "FFmpeg deinterlacer" is a very simple one. And it's a deinterlacer (25i -> 25p). For smooth motion I'd highly recommend to use a bobber (25i -> 50p).
My favorites quality-wise are: Yadif ("Double Framerate" mode), "Greedy 2 Frame" (available through DScaler plugin) and KernelBob (Threshold < 5).

[jos99]

To enable Hardware Deinterlacing, check "Set interlaced flag in output media type". I also learned that it may be necessary to limit the output colorspace to NV12.
Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though...

I personally am not really satisfied with Hardware Deinterlacing. But you should give it a try and see if it works well for you or not.

Thanks- setting to NV12 seems to allow hardware deinterlacing with my HD 3200 (780G) using Overlay, VMR7 and VMR9. This allows me to disable deinterlace and resize options in ffdshow and reduce usage from about 59% on 1080i 16.2Mbp/s h.264 TV (BBC HD) to 43-48% using 64x2 5000+ 2GB. I don't know if you saw my previous post but I am actually getting a reduction in CPU usage using normal ffdshow (2338) over ffdshow mt (2307-2333 didn't work for me)- can you explain this? Does it suggest my system is not using the dual cores correctly?

[Thunderbolt8]

Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though..
and here it goes already :S not getting rid of haali, it gives me the best PQ, more than any switch of deinterlacer. all other renderers cannot keep up with it.

[LoRd_MuldeR]

I don't know if you saw my previous post but I am actually getting a reduction in CPU usage using normal ffdshow (2338) over ffdshow mt (2307-2333 didn't work for me)- can you explain this?

Sure. In contrast to ffdshow-mt, the "normal" ffdshow uses an inefficient multi-threading method and hence won't be able to fully utilize your multi-core CPU.
Hence the reduced CPU usage along with reduced throughput (that is: worse performance).

Also I say it again: CPU usage alone doesn't say anything about performance. It's the actual throughput that matters!
So if you want to benchmark ffdshow vs. ffdhshow-mt on your local machine, download and use the timeCodec.exe (http://haali.cs.msu.ru/mkv/timeCodec.exe) tool and compare the "dfps" values.
Looking at the CPU load in taskman/procexp doesn't tell you much...


and here it goes already :S not getting rid of haali, it gives me the best PQ, more than any switch of deinterlacer. all other renderers cannot keep up with it.

As said before: I personally don't use Hardware Deinterlacing either. But for many people it's the way to go...

[bebo]

clsid:

Thanks for the tip on MpegSplitter.ax. I found MpegSplitter.ax in the standalone filters per your direction. Next I went into GSpot to change the merit of same. Odd thing though...could not see MpegSplitter.ax in GSpot's list of codecs and filters. Tried dropping file in other directories...nothing worked - still couldn't see it. So I couldn't change the merit to prioritize MpegSplitter.ax.




clsid - got you PM - thanks will try.
Clsid and littleD:

Success! Thanks to you both for helping me get out of the woods on the last part of this project. Dragged and dropped MpegSplitter.ax over regsvr32 and then changed the ID value for the .mt2s extension per clsid's tweak and voila! MLP track playing in bit perfect resolution. Thanks for staying with the problem to its solution.

Only problem I have now is for some reason I now cannot ffwd, rew, or change chapters. I get a black screen and everything stops with no recoevery. Not complaining though because I've really wanted to get to this point for so long that watching a movie without controls is a small consolation to deal with. Will work on that later, right now I just want to watch some movies...

Thanks again guys.

bebo

[Snowknight26]

Would I be correct in assuming that DTS Express can't be decoded by ffdshow because libavcodec cant (libdts too). If yes, any plans to add DTS Express decoding, even if it means bugging the ffmpeg team?

[BatKnight]

I've been thinking about one thing, and I would like to know your opinion.

Imagine the following scenario:
One owns an external DTS-ES/DD-EX decoder and every DTS or AC3 that plays on the HTPC is SPDIFed to this decoder and played correctly.
But when it comes to a TrueHD MLP file, ffdshow decodes the MLP and doesn't SPDIF it, so the audio must be AC3 encoded for the surround channels to be properly played. Otherwise it would have to be the external decoder to apply something like a DTS Neo:6 to have surround sound.

My question is: sound quality wise, which is better?
- ffdshow to be able to strip the AC3 stream from a TrueHD track and then directly SPDIF it to the external decoder to properly play surround?
- ffdshow to decode the TrueHD track and then ffdshow AC3 encodes (640kbps) the audio and SPDIFs it to the decoder?

My main doubt is whether the decoding of the MLP and the following AC3 encoding (even at 640) is more lossy than the direct strip of an AC3 stream inside the MLP track.

What are your opinions and expertise on this?

Thanks

Bat

[haruhiko_yamagata]

I am using MSVC7.1 with the Windows Platform SDK 5.1. Shouldn't that support the safe string functions as well?
I'm talking about this because MSVC7.1 doesn't support that safe functions.

[tal.aloni]

My question is: sound quality wise, which is better?


the best is getting an 6/8 ch PCM over HDMI cabable receiver.
If we must stay in the s/pdif realm, it would be wiser not to re-encode, but that's not always preferred. for example, my room demand some equalization, so I would prefer re-encoding, that way I could apply the necessary post-processing, most receivers are much more limited in that area.

[tal.aloni]

Would I be correct in assuming that DTS Express can't be decoded by ffdshow because libavcodec cant (libdts too).

pretty much, but I'm not so sure it would be a priority,
current decoding of DTS-MA / DTS-HD is limited to the core DTS track, so I'm guessing that those formats will have more focus than DTS express. but this is up to the ffmpeg developers.

[BatKnight]

the best is getting an 6/8 ch PCM over HDMI cabable receiver.
If we must stay in the s/pdif realm, it would be wiser not to re-encode, but that's not always preferred. for example, my room demand some equalization, so I would prefer re-encoding, that way I could apply the necessary post-processing, most receivers are much more limited in that area.
I understand, but considering the scenario where the external decoder isn't TrueHD or DTS-HD decoding capable, and if it is quaility-wiser not to reencode, then why isn't the option of stripping the AC3 part of a TrueHD track available?
I've tried with the TrueHD 5.1ch 48KHz.m2ts sample file and even with AC3 SPDIF pass-through selected, ffdshow still decodes the MLP.
I get the ffdshow audio decoder saying:

Input: 48000Hz, 6 channels mlp (livabcodec) and the Output Pin: Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps

I recall the ability to play the AC3 stream from this same file before the libavcodec branch was merged into the SVN trunk.
I am now using ffdshow-mt 2344, but the SVN ffdshow does the same.

Bat

[tal.aloni]

then why isn't the option of stripping the AC3 part of a TrueHD track available?

There is:
Disable the MLP decoder (and enable AC3 S/PDIF pass-through).

[haruhiko_yamagata]

That's what I meant - you need GCC anyway, so why suddenly stop supporting it for compiling the main part?Because it takes time to support GCC compilation. Besides I have to give up using any MSVC specific features.
Milan loved GNU so much, I have tried to respect it. However it's just hard.

[haruhiko_yamagata]

Perhaps we can statically link in that stuff? Then we could completely switch to VS2008.

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. For example, if you call _set_se_translator in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by code in the main executable will be caught.This was the rationale that I didn't want to link statically. Because I couldn't understand what it means.
Now I can understand, I think static link should be OK.

[haruhiko_yamagata]

OK, I just updated from 2307 to 2333 mt as I saw the resource leak was fixed and ffdshow h.264 decoder wouldn't load for h.264 TV on DVBviewer.:scared:There is no DVB in Japan. Can you reproduce it with off line file? I can play h264.ts file using DVBViewer (off line mode).

[ikarad]

Which is completely useless if your source isn't telecined but "true" interlaced :rolleyes:




To enable Hardware Deinterlacing, check "Set interlaced flag in output media type". I also learned that it may be necessary to limit the output colorspace to NV12.
Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though...

I personally am not really satisfied with Hardware Deinterlacing. But you should give it a try and see if it works well for you or not.
Anyway, the "FFmpeg deinterlacer" is a very simple one. And it's a deinterlacer (25i -> 25p). For smooth motion I'd highly recommend to use a bobber (25i -> 50p).
My favorites quality-wise are: Yadif ("Double Framerate" mode), "Greedy 2 Frame" (available through DScaler plugin) and KernelBob (Threshold < 5).

Most of sources are only telecined like anime.

[nm]

Most of sources are only telecined like anime.
Depends on where you live and what you watch. In PAL countries all TV broadcasts and DVD releases are basically either straight progressive (2:2 pulldown) or interlaced. Personally I only have some 3:2 telecine test clips around but I receive interlaced DVB every day.

[LoRd_MuldeR]

Most of sources are only telecined like anime.

That applies to NTSC countries and to cinema productions only! In PAL countries there's no such thing as "telecined" video ;)

In PAL countries you either get the movie as progressive (24p -> speed up -> 25p) or you get a crappy field blended conversion (24p -> telecine -> NTSC -> field blend -> PAL).

Also TV productions will always be "true" interlaced, 60 fields/second in NTSC countries or 50 fields/second in PAL countries...

[clsid]

@xxl, haruhiko,

I have installed VS2008SP1. Static linking seems to work ok. I am uploading a build to sf.net now so everyone can test. It also includes Haruhiko's recent safe string patch.

Once all vs2008 project files have been updated for static mfc linking, we could completely switch to supporting just vs2008. I think we are then all using vs2008? If so, all vs2003/2005 project files can be removed.

[jos99]

There is no DVB in Japan. Can you reproduce it with off line file? I can play h264.ts file using DVBViewer (off line mode).
Sorry for not being more specific- it wasn't just TV, it wouldn't load for any h.264 file- just gave a black screen and ffdshow didn't show up in the filters in use. Maybe I selected something wrong in the setup?

[_xxl]

Once all vs2008 project files have been updated for static mfc linking, we could completely switch to supporting just vs2008. I think we are then all using vs2008? If so, all vs2003/2005 project files can be removed.
Ok, when ready please remove them.

[fastplayer]

I am uploading a build to sf.net now so everyone can test. It also includes Haruhiko's recent safe string patch.
You just uploaded build 2347, yet 2348 contains the new goodies. Am I missing something? :confused:

[clsid]

The build includes the goodies (some of which are not comitted yet).

[Reimar]

Then I calculated badly. But it's at least 160% faster.
[...]
Same file, yadif double frame rate
ffdshow_rev2303_20081106-mt.exe:User: 41s, kernel: 0s, total: 41s, real: 42s, fps: 29.2, dfps: 29.2 34.25ms/frame 27.72ms/yadif -> 100%
ffdshow_rev2307_20081107-mt.exe:User: 28s, kernel: 0s, total: 29s, real: 29s, fps: 42.3, dfps: 42.3 23.64ms/frame 17.11ms/yadif -> 162%


Going by this SSE speed is 162% the original speed, but that is the same as being 62 % faster, 162 % faster would be more than double speed!

[tal.aloni]

_xxl, great work!
I'm very happy with ffdshow-mt,
finally there's a free and stable alternative for H.264 decoding.

Tal

[CruNcher]

though stability compared to commercial decoder seems still low i sometimes lose up to 4 frames of the original source input (beginning,end) :( in different rendering scenarios (AVC,ASP,Mpeg-2), also frame exact seeking is still bad too. Using the same Splitter Haali's for all of them ffdshow always loses frames or endsup @ the wrong frame when for example requesting a b-frame compared to CoreAVC,DivX,Elecard,Cyberlink,Arcsoft,Nero :( I lost hope that the Libavcodec guys gonna ever improve that but i wonder if it can't be done via a workaround over dshow forceing it somehow.

[LoRd_MuldeR]

though stability compared to commercial decoder seems still low i sometimes lose up to 4 frames of the original source input (beginning,end) :( in different rendering scenarios (AVC,ASP,Mpeg-2), also frame exact seeking is still bad too. Using the same Splitter Haali's for all of them ffdshow always loses frames or endsup @ the wrong frame when for example requesting a b-frame compared to CoreAVC,DivX,Elecard,Cyberlink,Arcsoft,Nero :( Tough i guess the Libavcodec guys never gonna improve that but i wonder if it can't be done via a workaround over dshow :(

Why not use DGAVCSource when you need frame accurate-access? That will be required for editing only anyways, for pure playback it doesn't matter...

[CruNcher]

Easy answer DGAVCSource isn't dshow it would make the transcoding framework unnecessarily complex switching stuff based on input, frame accurate access is for example important capturing frames :(

[clsid]

It is still unfinished code so issues are to be expected.

[BatKnight]

There is:
Disable the MLP decoder (and enable AC3 S/PDIF pass-through).
OK, sorry. My bad.

But something still bugs me. When playing the "TrueHD 7.1ch 96KHz.m2ts" file with MLP disabled and AC3 pass-through enabled it states the following:

Input: 48000Hz, 6 channels 640 kbps ac3 (liba52).

My question is: why is it stripping only 6 channels, if the file is 7.1 and with MLP decoding it says 8 channels?
Thanks

Bat

[Snowknight26]

The AC3 'core' is only 5.1.

[haruhiko_yamagata]

@xxl, haruhiko,

I have installed VS2008SP1. Static linking seems to work ok. I am uploading a build to sf.net now so everyone can test. It also includes Haruhiko's recent safe string patch.

Once all vs2008 project files have been updated for static mfc linking, we could completely switch to supporting just vs2008. I think we are then all using vs2008? If so, all vs2003/2005 project files can be removed.OK, we are working on it.
By the way, what setting did you use to pack the installer? May be you have forced "VS2003SP1" which should be correct for now.
Could you update the installer for static link?
Perhaps we can omit packing msvcr71.dll.

[Snowknight26]

When installing ffdshow, the shortcut for the VFW config doesn't work because apparently there is no entry point named configureVFW.

[haruhiko_yamagata]

When installing ffdshow, the shortcut for the VFW config doesn't work because apparently there is no entry point named configureVFW.It works for me. Did you check "VFW interface" on installation? Which build are you using?

[Snowknight26]

Yes I did. Tried albian's latest build (ffdshow_rev2340_20081121_dbt.exe) and an earlier one from xvidvideo.ru.
Probably irrelevant, but it works on my Vista x64 box, but not on my Server 03 x64 one.

[haruhiko_yamagata]

Yes I did. Tried albian's latest build (ffdshow_rev2340_20081121_dbt.exe) and an earlier one from xvidvideo.ru.
Probably irrelevant, but it works on my Vista x64 box, but not on my Server 03 x64 one.Well, I don't have Server 03 x64.
Probably it's a bug of Server 2003. It is likely that it has problem in loading msvcr90.dll for a dll installed in the system32 directory.
Please let us know if it works after we have finished static link stuff.

[clsid]

The builds from xvidvideo.ru might have the runtime detection disabled. That means that the installer won't prompt you if you haven't got the required runtimes installed. But that would also mean that ffdshow audio/video won't work either. Static linking is going to solve the entire runtime issue, as those won;t be required anymore.

@Haruhiko,
I will update the install script once all project files are updated. I will do that later this week. I think that the manifest files (those runtime assembly related ones) are also no longer needed. So things will clean up nicely.

According to xxl, only the ffavisynth plugin won't link statically. Perhaps you could take a look at that one if you have some time.

[haruhiko_yamagata]

Thanks. I've sent a PM to xxl.

[alexins]

The builds from xvidvideo.ru might have the runtime detection disabled.
In my assemblings always runtime detection in the position enabled (#define VS2008SP1 = True)

[haruhiko_yamagata]

Thanks, but does the runtime detection work on 2003 server?
Anyway, we will move to static link, it will solve the CRT problem if it works.

[cca]

I would like to test the ffdshow-MT, but no build from xvidvideo.ru works, the audio part seems to load, but the video part of ffdshow cannot connect with the splitter. Normal ffdshow worked and works as intended. What am I missing?

[haruhiko_yamagata]

I would like to test the ffdshow-MT, but no build from xvidvideo.ru works, the audio part seems to load, but the video part of ffdshow cannot connect with the splitter. Normal ffdshow worked and works as intended. What am I missing?Which splitter is used?
Is the video H.264?

[albain]

OK, sorry. My bad.

But something still bugs me. When playing the "TrueHD 7.1ch 96KHz.m2ts" file with MLP disabled and AC3 pass-through enabled it states the following:

Input: 48000Hz, 6 channels 640 kbps ac3 (liba52).

My question is: why is it stripping only 6 channels, if the file is 7.1 and with MLP decoding it says 8 channels?
Thanks

Bat


If you send the AC3 core directly to SPDIF it will surely be better quality than decoding MLP and reencoding it to AC3.

However, if you decode MLP and sending the (raw) stream directly to your speakers, it will have the best quality.

[albain]

Just a thought, I don't know how complicated it is :

if ffmpeg team doesn't plan to merge ffmpeg-mt into their main trunk soon, why not creating a separate dll (ie libavcodec-mt.dll) next to libavcodec.dll and load from it only the MT decoders (h264 for now) ?
Then FFDShow should have the ability to load one or the other depending on the input format.

[albain]

OK, sorry. My bad.

But something still bugs me. When playing the "TrueHD 7.1ch 96KHz.m2ts" file with MLP disabled and AC3 pass-through enabled it states the following:

Input: 48000Hz, 6 channels 640 kbps ac3 (liba52).

My question is: why is it stripping only 6 channels, if the file is 7.1 and with MLP decoding it says 8 channels?
Thanks

Bat


If you send the AC3 core directly to SPDIF it will surely be better quality than decoding MLP and reencoding it to AC3.

Like said before, AC3 is limited in channels (5+1) and in bitrate.
MLP has more channels and higher bitrate, so better quality.

So if you decode MLP and send the (raw) stream directly to your speakers, it will have the best quality.

[cca]

Which splitter is used?
Is the video H.264?

Both XviD and H264. So it is the standard AVI splitter for XviD and Haali splitter for H264. None work with ffdshow-MT, but work with no problem with normal ffshow. I already have installed the VS 2005 and 2008 redist packages. Does ffshow-MT require any other runtimes?

EDIT: It seems the problem is libavcodec itself. DVD playback using libmpeg2 and XVID playback with xvidcore.dll works. Anything that uses libavcodec just doesn't work. Also, in version details there is nothing displayed for libavcodec.dll, while version numbers are displayed for the rest of the libraries. Either it is not correctly compiled, or some dependecy is missing.

[Reino]

I'm using rev.2322 (13NOV2008) and I'm having some problems with ASS-subtitles. I believe this due to rev.2270.
Revision 2270 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2270) - Directory Listing (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/?pathrev=2270)
Modified Fri Oct 31 09:52:42 2008 UTC (3 weeks, 3 days ago) by albain

Improvements of SSA subtitles : collisions, position, move, layers
Added a new dialog box for overriding some SSA settings

Around a month ago I made a tutorial movie (ASS subtitle encoded on top of the video stream!)

Rendered with FFDShow rev.2322: (no settings were enabled under the "ASS/SSA config"-button)
http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.th.png (http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.png)

Rendered with FFDShow rev.2054: (older version on my laptop)
http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.th.png (http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.png)

The actual subtitle line in the ass-file:
Dialogue: 0,0:02:48.48,0:02:55.52,Default,,0000,0000,0000,,{\pos(320,453)}You can find Avisynth
at {\c&H00FFFF&}http://avisynth.org{\c} and\Nclick the download-link in the upper left corner.
As you can see, the only break ("\N") comes after "and".
I haven't changed any settings compared to the older revision, so I'm wondering why FFDShow shows this behaviour.
Can this be fixed?

[haruhiko_yamagata]

Just a thought, I don't know how complicated it is :

if ffmpeg team doesn't plan to merge ffmpeg-mt into their main trunk soon, why not creating a separate dll (ie libavcodec-mt.dll) next to libavcodec.dll and load from it only the MT decoders (h264 for now) ?
Then FFDShow should have the ability to load one or the other depending on the input format.
If ffmpeg-mt is finished and ffmpeg still does not merge it, it will be the choice.
I think it's not time for it at this moment.

[haruhiko_yamagata]

Both XviD and H264. So it is the standard AVI splitter for XviD and Haali splitter for H264. None work with ffdshow-MT, but work with no problem with normal ffshow. I already have installed the VS 2005 and 2008 redist packages. Does ffshow-MT require any other runtimes?

EDIT: It seems the problem is libavcodec itself. DVD playback using libmpeg2 and XVID playback with xvidcore.dll works. Anything that uses libavcodec just doesn't work. Also, in version details there is nothing displayed for libavcodec.dll, while version numbers are displayed for the rest of the libraries. Either it is not correctly compiled, or some dependecy is missing.
pthreadGC2.dll. Where is it in your hard drive?
Are you using Vista x64?

[cca]

pthreadGC2.dll. Where is it in your hard drive?
Are you using Vista x64?

I do not seem to have such a file. I do use Vista x64, but I use x86 player and ffdshow.

EDIT: Thanks to haruhiko-san I found pthreadGC2.dll from ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/ and move it to C:\Windows\SysWOW64. Now finally ffdshow-MT works! This file should be included with the setup, or at least some link to obtain it.

[alexins]

I do not seem to have such a file. I do use Vista x64, but I use x86 player and ffdshow.

EDIT: Thanks to haruhiko-san I found pthreadGC2.dll from ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/ and move it to C:\Windows\SysWOW64. Now finally ffdshow-MT works! This file should be included with the setup, or at least some link to obtain it.
The file of pthreadGC2.dll automatically is added during the installation of ffdshow-mt.

[haruhiko_yamagata]

I do not seem to have such a file. I do use Vista x64, but I use x86 player and ffdshow.

EDIT: Thanks to haruhiko-san I found pthreadGC2.dll from ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/ and move it to C:\Windows\SysWOW64. Now finally ffdshow-MT works! This file should be included with the setup, or at least some link to obtain it.OK, I have fixed the installer.

[_xxl]

Isn't possible to get rid of pthreadGC2.dll ?

[cca]

The file of pthreadGC2.dll automatically is added during the installation of ffdshow-mt.

Unfortunately, it is not. Perhaps something related to Vista 64? Anyway, haruhiko-san says he fixed the installer, we should know with the next build.

Edit: from the changelog: "ffmpeg-mt branch: update installer If vfw was not checked, pthreadGC2.dll was not installed."
Indeed, I never check this box, I do not need vfw functionality, and it triggered the problem!

[haruhiko_yamagata]

Isn't possible to get rid of pthreadGC2.dll ?
Porting pthread.c to Win32 API would take a week or more.

[Snowknight26]

Thanks, but does the runtime detection work on 2003 server?
Yes it does. I was prompted to install a C++ redistributable the first time I tried to install ffdshow from xvidvideo.ru after a fresh install of Server 2003.

[clsid]

I am having trouble getting static linking to work properly with the VS2008 ICL project files :(

Are VS2008 builds compatible with win9x?

[_xxl]

Are VS2008 builds compatible with win9x?
Win98 shouldn't be supported anymore.

[Px]

I am having trouble getting static linking to work properly with the VS2008 ICL project files :(

Are VS2008 builds compatible with win9x?
No, for Win98 support use VS2005 or VS2003

[BatKnight]

@tal.aloni

I've noticed that it might exist a cosmetic bug at the information that ffdshow audio decode shows.
Playing a DTS-ES 6.1 WAV file it should identify it as 7 channels but it shows like this:

libdts: 44100 Hz, 6 channels 1411 kbps dts (libdts)
libavcodec: 44100 Hz, 6 channels dts (libavcodec)

Another example:
- Playing WALL-E.1080p.BluRay.x264-HD1080.mkv which has a 6.1 DTS-ES Matrix track, ffdshow says on the input: 48000Hz 6 channels 1536 kbps (libdts). I can confirm it's a 6.1 track because I'm passing-it-trough via SPDIF and my external decoders tells me so.

I'm bringing this up because when decoding a 7.1 MLP file with libavcodec, for example, it correclty passes the information as 96000Hz, 8 channels mlp (libavcodec)

This bug also happens on 6.1 and 7.1 AC3 files and 7.1 DTS. It always shows only 6 channels.
Why doesn't fddshow always shows 6 channels for 5.1; 7 channels for 6.1 tracks and 8 channels for 7.1 tracks?

I am using ffdshow-mt 2351 build, but I've always noticed this since the times of the libavcodec branch development.

Bat

[clsid]

No, for Win98 support use VS2005 or VS2003
Well, the idea was to eventually remove support for VS2003/VS2005.

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.

[avivahl]

I'm using rev.2322 (13NOV2008) and I'm having some problems with ASS-subtitles. I believe this due to rev.2270.


Around a month ago I made a tutorial movie (ASS subtitle encoded on top of the video stream!)

Rendered with FFDShow rev.2322: (no settings were enabled under the "ASS/SSA config"-button)
http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.th.png (http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.png)

Rendered with FFDShow rev.2054: (older version on my laptop)
http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.th.png (http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.png)

The actual subtitle line in the ass-file:
Dialogue: 0,0:02:48.48,0:02:55.52,Default,,0000,0000,0000,,{\pos(320,453)}You can find Avisynth
at {\c&H00FFFF&}http://avisynth.org{\c} and\Nclick the download-link in the upper left corner.
As you can see, the only break ("\N") comes after "and".
I haven't changed any settings compared to the older revision, so I'm wondering why FFDShow shows this behaviour.
Can this be fixed?
Maybe you have "Split long subtitle lines" checked? (under Subtitles->Text)
EDIT: Oh, I didn't notice the text shows up twice on the newer ffdshow. Looks like a bug.

[Px]

Well, the idea was to eventually remove support for VS2003/VS2005.

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.
Maybe, some final "stable" (not beta) build for Win98/ME? :)

[haruhiko_yamagata]

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.
Agreed.

[jamos]

With the latest beta build I can enable VC-1 video for the encoder but when loaded the video is distorted. In windows xp 32bit I do not get this issue with same build. Any clue on why in Vista 64 bit os it would be a problem?

using megui with FFdshow


thanks...

n/m Haali Media Splitter 1.7.401.3 works good in vista 64 with VC-1 files..Ill use that instead of FFdShow

[tal.aloni]

BatKnight, 6.1 AC3 and DTS show only 6 channels because that's what's being decoded.
the additional channels of DD Matrix / DTS-ES are not supported by ffdshow decoders.

[BatKnight]

BatKnight, 6.1 AC3 and DTS show only 6 channels because that's what's being decoded.
the additional channels of DD Matrix / DTS-ES are not supported by ffdshow decoders.
I see, so you mean that when Pass-through is selected the info provided by the ffdshow decoder is to be discarded, because there is no ffdshow internal decoding?
Wouldn't it be more accurate to present the info of the audio being passed-through? Because imagine this: if one wouldn't have an external decoder to provide the information of being a 6.1 track how would it be possible to know what is being passed-through via SPDIF if ffdshow shows the info as if it was itself decoding it?

Thanks in advance

Bat

[lych_necross]

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.

I agree whole heartily. There is no need to support OSes that are approx. 10+ years old. In fact, removing support for Win9x based OSes will simplify the coding process and probably increase stability.

[tal.aloni]

I see, so you mean that when Pass-through is selected the info provided by the ffdshow decoder is to be discarded, because there is no ffdshow internal decoding?

True.


Wouldn't it be more accurate to present the info of the audio being passed-through?
but then you'll have to parse the audio, this is an unnecessary overhead. and even then, you'll have to recognize the track as 6.1, and since current decoders does not support it, you'll have to code you're own routine. this is too much work just for cosmetics.

[haruhiko_yamagata]

Good news,
Binary files of pthread libray for x64 is now online.
https://sourceforge.net/projects/mingw-w64/
Now I can build ffmpeg-mt branch for x64.

[Mercury_22]

Good news,
Binary files of pthread libray for x64 is now online.
https://sourceforge.net/projects/mingw-w64/
Now I can build ffmpeg-mt branch for x64.

FINALLY ! :thanks: I can't wait ! :helpful:

[KoD]

Bug report regarding wrong channel mapping when using libavcodec for DTS decoding:

1. one needs a file with multiple audio tracks, where the default audio track is DTS (like [CCCP]_Manhole_Test_Your_5.1_[revamped].mkv from here (http://www.cccp-project.net/beta/index.php?dir=test_files/), with a 5.1 DTS default audio track)
2. using Haali's splitter for splitting mkv
3. ffdshow audio configured to use libavcodec for dts decoding
4. doesn't matter if the mixer in ffdshow is enabled or not
5. the 5.1 dts audio track is played with wrong channel order: L is played on C, R is played on L, etc..

This doesn't happen if libdts is used instead of libavcodec.

Behavior experienced on ffdshow r2335, clsid's ICL10 build, ZoomPlayer 6 used as player.

[clsid]

DTS channel order was fixed at rev. 2340.

[Thunderbolt8]

So if you want to benchmark ffdshow vs. ffdhshow-mt on your local machine, download and use the timeCodec.exe (http://haali.cs.msu.ru/mkv/timeCodec.exe) tool and compare the "dfps" values.
is it possible to include the haali renderer there?

[haruhiko_yamagata]

FINALLY ! :thanks: I can't wait ! :helpful:
Well, can compile does not mean works stable...
But it's a step anyway.

[LoRd_MuldeR]

is it possible to include the haali renderer there?

Nope. Only VRM7, VMR9, Overlay Mixer and Old Renderer.

But the benchmark has to be done with the "Null" renderer anyways, since we won't to benchmark ffdshow and not a certain renderer ;)

If at all, the renderer would bottleneck the frame flow and distort your results...

[CruNcher]

im not sure if dfps is either a good measurement for null i guess real rendering time is the most efficient normal fps can also be funny with some decoder showing you 1000 of frames rendered which is impossible for the real render time :D :)
from my experience real rendering time never lies especialy when you compare very close results (CoreAVC,DivX) and can be nicely compared with mplayer -benchmark :)

[alexins]

Well, can compile does not mean works stable...
But it's a step anyway.

ffdshow-MT x64, libavcodec.dll compile without error, but does not work.

[Atak_Snajpera]

libavcodec can not decode this .mkv (vc-1) it works only when wmv9 is selected. Can I ask somebody to inform ffmpeg team about this.
http://www.mediafire.com/?ytesbxetzk4

[KoD]

DTS channel order was fixed at rev. 2340.

Thank you for the notice.

[haruhiko_yamagata]

libavcodec can not decode this .mkv (vc-1) it works only when wmv9 is selected. Can I ask somebody to inform ffmpeg team about this.
http://www.mediafire.com/?ytesbxetzk4I can tell you that ffplay does not play the file. Please submit a report directly.

[roozhou]

Then I calculated badly. But it's at least 160% faster.
Please remember to subtract decoding time.

rev2303:MMX-EXT
rev2307:SSSE3
rev2333:SSSE3 + 4 threads

On Core2 Quad,

MPEG-2 1080i, libmpeg2 yadif disabled
ffdshow_rev2333_20081117-mt.exe:User: 7s, kernel: 0s, total: 7s, real: 8s, fps: 158.8, dfps: 153.2 6.53ms/frame 0.00ms/yadif

Same file, yadif double frame rate
ffdshow_rev2303_20081106-mt.exe:User: 41s, kernel: 0s, total: 41s, real: 42s, fps: 29.2, dfps: 29.2 34.25ms/frame 27.72ms/yadif -> 100%
ffdshow_rev2307_20081107-mt.exe:User: 28s, kernel: 0s, total: 29s, real: 29s, fps: 42.3, dfps: 42.3 23.64ms/frame 17.11ms/yadif -> 162%
ffdshow_rev2333_20081117-mt.exe:User: 11s, kernel: 0s, total: 11s, real: 18s, fps: 109.3, dfps: 65.6 15.24ms/frame 8.71ms/yadif -> 318%

Well it is 60% faster, not 160%.

I tested it under mplayer and it should be more accurate.

E2160 1.8G
MPEG2 1440x1080i

w/o yadif:
mplayer -vc mpeg12 -vo null -nosound -benchmark -quiet -noaspect test.m2t

BENCHMARKs: VC: 2.747s VO: 0.000s A: 0.000s Sys: 0.376s = 3.123s

w/ yadif double-framerate:
mplayer -vc mpeg12 -vo null -nosound -benchmark -quiet -noaspect -vf yadif=1:0 test.m2t

MMX2:
BENCHMARKs: VC: 2.718s VO: 12.080s A: 0.000s Sys: 0.354s = 15.152s

SSSE3:
BENCHMARKs: VC: 2.726s VO: 9.465s A: 0.000s Sys: 0.498s = 12.689s

[haruhiko_yamagata]

I tested it under mplayer and it should be more accurate.
SSE2/SSSE3 optimization and multithreading of yadif are ffdshow original, mplayer does not have these code.
Your test is pointless.

[roozhou]

SSE2/SSSE3 optimization and multithreading of yadif are ffdshow original, mplayer does not have these code.
Your test is pointless.

I ported the SSE2/SSSE3 codes back and compiled mplayer myself.

You should test with the same svn build. Maybe the 60% speedup contains benefits from other optimization than SSSE3 of yadif.

And on AMD CPUs earlier than Phenom, MMX2 may be faster than SSE2. Hope you can test it on those AMD CPUs.

[haruhiko_yamagata]

I ported the SSE2/SSSE3 codes back and compiled mplayer myself.

You should test with the same svn build. Maybe the 60% speedup contains benefits from other optimization than SSSE3 of yadif.No, it's 60% faster on Core 2 Quad without multithreading or other optimization.
I don't know why it is only 27% faster for you.

And on AMD CPUs earlier than Phenom, MMX2 may be faster than SSE2. Hope you can test it on those AMD CPUs.I'm not interested in it.

Please don't reply to this post. Stop here.

[TheShadowRunner]

Hi All, I just attempted to upgrade to CLSID's latest icl10 build. I'm prompted to install "Microsoft Visual C++ 2008 SP1 Redistributable Package". I just would like to know if after installation it's safe to delete Microsoft Visual C++ 2005 Redistributable Package ? (ie, is the 2008 version going to replace the 2005 files or are these different files and I should keep 2005 too?)
Thanks for the info.

TSR

[fastplayer]

^Keep the 2005 redist, you never know what app might need em. The Redist files are installed side-by-side and don't overwrite anything.

[TheShadowRunner]

Exactly what i wanted to know, thanks.

[KoD]

I've also just attempted to upgrade to CLSID's latest icl10 build, and although I've got VS2008SP1 installed, I get the "MSVCR90.dll was not found" error message when trying to use ffdshow. Has someone tinkered with the manifest files ?

[LoRd_MuldeR]

Same problem here:

http://img155.imageshack.us/img155/59/ffdsinstallererrorym7.png

[TheShadowRunner]

Confirmed, same MSVCR90.dll error. XP SP3 with the "Microsoft Visual C++ 2008 SP1 Redistributable Package" installed.

Edit, contrary to LoRd, install went fine. It's upon using the codec that I'm getting the "MSVCR90.dll was not found" error.
Moving the dll to the ffdshow folder doesn't help either.

[fastplayer]

Has someone tinkered with the manifest files ?
AFAIK, they've been removed. Static linking is not 100% finished yet, too.

[KoD]

I didn't know it's possible not to use manifest files with these v7+ dlls from Microsoft. Usually the manifest files are loaded as a resource in the executable, though.

I've even tried editing the external manifest file, still no luck. Going back to an older version now.

Maybe this will help the developers: Why your application fails to load after building with a new version of VS? (http://blogs.msdn.com/vcblog/archive/2007/07/02/why-your-application-fails-to-load-after-building-with-a-new-version-of-vs.aspx).

[clsid]

A new ICL build will be online shortly. That will be linked statically. I have finished updating all project files.

Edit: build is online

[TheShadowRunner]

Thanks CLSID, installing now.

Edit: all good, works fine here, install and usage.

[LoRd_MuldeR]

Thanks CLSID, installing now.

Edit: all good, works fine here, install and usage.

Yup, works fine now :)

[clsid]

It would be interesting to see a benchmark between this new build (VS2008 static) versus one of my older builds (VS2003).

[LoRd_MuldeR]

Here you go:

E:\HD\palvik-Clip003 - Copy_001.mp4

[ffdshow r2335 ICL, 4 threads]
User: 1s, kernel: 0s, total: 2s, real: 18s, fps: 196.2, dfps: 23.0
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 177.9, dfps: 23.6
User: 1s, kernel: 0s, total: 2s, real: 17s, fps: 202.2, dfps: 23.7

[ffdshow r2373 ICL, 4 threads]
User: 3s, kernel: 0s, total: 3s, real: 20s, fps: 111.7, dfps: 20.3
User: 3s, kernel: 0s, total: 3s, real: 20s, fps: 111.7, dfps: 20.4
User: 3s, kernel: 0s, total: 3s, real: 18s, fps: 125.3, dfps: 22.0

[ffdshow-mt r2333, 4 threads]
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 278.0, dfps: 56.3
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 280.9, dfps: 56.4
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 242.6, dfps: 56.7

[Atak_Snajpera]

I can tell you that ffplay does not play the file. Please submit a report directly.
Where should i go with this file?

[LoRd_MuldeR]

Where should i go with this file?

http://ffmpeg.org/mailinglists.html

[LoRd_MuldeR]

According to the benchmark on my machine the latest ICL build is slightly slower than the previous one:
http://forum.doom9.org/showpost.php?p=1217432&postcount=5290

[tal.aloni]

I can definitely feel an improvement with audio processing.
Thanks clsid!

[clsid]

According to the benchmark on my machine the latest ICL build is slightly slower than the previous one:
http://forum.doom9.org/showpost.php?p=1217432&postcount=5290
Hmmm, that is a significant drop in performance. :eek: 7% when taking fastest values for both.

I shall make some additional builds of ffdshow.ax tomorrow for benchmarking. Maybe I can improve performance a bit.

[LoRd_MuldeR]

Hmmm, that is a significant drop in performance. :eek: 7% when taking fastest values for both.

Well, this was a test on one specific machines with one specific CPU type. You should get a few more tests from other people using different CPU types...

[Atak_Snajpera]

http://ffmpeg.org/mailinglists.html
Reported!
ID 734 https://roundup.mplayerhq.hu/roundup/ffmpeg/issue?status=-1,1,2&@sort=-activity&@search_text=&@dispname=Show%20Unresolved&@filter=status&@group=priority&@columns=id,activity,title,creator,assignedto,status&@pagesize=50&@startwith=0&assignedto=429

[Eragon4ever]

bbc-japan_1080p.mov

[ffdshow r2335 ICL, 2 threads]
User: 179s, kernel: 0s, total: 179s, real: 198s, fps: 42.5, dfps: 38.4
User: 173s, kernel: 0s, total: 174s, real: 188s, fps: 43.8, dfps: 40.5
User: 171s, kernel: 0s, total: 171s, real: 177s, fps: 44.5, dfps: 42.8

[ffdshow r2373 ICL, 2 threads]
User: 165s, kernel: 0s, total: 166s, real: 172s, fps: 45.9, dfps: 44.2
User: 165s, kernel: 0s, total: 165s, real: 171s, fps: 46.1, dfps: 44.4
User: 168s, kernel: 0s, total: 168s, real: 182s, fps: 45.2, dfps: 41.8

[STaRGaZeR]

I've noticed something strage. With clsid builds, ICL and generic, playing Blu-ray videos results in ffdshow flagging progressive as progressive/interlaced in a regular pattern when AUTO is selected. It disappears obviously when force bob/weave, but the strage thing is that xvidvideo.ru builds don't have this issue whatsoever.

[MatMaul]

Reported!
ID 734 https://roundup.mplayerhq.hu/roundup/ffmpeg/issue?status=-1,1,2&@sort=-activity&@search_text=&@dispname=Show%20Unresolved&@filter=status&@group=priority&@columns=id,activity,title,creator,assignedto,status&@pagesize=50&@startwith=0&assignedto=429
I think this will just be ignored because your report does not seem to follow the rules stated here :
http://ffmpeg.mplayerhq.hu/bugreports.html

edit : I can't access the directory, I think it would be good to copy the description in the ticket

[Atak_Snajpera]

I think this will just be ignored because your report does not seem to follow the rules stated here :
I give up. Those rules are insane. Hack the address then do this , don't that ...

BTW. Looks like that libavcodec cannot decode interlaced vc-1 (I see horizontal lines in source)

[LoRd_MuldeR]

I give up. Those rules are insane. Hack the address then do this , don't that ...

Well, you must understand that ffmpeg is a huge project and the devs don't want to be bombed with tons of noob questions...

[KoD]

The performance when going from VS2003 to VS2005 and VS2008 should be naturally worse, since each new version of the C compiler generates more additional code to improve security: more exception code handling, some functions are replaced with calls to slower functions that do buffer size checking, memory guards to detect buffer overflows and other techniques used to hijack code. These pieces of code decorate each function call, some decorate memory handling functions, so obviously performance will drop as each call will have to waste more time doing something else than just what was intended from it. A few of these improvements in security but which ultimately hurt performance are described in the MSDN magazine here (http://msdn.microsoft.com/en-us/magazine/cc337897.aspx).

While I can see why these would be necessary on an application that deals with accounting, data security and such, they seem out of place from multimedia applications which primarily need to be fast.

Edit: forgot to say that the new versions of the C runtimes are compiled as such as well, so the slowdown comes mostly from using them.

[_xxl]

The performance when going from VS2003 to VS2005 and VS2008 should be naturally worseI have remembered that some time ago ffdshow compiled by VC6 + ICL8 was the fastest.

[yesgrey]

While I can see why these would be necessary on an application that deals with accounting, data security and such, they seem out of place from multimedia applications which primarily need to be fast.

Well, if the software is not slowed down, why will we need new and faster cpus?... ;)

[STaRGaZeR]

Well, if the software is not slowed down, why will we need new and faster cpus?... ;)

Because you will be able to do the same in a fraction of time. When you're dealing with huge amounts of time required for a specific task even a 10% is a huge improvement. Time is money ;)

[CruNcher]

Does somebody know if x264-hd benchmark test clip (test-720p.mpg) is broken i get strange artifacts per frame rendering with libavcodec (Mpeg-2) also with ffplay, libmpeg2 rendering is fine very strange, also some decoder signal SD for that clip i wonder what's going on with the bitstream.

http://s11b.directupload.net/images/081127/rln5orow.png (libavcodec)
http://s10b.directupload.net/images/081127/td5c4z54.png (libmpeg2)

i don't have time currently (testing a new commercial GPU video product,and preparing my own stuff) to fight around looking @ whats happening here just found it by accident testing my encoding framework, maybe someone else has :)

[haruhiko_yamagata]

While I can see why these would be necessary on an application that deals with accounting, data security and such, they seem out of place from multimedia applications which primarily need to be fast.Do you think security is not important for multimedia applications? I don't think so. The security issue that has been fixed recently was so serious that I had to admit sacrificing MSVC7/MinGW 4.0.x and even adding a few bugs. ffdshow can be used from web browsers. Just clicking a link can trigger its security hole and infect a virus.

By the way, it's not getting slower for me.
Test file: premiere-paff.ts (H.264)
2373 MCVC9
User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 542.0, dfps: 99.4

2373 ICL
User: 2s, kernel: 0s, total: 2s, real: 11s, fps: 460.3, dfps: 103.4

2301 MSVC7
User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 583.3, dfps: 96.1

2301 ICL
User: 2s, kernel: 0s, total: 2s, real: 11s, fps: 549.8, dfps: 103.1

[LoRd_MuldeR]

Do you think security is not important for multimedia applications? I don't think so.

Security is very important in multimedia applications. If you follow the Newstickers, you read about "new" exploits in VLC Player and friends every few days...

@KoD
If there is a buffer overflow in your multimedia application, an attacker can easily execute his own (destructive) code on your local machine, just by providing a manipulated audio/video file :scared:
You really can't want that unresolved and you should be thankful to the developers for taking care of it...

[LoRd_MuldeR]

Here is another benchmark, this time I used another (longer) file:

E:\HD\x264.736.aq.0.48.8mbit.mkv

[ffdshow r2373 ICL, 4 threads]
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 177.1, dfps: 33.8
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 174.1, dfps: 33.8
User: 4s, kernel: 1s, total: 6s, real: 33s, fps: 180.7, dfps: 33.8

[ffdshow r2373 MSVC, 4 threads]
User: 5s, kernel: 0s, total: 6s, real: 33s, fps: 185.8, dfps: 33.7
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 170.0, dfps: 33.5
User: 5s, kernel: 0s, total: 6s, real: 33s, fps: 177.5, dfps: 33.1

[ffdshow r2335 ICL, 4 threads]
User: 5s, kernel: 1s, total: 6s, real: 32s, fps: 173.7, dfps: 34.0
User: 4s, kernel: 1s, total: 6s, real: 33s, fps: 179.3, dfps: 33.9
User: 5s, kernel: 1s, total: 6s, real: 33s, fps: 166.4, dfps: 33.2

[ffdshow-MT r2368 MSVC, 4 threads]
User: 4s, kernel: 0s, total: 4s, real: 12s, fps: 226.4, dfps: 88.0
User: 4s, kernel: 0s, total: 4s, real: 12s, fps: 227.1, dfps: 87.6
User: 4s, kernel: 0s, total: 4s, real: 12s, fps: 239.3, dfps: 87.2

Conclusions: Difference between MSVC and ICL is negligible. Difference between r2373 and 2335 is negligible too. The MT branch still rules (no surprise).

[clsid]

Those are better results :)

[CruNcher]

Forceware 180.70 (Nvidia G92)

Null

CoreAVC = User: 5s, kernel: 0s, total: 5s, real: 31s, fps: 702.2, dfps: 110.9, Memory: 50
DivX = User: 6s, kernel: 0s, total: 6s, real: 37s, fps: 505.4, dfps: 93.3, Memory: 50
ffdshow-mt = User: 7s, kernel: 0s, total: 7s, real: 55s, fps: 454.5, dfps: 63.0, Memory: 52
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 58s, fps: 9800.3, dfps: 60.0, Memory: 161
Cyberlink = User: 13s, kernel: 0s, total: 13s, real: 58s, fps: 268.3, dfps: 60.2, Memory: 115
MPC VideoDecoder = No measuring possible (doesn't start rendering) also not if DXVA is disabled

VMR7 (low to none kernel activity)

CoreAVC = User: 7s, kernel: 0s, total: 8s, real: 58s, fps: 436.8, dfps: 59.9, Memory: 56
Arcsoft = User: 1s, kernel: 0s, total: 1s, real: 58s, fps: 2398.0, dfps: 60.0, Memory: 157
Cyberlink = User: 11s, kernel: 1s, total: 12s, real: 58s, fps: 281.8, dfps: 60.7, Memory: 250
DivX = User: 8s, kernel: 1s, total: 9s, real: 59s, fps: 366.5, dfps: 58.8, Memory: 56
ffdshow-mt = User: 8s, kernel: 0s, total: 9s, real: 64s, fps: 378.2, dfps: 54.8, Memory: 56
MPC VideoDecoder = User: 8s, kernel: 1s, total: 9s, real: 79s, fps: 359.5, dfps: 44.2, Memory: 40

Overlay (GPU) (0-1.4x% CPU,low to none kernel activity)

MPC VideoDecoder = User: 0s, kernel: 0s, total: 1s, real: 61s, fps: 3087.8, dfps: 57.4, Memory: 31
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 72s, fps: 22540.8, dfps: 48.5, Memory: 60
Cyberlink = No measuring possible falls back to CPU

VMR7 (GPU) (0-1.4x% CPU,low to none kernel activity)

MPC VideoDecoder = User: 0s, kernel: 1s, total: 2s, real: 61s, fps: 1720.7, dfps: 57.3, Memory: 82
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 72s, fps: 17339.1, dfps: 48.3, Memory: 109
Cyberlink = No measuring possible falls back to CPU

VMR9 (GPU) (0-2.x% CPU, kernel activity peaking)

MPC VideoDecoder = User: 0s, kernel: 1s, total: 2s, real: 61s, fps: 1720.7, dfps: 57.3, Memory: 85 (heavy kernel peaking)
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 78s, fps: 8348.4, dfps: 45.0, Memory: 94
Cyberlink = No measuring possible falls back to CPU


GPU = 100W (CPU idle 1.1 GHz, 1.1v)
CPU = 175W (GPU Idle + CPU Load 2.5 GHz, 1.35v)

Hmm Arcsoft and Cyberlink behave different (GPU) benchmarking with timecodec (Cyberlink uses 100% CPU) it seems Cyberlink falls back to CPU rendering running within timecodec

PS: Arcsofts Decoder renders definitely more files successful in GPU Mode (outside timecodec) then Cyberlink does using VMR 7 (stays black a lot of times with Cyberlinks Decoder)
MPC - Video Decoder (DXVA) has especially problems with Broadcast Related Bitstreams (for Progressive it seems the most efficient) except under VMR9 here MPC Video Decoder shows up some really bad performance in Kernel times (Win XP)

CoreAVC vs GPU is a easy answer (for playback) especially for people with older CPUs and already installed next Gen GPU it makes no sense to use CoreAVC as the Power Saving can be very big in this situation up to 75W

[Snowknight26]

Half the time I enable visualizations in ffdshow they either don't show (quants/MVs) or they do show but they show zeroed results (graph is a flat line).

[LoRd_MuldeR]

I never really understood what "Graph" is supposed to do. It looks like a solid block moving from the right to the left, not really what a graph is supposed to look like :confused:

However "Motion vectors" and "Quantizers" seem to work as expected for me. That is with MPEG-2 and H.264 sources.

[Thunderbolt8]

Reported!
ID 734 https://roundup.mplayerhq.hu/roundup/ffmpeg/issue?status=-1,1,2&@sort=-activity&@search_text=&@dispname=Show%20Unresolved&@filter=status&@group=priority&@columns=id,activity,title,creator,assignedto,status&@pagesize=50&@startwith=0&assignedto=429
libav already made problems some time ago when I had that sample of the galapagos hd dvd, which was 1080i 29.97fps. back then haruhiko_yamagata disabled vc-1 support for libavcodec, since it was buggy I guess.

[LoRd_MuldeR]

With recent ffdshow builds I get a strange problem with the "Greedy 2 Frame" deinterlacer (available as DScaler plugin).
During playback I get see strange flickering and in the config menu the sliders behave in a strange way. When I move one slider, the other one will be reset to "0".

Any ideas? Maybe related to the move to VS2008 ??? :confused:

[Snowknight26]

I never really understood what "Graph" is supposed to do. It looks like a solid block moving from the right to the left, not really what a graph is supposed to look like :confused:

Should look like this: http://www.stfcc.org/misc/visualizations.working.jpg
And not working obviously: http://www.stfcc.org/misc/visualizations.notworking.jpg

However "Motion vectors" and "Quantizers" seem to work as expected for me. That is with MPEG-2 and H.264 sources.

I wish that was the case for me. 50% of the time isn't good enough. :\

[haruhiko_yamagata]

I never really understood what "Graph" is supposed to do. It looks like a solid block moving from the right to the left, not really what a graph is supposed to look like :confused:The graph renders the input bit rate. One column represents one frame. So there should be peaks and dips if a good encoder is used.

[haruhiko_yamagata]

With recent ffdshow builds I get a strange problem with the "Greedy 2 Frame" deinterlacer (available as DScaler plugin).
During playback I get see strange flickering and in the config menu the sliders behave in a strange way. When I move one slider, the other one will be reset to "0".

Any ideas? Maybe related to the move to VS2008 ??? :confused:I can reproduce if the clip has mixed flags of interlaced and progressive. "Process frames flagged as progressive" is related.

[haruhiko_yamagata]

I wish that was the case for me. 50% of the time isn't good enough. :\It works only if libavcodec is used as decoder.

[Yong]

Hi, im here to report the ffdshow latest svn compiling problem,

1. compiling ffdshow.ax with msvc2008 sp1, comment out this 2 line compiling will work without any error.
IIRC older compiler, e.g. msvc 2005 and gcc also have problem with this 2 lines.
1>.\src\audioFilters\TaudioFilter.cpp(252) : error C2664: '_mm_castps_si128' : cannot convert parameter 1 from 'const __m128' to '__m128 &'
1> Conversion loses qualifiers
1>.\src\audioFilters\TaudioFilter.cpp(253) : error C2664: '_mm_castps_si128' : cannot convert parameter 1 from 'const __m128' to '__m128 &'
1> Conversion loses qualifiers

2. when compiling the ff_wmv9.dll with mingw-gcc4.2.1sjlj
dllwrap -mno-cygwin --target=i686-pc-mingw32 \
-Wl,--enable-stdcall-fixup --strip-all \
--def ff_wmv9.def -o ../../../bin/ff_wmv9.dll ff_wmv9.o GenProfile_lib.o nssBuffer.o videoenc.o writerSink.o include/wmguids.o ../../imgFilters/ffImgfmt.o combase.o -lstdc++ -lsupc++ -luuid -lole32 -loleaut32 -lwinmm -lgdi32 -ldxguid
../../imgFilters/ffImgfmt.o:ffImgfmt.cpp:(.text+0x3e1): undefined reference to `int _snwprintf_s<wchar_t>(wchar_t*, unsigned int, unsigned int, wchar_t const*, ...)'
../../imgFilters/ffImgfmt.o:ffImgfmt.cpp:(.text+0xc43): undefined reference to `int _snwprintf_s<wchar_t>(wchar_t*, unsigned int, unsigned int, wchar_t const*, ...)'
collect2: ld returned 1 exit status
E:\msys\mingw\bin\dllwrap.exe: E:\msys\mingw\bin\gcc exited with status 1
make: *** [../../../bin/ff_wmv9.dll] Error 1
make: Leaving directory `/sources/ffdshow/src/codecs/wmv9'

but msvc2008 sp1 compile just fine.

Im sorry if the infomations i provided are not enough.. :p

[haruhiko_yamagata]

Hi, im here to report the ffdshow latest svn compiling problem,

1. compiling ffdshow.ax with msvc2008 sp1, comment out this 2 line compiling will work without any error.
IIRC older compiler, e.g. msvc 2005 and gcc also have problem with this 2 lines.
It depends on Platform SDK version. Which macro should we use to check SDK version?

2. when compiling the ff_wmv9.dll with mingw-gcc4.2.1sjlj

but msvc2008 sp1 compile just fine.

Im sorry if the infomations i provided are not enough.. :pGCC compilation of ffdshow.ax and ff_wmv9.dll was dropped at rev 2349. Please use MSVC9.

[Snowknight26]

It works only if libavcodec is used as decoder.

The only settings that were changed in my 2 screenshots was the order in which I checked the Visualization options. Both times the video was being decoded with libavcodec.

[haruhiko_yamagata]

The only settings that were changed in my 2 screenshots was the order in which I checked the Visualization options.How is it different?

[Snowknight26]

Not entirely sure what you're asking.

[haruhiko_yamagata]

Can anybody help us to understand each other?

By the way, I'm going into bug fix/finalizing phase.
What is left for next stable release?

[fastplayer]

Revision 2390
Modified Sat Nov 29 13:23:50 2008 UTC (4 minutes, 39 seconds ago) by h_yamagata

libavcodec MPEG-2: fix timestamps issue (DVD)
Is this the issue MatMaul (http://forum.doom9.org/showthread.php?p=1214645#post1214645), me (http://forum.doom9.org/showthread.php?p=1107246#post1107246) and a couple of others reported about?

[LoRd_MuldeR]

The graph renders the input bit rate. One column represents one frame. So there should be peaks and dips if a good encoder is used.

Doesn't look like that for me :confused:

http://img58.imageshack.us/img58/1982/grapheu7.th.png (http://img58.imageshack.us/my.php?image=grapheu7.png)

Maybe the stream is CBR, but I don't think so. Even streaming isn't perfect CBR, but allows some local ratecontrol optimizations...


I can reproduce if the clip has mixed flags of interlaced and progressive. "Process frames flagged as progressive" is related.

The funny thing is: When I configure ffdshow "offline" the sliders work just fine.

But as soon as a media is playing, they go crazy. Move one slider, get the other one reset to zero.

Any chance for a fix? :o

[fastplayer]

What is left for next stable release?
I can tell you exactly what's left: A proper changelog! :D
I really hope that all devs have kept track of what they've added/changed/fixed since the beta5 release.
If you have something that's "readable", PM me! :)

[haruhiko_yamagata]

Is this the issue MatMaul (http://forum.doom9.org/showthread.php?p=1214645#post1214645), me (http://forum.doom9.org/showthread.php?p=1107246#post1107246) and a couple of others reported about?Yes, it will be OK.

[haruhiko_yamagata]

Doesn't look like that for me :confused:

http://img58.imageshack.us/img58/1982/grapheu7.th.png (http://img58.imageshack.us/my.php?image=grapheu7.png)

Maybe the stream is CBR, but I don't think so. Even streaming isn't perfect CBR, but allows some local ratecontrol optimizations...
It works better for me. What is the video format and which decoder is used?

The funny thing is: When I configure ffdshow "offline" the sliders work just fine.

But as soon as a media is playing, they go crazy. Move one slider, get the other one reset to zero.

Any chance for a fix? :oSimply wait for the next build, please :D .

[haruhiko_yamagata]

I can tell you exactly what's left: A proper changelog! :D
I really hope that all devs have kept track of what they've added/changed/fixed since the beta5 release.
If you have something that's "readable", PM me! :)OK, I will update.
@developers, please add your work to the change log.

[fastplayer]

OK, I will update.
@developers, please add your work to the change log.
What changelog do you mean? Is there one I don't know about?

Once I have all the bits and pieces, I'll integrate it into the wiki-changelog, right here:
http://ffdshow-tryout.wiki.sourceforge.net/Changelog

FYI, the web documentation is dead. The wiki is the future:
http://ffdshow-tryout.wiki.sourceforge.net/
It's a bit easier to maintain and hopefully will encourage people to participate and add content. I said "hopefully" because nobody has added one single line since I set up the wiki a few months ago...
Multiple language support has been dropped because it's a pain-in-the-butt to keep it synchronized and I'd rather see all our efforts focused on one good documentation than on 3 mediocre ones... By the way, this was clsid's idea. So if you have a problem with that, argue with him. Yeah, good luck with that... :p

[LoRd_MuldeR]

It works better for me. What is the video format and which decoder is used?

Source: DVB Source, MPEG-2
Decoder: libavcodec mpeg2video

Simply wait for the next build, please :D .

:thanks:

[clsid]

The idea is to eventually have documentation in the Wiki for the many options that ffdshow has. Any volunteers that are willing to write some pieces of documentation? Even small pieces are welcome.

Perhaps we could let the installer create a link to the Wiki in the start menu (once the wiki has more content of course)? That would make it known to the general public. But before we allow the general public to edit the wiki it would be useful if there were some moderators that could monitor changes and undo vandalism.

[clsid]

Fresh builds will be online shortly :cool:

@Albain,
FFmpeg now appears to support decoding of DTS-HD:
http://svn.mplayerhq.hu/ffmpeg?view=rev&revision=15951

[fastplayer]

But before we allow the general public to edit the wiki it would be useful if there were some moderators that could monitor changes and undo vandalism.
Permissions are already set to "public" and it has been like that for 3 months. So far nobody has done anything legally or illegally...
I'm keeping an eye on the "recent changes" list almost daily and I make backups regularly. So I wouldn't be too much concerned about abuse and such. I am more concerned about the lack of content... :(

[clsid]

The wiki is not easy to find. The default webpage view on SourceForge hides several menu items, including the wiki. So I suspect that is one of the reasons for the lack of activity.

[STaRGaZeR]

By the way, I'm going into bug fix/finalizing phase.
What is left for next stable release?

I would like to remember a very useful proposition Leak did back in October:

http://forum.doom9.org/showthread.php?p=1208512#post1208512

http://forum.doom9.org/showthread.php?p=1208726#post1208726

I'm asking mainly because forcing ATi's deinterlacer in soft telecined frames (for the reasons discussed before in this thread) produces bad effects if you send it the field information instead of just plain progressive frames. Maybe a simple checkbox could do the trick, that way the "Apply pulldown" option will remain effective (like it is now) or not (like it was in rev2236), users could decide.

[fastplayer]

The wiki is not easy to find. The default webpage view on SourceForge hides several menu items, including the wiki. So I suspect that is one of the reasons for the lack of activity.
I agree and the wiki visual editor does not work with Opera and Safari browsers. Not exactly a show stopper but far from the user-friendliness and ease of use that wikis suggest...

[clsid]

Here are some bugs that have been reported in the past. Can anyone confirm if they are still present in revision 2391? If not, I will remove them from the bugtracker:

# Cubic blending deinterlacer doesn't work.
# Anamorphic MPEG-1 video displays with incorrect aspect ratio when using libavcodec as decoder.
# ttxt subtitles are always rendered in italic with small size and with times (new) roman font
# amr audio decoding doesn't work in 64-bit builds?

And here are a few more:
http://sourceforge.net/tracker/index.php?func=detail&aid=2333334&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1924063&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2215967&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1673817&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1952999&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2028210&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2056124&group_id=173941&atid=867360

[LoRd_MuldeR]

I think I mentioned it before, but the following deinterlacing filters don't deinterlace:
"Framerate doubler" and "Cubic blending"

If these can't be fixed easily, I think the code should be disabled/removed. There are enough alternatives.

BTW: What is "Bypass" good for? If the user doesn't want to deinterlace, (s)he can simply uncheck deinterlacing. Unless it's required for some special purpose, it could be removed too.

[fastplayer]

By the way, what's the name of the next release? Beta6? RC1? 1.0? :eek:
How about a preliminary changelog? So all you devs can log your changes in one central place, then we can clean out and streamline it into something presentable later.
Here you go:
http://ffdshow-tryout.wiki.sourceforge.net/IWantToBeAChangelogWhenIGrowUp

[STaRGaZeR]

Cubic blending does not work.

[ 2333334 ] no interlaced flag since rev23xx --> I've been using it with EVR Custom since forever, never had a problem like no flags whatsoever. Only bugs that have been corrected over time.

[ 2028210 ] Problemm with cropping --> Wasn't it fixed in rev2292? It's working for me, "Process whole image" should be checked.

[ 2056124 ] mpeg2 decoding/colorspace conversion bug --> The HQ vs noHQ is not a bug, but a feature. But I can't explain the difference between libmpeg2 and libav with HQ enabled.

[clsid]

It will be: Beta 6.

Most info can be found in the SVN log:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log

I am not really in the mood to convert that into a changelog. If you want to do it, go ahead. Don't forget to exclude the commits to the ffmpeg-mt branch. Many groups of commits can be summarized, e.g.: Added support for E-AC3 and Dolby TrueHD/MLP audio.

Beta 4 = revision 1685
Beta 4a = revision 1723
Beta 5 = revision 2033

[clsid]

Most of the page links in the wiki point to non-existing pages. Could you perhaps create empty stub pages? I think that will lower the threshold for people to add content. Also, page names are then created in an organized way. Stub pages could look like this:
Page Title

This page has no content yet. Please contribute!

[fastplayer]

Most of the page links in the wiki point to non-existing pages. Could you perhaps create empty stub pages? I think that will lower the threshold for people to add content. Stub pages could look like this:
Page Title

This page has no content yet. Please contribute!
Yes, I'm going through the SVN changelog. The question is: Should multiple fixes for one feature/option be summarized (like "Fixes for RemoteAPI") or should each fix be listed explicitly?

Edit: I'll make the stubs later. :)

[yesgrey]

Can anybody help us to understand each other?

When opening a video file with Visualizations unchecked and all options disabled nothing shows, as supposed.
If while watching the file you open the ffdshow dialog and then check the Visualizations, whitout any options being enabled, if then you start enabling the options nothing shows.

Summarizing: You only could see the Visualizations if any option is checked prior to checking the Visualizations check box.

[Leak]

Summarizing: You only could see the Visualizations if any option is checked prior to checking the Visualizations check box.
So, in other words, changing the types of visualization to display while they're already being displayed does nothing?

You're right, if you uncheck all four checkboxes on the "Visualizations" page, open a file and check the "Vizualizations" check box first followed by any of the others they won't have any effect.

Toggling the "Vizualizations" checkbox off and back on makes them appear, though.

EDIT: silly me thought I had a problem with quantizers, but of course resizing the image via AviSynth is bound to make them (and the motion vectors in case you also crop the image) go totally bonkers...

np: Gas - Track 5 (Gas)

[KoD]

Regarding the pass to VS2008: I've done a few tests so far with clisd's icl builds and there are indeed no speed differences between the pre and post ffdshow revisions. I've checked both simple video decoding scenarios, as well as other scenarios that could be common like when deinterlacers, resizing or color conversions are used. The end result was: there was no (absolutely none, actually) difference in speed for the ICL compiled builds. I wasn't keen on testing the builds that use only the VS2008 C compiler, as I don't use them.

Finally, a few bugs that have been reported before but I don't know if they're accounted officially:
1. mpeg1 layer 3 in avi files causes "clicks" when libavcodec is used as a decoder (Microsoft's avi splitter is used); same files don't show this behavior when mp3lib for instance is used
2. mpeg1 layer 2 in mpg files also causes clicks when libacodec is used as a decoder (Microsoft's mpeg splitter is used); same files don't show this behavior when mp3lib for instance is used

When extracting the mp3 or mpeg1 layer 2 audio from the video file and playing it as is, libavcodec doesn't generate those clicks anymore.

There has to be something wrong in how the libavcodec decoder expects the audio frames it receives to be formatted or such, as other decoders don't have this issue.

[clsid]

Yes, I'm going through the SVN changelog. The question is: Should multiple fixes for one feature/option be summarized (like "Fixes for RemoteAPI") or should each fix be listed explicitly?
If the SVN log mentions some specific details about a fix, then it might be useful to mention those details in the changelog as well. Fixes that don't include much details can be grouped together. Multiple fixes for the same issue can also be summarized. Just do whatever you think is best.

[tal.aloni]

@Haruhiku,
I've started working on correcting the RGB <> BGR mismatches in the source code, it's opposite over opposite,
and I'll try to make it right.

Tal

[MatMaul]

Yes, it will be OK.
thanks a lot !
here is an other bug I reported :
http://sourceforge.net/tracker/index.php?func=detail&aid=2298876&group_id=173941&atid=867360

[haruhiko_yamagata]

I think I mentioned it before, but the following deinterlacing filters don't deinterlace:
"Framerate doubler" and "Cubic blending"

If these can't be fixed easily, I think the code should be disabled/removed. There are enough alternatives.

BTW: What is "Bypass" good for? If the user doesn't want to deinterlace, (s)he can simply uncheck deinterlacing. Unless it's required for some special purpose, it could be removed too.
I will remove them. I didn't check the code, just because the drop down list is too messy.
544x576 MPEG-2, libmpeg2, Core2 Quad

None:User: 1s, kernel: 0s, total: 1s, real: 1s, fps: 485.4, dfps: 476.6
Linear interpolation:User: 1s, kernel: 0s, total: 1s, real: 1s, fps: 411.6, dfps: 405.0
Linear blending:User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 405.2, dfps: 399.0
Cubic interpolation:User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 405.2, dfps: 399.0
Median:User: 1s, kernel: 0s, total: 1s, real: 1s, fps: 408.4, dfps: 405.2
TomsMoComp:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 325.7, dfps: 323.7
DGBob(single):User: 5s, kernel: 0s, total: 5s, real: 5s, fps: 158.8, dfps: 158.8
DGBob(double):User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 93.0, dfps: 92.9
ffmpeg deinterlacer:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 392.8, dfps: 392.8
5-tap lowpass:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 375.6, dfps: 372.9
Kernel deinterlacer:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 362.4, dfps: 359.9
Kernel bob:User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 275.2, dfps: 275.2
yadif (single):User: 1s, kernel: 0s, total: 1s, real: 2s, fps: 480.9, dfps: 381.2
yadif (double):User: 2s, kernel: 0s, total: 2s, real: 2s, fps: 395.8, dfps: 304.4

This is a rough bench mark test.
Classic deinterlacers such as "Linear interpolation" is a bit faster than modern deinterlacers.
What is DGBob good for?

[Leak]

What is DGBob good for?
It's another deinterlacer made by Donald Graft, aka neuron2 (http://www.neuron2.net/dgbob/dgbob.html)...

(Can't tell you more as I haven't used it, mind you...)

np: Gas - Track 7 (Pop)

[LoRd_MuldeR]

It's another deinterlacer made by Donald Graft, aka neuron2 (http://www.neuron2.net/dgbob/dgbob.html)...

(Can't tell you more as I haven't used it, mind you...)

np: Gas - Track 7 (Pop)

It's another bobber. IMHO you get nicer results with Yadif or KernelBob, but thats subjective. Other users may prefer DGBob.

I vote for: Keep it. (And you really don't want to insult Neuron2 by removing his filter, right? ^^)

Classic deinterlacers such as "Linear interpolation" is a bit faster than modern deinterlacers.

Another point for "classic" deinterlacers besides speed is that they produce a 100% artifact-free results. Throw away half of the lines, interpolate to get a full frame.

All those fancy motion-compensated deinterlacers retain more information in "static" areas, but some artifacts slip through here and there.

People that can live with a rather smooth image and don't want to mess with threshold values may prefer one of the simple deinterlacers. Enabled and watch ;)

[haruhiko_yamagata]

Here are some bugs that have been reported in the past. Can anyone confirm if they are still present in revision 2391? If not, I will remove them from the bugtracker:

# Cubic blending deinterlacer doesn't work.
# Anamorphic MPEG-1 video displays with incorrect aspect ratio when using libavcodec as decoder.
# ttxt subtitles are always rendered in italic with small size and with times (new) roman font
# amr audio decoding doesn't work in 64-bit builds?

And here are a few more:
http://sourceforge.net/tracker/index.php?func=detail&aid=2333334&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1924063&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2215967&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1673817&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=1952999&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2028210&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2056124&group_id=173941&atid=867360
I would like to release next beta as soon as possible, because the security hole fixed at rev 2349 is very serious.
Some bugs that has been added after beta5 should be fixed before beta6, other bugs before RC1.
@albain: Could you fix the regression bug of subtitle?

[haruhiko_yamagata]

When opening a video file with Visualizations unchecked and all options disabled nothing shows, as supposed.
If while watching the file you open the ffdshow dialog and then check the Visualizations, whitout any options being enabled, if then you start enabling the options nothing shows.

Summarizing: You only could see the Visualizations if any option is checked prior to checking the Visualizations check box.
Thank you. I understand. If you close the dialog, it will appear.

[DeathTheSheep]

Subtitles still bad. (See previous post).


http://img175.imageshack.us/img175/9320/subsny9.jpg

[haruhiko_yamagata]

Source: DVB Source, MPEG-2
Decoder: libavcodec mpeg2video
Oh, yes, it won't work. I've forgotten I've written it won't work.
The fix is impossible in the short term.

pict.srcSize = (size_t)frame->reordered_opaque3; // FIXME this is not correct for MPEG-1/2 that use SOURCE_TRUNCATED. (Just for OSD, not that important bug)

[haruhiko_yamagata]

I would like to remember a very useful proposition Leak did back in October:

http://forum.doom9.org/showthread.php?p=1208512#post1208512
I think I have fixed this. Is it not?

http://forum.doom9.org/showthread.php?p=1208726#post1208726

This would be a nice feature. I hope Leak will eventually implement the feature, but next beta is not bound to it.

[LoRd_MuldeR]

The configuration sliders for "Greedy 2 Frame" still do crazy things in r2392.

Also I'm happy to announce yet another DVBViewer problem:
Moving the window from one screen to another one with Yadif enabled causes "slow motion" playback now :(

[haruhiko_yamagata]

The configuration sliders for "Greedy 2 Frame" still do crazy things in r2392.I see, if I try to slide one slider, another one moves.

Also I'm happy to announce yet another DVBViewer problem:
Moving the window from one screen to another one with Yadif enabled causes "slow motion" playback now :(
Is this once fixed and added back?

[LoRd_MuldeR]

Is this once fixed and added back?

With Yadif enabled:
* Primary screen: Plays perfectly smooth.
* Move to second screen: Get "slow motion" effect
* Move back to primary screen: Plays smooth again
* Move to second screen again: The "slow motion" is back
* And so on...

[Leak]

With Yadif enabled:
* Primary screen: Plays perfectly smooth.
* Move to second screen: Get "slow motion" effect
* Move back to primary screen: Plays smooth again
* Move to second screen again: The "slow motion" is back
* And so on...
What's the CPU use on the second screen? If it goes through the roof it's probably the graphics driver being unable to handle this situation - which for instance also happens if you drag a 3D game window from the primary screen to the secondary; but if this is the case I couldn't think of a reason why yadif should cause it unless it's extra CPU use pushes DVBViewer over the edge...

np: Squarepusher - Duotone Moonbeam (Just A Souvenir)

[yesgrey]

If you close the dialog, it will appear.

Yes, that works. I also tried just clicking the "Apply" button, but had no effect.

[Djon]

Hi :)
Little question : I plan to install Vista 64, should I use ffdshow 64 ? I actually use ffdshow-mt due to my Quad core CPU.
Thanks for responses.

[LoRd_MuldeR]

What's the CPU use on the second screen? If it goes through the roof it's probably the graphics driver being unable to handle this situation - which for instance also happens if you drag a 3D game window from the primary screen to the secondary; but if this is the case I couldn't think of a reason why yadif should cause it unless it's extra CPU use pushes DVBViewer over the edge...

np: Squarepusher - Duotone Moonbeam (Just A Souvenir)

Can't be a graphics driver problem, because I didn't change/update the driver. But I did update ffdshow-MT ;)

But the CPU usage goes crazy indeed. On the primary screen (with Yadif working) it's in the ~10% range.
As soon as I move to the second screen it jumps to ~25%, maximum load for a single core.

[EDIT]

When limiting the output colorspace to RGB32 (let ffdshow do the YUV -> RGB conversion) the problem seems to be gone!

Shouldn't this be even slower? :confused:

[LoRd_MuldeR]

Hi :)
Little question : I plan to install Vista 64, should I use ffdshow 64 ? I actually use ffdshow-mt due to my Quad core CPU.
Thanks for responses.

There is no reason to use ffdshow x64 yet, because...
* Only 64-Bit players would be able to use it (e.g. MPC x64), none of the 32-Bit players
* Usually 64-Bit binaries are less optimized and slower than the 32-Bit binaries, at least for the time being
* ffdshow x64 is still experimental, the x86 version is much more stable
* 32-Bit players using 32-Bit filters (including ffdshow x86) will run on 64-Bit Windows just fine

[Djon]

* Usually 64-Bit binaries are less optimized and slower than the 32-Bit binaries

Okay, thanks for answer, but, what's the advantage of 64-Bit OS so ? Should I use MPC x86 even if I use Vista 64 ?

[LoRd_MuldeR]

Okay, thanks for answer, but, what's the advantage of 64-Bit OS so ?

Support for more than ~3 GB of total RAM. No 2 GB memory limitation per process (64-Bit processes only).

And support for 64-Bit binaries, which could be faster than 32-Bit binaries, if fully optimized for AMD64 processors (few are yet).

Should I use MPC x86 even if I use Vista 64 ?

Yes. If you used MPC x64, you would be limited to use 64-Bit filters!

There are very few 64-Bit filters at the moment and they usually are slower and/or less stable than their 32-Bit pendants.

I just don't see any advantage in going MPC x64 currently, except for testing...

[Djon]

Hmm, so ffdshow-mt + MPC HC x86 is the best combo, doesn't matter 32 or 64 OS ?

[LoRd_MuldeR]

Hmm, so ffdshow-mt + MPC HC x86 is the best combo, doesn't matter 32 or 64 OS ?

Speed-wise yes. Stability-wise no.

For best stability you shouldn't go with ffdshow-MT yet (ffmpeg-MT is work in progress, for example some H.264's still show artifacts).

[leeperry]

I already spoke about it w/ Seb.26(occasional ffdshow coder), and he kept telling me that ffdshow can't resize vertically.

is he right, or are we overlooking something ?

this is a 2.35 movie :

http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031t.jpg (http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031.html)

if I change the AR to 1.78 I get this :

http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aect.jpg (http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aec.html)

is there a way to expand the picture vertically, instead of horizontally ? I've tried every option I could think of :rolleyes:

thanks

[Djon]

I watch a lot of big-resolution movies (1080p +) and I see a little difference with -MT, but thank you for all the answers.
See you at avidemux's forum :)

[LoRd_MuldeR]

I watch a lot of big-resolution movies (1080p +) and I see a little difference with -MT, but thank you for all the answers.

You should see a HUGE speed-difference between ffdshow and ffdshow-MT, especially for HD media :cool:

If you don't see any visual differences then you are lucky and don't have any of the files that are broken with MT ;)

(I checked the sample that was posted a while ago and it still shows artifacts with latest ffdshow-MT build)

[STaRGaZeR]

I think I have fixed this. Is it not?

You introduced changes about how to deal with telecined content in rev2236, flagging it as progressive. Those changes broke Pulldown, so you changed it in rev2276 now sending field information and allowing Pulldown to work. But as Leak says:

So in most places the INT_TFF/INT_BFF bits should be just ignored when PROGRESSIVE_FRAME bit is set, but in the AviSynth filter "Apply Pulldown" would instead ignore PROGRESSIVE_FRAME in favour of the interlacing bits...

In most places, the field information is ignored. But ATI's deinterlacer does not ignore it, and the resulting image is blinking. So in order to allow Pulldown and at the same time don't send field information to the renderer, just frames flagged as progressive, what do you suggest?

[haruhiko_yamagata]

I already spoke about it w/ Seb.26(occasional ffdshow coder), and he kept telling me that ffdshow can't resize vertically.

is he right, or are we overlooking something ?

this is a 2.35 movie :

http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031t.jpg (http://pix.nofrag.com/6/a/7/8ec9f5f8570e97adc222b1eb80031.html)

if I change the AR to 1.78 I get this :

http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aect.jpg (http://pix.nofrag.com/4/4/3/683dc073f2d8bd3054f3d5ad95aec.html)

is there a way to expand the picture vertically, instead of horizontally ? I've tried every option I could think of :rolleyes:

thanksffdshow can.
If you stretch vertically too much that the height is bigger than screen height, it will be like that. Your application may shrinking the screen. It depends on application and video renderer.

[haruhiko_yamagata]

In most places, the field information is ignored. But ATI's deinterlacer does not ignore it, and the resulting image is blinking. So in order to allow Pulldown and at the same time don't send field information to the renderer, just frames flagged as progressive, what do you suggest?It is not flagged to downstream, if both FIELD_TYPE::PROGRESSIVE_FRAME and FIELD_TYPE::INT_?FF is set.
Could you send me the sample? I think libmpeg2 wrapper failed to detect telecine for that file.

[leeperry]

ffdshow can.
If you stretch vertically too much that the height is bigger than screen height, it will be like that. Your application may shrinking the screen. It depends on application and video renderer.
ok thanks for the fast reply.
so I've tried both KMP and MPC and set "adjust window from outside" in both players.
I've also set the PAR to 1:1 in ffdshow and the AR to DAR in my players.

yet it's doesn't output 1280 wide picture with 1:78 vertical ratio instead of 2.35

as HR says through its OSD, ffdshow is outputting 973x384 :

http://pix.nofrag.com/0/e/0/89263d60e7624a554b4db90db69c6t.jpg (http://pix.nofrag.com/0/e/0/89263d60e7624a554b4db90db69c6.html)

sure you can upscale 973x384 to 1.78, but I'd like to vertically resize........not horizontally, and I can't get ffdshow to do it :(

[haruhiko_yamagata]

Can't be a graphics driver problem, because I didn't change/update the driver. But I did update ffdshow-MT ;)

But the CPU usage goes crazy indeed. On the primary screen (with Yadif working) it's in the ~10% range.
As soon as I move to the second screen it jumps to ~25%, maximum load for a single core.

[EDIT]

When limiting the output colorspace to RGB32 (let ffdshow do the YUV -> RGB conversion) the problem seems to be gone!

Shouldn't this be even slower? :confused:Probably the video renderer switch to GDI or something slower.
By the way, in which revision does the problem start? Is it the same from the start?

[haruhiko_yamagata]

The configuration sliders for "Greedy 2 Frame" still do crazy things in r2392.
Thank you for finding this issue.
After fixing it at rev 2397, it looks like more general problem.

[fastplayer]

Yes, it will be OK.
Just tested it with the "Forbidden Kingdom" DVD and it works both in MPC and WMP.
:thanks:

[KoD]

When ffdshow is installed, choosing to reset settings during install, the following video decoders are enabled:
FVFW
QTRLE
QRZPA
FFV1

While FVFW and FFV1 are formats that are specific to ffdshow, so it's understandable to have them enabled by default, I don't know if QTRLE and QRZPA should get the honors of being enabled by default as well. After all, much more common formats like xvid, divx and h264 are not. What do you think ?

[fastplayer]

..., I don't know if QTRLE and QRZPA should get the honors of being enabled by default as well.
I agree. ffdshow's policy is to override as little as possible. Most people have QT installed anyway which should take care of the formats you mentioned.

[clsid]

I agree that they shouldn't be enabled. But they aren't interfering with QT, which isn't a DirectShow player.

Edit: they don't get enabled here after deleting ffdshow's registry keys. Theora does however, and I will fix that.

[tal.aloni]

@developers,
when I fixed the Grab filter related Color Space conversion issue, I noticed that there were some major inconsistencies regarding the RGB colorspace. the FF_CSP_ enum is referring to how the bytes are stored in memory, which is the opposite of the writing order under x86 architecture (little endians).
we work with many libraries, some use the write order(libmplayer), and some use the "byte order" (ffmpeg).

(also, when writing to files, the write order equals to the "byte order", which makes things even more confusing)
it's hard to decide what's right to do in this case, because in any way, our enum will appear to be erroneous,

I made a patch that I think will make the code more clear,
I guess future work should be done (comments etc.),
I would like to hear what you think, and if you have a better suggestion.

http://iknowu.net/files/public/ffdshow/2401-LittleEndian.patch

Tal

to summerize, I replaced the FF_CSP_RGB?? in the enum with FF_CSP_BGR?? and vice versa, and defined the following: (I also replaced the FF_CSP_????? in the rest of the code, to match the appropriate values)

#define FF_CSP_RGB15_LITTLE_ENDIAN FF_CSP_BGR15
#define FF_CSP_RGB16_LITTLE_ENDIAN FF_CSP_BGR16
#define FF_CSP_RGB24_LITTLE_ENDIAN FF_CSP_BGR24
#define FF_CSP_RGB32_LITTLE_ENDIAN FF_CSP_BGR32
#define FF_CSP_BGR15_LITTLE_ENDIAN FF_CSP_RGB15
#define FF_CSP_BGR16_LITTLE_ENDIAN FF_CSP_RGB16
#define FF_CSP_BGR24_LITTLE_ENDIAN FF_CSP_RGB24
#define FF_CSP_BGR32_LITTLE_ENDIAN FF_CSP_RGB32

[jmartinr]

@ leeperry

I'd like to vertically resize........not horizontally, and I can't get ffdshow to do it.

If you crop the sides in the avisynth filter section before resizing you can do what you want. At least that is when I understood your problem correctly.

I've automated the cropping like this:

# if DAR is bigger than 16:9 we crop something off
# maximum DAR x:y
mx=16
my=9
maxwidth=round(last.height*float(ffdshow_sar_y)*mx/ffdshow_sar_x/my)
maxwidth=maxwidth-(maxwidth%16)
maxwidth=min(last.width,maxwidth)
crop((last.width-maxwidth)/2,0,maxwidth,0)

[leeperry]

@ leeperry
If you crop the sides in the avisynth filter section before resizing you can do what you want. At least that is when I understood your problem correctly.
cool, thanks!

but after I asked him a while ago, haruhiko was kind enough to add AR presets in ffdshow.

this is very convenient, like for mod8/16 movies that don't have exactly the right AR(like 2.42 instead of 2.40, or 2.37 instead of 2.35)

but fixing the AR will add horizontal black borders at this point....and I can't find a way to get ffdshow to vertically resize :confused:

Seb.26 tells me that ffdshow can't vertically resize, haruhiko tells me the opposite....

apparently ffdshow resize works as if you checked "touch window from inside" in MPC, when what you want is "touch window from outside" :(

maybe a ffdshow/HR limitation, or some misconfigured option I overlooked :rolleyes:

[jmartinr]

@leeperry

Keep fiddling around. I have ticked "borders inside" and I can resize vertically. Any film I play is resized to 720x576 (my TV's resolution).

[leeperry]

@leeperry

Keep fiddling around. I have ticked "borders inside" and I can resize vertically. Any film I play is resized to 720x576 (my TV's resolution).
well I'm trying it on a 2.19:1 720p trailer

whatever inside or outside borders doesn't change much as I don't add borders.

I got resize enabled to 1280*768, if I check 1.78 or 2.35 the picture is nowhere near vertically large enough for this AR...

oh well, ffdshow is too l33t for me I guess :D

[jmartinr]

@ leeperry

It's still not very clear to me.

1. Do you want to keep the pixel aspect ratio?
2. Do you crop the sides?

You have to use one of two methods to change the screen aspect ratio. Which one is it?

[leeperry]

@ leeperry
It's still not very clear to me.

1. Do you want to keep the pixel aspect ratio?
2. Do you crop the sides?

You have to use one of two methods to change the screen aspect ratio. Which one is it?
well I wanna change the DAR.
like resizing a 1280*540 video to 1280*720 for instance, going from 2.37 to 1.78

exactly as if you checked "touch window from outside" in MPC/KMP...when right now ffdshow is working as if I had "touch window from inside" enabled.

maybe coz I set the PAR to 1:1? hah :p

[KoD]

I agree that they shouldn't be enabled. But they aren't interfering with QT, which isn't a DirectShow player.

Edit: they don't get enabled here after deleting ffdshow's registry keys. Theora does however, and I will fix that.

When installing ffdshow, there's this entry called "Reset all video/audio settings" or something like that, for both video and audio. I thought the purpose of checking that entry (not half-checked, but fully checked) was to remove any video codec entries. That's why I find it odd to see that when I check it, those two QTxx formats are enabled.

It's not like it's hard to disable them manually each time after installing ffdshow, but I really don't see the point in having them enabled. Let's see, when checking that entry during setup, divx, xvid, h264, and all of the audio formats are disabled, but these two are not. Which exactly are more likely to be used by people, these two oddballs or the really common formats ? It doesn't make sense.

Besides, those two don't help with Quicktime playback either, you'd need the audio formats for Quicktime enabled as well (and they are not when you reset the audio settings during setup), and not all audio formats Quicktime has used in the past can be decoded by ffdshow either, at least from what I remember. Once again, it doesn't make sense and it's not consistent.

I'm starting to feel this is more an issue of "this guy always criticizes us, so we'll always say No to whatever he says". If that's the case, you can do better than that.

[haruhiko_yamagata]

Finally, a few bugs that have been reported before but I don't know if they're accounted officially:
1. mpeg1 layer 3 in avi files causes "clicks" when libavcodec is used as a decoder (Microsoft's avi splitter is used); same files don't show this behavior when mp3lib for instance is used
2. mpeg1 layer 2 in mpg files also causes clicks when libacodec is used as a decoder (Microsoft's mpeg splitter is used); same files don't show this behavior when mp3lib for instance is used

I can't reproduce. Is it hard to hear? Does it depend on samples?
I think Microsoft's AVI splitter is used.

[rack04]

My latest test results:

ffdshow tryouts svn 2399
User: 60s, kernel: 0s, total: 60s, real: 70s, fps: 63.3, dfps: 54.6

ffdshow tryouts -mt 2392
User: 5s, kernel: 0s, total: 6s, real: 52s, fps: 638.5, dfps: 73.5

[clsid]

@KoD, I generally don't use ffdshow's installer, so that's why I didn't notice it. I have fixed the install script.

[LoRd_MuldeR]

My latest test results:

ffdshow tryouts svn 2399
User: 60s, kernel: 0s, total: 60s, real: 70s, fps: 63.3, dfps: 54.6

ffdshow tryouts -mt 2392
User: 5s, kernel: 0s, total: 6s, real: 52s, fps: 638.5, dfps: 73.5

What video format? And how many threads/cores? :confused:

[rack04]

What video format?

General
Complete name : C:\Personal\Videos\inkheart-tlr2a_h1080p.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 153 MiB
Duration : 2mn 8s
Overall bit rate : 9 998 Kbps
Encoded date : UTC 2008-11-30 16:02:09
Tagged date : UTC 2008-11-30 16:02:09
Writing application : Yamb 2.0.0.8 [http://yamb.unite-video.com]

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 8s
Bit rate mode : Variable
Bit rate : 9 896 Kbps
Maximum bit rate : 26.7 Mbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.400
Frame rate mode : Constant
Frame rate : 29.970 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.215
Stream size : 151 MiB (99%)
Encoded date : UTC 2008-10-20 18:09:37
Tagged date : UTC 2008-11-30 16:02:17

Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 2mn 8s
Bit rate mode : Variable
Bit rate : 98.1 Kbps
Maximum bit rate : 164 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 44.1 KHz
Resolution : 16 bits
Stream size : 1.50 MiB (1%)
Encoded date : UTC 2008-11-30 16:02:16
Tagged date : UTC 2008-11-30 16:02:17


And how many threads/cores? :confused:

I don't know how to change the threads/cores.

The test was run on my laptop. Intel Mobile Core 2 Duo T7250.

[LoRd_MuldeR]

I don't know how to change the threads/cores.

START -> Programs -> ffdshow -> Video decoder configuration -> Decoder options -> Libavcodec options -> Number of decoding threads

The test was run on my laptop. Intel Mobile Core 2 Duo T7250.

That explains the "small" speed-up between ffdshow and ffdshow-MT. On a Quadcore you'd see a bigger difference :cool:

[rack04]

START -> Programs -> ffdshow -> Video decoder configuration -> Decoder options -> Libavcodec options -> Number of decoding threads



That explains the "small" speed-up between ffdshow and ffdshow-MT. On a Quadcore you'd see a bigger difference :cool:

So the note that pops up when changing the number of decoding threads that says "mpeg1/2 decoder only" does not apply? I can test later with my Q6600.

[LoRd_MuldeR]

So the note that pops up when changing the number of decoding threads that says "mpeg1/2 decoder only" does not apply?

With ffdshow-MT the "Number of decoding threads" options applies to H.264 too :)

[rack04]

With ffdshow-MT the "Number of decoding threads" options applies to H.264 too :)

So does the MT version contain all the changes that exist in the regular version?

[LoRd_MuldeR]

Probably the video renderer switch to GDI or something slower.
By the way, in which revision does the problem start? Is it the same from the start?

Sorry for late reply, I wasn't at home last night.

I can reproduce the problem with r2250 (oldest rev on my HDD), so it may be there since Yadif was added.
Think I never noticed the problem, because I usually enforce RGB32 output, for proper TV-Levels in YUV -> RGB conversion.

The reason why I think this may be a problem on the ffdshow side (not on the renderer's side) is that it won't happen with KernelBob.
As long as RGB32 output works, it's not a big problem for me though...

[STaRGaZeR]

I can't reproduce. Is it hard to hear? Does it depend on samples?
I think Microsoft's AVI splitter is used.

Yes, it depends on samples. And yes, Microsoft's splitter is used.
This sample is full of those glitches: http://unigine.com/download/video/Unigine_Tropics_1024x576.avi .

[MatMaul]

Yes, it depends on samples. And yes, Microsoft's splitter is used.
This sample is full of those glitches: http://unigine.com/download/video/Unigine_Tropics_1024x576.avi .
there is an audible glitch at 1mn 10s which doesn't appear with mp3lib

[clsid]

So does the MT version contain all the changes that exist in the regular version?
Most changes from the trunk are applied also applied to the MT branch. There is a delay in the updates though, it can take a few days.

[clsid]

Support for RealVideo4 (RV40) has been added at revision 2405. It works reasonably well with the few files I tried. Although not everything plays as smooth as it should. And no, I don't know how to fix that.

[tal.aloni]

Guys, please check if you can pass-through DTS-Wav, or something else which have 44100 khz frequency.

I'm not sure if it's a bug, or something with my platform.
(I can pass-through 44,100khz fine using AC3filter)

Thanks,
Tal

[ash925]

I am a bit confused about the following,when an application like megui(x264) is used to encode an avisynth script with an xvid,divx etc source does changing the settings of ffdshowz(sharpen,blur etc) in software like mpc(patched builds) have an effect on the content decoded as input for the encoder.

[clsid]

Yes, the settings in ffdshow will apply to all programs that use it for decoding.

You could make a new Profile with default settings and let that autoload based on the application exe of MeGUI.

[fastplayer]

Why does the "Apply"-button change its state from disabled to enabled every time you navigate to "DirectShow control" in ffdshow's options even though you haven't changed any setting on that page at all? I find this confusing because it suggests that I have performed - possibly unwanted - changes...

[tetsuo55]

Support for RealVideo4 (RV40) has been added at revision 2405. It works reasonably well with the few files I tried. Although not everything plays as smooth as it should. And no, I don't know how to fix that.

I saw that change, been waiting for it for some time.

Your results vary? With smooth do you mean stuttering or artifacts?

[clsid]

Here is a sample file:
http://www.matroska.org/samples/matrix/Matrix.Reloaded.Trailer-RV9-Karl640x432_HE_AAC_subtitled_chapters.mkv

This file has a FPS of 25.000, but ffdshow shows values of 12.658 and 1000.000 several times.

[STaRGaZeR]

I've been using CoreAVC to see some files unplayable with ffdshow for now (predictive lossless to be precise) and I've noticed a major difference while seeking between the two. CoreAVC never shows garbage on screen. If a frame is incomplete at the point you've specified it pauses for a few miliseconds to complete it before displaying. ffdshow doesn't do this, and it can show pixelation, wrong colors, etc. that can last for more or less time depending on the source. Is this how libav is supposed to work, or this is ffdshow's custom behaviour? Not a bug, but it's really nice to see and improves visual experience.

What do you guys think?

[LoRd_MuldeR]

I've been using CoreAVC to see some files unplayable with ffdshow for now (predictive lossless to be precise) and I've noticed a major difference while seeking between the two. CoreAVC never shows garbage on screen. If a frame is incomplete at the point you've specified it pauses for a few miliseconds to complete it before displaying. ffdshow doesn't do this, and it can show pixelation, wrong colors, etc. that can last for more or less time depending on the source. Is this how libav is supposed to work, or this is ffdshow's custom behaviour? Not a bug, but it's really nice to see and improves visual experience.

What do you guys think?

I guess if you seek to a NONE-IDR frame, then CoreAVC will go back to the previous IDR frame and decode all frames up to the current frame.
Or it waits for the next IDR frame to come. Anyways, this would explain the delay (pausing) and why the frame is displayed properly.

In contrast ffdshow/libavcodec obviously will decode the frame you throw at it. Hence you may see corrupted output after seek until the next IDR frame is reached.
But I think this also depends on the container. Usually you should never seek to a NONE-IDR frame. Doesn't happen with my MP4/MKV files at least...

[Eragon4ever]

What STaRGaZeR describes is a bug with (some) older H.264 files. http://roundup.mplayerhq.hu/roundup/ffmpeg/issue669

Assuming he is talking about a seeking issue.

[cbemoore]

I've just found a bug with DTS decoding in the latest (rev 2405) ffdshow code. I guess its either the decoder at fault, or maybe its related to the recent audio restructuring code.

My ffdshow mixer is set to 5channels+LFE, and I'm trying to play a 3-channel DTS film with Left, Center and Right channels. For some reason, the center channel being sent to my rear speakers instead of the front center. Older versions of ffdshow didn't have this issue. I haven't enabled ffdshow channel swapping, so that's not the problem.

Just to confirm the problem, I tried using S/PDIF to my receiver, and the receiver outputs correctly to the front center speaker.

Is there anything I can do to help debug the problem? I can upload a sample if you let me know where to put it.

[LoRd_MuldeR]

Thank you for finding this issue.
After fixing it at rev 2397, it looks like more general problem.

I just installed the r2407 build and I still get heavy flickering with "Greedy 2 Frame". Also the slider problem remains.

Note that it still was working fine in r2342, so it must have been broken after that revision somehow...

[STaRGaZeR]

I guess if you seek to a NONE-IDR frame, then CoreAVC will go back to the previous IDR frame and decode all frames up to the current frame.
Or it waits for the next IDR frame to come. Anyways, this would explain the delay (pausing) and why the frame is displayed properly.

In contrast ffdshow/libavcodec obviously will decode the frame you throw at it. Hence you may see corrupted output after seek until the next IDR frame is reached.
But I think this also depends on the container. Usually you should never seek to a NONE-IDR frame. Doesn't happen with my MP4/MKV files at least...

This is what I'm referring to. Would it be better to go back to the previous IDR frame to display always complete frames when seeking? In my computer CoreAVC takes miliseconds, I can see it but it's miles better than having several seconds of corrupted image due to a large section without an IDR frame. Oh and it does happen with MP4/MKV too.

[LoRd_MuldeR]

Oh and it does happen with MP4/MKV too.

Can't see corrputed image when seeking in H.264 files (MKV or MP4), using MPC-HC + HaaliMediaSplitter + ffdshow-MT :confused:

Does it happen with all files or specific ones only?

[STaRGaZeR]

Can't see corrputed image when seeking in H.264 files (MKV or MP4), using MPC-HC + HaaliMediaSplitter + ffdshow-MT :confused:

Does it happen with all files or specific ones only?

All files in general, with your same configuration. In some of those files it's almost not noticeable though. And by the way the MT branch has this bloking issue even more noticeable in my experience.

Eragon4ever, we're talking about the same thing. But it is not related to only one file or stream.

[Ryokurin]

This may be a stupid question, but I'm missing where the mt versions are located, or are they not generally available yet?

[LoRd_MuldeR]

This may be a stupid question, but I'm missing where the mt versions are located, or are they not generally available yet?

Builds are available here, for example:
http://www.xvidvideo.ru/content/category/1/40/30/

[rack04]

That explains the "small" speed-up between ffdshow and ffdshow-MT. On a Quadcore you'd see a bigger difference :cool:

ffdshow-MT, svn 2407 (4 Threads)
User: 9s, kernel: 0s, total: 9s, real: 23s, fps: 384.7, dfps: 165.1

ffdshow, svn 2399 (4 Threads)
User: 51s, kernel: 0s, total: 51s, real: 55s, fps: 75.0, dfps: 68.6

ffdshow-MT, svn 2407 (2 Threads)
User: 5s, kernel: 0s, total: 6s, real: 40s, fps: 636.2, dfps: 94.7

ffdshow, svn 2399 (2 Threads)
User: 51s, kernel: 0s, total: 51s, real: 59s, fps: 74.6, dfps: 64.1

[Anima123]

Support for RealVideo4 (RV40) has been added at revision 2405. It works reasonably well with the few files I tried. Although not everything plays as smooth as it should. And no, I don't know how to fix that.

Though it's not really usable at this stage, this makes people to get more expectation on RV decoding. Thanks ffdshow devs and thanks Kostya who write the original code without specifications of RV format.

[whurlston]

Where can I find a list of the GUIDs for accepted pin connections for TrueHD and DTS-HD?

[LoRd_MuldeR]

ffdshow-MT, svn 2407 (4 Threads)
User: 9s, kernel: 0s, total: 9s, real: 23s, fps: 384.7, dfps: 165.1

ffdshow, svn 2399 (4 Threads)
User: 51s, kernel: 0s, total: 51s, real: 55s, fps: 75.0, dfps: 68.6

ffdshow-MT, svn 2407 (2 Threads)
User: 5s, kernel: 0s, total: 6s, real: 40s, fps: 636.2, dfps: 94.7

ffdshow, svn 2399 (2 Threads)
User: 51s, kernel: 0s, total: 51s, real: 59s, fps: 74.6, dfps: 64.1

The difference between 2 threads and 4 threads in ffdshow r2399 can be explained with inaccurateness of the test.
It never uses more than two threads for H.264, results should be the same.

The difference between ffdshow and ffdshow-MT is as expected:
147% speed with 2 threads and 257% speed with 4 threads (compared to ffdshow r2399).

[haruhiko_yamagata]

@developers,
when I fixed the Grab filter related Color Space conversion issue, I noticed that there were some major inconsistencies regarding the RGB colorspace. the FF_CSP_ enum is referring to how the bytes are stored in memory, which is the opposite of the writing order under x86 architecture (little endians).
we work with many libraries, some use the write order(libmplayer), and some use the "byte order" (ffmpeg).

(also, when writing to files, the write order equals to the "byte order", which makes things even more confusing)
it's hard to decide what's right to do in this case, because in any way, our enum will appear to be erroneous,

I made a patch that I think will make the code more clear,
I guess future work should be done (comments etc.),
I would like to hear what you think, and if you have a better suggestion.

http://iknowu.net/files/public/ffdshow/2401-LittleEndian.patch

Tal

to summerize, I replaced the FF_CSP_RGB?? in the enum with FF_CSP_BGR?? and vice versa, and defined the following: (I also replaced the FF_CSP_????? in the rest of the code, to match the appropriate values)

#define FF_CSP_RGB15_LITTLE_ENDIAN FF_CSP_BGR15
#define FF_CSP_RGB16_LITTLE_ENDIAN FF_CSP_BGR16
#define FF_CSP_RGB24_LITTLE_ENDIAN FF_CSP_BGR24
#define FF_CSP_RGB32_LITTLE_ENDIAN FF_CSP_BGR32
#define FF_CSP_BGR15_LITTLE_ENDIAN FF_CSP_RGB15
#define FF_CSP_BGR16_LITTLE_ENDIAN FF_CSP_RGB16
#define FF_CSP_BGR24_LITTLE_ENDIAN FF_CSP_RGB24
#define FF_CSP_BGR32_LITTLE_ENDIAN FF_CSP_RGB32

Sorry for late reply. I've been too confused to reply...
I'm still confused, but I prefer to call it after how it is ordered in memory.
I would prefer just adding comment how it should look like in memory and register.
Updating libswscale is still in mess in the ffmpeg-mt branch, so minimal change is convenient for me.

[haruhiko_yamagata]

All files in general, with your same configuration. In some of those files it's almost not noticeable though. And by the way the MT branch has this bloking issue even more noticeable in my experience.

Eragon4ever, we're talking about the same thing. But it is not related to only one file or stream.
I know seek is somewhat broken. ffmpeg-mt branch is more broken, or it's not even implemented.
ffdshow has the

@LoRd_MuldeR
premiere-paff.ts reproduce the problem.

[haruhiko_yamagata]

What STaRGaZeR describes is a bug with (some) older H.264 files. http://roundup.mplayerhq.hu/roundup/ffmpeg/issue669

Assuming he is talking about a seeking issue.
Without looking at this file, i think the solution is to implement parsing of the SEI that tells one at what point the decoded data is correct after seeking (random access).

ffdshow decode the SEI, but still show the problem. Even if I disable allowing I frame as an entry point. IDR and GDR should be OK as an entry point.
As Dark Shikari pointed, it looks like a regression bug of libavcodec.

[LoRd_MuldeR]

@LoRd_MuldeR
premiere-paff.ts reproduce the problem.

Because it's TS and hence we may seek to None-IDR frames, maybe? :confused:

[haruhiko_yamagata]

Because it's TS and hence we may seek to None-IDR frames, maybe? :confused:
TS file has IDR and GDR flags (SEI message). Seeking should work.

[haruhiko_yamagata]

Sorry for late reply, I wasn't at home last night.

I can reproduce the problem with r2250 (oldest rev on my HDD), so it may be there since Yadif was added.
Think I never noticed the problem, because I usually enforce RGB32 output, for proper TV-Levels in YUV -> RGB conversion.

The reason why I think this may be a problem on the ffdshow side (not on the renderer's side) is that it won't happen with KernelBob.
As long as RGB32 output works, it's not a big problem for me though...Does it work if Fizick's AviSynth-yadif is enabled in ffdshow?

[tal.aloni]

Sorry for late reply. I've been too confused to reply...
I'm still confused, but I prefer to call it after how it is ordered in memory.
I would prefer just adding comment how it should look like in memory and register.

I know what you mean about being confused :)

OK, I will add comments.
and OK, we'll call it after how it is ordered in memory.

how about adding a _WRITE_ORDER definitions for the PNG / BMP saving part?
(and maybe for the interaction with libmplayer as well)


#define FF_CSP_RGB24_WRITE_ORDER FF_CSP_BGR24
#define FF_CSP_BGR24_WRITE_ORDER FF_CSP_RGB24


(I would like other developers to donate their opinion too)

p.s. I'm not going to touch libswscale, this is internal representation only.

Tal

[LoRd_MuldeR]

TS file has IDR and GDR flags (SEI message). Seeking should work.

Maybe the TS parser/splitter is at fault, sending a None-IDR frame to the decoder after seeking? :confused:

Does it work if Fizick's AviSynth-yadif is enabled in ffdshow?

Yup. Just gave it a try. No "slow motion" problem with the Avisynth version of Yadif and "YV12,adj" output.
But it's back as soon as I switch to internal Yadif ...

[haruhiko_yamagata]

Maybe the TS parser/splitter is at fault, sending a None-IDR frame to the decoder after seeking? :confused:
The splitters may start sending at any random frame. Decoders has to drop frames until the first IDR or GDR arrives.
ffdshow does this correctly, though I'm not sure if I haven't bugged.

[LoRd_MuldeR]

Yup. Just gave it a try. No "slow motion" problem with the Avisynth version of Yadif and "YV12,adj" output.
But it's back as soon as I switch to internal Yadif ...

Now I'm completely confused!

All of a sudden the "slow down" also happens with RGB32 output and with both, internal Yadif -and- Avisynth Yadif. Why? It did work all the time :confused:
But I still doesn't happen with KernelBob. This all makes me believe DVBViewer is totally borked, showing random behavior...

:(

[ash925]

@clsid:thnx

[Keepitsimple]

lord_mulder, Is there an alternative to dvbviewer? Ie opensource dvb viewing.

[LoRd_MuldeR]

lord_mulder, Is there an alternative to dvbviewer? Ie opensource dvb viewing.

There are many DVB applications. But my Technisat card ships with a special edition of DVBViewer and other apps don't recognize my card (using the standard drivers).

I know there are alternative drivers (BDA) available that should make the card work with other apps, but so far DVBViewer works fairly good for me.

[Snowknight26]

In r2314, if DTS is set to libavcodec and DTS is checked under Output -> pass-through, files with DTS don't play. Works fine with libdts though.

[tal.aloni]

In r2314, if DTS is set to libavcodec and DTS is checked under Output -> pass-through, files with DTS don't play. Works fine with libdts though.

Works fine here (2407). maybe it's related to problematic file?
EDIT:
when DTS-passthrough is checked, libavcodec is not being used (if the file can be passed through),
so can I assume the file cannot be passed through? is it DTS-HD?

[KoD]

@KoD, I generally don't use ffdshow's installer, so that's why I didn't notice it. I have fixed the install script.
Thank you for doing it. Sorry for being a little rude.

[KoD]

I can't reproduce. Is it hard to hear? Does it depend on samples?
I think Microsoft's AVI splitter is used.

Yes, it depends on samples. And these glicthes sometimes don't happen if you seek in the file. But the glitches happen if you let the file play from the start without seeking in it.

Since a mp3 sample was posted, here is a mpeg1 audio layer 2 sample in a mpg. There are some glitches after 2 minutes 10 seconds or so in the video with libavcodec, but not with mp3lib. Microsoft's mpeg splitter is used.

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

[haruhiko_yamagata]

Yes, it depends on samples. And these glicthes sometimes don't happen if you seek in the file. But the glitches happen if you let the file play from the start without seeking in it.

Since a mp3 sample was posted, here is a mpeg1 audio layer 2 sample in a mpg. There are some glitches after 2 minutes 10 seconds or so in the video with libavcodec, but not with mp3lib. Microsoft's mpeg splitter is used.

http://www.mediafire.com/?myzzynzj2za
Thanks, I hope the latest svn is OK.

[haruhiko_yamagata]

Subtitles still bad. (See previous post).


http://img175.imageshack.us/img175/9320/subsny9.jpg

@albain:Please respond or I will revert rev 2270.
I have tried to fix but it's hard.

[haruhiko_yamagata]

I know what you mean about being confused :)

OK, I will add comments.
and OK, we'll call it after how it is ordered in memory.

how about adding a _WRITE_ORDER definitions for the PNG / BMP saving part?
(and maybe for the interaction with libmplayer as well)


#define FF_CSP_RGB24_WRITE_ORDER FF_CSP_BGR24
#define FF_CSP_BGR24_WRITE_ORDER FF_CSP_RGB24


(I would like other developers to donate their opinion too)

p.s. I'm not going to touch libswscale, this is internal representation only.

Tal
Personally, it's more confusing for me.
Once we decided to call it after how it is ordered in memory, we can remember it. Please add some comment to PNG and BMP conversion part.

[Reimar]

Personally, it's more confusing for me.
Once we decided to call it after how it is ordered in memory, we can remember it. Please add some comment to PNG and BMP conversion part.

Just to explain why it is in FFmpeg the way it is: calling it "after how it is ordered in memory" works really badly for the 16, 15 and 8 bit RGB/BGR formats (same for the 10 bit/component formats except FFmpeg does not support them yet).

[Snowknight26]

Works fine here (2407). maybe it's related to problematic file?
EDIT:
when DTS-passthrough is checked, libavcodec is not being used (if the file can be passed through),
so can I assume the file cannot be passed through? is it DTS-HD?

No its not DTS-HD, but yes it could be passed through because as soon as I switched the decoder to libdts it would pass-through just fine.

[nlnl]

Can we do inverse telicine + deinterlace transformation in ffdshow for film source (29i (film) -> 24p) ?
Thank you.

[Leak]

Can we do inverse telicine + deinterlace transformation in ffdshow for film source (29i (film) -> 24p) ?
Errr... yes? (http://ffdshow-tryout.wiki.sourceforge.net/AviSynth)

np: Mr. Scruff - Kalimba (Ninja Tuna)

[tal.aloni]

Personally, it's more confusing for me.
Once we decided to call it after how it is ordered in memory, we can remember it. Please add some comment to PNG and BMP conversion part.

OK, here it is, comments only patch:
http://iknowu.net/files/public/ffdshow/2410-Comments-RC2.patch

Please notify me if you think something is inaccurate.

Tal

[Snowknight26]

It seems that the channel order for 5.1 channel AC3 streams differs between liba52 and libavcodec in r2314 - using the Mixer to downmix to 2.0 though so don't hold me to it. I'll check the latest revision soon but I doubt there are any changes as they would have been mentioned in the SVN (unless its under updated ffmpeg).

[haruhiko_yamagata]

OK, here it is, comments only patch:
http://iknowu.net/files/public/ffdshow/2410-Comments-RC2.patch

Please notify me if you think something is inaccurate.

TalThank you, the patch looks OK. Please commit it.

[haruhiko_yamagata]

Just to explain why it is in FFmpeg the way it is: calling it "after how it is ordered in memory" works really badly for the 16, 15 and 8 bit RGB/BGR formats (same for the 10 bit/component formats except FFmpeg does not support them yet).Thank you for letting me know.
I don't care about RGB15/16, because we hardly use them.

[haruhiko_yamagata]

It seems that the channel order for 5.1 channel AC3 streams differs between liba52 and libavcodec in r2314 - using the Mixer to downmix to 2.0 though so don't hold me to it. I'll check the latest revision soon but I doubt there are any changes as they would have been mentioned in the SVN (unless its under updated ffmpeg).Do you have a sample that is easy to hear?

[cbemoore]

It seems that the channel order for 5.1 channel AC3 streams differs between liba52 and libavcodec in r2314 - using the Mixer to downmix to 2.0 though so don't hold me to it. I'll check the latest revision soon but I doubt there are any changes as they would have been mentioned in the SVN (unless its under updated ffmpeg).

You're right. I originally posted the issue here (http://forum.doom9.org/showthread.php?p=1219215#post1219215), but noone commented.

I've just tried changing from libavcodec to liba52, and this solves the problem. So it looks like libavcodec is broken.

@Haruhiko - I've got a 66MB sample if that helps? How can I send it to you?

[Snowknight26]

Do you have a sample that is easy to hear?

Funny you should mention that.. I just deleted it. Found another one though. (http://www.stfcc.org/misc/pleasantville.ac3)

Also, another thing. With DTS being decoded with libavcodec, the output is always 16-bit, regardless of what I specify under Output.

[tal.aloni]

Thank you, the patch looks OK. Please commit it.

I have commited as rev. 2415,
I accidently forgot to add comment while committing, (oh, the irony), please forgive me.
Reimar, Thanks for stepping in to clarify.

I still feel we could do a little bit better regarding the issue. (both ffdshow and ffmpeg)

Tal

[whurlston]

I can decode TrueHD audio streams by connecting to the ArcSoft MPEG demux but the channel mappings are off. The center channel plays out of the back left surround. Is anyone else experiencing this?

[cbemoore]

I can decode TrueHD audio streams by connecting to the ArcSoft MPEG demux but the channel mappings are off. The center channel plays out of the back left surround. Is anyone else experiencing this?

Not sure about TrueHD, but DTS mappings are wrong with libavcodec....

[STaRGaZeR]

The MP3 clicks using libav are gone with the last rev! In fact there are no problems when seeking, playing... whatever. Also if mp3lib is selected ffdshow crashes the player (maybe with the changes in rev2416?).

cbemoore, please describe your details because DTS mapping is fine here with libav. Samples are always welcome.

PS: any news about the high pitch sound when playing DVDs (only happens with DVDs as a whole, not with the individual VOBs) with libavcodec AC3 in MPC-HC?

[clsid]

I will fix the mp3lib problem. It is an SSE2 issue and MinGW GCC being a bitch with alignment.

[haruhiko_yamagata]

Since we have dropped ANSI builds, translations are welcome in UNICODE.
Many of the files in \bin\languages are garbled for me.
Maybe because I don't have proper font for them, but Unicode works definitely better.
I converted ffdshow.1028.tc successfully, but I can't convert most of the files.
Please convert them to UNICODE.

[fastplayer]

Since we have dropped ANSI builds, translations are welcome in UNICODE.
So support for Win95/98/ME is no more? Since which build? Link to last build?
This should go into the FAQ. I'll add an entry.

[clsid]

Here are the files converted to Unicode (with UltraEdit):
http://www.zshare.net/download/5228467730784fef/

Revision 2352 is the last build that works on win9x.

[haruhiko_yamagata]

Funny you should mention that.. I just deleted it. Found another one though. (http://www.stfcc.org/misc/pleasantville.ac3)
I can't find any difference between liba52 and libavcodec. Which channel is wrong? Where is it audible?

Also, another thing. With DTS being decoded with libavcodec, the output is always 16-bit, regardless of what I specify under Output.
I can't reproduce.

[fastplayer]

Revision 2352 is the last build that works on win9x.
I guess that's enough:
http://ffdshow-tryout.wiki.sourceforge.net/FAQ#win9x

[haruhiko_yamagata]

Here are the files converted to Unicode (with UltraEdit):
http://www.zshare.net/download/5228467730784fef/
ffdshow.1028.tc doesn't look correct to me.
Did you manually specify the original local?

[tal.aloni]

please review my latest patch:

1. DRC is now based on presets, (this might be useful for "night mode" preset).

2. DRC can now be turned on/off immediately, without restarting ffdshow, very useful to test its effects.

3. I moved the DRC checkbox to the processing tab,
IMO, this is the most appropriate location, this would also give me the needed space to add a DRC Level "slider" in the future. (other places suggested in the past are problematic)

http://iknowu.net/files/public/ffdshow/Processing-DRC.png

Patch:
http://iknowu.net/files/public/ffdshow/2414-DRCBasedOnPresets.patch

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2414-DRC_20081205.exe

[fastplayer]

3. I moved the DRC checkbox to the processing tab,
IMO, this is the most appropriate location,...
...and the most un-intuitive location IMO... :p

[haruhiko_yamagata]

3. I moved the DRC checkbox to the processing tab,
IMO, this is the most appropriate location, this would also give me the needed space to add a DRC Level "slider" in the future. (other places suggested in the past are problematic)
It's difficult to find. People don't open that page.
Please add a new page below "Processing" with fixed order.


//EDIT this was my mistake.
The installer upgrade path will continue to overwrite all the presets on every installation, because it does not delete the old registry value.

[fastplayer]

Are these "Processing" options related to "Presets" or not? Because that's what the indent suggests. It somehow "confuses" me and probably even Joe Sixpack and Joe The Plumber... :D
How about moving it close to the "Output" options?

[clsid]

ffdshow.1028.tc doesn't look correct to me.
Did you manually specify the original local?
No. I only converted from ASCII to Unicode.

ffdshow.2052.sc was the only file that originally had UTF-8 encoding. Maybe that is why something went wrong. Are the other files OK?

Maybe the editors mentioned here will be better:
http://sourceforge.net/tracker/index.php?func=detail&aid=1952999&group_id=173941&atid=867360

[haruhiko_yamagata]

No. I only converted from ASCII to Unicode.

ffdshow.2052.sc was the only file that originally had UTF-8 encoding. Maybe that is why something went wrong. Are the other files OK?

Maybe the editors mentioned here will be better:
http://sourceforge.net/tracker/index.php?func=detail&aid=1952999&group_id=173941&atid=867360
UTF-8 is OK, though the recommended is UTF-16 with BOM (little endian).
I can't find a good converter that can convert all the files.
You have to specify locale (for example 1041 for Japanese). Auto detection may succeed, but we can't depend on it.

[haruhiko_yamagata]

Why does the "Apply"-button change its state from disabled to enabled every time you navigate to "DirectShow control" in ffdshow's options even though you haven't changed any setting on that page at all? I find this confusing because it suggests that I have performed - possibly unwanted - changes...
I can't reproduce this.

[haruhiko_yamagata]

I've just found a bug with DTS decoding in the latest (rev 2405) ffdshow code. I guess its either the decoder at fault, or maybe its related to the recent audio restructuring code.

My ffdshow mixer is set to 5channels+LFE, and I'm trying to play a 3-channel DTS film with Left, Center and Right channels. For some reason, the center channel being sent to my rear speakers instead of the front center. Older versions of ffdshow didn't have this issue. I haven't enabled ffdshow channel swapping, so that's not the problem.

Just to confirm the problem, I tried using S/PDIF to my receiver, and the receiver outputs correctly to the front center speaker.

Is there anything I can do to help debug the problem? I can upload a sample if you let me know where to put it.
Please send it through MegaUpload or sendspace.

[fastplayer]

I can't reproduce this.
It happens always for "DirectShow control" in the ffdshow's video decoder configuration. It will not happen if the last saved option is "DirectShow control". That is when you exit ffdshow settings with this page open.
I can reproduce it on Server 2003 (32bit) as well as XP (32bit) inside a VM. This has been happening for a long time but I was too lazy to post about it... :o
It happens sometimes in audio configuration, too. Unfortunately, I can not reproduce this reliably.

Edit: Forget the last sentence. The "Apply" button goes from "disabled" to "enabled" when I visit OSD first (without changing any setting at all) in ffdshow audio configuration.
Edit - part deux: On a fresh install, ffdshow audio configuration --> DirectShow control --> Apply button --> Enabled
Edit - part trois: On a fresh install, ffdshow audio configuration --> OSD --> Apply button --> Enabled --> click on Apply --> go to another category --> go back to OSD --> Apply button enabled again...
For me, the behavior of the "Apply" button is completely erratic.

[Dark Eiri]

Can you please add fallout3.exe to the blacklist by default? It causes the game to crash every 30 seconds or so.

[tal.aloni]

Haruhiko, you were partially right, the 'default' preset was being overwritten, I have fixed it.

anyway, I have created another tab, as requested,
and called it "Decoder options", also, I created an "audio" folder in the "dialog" folder, I hope that's OK. (I think that seperation to audio and video there would be preferred)

http://iknowu.net/files/public/ffdshow/drc/Processing-DRC-RC2.png

Patch:
http://iknowu.net/files/public/ffdshow/drc/2420-DRCBasedOnPresets-RC4.patch

Build:
http://iknowu.net/files/public/ffdshow/drc/ffdshow_rev2420-PresetDRC-RC4_20081205.exe

Tal

Note:
I have manualy modified the icl10 and the VC2003 project files, but I don't have these compilers to test.
if something is wrong, please notify me.

[Snowknight26]

I can't find any difference between liba52 and libavcodec. Which channel is wrong? Where is it audible? Maybe it only happens in mkvs. http://www.stfcc.org/misc/pleasantville.mkv

I can't reproduce.
http://www.stfcc.org/misc/dts.libavcodec.jpg
http://www.stfcc.org/misc/dts.libdts.jpg
Notice the system tray info.

[clsid]

Can you please add fallout3.exe to the blacklist by default? It causes the game to crash every 30 seconds or so.
It is already on the default blacklist. Reset yours to default.

[KoD]

ffdshow translation files converted to UTF16LE & BOM. Manually converted using the most likely code pages. Download link here (http://s000.tinyupload.com/index.php?file_id=27160445829653187709). The japanese translation file is the one posted on SVN 5 hours ago. The english transaltion file was not included.

[haruhiko_yamagata]

http://www.stfcc.org/misc/dts.libavcodec.jpg
http://www.stfcc.org/misc/dts.libdts.jpg
Notice the system tray info.
Is this a bug? I think it's the spec.

[haruhiko_yamagata]

ffdshow translation files converted to UTF16LE & BOM. Manually converted using the most likely code pages. Download link here (http://s000.tinyupload.com/index.php?file_id=27160445829653187709). The japanese translation file is the one posted on SVN 5 hours ago. The english transaltion file was not included.Good work. It looks OK. Can anyone confirm?
:thanks:

[fastplayer]

Good work. It looks OK. Can anyone confirm?
:thanks:
I can't confirm tc/sc/ja/jp because PSPad only shows some squares but everything else looks fine.

[Eragon4ever]

Everything looking fine here (tc/sc/ja/jp included). You might want to remove jp, though.

[clsid]

Maybe it only happens in mkvs. http://www.stfcc.org/misc/pleasantville.mkv


http://www.stfcc.org/misc/dts.libavcodec.jpg
http://www.stfcc.org/misc/dts.libdts.jpg
Notice the system tray info.
You have checked 16/24/32bit as allowed outputs. So when either of those are outputted, the behavior is correct.

libavcodec decodes to 16-bit, so that is why it chooses that as output.
liba52 probably decodes to 32-bit, so that is why it output as 32-bit

If you enable only 32-bit as allowed output, then ffdshow will output 32-bit. That means that when using libavcodec, it will convert from 16 to 32. That does not mean better quality, just extra CPU load.

[tal.aloni]

@developers,
The following variables have been removed from ffmpeg a long time ago, and I'm about to remove them from ffdshow as well:

inter_matrix_luma,inter_matrix_chroma,intra_matrix_luma,intra_matrix_chroma

if you have any objection, please notify me.

Patch:
http://iknowu.net/files/public/ffdshow/2420-IntraMatrixLuma.patch

[clsid]

OK.

h263.c also contains a few lines of inter/intra_matrix stuff that differs from FFmpeg SVN. I suspect that can be removed as well.

[BatKnight]

Is there any other site where one can download the latest ffdshow-MT build when Alexin's www.xvidvideo.ru is down?

Thanks

Bat

[Snowknight26]

If you enable only 32-bit as allowed output, then ffdshow will output 32-bit. That means that when using libavcodec, it will convert from 16 to 32. That does not mean better quality, just extra CPU load.

Why doesn't libavcodec just output 32-bit then downsample if necessary? Shouldn't it try to connect with the highest bitdepth allowed?

Continuing with the trend, AC3 is only decoded as 16-bit when 16/24/32-bit output is set. Since AC3 doesn't have a bitdepth, its up to the decoder to choose what the output is. Shouldn't libavcodec do all its internal decoding in 64-bit floating point then downsample to the maximum output allowed (32-bit if its checked)?

[Dark Shikari]

Why doesn't libavcodec just output 32-bit then downsample if necessary? Shouldn't it try to connect with the highest bitdepth allowed?

Continuing with the trend, AC3 is only decoded as 16-bit when 16/24/32-bit output is set. Since AC3 doesn't have a bitdepth, its up to the decoder to choose what the output is. Shouldn't libavcodec do all its internal decoding in 64-bit floating point then downsample to the maximum output allowed (32-bit if its checked)?Almost nothing in lavc uses 64-bit floating point IIRC; it's way too slow.

Internal decoding AFAIK is done in 32-bit float. The output conversion is defined by the sample_fmt, I think.

[tal.aloni]

I've added support for setting DRC level for liba52 (and added another function to modify it during playback), this could be useful for other projects besides ffdshow, but the website at sourceforge seems dead.

does anybody know if the project is still maintained somewere, and how can I contact the developers?

Thanks,
Tal

[fastplayer]

@clsid:
A RAR file (languages_unicode.rar) slipped into the {app}\languages directory and IS script.

[haruhiko_yamagata]

I have created another tab, as requested,
and called it "Decoder options", also, I created an "audio" folder in the "dialog" folder, I hope that's OK. (I think that seperation to audio and video there would be preferred)

http://iknowu.net/files/public/ffdshow/drc/Processing-DRC-RC2.png

I said below "Processing", but excuse me...
If it is called "Decoder options" it should be consistent with video, above "Output".
If we are not going to add more options in the page, "Dynamic range compression" is preferred because it is easier to find.
You might have to expand the width of the column though (IDD_FFDSHOWAUDIO). It looks somewhat ...
Anyway I'm not a good designer.

===================================================================
--- src/dialog/audio/CaudioDecoderOptions.cpp (revision 0)
+++ src/dialog/audio/CaudioDecoderOptions.cpp (revision 0)
@@ -0,0 +1,61 @@
+/*
+ * Copyright (c) 2004-2006 Milan Cutka
+ *
Please don't hesitate to put your name there.

[MatMaul]

here is a little patch concerning libavcodec which :
- activate high precision mp3 decoding (32 bits)
- activate the use of 32 bits output when the bitdepth of lossless format is superior to 16 (only concerning mlp atm)
Index: src/codecs/TaudioCodecLibavcodec.cpp
===================================================================
--- src/codecs/TaudioCodecLibavcodec.cpp (revision 2422)
+++ src/codecs/TaudioCodecLibavcodec.cpp (working copy)
@@ -125,6 +125,7 @@
switch (avctx->sample_fmt)
{
case SAMPLE_FMT_S16:fmt.sf=TsampleFormat::SF_PCM16;break;
+ case SAMPLE_FMT_S32:fmt.sf=TsampleFormat::SF_PCM32;break;
case SAMPLE_FMT_FLT:fmt.sf=TsampleFormat::SF_FLOAT32;break;
}
isGain=deci->getParam2(IDFF_vorbisgain);
@@ -231,7 +232,12 @@
{
fmt.setChannels(avctx->channels);
fmt.freq=avctx->sample_rate;
- fmt.sf=avctx->sample_fmt;
+ switch (avctx->sample_fmt)
+ {
+ case SAMPLE_FMT_S16:fmt.sf=TsampleFormat::SF_PCM16;break;
+ case SAMPLE_FMT_S32:fmt.sf=TsampleFormat::SF_PCM32;break;
+ case SAMPLE_FMT_FLT:fmt.sf=TsampleFormat::SF_FLOAT32;break;
+ }
}

// Correct channel mapping
Index: src/ffmpeg/config.h
===================================================================
--- src/ffmpeg/config.h (revision 2422)
+++ src/ffmpeg/config.h (working copy)
@@ -54,6 +54,8 @@
#define ENABLE_SMALL 0

#define ENABLE_GRAY 1
+
+#define CONFIG_AUDIO_NONSHORT 1


#define CONFIG_AASC_DECODER 1
Index: src/ffmpeg/libavcodec/mlp_parser.c
===================================================================
--- src/ffmpeg/libavcodec/mlp_parser.c (revision 2422)
+++ src/ffmpeg/libavcodec/mlp_parser.c (working copy)
@@ -258,8 +258,8 @@
goto lost_sync;

#ifdef CONFIG_AUDIO_NONSHORT
- avctx->bits_per_sample = mh.group1_bits;
- if (avctx->bits_per_sample > 16)
+ avctx->bits_per_raw_sample = mh.group1_bits;
+ if (avctx->bits_per_raw_sample > 16)
avctx->sample_fmt = SAMPLE_FMT_S32;
#endif
avctx->sample_rate = mh.group1_samplerate;
Index: src/ffmpeg/libavcodec/mlpdec.c
===================================================================
--- src/ffmpeg/libavcodec/mlpdec.c (revision 2422)
+++ src/ffmpeg/libavcodec/mlpdec.c (working copy)
@@ -302,7 +302,7 @@
m->avctx->frame_size = mh.access_unit_size;

#ifdef CONFIG_AUDIO_NONSHORT
- m->avctx->bits_per_sample = mh.group1_bits;
+ m->avctx->bits_per_raw_sample = mh.group1_bits;
if (mh.group1_bits > 16) {
m->avctx->sample_fmt = SAMPLE_FMT_S32;
}

[haruhiko_yamagata]

It happens always for "DirectShow control" in the ffdshow's video decoder configuration. It will not happen if the last saved option is "DirectShow control". That is when you exit ffdshow settings with this page open.
I can reproduce it on Server 2003 (32bit) as well as XP (32bit) inside a VM. This has been happening for a long time but I was too lazy to post about it... :o
It happens sometimes in audio configuration, too. Unfortunately, I can not reproduce this reliably.

Edit: Forget the last sentence. The "Apply" button goes from "disabled" to "enabled" when I visit OSD first (without changing any setting at all) in ffdshow audio configuration.
Edit - part deux: On a fresh install, ffdshow audio configuration --> DirectShow control --> Apply button --> Enabled
Edit - part trois: On a fresh install, ffdshow audio configuration --> OSD --> Apply button --> Enabled --> click on Apply --> go to another category --> go back to OSD --> Apply button enabled again...
For me, the behavior of the "Apply" button is completely erratic.
I can confirm when I visit OSD page, it turns to enabled.

[Snowknight26]

- activate the use of 32 bits output when the bitdepth of lossless format is superior to 16 (only concerning mlp atm)


Excellent. Hope FLAC (not like anyone uses libavcodec for it anyway, buggy) and LPCM come next if they don't already do that.

[haruhiko_yamagata]

here is a little patch concerning libavcodec which :
- activate high precision mp3 decoding (32 bits)
- activate the use of 32 bits output when the bitdepth of lossless format is superior to 16 (only concerning mlp atm)

Thank you, applied.

[tal.aloni]

Haruhiko,
1. the tabs are ordered by the order of execution,
so "Decoder options" should be on top, (right above "processing")
I would say that the "Decoder options" in the video decoder should be moved upward, and not the other way around.

2. I'm feeling much more comfortable with "Decoder options",
I'm assuming in the future it may be used for other settings.
(Dialog normalization for example)

Thanks for the feedback,
Tal

[haruhiko_yamagata]

Haruhiko,
1. the tabs are ordered by the order of execution,
so "Decoder options" should be on top, (right above "processing")
I would say that the "Decoder options" in the video decoder should be moved upward, and not the other way around.

2. I'm feeling much more comfortable with "Decoder options",
I'm assuming in the future it may be used for other settings.
(Dialog normalization for example)

Thanks for the feedback,
Tal
OK, but let's finalize beta6 before adding new features.
Please commit after beta6.

[Leak]

I said below "Processing", but excuse me...
If it is called "Decoder options" it should be consistent with video, above "Output".
Shouldn't "Decoder options" be up there anyway? After all those options are all applied before any filtering is done while the "Output" options all apply after filtering...

EDIT: *reads rest of thread* Yeah, what Tal.Aloni said... :)

np: Boy Robot - My Heart's Still Beating (Glamorizing Corporate Lifestyle)

[haruhiko_yamagata]

Shouldn't "Decoder options" be up there anyway? After all those options are all applied before any filtering is done while the "Output" options all apply after filtering...

EDIT: *reads rest of thread* Yeah, what Tal.Aloni said... :)

np: Boy Robot - My Heart's Still Beating (Glamorizing Corporate Lifestyle)
Yes, but still below OSD?
OSD is not in the preset settings.

[tal.aloni]

OK, but let's finalize beta6 before adding new features.
Please commit after beta6.

OK, I'll commit after beta 6.

Here is the latest design:
http://iknowu.net/files/public/ffdshow/drc/Processing-DRC-RC5.png

Tal

p.s.
IMO, OSD should be in the preset settings,
but I can see that it will take much work to implement that.

[haruhiko_yamagata]

In r2314, if DTS is set to libavcodec and DTS is checked under Output -> pass-through, files with DTS don't play. Works fine with libdts though.Please update to the latest and if the problem is still there, please send us a sample.
Also information about your system and settings may be required.

[haruhiko_yamagata]

I have cleaned most bugs.
Anything that should be fixed before beta6?

[haruhiko_yamagata]

OK, I'll commit after beta 6.

Here is the latest design:
http://iknowu.net/files/public/ffdshow/drc/Processing-DRC-RC5.png

Tal

p.s.
IMO, OSD should be in the preset settings,
but I can see that it will take much work to implement that.Looks nice.
Moving OSD to preset settings isn't worth while IMO.

[fastplayer]

I can confirm when I visit OSD page, it turns to enabled.
Thanks for the fix!
Visiting DirectShow control - both in audio and video configuration - still triggers the "Apply" button state to switch. That is right after a fresh install with default settings and without any setting changed whatsoever. This has got to be reproducible... :confused:

[tal.aloni]

it seems that DRC is not implemented for libdts,
I looked upon the code, the dynamic range values are being read from the stream, but are not being used.

(with my latest patch, it is now easy to test DRC effects)

Tal

p.s. the tracks have DRC support when using AC3Filter.

Edit:
from the libdca project page: (http://www.videolan.org/developers/libdca.html)

some of the missing things are: Joint channels coding, Dynamic range, etc... - see the TODO file

[haruhiko_yamagata]

Thanks for the fix!
Visiting DirectShow control - both in audio and video configuration - still triggers the "Apply" button state to switch. That is right after a fresh install with default settings and without any setting changed whatsoever. This has got to be reproducible... :confused:
Reproduced, but only at the first time after clean installation.
If it is the case, I know why. It's not worthy of fix.

[fastplayer]

OK, then let's leave it like that. It's not a showstopper but a bit confusing nonetheless :)

[STaRGaZeR]

I have cleaned most bugs.
Anything that should be fixed before beta6?

ffdshow doesn't detect H.264 pulldown, present in NTSC HDDVD streams. But not that important since HDDVD is dead.

Sample in a moment.

EDIT: http://www.megaupload.com/?d=QNO25KDZ (50MB)

[LoRd_MuldeR]

It seems http://www.xvidvideo.ru/ is down. Is there another source for recent ffdshow-MT builds?

[Yong]

http://y0ngc6.googlepages.com/ffdshow_rev2346_20081204-mt.exe ;)

[BatKnight]

http://y0ngc6.googlepages.com/ffdshow_rev2346_20081204-mt.exe ;)
That one is old, I already have 2407 from xvidvideo.ru but now that it's down I don't know where to get the latest MT build.

Thanks

Bat

[tal.aloni]

Here is ffdshow-MT rev. 2407: (originated from xvidvideo.ru)

http://iknowu.net/files/public/ffdshow/ffdshow_rev2407_20081201-mt.exe

anyway, I'm sure xvidvideo.ru will be back soon, it's not the first time.

[LoRd_MuldeR]

http://y0ngc6.googlepages.com/ffdshow_rev2346_20081204-mt.exe ;)

This seems to be a pretty old build. The latest build I downloaded from xvidvideo.ru before it went down was rev2407 :confused:

[khagaroth]

ffdshow crashes if the language file is bigger than 103 704 bytes. After the switch to unicode, my language file is much bigger.

And considering the translation, would it be possible to get language template file (English) with all the translatable strings. The translation mode, apart from not working correctly (doesn't allow to enter long strings, randomly deletes some already translated strings, it isn't possible to translate some dialogs etc.), is not very suitable for tracking changes between releases, and tracking the changes in the rc script and crosschecking with resource.h to get the id's is a PITA.

[Yong]

This seems to be a pretty old build. The latest build I downloaded from xvidvideo.ru before it went down was rev2407 :confused:

its r2433 btw :p
i forgot to change to rev number on iss script :D
and btw the file "version.ver" does not up to date,
#define VERSION_MAJOR 1
#define VERSION_MINOR 0
#define VERSION_BUILD 5
#define VERSION_QFE 2353
#define VERSION_BUILD_DATE "02/12/2008"
#define VERSION_BUILD_TIME "16:10:41UTC"
i always get the latest code from svn repository before compiling them, it just the rev number is old doesnt mean its old build, dont worry :p
edit: wait, r2413 is mt build, r2433 is normal build :P
edit2: 2413 just contain some 64bit fixes for xvid codes, nothing major update to ffmpeg-mt.

[LoRd_MuldeR]

its r2433 btw :p
i forgot to change to rev number on iss script :D

Sorry, didn't notice. The configure dialog says r2346 too ;)

[Eragon4ever]

And considering the translation, would it be possible to get language template file (English) with all the translatable strings. The translation mode, apart from not working correctly (doesn't allow to enter long strings, randomly deletes some already translated strings, it isn't possible to translate some dialogs etc.), is not very suitable for tracking changes between releases, and tracking the changes in the rc script and crosschecking with resource.h to get the id's is a PITA.
True, maybe using something like TortoiseSVN would be better.

The TortoiseSVN project uses gettext PO (portable object) files for its translation. PO files are plain text, so you can even translate using a normal text editor. The only thing you have to take care of is that the editor can handle the UTF-8 charset.

[Thunderbolt8]

would it be possible to implement multi core support for mpeg2 in ffdshow(-mt) as well? sounds a bit stupid, but I got problem with most interlaced 1080i mpeg2 caps with my C2Q @2,75
with delinterlacing activated (ffmpeg, yadif etc.) im slightly over the verge to delay, meaning the delay slowly increases and the movie gets out of sync :S
(not even need to speak of additional sharpening, then its way too slow). using haali, I tried libav and libmpeg, ffmpeg deinterlacer, yadif and others, but speed remains a little too slow for fluent playback :/

[clsid]

You would need to ask that question to the ffmpeg-mt devs, not to us. But afaik, the MT API of ffmpeg-mt is very generic and will eventually be used for several video formats, at least all of the MPEG based ones (MPEG-2, MPEG-4, H.264, etc.).

[haruhiko_yamagata]

ffdshow crashes if the language file is bigger than 103 704 bytes. After the switch to unicode, my language file is much bigger.
Thank your for report. fixed at rev 2438.

And considering the translation, would it be possible to get language template file (English) with all the translatable strings. The translation mode, apart from not working correctly (doesn't allow to enter long strings, randomly deletes some already translated strings, it isn't possible to translate some dialogs etc.), is not very suitable for tracking changes between releases, and tracking the changes in the rc script and crosschecking with resource.h to get the id's is a PITA.I would like to improve translation support code, just don't have time to...

[fastplayer]

What is the limit now for language files?
I want to add this info to the changelog.

[haruhiko_yamagata]

ffdshow doesn't detect H.264 pulldown, present in NTSC HDDVD streams. But not that important since HDDVD is dead.

Sample in a moment.

EDIT: http://www.megaupload.com/?d=QNO25KDZ (50MB)Thank you for the sample.
I'll implement after beta6.

[haruhiko_yamagata]

What is the limit now for language files?
I want to add this info to the changelog.Practically no limitation as far as we edit using text editor.
256KB for the [-1] section.
32KB for one page of the dialog.
It must be UTF-16 with BOM, little endian.

Strings that are longer than 260 cannot be translated from GUI.
The translate mode may have some other bugs.

[fastplayer]

OK, since there's no actual limit in file size, I think it's enough to say that a bug was fixed that limited the translation file size.

[Leak]

Practically no limitation as far as we edit using text editor.
256KB for the [-1] section.
32KB for one page of the dialog.
It must be UTF-16 with BOM, little endian.
Well, as far as I can see you've made the limit 4 times larger, but wouldn't allocating memory based on the size of the file on disk instead of a fixed constant make more sense?

np: Boy Robot - Loving You Makes Me Nervous (Glamorizing Corporate Lifestyle)

[MatMaul]

Excellent. Hope FLAC (not like anyone uses libavcodec for it anyway, buggy) and LPCM come next if they don't already do that.
done for flac, patch sent to ffmpeg.
EDIT : can I have some samples for LPCM ?

[haruhiko_yamagata]

Well, as far as I can see you've made the limit 4 times larger, but wouldn't allocating memory based on the size of the file on disk instead of a fixed constant make more sense?

np: Boy Robot - Loving You Makes Me Nervous (Glamorizing Corporate Lifestyle)
Yes, but it won't over 256KB. Even if it does, it won't crash.

[fastplayer]

How complete is RV40 support? Complete enough to make it into the changelog?

[Snowknight26]

can I have some samples for LPCM ?

32-bit LPCM samples? Only thing I can find is 16/24-bit.

[Inventive Software]

How complete is RV40 support? Complete enough to make it into the changelog?

RV40 in ffmpeg is still not 100% though, so anything in ffdshow will be incomplete.

[clsid]

I have just tested a 32-bit build of ffdshow on Vista x64 and libfaad2 fails to load. Video decoding is working fine. Can anyone confirm this issue?

[MatMaul]

32-bit LPCM samples? Only thing I can find is 16/24-bit.
nevermind, I just read the code ans this is already supported so I don't need any samples.
thanks anyway.

[STaRGaZeR]

I have just tested a 32-bit build of ffdshow on Vista x64 and libfaad2 fails to load. Video decoding is working fine. Can anyone confirm this issue?

Works fine here. Never had a problem with libfaad2.

[Snowknight26]

Another r2314 issue (yea, I know, old build). With DTS passthrough set and no cable connected to S/PDIF or HDMI for audio, another instance of ffdshow opens up and plays 8000Hz, 16-bit, mono PCM static.

[flanger216]

I have just tested a 32-bit build of ffdshow on Vista x64 and libfaad2 fails to load. Video decoding is working fine. Can anyone confirm this issue?

Confirmed, using the latest mt build.

[haruhiko_yamagata]

I have just tested a 32-bit build of ffdshow on Vista x64 and libfaad2 fails to load. Video decoding is working fine. Can anyone confirm this issue?
I can't reproduce. I don't have Vista64. I'm on Xp64.
Which revision does the problem start?

[clsid]

It is a brand new laptop, so I haven't tried any older builds. I will do some more testing later.

[Mercury_22]

I have just tested a 32-bit build of ffdshow on Vista x64 and libfaad2 fails to load. Video decoding is working fine. Can anyone confirm this issue?
Working here with ffdshow_rev2443_20081207_xxl_mt and MPC-HC 1.2.918.0 (32-bit :) )

[tetsuo55]

I have a feature request.

FFdshow currently supports several settings for RGB level conversion.

I would like to have a similar option as the resize window.

Use REC601 for resolutions Equal to or Under Y*X for everything else use REC709

Default settings for Y*X could be 800*600
Also some cases are quite tricky like 1920*586, which should obviously be decoded with REC709

[clsid]

I have just tested a 32-bit build of ffdshow on Vista x64 and libfaad2 fails to load. Video decoding is working fine. Can anyone confirm this issue?
Must have been a bad build. I have made a fresh build and it is working again.

[MatMaul]

Use REC601 for resolutions Equal to or Under Y*X for everything else use REC709
Use presets.

[Snowknight26]

With r2447, the High quality YV12 to RGB conversion checkbox is under both Output and RGB conversion.

Also, theres is a volume difference with AC3 decoding between libavcodec and liba52. The latter seems to be a bit more quiet.

[whurlston]

r2447 fixed my channel mapping issue with TrueHD. Thanks guys (MatMaul in particular I think).

[leeperry]

cool, Haruhiko fixed some blurring problem with small fonts.
but is there a way you could let us choose how blurry we want the subs post-processing to be ? I guess it's about 2X/3X AA/GDI or sumthing ?

ppl with projectors like very sharp subs...

:thanks:

[LoRd_MuldeR]

With ffdshow-MT r2452 I get "slow motion" playback in DVBViewer, even when no filter is enabled!

The strange thing is: As soon as I enable the "KernelBob" deinerlacer it will run smooth again. Yadif doesn't work :confused:

(Happens on both of my screens and with both, RGB and YUV output)

Any ideas? :thanks:

[tal.aloni]

With ffdshow-MT r2452 I get "slow motion" playback in DVBViewer, even when no filter is enabled!

this might be related to the compilation.

[avivahl]

Sometimes, when seeking a mkv file w/ AC3 I can hear little "clicks" (at the exact moment of seeking). This was verified by another person as well (he's on XP). It happens when using either liba52 or libavcodec.

ffdshow_rev2447_20081208_clsid.exe
ffdshow_rev2447_20081208_clsid_x64.exe
Vista x64 + SP1 + All Updates + Latest Drivers

Avi Vahl.

[LoRd_MuldeR]

With ffdshow-MT r2452 I get "slow motion" playback in DVBViewer, even when no filter is enabled!this might be related to the compilation.

I used "ffdshow_rev2452_20081208_xxl_mt.exe" from SourceForge site...


[EDIT]

The problem doesn't exist in "ffdshow_rev2447_20081208_clsid_sse_icl10.exe", but that one also has the "slow motion" problem with Yadif.

Again KernelBob works fine, so it can't be a 50 fps renderer problem.

[tal.aloni]

Sometimes, when seeking a mkv file w/ AC3 I can hear little "clicks" (at the exact moment of seeking).

this can be perfectly normal,
I wouldn't expect ffdshow to perform fading effects or decrease / increase volume....
do you have any audio filters / special settings turned on?

[avivahl]

this can be perfectly normal,
I wouldn't expect ffdshow to perform fading effects or decrease / increase volume....
do you have any audio filters / special settings turned on?I only have the Mixer filter on (which converts the 5.1 to 2.0). All the settings there are default.

Btw, after doing a clean installation w/ the default setup parameters, I could see that the "Normalize" in the Mixer tab isn't checked. But when I press the "Reset" button, it checks it (as if it was the default value). Are the defaults of the installation any different than the "Reset" ones? Is this inconsistency on purpose?

[Snowknight26]

When playing a 23.976 fps H.264 stream, Movie FPS under Info & CPU jumps between 24.096 and 23.809 every 1 or 2 frames.

[whurlston]

Some pieces of information:

... FWIW, here are the GUIDs used by Nero and ArcSoft splitters to signal TrueHD/MLP:

Nero: {1E889BE7-B276-4064-9A39-160A06895B52}
ArcSoft: {4288B843-610B-4E15-A53B-43007FCFF614}

IIRC PowerDVD uses just another GUID for TrueHD/MLP, but I don't know that right now. There doesn't seem to be a standard GUID for TrueHD/MLP, but every splitter seems to use its own GUID.


Arcsoft DTS-HD subtype: {F6498F57-B399-4A43-A6FA-F694AD42B9BE}

Cyberlink HD Audio major type (Used for DTS-HD and TrueHD): {43DC7A79-60B4-40B5-A3E7-963F9B35DC11}
Cyberlink DTS-HD subtype: {6A644687-5756-4D0D-8AA3-178ACF48DEC9}
Cyberlink TrueHD subtype: {2F02DABC-522A-4AAF-AE2C-43A54F29E919}

The Cyberlink demux only seems to expose the HD audio streams when playing a BD disc within PowerDVD.

[avivahl]

When playing a 23.976 fps H.264 stream, Movie FPS under Info & CPU jumps between 24.096 and 23.809 every 1 or 2 frames.Bug verified.

[whurlston]

Bug?

I cannot get ffdshow to autoload when rendering a media file with the Arcsoft Demux and a TrueHD audio stream. ffdshow is set to "Merit: very high" (0xffffff00) but the Arcsoft Audio Decoder HD loads every time (merit: 0x60000000). Both directshow apps I tested with are in the "Always use" list (I had to add one of them). It does work however if the audio stream is AC3.

[leeperry]

When playing a 23.976 fps H.264 stream, Movie FPS under Info & CPU jumps between 24.096 and 23.809 every 1 or 2 frames.
in a MKV container ?

[haruhiko_yamagata]

The problem doesn't exist in "ffdshow_rev2447_20081208_clsid_sse_icl10.exe", but that one also has the "slow motion" problem with Yadif.

Again KernelBob works fine, so it can't be a 50 fps renderer problem.Isn't any strange DirectShow filter added between ffdshow and VMR after moving the window?
Please make sure "Multiple ffdshow instance" is set to "only one -check all filters in graph".

[tetsuo55]

Use presets.

Imho using presets is not the best solution.

My suggestion will result in correct conversion for everyone in 99% of all cases without having to manually create presets every time

[STaRGaZeR]

Imho using presets is not the best solution.

My suggestion will result in correct conversion for everyone in 99% of all cases without having to manually create presets every time

I agree. Currently ffdshow uses BT.601 for everything by default. It would be better to use BT.601 for x<1280 or x<1025 and BT.709 for everything else automatically. Just like we have an Auto option for deinterlacing.

[haruhiko_yamagata]

I agree. Currently ffdshow uses BT.601 for everything by default. It would be better to use BT.601 for x<1280 or x<1025 and BT.709 for everything else automatically. Just like we have an Auto option for deinterlacing.
I agree. Simply add a radio button "Auto" (even without option) will help.
And H.264 has flag that indicates 601 or 709.
When I have time. And of course patches are welcome.

[leeperry]

sorry to repeat myself, Haruhiko....but do you think you could let the user choose how blurry he wants his subs ? :thanks:

[haruhiko_yamagata]

sorry to repeat myself, Haruhiko....but do you think you could let the user choose how blurry he wants his subs ? :thanks:I can do so, but its priority is not high.

[Kurtnoise]

@devs : what is the WAVE_FORMAT_xx type for eac3 streams ?

[Reino]

Today I updated to rev.2447 and I can confirm the ASS-subtitle problem I had here (http://forum.doom9.org/showthread.php?p=1216586#post1216586) is gone now.
Thanks!

[leeperry]

I can do so, but its priority is not high.
awesome! ideally I'd like to get very sharp subs..like most ppl using projectors on a large screen, they are pretty blurry atm :(

if you could also think about full blown OzoneMP support, that'd be so awesome :o

:thanks: for all your hard work Haruhiko http://forum.slysoft.com/images/smilies/bowdown.gif

[tal.aloni]

@devs : what is the WAVE_FORMAT_xx type for eac3 streams ?

sadly, the same as AC3 streams.
what are you building, Kurtnoise13?

[LoRd_MuldeR]

Isn't any strange DirectShow filter added between ffdshow and VMR after moving the window?
Please make sure "Multiple ffdshow instance" is set to "only one -check all filters in graph".

No, looks like this:

http://img116.imageshack.us/img116/5685/graphstudiora6.th.png (http://img116.imageshack.us/img116/5685/graphstudiora6.png)

Avisynth Yadif doesn't work either in latest builds. I'm now back at "ffdshow_rev2347_20081123-mt.exe", which seems to work good (internal Yadif and Greedy 2 Frame).

Something must have been broken after that build :confused:

[avivahl]

in a MKV container ?
Yes. I also noticed the "major" fps jumps in .mp4 files (shows "23.976 -> 24.xxx"; flickering as if the fps is changing every 10ms :/)
Even .avi files (some of them) show minor jumps in the "Info" panel. They show 23.976 which switches back and forth (flickering) to 23.975.
Happens in both x64 and x86 versions of ffdshow tryouts.

ffdshow_rev2447_20081208_clsid.exe
ffdshow_rev2447_20081208_clsid_x64.exe

[leeperry]

Yes. I also noticed the "major" fps jumps in .mp4 files (shows "23.976 -> 24.xxx"; flickering as if the fps is changing every 10ms :/)
Even .avi files (some of them) show minor jumps in the "Info" panel. They show 23.976 which switches back and forth (flickering) to 23.975.
well essentially MKV is not a fixed frame container, so it's quite normal that h264 MKV keep "bouncing" constantly...I also see it in HR's jitter in combination w/ Reclock, mind you :(

but mp4 has very stable jitter in HR, try to switch splitters maybe ?

try to remux your MKV sample file to TS/VOB, and I bet the frame rate will be rock stable in ffdshow ;)

[Snowknight26]

It also happens with m2ts files. It was fine with r2314 as the Movie FPS would always stay constant, but not anymore.

[leeperry]

It also happens with m2ts files. It was fine with r2314 as the Movie FPS would always stay constant, but not anymore.
good point, I just tried r2301 ICL10 w/ some HD bits and it's not drifting at all on 23.976 MKV :eek:

a wild guess would be that it was just giving the media info before, and now it's actually counting..only Haruhiko & clsid would know for sure :o

[avivahl]

good point, I just tried r2301 ICL10 w/ some HD bits and it's not drifting at all on 23.976 MKV :eek:

a wild guess would be that it was just giving the media info before, and now it's actually counting..only Haruhiko & clsid would know for sure :ohttp://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2456

[LoRd_MuldeR]

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2456

The "ffdshow_rev2460_20081209_clsid.exe" build still has the problem mentioned here (http://forum.doom9.org/showpost.php?p=1222356&postcount=5572) and here (http://forum.doom9.org/showthread.php?p=1222086#post1222086).

[whurlston]

Please forgive my noviceness but I don't know how to create a patch file. I was able to connect the audio decoder to the ArcSoft MPEG Demux with a DTS-HD audio track after making the following changes:

src/ffdshow_mediaguids.h : insert at line 393:
DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_DTSHD ,0xf6498f57, 0xb399, 0x4a43, 0xa6, 0xfa, 0xf6, 0x94, 0xad, 0x42, 0xb9, 0xbe);

src/TffdshowDecAudio.cpp : change line 215 (original line commented):
//else if (mt.subtype==MEDIASUBTYPE_DTS)
else if (mt.subtype==MEDIASUBTYPE_DTS || mt.subtype==MEDIASUBTYPE_ARCSOFT_DTSHD)

src/TffDecoder_reg.cpp : change line 439 (append comma and insert next line):
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_MLP },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_DTSHD }

[tetsuo55]

Possible bug, can someone confirm?

When i enable post-processing and i choose the preset, cpu usage jumps to 100%

but when i manually max out the settings with custom cpu usage is 30%

[haruhiko_yamagata]

Possible bug, can someone confirm?

When i enable post-processing and i choose the preset, cpu usage jumps to 100%

but when i manually max out the settings with custom cpu usage is 30%
I can't reproduce. Could you show us the settings (Screen shot or exported preset settings)?

[haruhiko_yamagata]

No, looks like this:

http://img116.imageshack.us/img116/5685/graphstudiora6.th.png (http://img116.imageshack.us/img116/5685/graphstudiora6.png)

Avisynth Yadif doesn't work either in latest builds. I'm now back at "ffdshow_rev2347_20081123-mt.exe", which seems to work good (internal Yadif and Greedy 2 Frame).

Something must have been broken after that build :confused:
I have no idea where to start. Could you send me the debug output again?

[tetsuo55]

Just rechecked it and you need to enable "automatic quality control"

Ps its build 2364

Cannot get a screenshot right now.

All settings at default
Output set to "RGB32" HQ checked

Using libvacodec

Postproccessing checked
-Presets bulleted
--Automatic quality control checked
--mplayer checked

Unchecking automatic quality control brings the cpu usage back down

------------

PS
What does the level fix thing do and why do we need it?

[haruhiko_yamagata]

Just rechecked it and you need to enable "automatic quality control"
[...]
I still can't reproduce.
Windows GUI is very slow. If you leave the dialog open, it will use a lot of CPU.

[leeperry]

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2456
cool! thanks for the heads up

there's no >2456 ICL10 version from clsid yet(or MT version from XXL), so I'll try the generic builds to see how the jitter goes in HR w/ Reclock :)

[tetsuo55]

I still can't reproduce.
Windows GUI is very slow. If you leave the dialog open, it will use a lot of CPU.

Found out what was wrong.

there isn't really a 100% cpu usage.
I enabled the OSD and added to the default selection "CPU LOAD"

When automatic quality control is enabled, the OSD displays 100% and sporadically displays 0%.
The slider is constantly changing position and real CPU usage is only about 30%

Looks like the CPU load calulcation is breaking or something

[STaRGaZeR]

cool! thanks for the heads up

there's no >2456 ICL10 version from clsid yet(or MT version from XXL), so I'll try the generic builds to see how the jitter goes in HR w/ Reclock :)

The actual frame rate has been always the same, only the calculation shown in Info & CPU changed ;)

[leeperry]

The actual frame rate has been always the same, only the calculation shown in Info & CPU changed ;)
well ?

that tells me otherwise : "After seeking several frames may have inaccurate timestamps."

if you throw frames w/ wrong timestamps to HR, its jitter is gonna go nuts :devil:

[LoRd_MuldeR]

I have no idea where to start. Could you send me the debug output again?

I do when I get home tomorrow...

[haruhiko_yamagata]

Found out what was wrong.

there isn't really a 100% cpu usage.
I enabled the OSD and added to the default selection "CPU LOAD"

When automatic quality control is enabled, the OSD displays 100% and sporadically displays 0%.
The slider is constantly changing position and real CPU usage is only about 30%

Looks like the CPU load calulcation is breaking or something
Then it's a bug, ffdshow probably reads and clear the CPU usage twice per frame. Not very important though.

[STaRGaZeR]

well ?

that tells me otherwise : "After seeking several frames may have inaccurate timestamps."

if you throw frames w/ wrong timestamps to HR, its jitter is gonna go nuts :devil:

How about the rest?

frame rate calculation: fix compatibility issue with some splitters (matroska, flv)
Matroska and flv splitters round timestamps to milli-seconds. Thus frame rate calculation based on these timestamps has some error.
After seeking several frames may have inaccurate timestamps.

But go test it, you'll see how everything is the same.

[clsid]

@all

What are the remaining important bugs and regressions that need to be fixed for beta6?

[whurlston]

@all

What are the remaining important bugs and regressions that need to be fixed for beta6?

Would you mind adding this? http://forum.doom9.org/showpost.php?p=1222619&postcount=5579

[tetsuo55]

Then it's a bug, ffdshow probably reads and clear the CPU usage twice per frame. Not very important though.

It's actually more important than it seems.
Because if the miss-read CPU LOAD ffdshow is lowering the postproccessing settings for nothing

[clsid]

Would you mind adding this? http://forum.doom9.org/showpost.php?p=1222619&postcount=5579
Sure. Have you tested if ffdshow decodes correctly when connected to that splitter?

[whurlston]

Sure.Thanks.

Have you tested if ffdshow decodes correctly when connected to that splitter?

Yup. It decodes the DTS-Core only it seems but I expected that. It works using both libdts and libavcodec.

[MatMaul]

this one is still here but it is perhaps not a priority :
http://sourceforge.net/tracker/index.php?func=detail&aid=2298876&group_id=173941&atid=867360

EDIT : and here is a patch to enable 32bits output for flac when the bitdepth is superior to 16 (encoded from a bluray by eac3to for example)
Index: src/ffmpeg/libavcodec/flac.c
===================================================================
--- src/ffmpeg/libavcodec/flac.c (revision 2461)
+++ src/ffmpeg/libavcodec/flac.c (working copy)
@@ -611,7 +611,7 @@
const uint8_t *buf, int buf_size)
{
FLACContext *s = avctx->priv_data;
- int tmp = 0, i, j = 0, input_buf_size = 0;
+ int tmp = 0, i, j = 0, input_buf_size = 0, shift, offset_per_sample;
int16_t *samples = data;
int alloc_data_size= *data_size;

@@ -712,14 +712,31 @@
}
}
#else
+ avctx->bits_per_raw_sample = s->bps;
+
+ if (s->bps > 16)
+ {
+ offset_per_sample = 2;
+ avctx->sample_fmt = SAMPLE_FMT_S32;
+ shift = 32 - s->bps;
+ }
+ else
+ {
+ offset_per_sample = 1;
+ avctx->sample_fmt = SAMPLE_FMT_S16;
+ shift = 16 - s->bps;
+ }
+
#define DECORRELATE(left, right)\
assert(s->channels == 2);\
for (i = 0; i < s->blocksize; i++)\
{\
int a= s->decoded[0][i];\
int b= s->decoded[1][i];\
- *samples++ = ((left) << (24 - s->bps)) >> 8;\
- *samples++ = ((right) << (24 - s->bps)) >> 8;\
+ *(int32_t *)samples = (left) << shift;\
+ samples += offset_per_sample;\
+ *(int32_t *)samples = (right) << shift;\
+ samples += offset_per_sample;\
}\
break;

@@ -729,7 +746,10 @@
for (j = 0; j < s->blocksize; j++)
{
for (i = 0; i < s->channels; i++)
- *samples++ = (s->decoded[i][j] << (24 - s->bps)) >> 8;
+ {
+ *(int32_t *)samples = s->decoded[i][j] << shift;
+ samples += offset_per_sample;
+ }
}
break;
case LEFT_SIDE:

[tal.aloni]

I have commited the "DRC based on presets" patch as rev. 2467,
please note that AFAIK, DRC is not supported when working with DTS, both with libdts and libavcodec, I have tested AC3 successfully with both libraries.

there is another patch I have ready:
+ DRC slider added, this will allow to use dynamic range compression level between 0% to 100%.

two notes:
1. I had to patch liba52 to add this feature. (libavcodec have native support for custom DRC level)
2. although it sounds right, I'm not 100% sure about the accuracy of my method to calculate partial DRC in liba52.
here is the relevant line: (based on what I saw in libavcodec)

- state->dynrng = state->level * range;
+ state->dynrng = state->level * ((range - 1.0) * state->dynrngclevel + 1.0); //ffdshow custom code


patch:
http://iknowu.net/files/public/ffdshow/drc/2467-DRC_Slider.patch

build:
http://iknowu.net/files/public/ffdshow/drc/ffdshow_rev2467-DRC_Slider_20081210.exe

[haruhiko_yamagata]

It's actually more important than it seems.
Because if the miss-read CPU LOAD ffdshow is lowering the postproccessing settings for nothing
Only if both OSD-"CPU Load" and postprocessing "Automatic quality control" is enabled.
I'm afraid I can't fix all bugs. I have limited time.

[fastplayer]

Will Beta 6 be 32-bit only? Or: How complete are 64-bit builds currently?

[haruhiko_yamagata]

I'm not sure but perhaps 32-bit only.
64-bit builds are still experimental.

[Reino]

@all

What are the remaining important bugs and regressions that need to be fixed for beta6?
http://img101.imageshack.us/img101/959/frapsvsffdshoweg2.gif
Wrong colourspace, brightness, gamma? bug?

CMR2005_JPN3_P206_024756_sample.avi (http://www.zshare.net/video/5258209283398d21/) - AVI[FPS1+PCM] 33.36MB

[LoRd_MuldeR]

Wrong colourspace, brightness, gamma? bug?

TV Levels -vs- PC Levels? RGB Output -vs- YUV Output?

[whurlston]

Clsid, ArcSoft DTSHD works with build 7475, thanks for adding that. Now I can finally finish my BD plugin for GBPVR.
:thanks:

[Reino]

TV Levels -vs- PC Levels? RGB Output -vs- YUV Output?Just standard settings, so PC Levels and YV12 Output. It only happens with Fraps files, so it has to be a bug or Fraps support is still incomplete.

[LoRd_MuldeR]

Just standard settings, so PC Levels and YV12 Output. It only happens with Fraps files, so it has to be a bug or Fraps support is still incomplete.

Try to enforce RGB32 output in ffdshow and then test "Full Range" -vs- "Standard" on the "RGB conversion" page.

Many renderers don't handle YUV data properly :rolleyes:

[tal.aloni]

there is another patch I have ready:
+ DRC slider added, this will allow to use dynamic range compression level between 0% to 100%.

two notes:
1. I had to patch liba52 to add this feature. (libavcodec have native support for custom DRC level)

Is it safe to commit?
should I try getting my patch into liba52 first?
(it seems that we have a few other modifications as well)

Thanks,
Tal

[Reino]

Try to enforce RGB32 output in ffdshow and then test "Full Range" -vs- "Standard" on the "RGB conversion" page.Ah I see. RGB32 and Full range did the trick. I can see some aliasing with FFDShow as FPS1 decoder though (no matter what renderer {VMR7,VMR9} I use). With Fraps itself everything looks very smooth.
Is this the only way to succeed, because in that case it will be the only file-format that needs additional settings configurated to show the original colours.

[LoRd_MuldeR]

I can see some aliasing with FFDShow as FPS1 decoder though (no matter what renderer {VMR7,VMR9} I use).

Is "High quality YUV to RGB conversion checked?

With Fraps itself everything looks very smooth.
Is this the only way to succeed, because in that case it will be the only file-format that needs additional settings configurated to show the original colours.

I guess your FRAPS videos are the only videos you have that use the "Full Range" (PC Levels), while movies usually use TV Levels (Standard). Which makes perfect sense, since FRAPS captures from PC games. So as long as your renderer expects "TV Levels", you must either live with wrong colors for FRPAS footage -or- feed your renderer with RGB32 data (software YUV -> RGB conversion). I'd recommend to use Haali Renderer, which allows you to select the desired levels and everything will be fine, even with YUV output...

[Nightshiver]

I've been meaning to ask. What is the difference between the "Official ffdshow beta releases" (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199421) and the SVN builds by Clsid (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416) ? Should I stick with the latest official beta or go with the latest SVN build?

[LoRd_MuldeR]

I've been meaning to ask. What is the difference between the "Official ffdshow beta releases" (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199421) and the SVN builds by Clsid (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416) ? Should I stick with the latest official beta or go with the latest SVN build?

Beta release: Old version, but more tested. Should be pretty stable.

Latest SVN: Has all the fancy new features on board. Less tested, so mabye less stable.

[Reino]

Is "High quality YUV to RGB conversion checked?

I guess your FRAPS videos are the only videos you have that use the "Full Range" (PC Levels), while movies usually use TV Levels (Standard). Which makes perfect sense, since FRAPS captures from PC games. So as long as your renderer expects "TV Levels", you must either live with wrong colors for FRPAS footage -or- feed your renderer with RGB32 data (software YUV -> RGB conversion). I'd recommend to use Haali Renderer, which allows you to select the desired levels and everything will be fine, even with YUV output...

Haha, it seems I'm learning new things every day!
To solve the aliasing I had to enable "High quality YV12 to RGB conversion" indeed.

I never thought the source of the problem could be Fraps itself!
In case of my video sample I noticed, besides Full range, I also had to select ITU-R BT.709 to match the colours.
On the other hand, in case of the FPS1 video sample on mplayerhq.hu (http://samples.mplayerhq.hu/V-codecs/FPS1/fraps_vidc_fps1_sample.avi), ITU-R BT.601 was okay.
I never heared of these specifications, so I did some reading (http://en.wikipedia.org/wiki/Rec._601) and some reading (http://en.wikipedia.org/wiki/Rec._709).
ITU-R BT.709 seems to be the standard format for High-definition video material. This may explain why my sample (created with a relatively up to date Fraps version) is BT.709 and the mplayerhq.hu sample (2004-Aug-31 00:11:15) is BT.601.

Now when I compare screenshots from my sample, they are indentical for 99.99%.

Thanks a lot for your input LoRd_MuldeR!

[Snowknight26]

Regarding: http://forum.doom9.org/showthread.php?p=1209050#post1209050

Confirmed.

Any word on this? Got another 1080i25 Blu-ray thats doing the same thing for myself as well as others.

[STaRGaZeR]

Changes made after rev2460 broke some H.264 files, like this one:

http://computergames.ro/en/downloads/getfile/id/31500/mirror/computergames-1/name/the-chronicles-of-riddick-assault-on-dark-athena-trailer-hd.html (79MB)

Maybe the changes in rev2462?

[LoRd_MuldeR]

@haruhiko_yamagata:

Here is the debug log you have requested:
http://www.mediafire.com/file/wymi2njhwyz/ffdshow-mt.dvbviewer.debug.log

Problem: When checking Yadif the video will run in "slow motion", after unchecking it will run extremely fast for a moment to re-sync.
Note that checking or unchecking the Yadif deinterlacer doesn't produce any new entries on the debug log.

When I keep Yadif checked for a longer time, the sound will begin to stutter and we get these "jitter correction" messages (238 to 257).
If I then uncheck Yadif, I will get scrambled video output for a moment until it has re-synced.
That short moment of re-sync produced all these "MPEG motion vector out of boundary" messages and stuff, starting at 258.
There is no scrambled video output while Yadif is still checked. It just runs much too slow.

Tested with r2452. Last build that works properly for me (Yadif and also Greedy 2 Frame) is r2347.
In current build I can't use Yadif. Greedy 2 Frame is broken too, but I think that's another issue. KernelBob does work fine.

:thanks:

[leeperry]

ITU-R BT.709 seems to be the standard format for High-definition video material. This may explain why my sample (created with a relatively up to date Fraps version) is BT.709 and the mplayerhq.hu sample (2004-Aug-31 00:11:15) is BT.601.
you seem to be dealing with videogames videos, these are natively RGB.
whether they are encoded in 601 or 709 depends on the YV12 encoder settings I guess.

the difference I'm seeing between your 2 pics are mostly levels...games are natively 0-255

[tal.aloni]

DRC slider patch has been commited as rev. 2480,
I have thoroughly tested my extension to liba52,
(it produces the exact results as the older version when DRC is set to 0% or 100%).
I will try to add this patch to liba52 @ sourceforge as well, it can benefit other projects too.

Tal

[fastplayer]

Changes made after rev2460 broke some H.264 files, like this one:

http://computergames.ro/en/downloads/getfile/id/31500/mirror/computergames-1/name/the-chronicles-of-riddick-assault-on-dark-athena-trailer-hd.html (79MB)

Maybe the changes in rev2462?
Confirmed. I guess no Beta 6 until this is fixed :D

DRC slider patch has been commited as rev. 2480,
I have thoroughly tested my extension to liba52,
(it produces the exact results as the older version when DRC is set to 0% or 100%).
I will try to add this patch to liba52 @ sourceforge as well, it can benefit other projects too.

Tal
Cool, I hope you've added a tooltip or some kind of explanation for this feature because I so don't know what it is good for... :D

[tal.aloni]

fastplayer,
this is an extension to the existing "dynamic range compression" implementation, instead of "off" or "on", you can now set custom level.
IMO, DRC is only useful if you don't want to wake your neighbors / parents / wife / kids. I wouldn't recommend using it regularly.

if anybody can think of an appropriate tooltip, I would gladly add it, I think "dynamic range compression" says it all.

http://iknowu.net/files/public/ffdshow/drc/DRC_Slider.png

[haruhiko_yamagata]

Changes made after rev2460 broke some H.264 files, like this one:

http://computergames.ro/en/downloads/getfile/id/31500/mirror/computergames-1/name/the-chronicles-of-riddick-assault-on-dark-athena-trailer-hd.html (79MB)

Maybe the changes in rev2462?
Thank you for report.
I have fixed my working copy. I'll commit soon.

// EDIT
After all, it is still difficult to completely get dependent from file name extensions.

[haruhiko_yamagata]

Regarding: http://forum.doom9.org/showthread.php?p=1209050#post1209050



Any word on this? Got another 1080i25 Blu-ray thats doing the same thing for myself as well as others.
Please update to the latest, which should work (except the regression above).

[fastplayer]

fastplayer,
this is an extension to the existing "dynamic range compression" implementation, instead of "off" or "on", you can now set custom level.
Thanks,
but what is the difference between this new option (when set to 100%) and having "Regain volume" enabled in the Volume tab? Wasn't AC3/DTS supported before by the "Regain volume" option?

Edit: Will this be part of Beta 6?

[tal.aloni]

Thanks,
but what is the difference between this new option (when set to 100%) and having "Regain volume" enabled in the Volume tab? Wasn't AC3/DTS supported before by the "Regain volume" option?

Well, both apply "dynamic range compression",
but there is a difference:
AC3/DTS files have pre-calculated amplification factors built-in, in theory they should provide smoother amd more accurate "volume control", but in practice they are usually used to "flatten out" the sound.

"Regain volume" on the other hand, does not require pre-calculated values, and can be used with all audio formats supported by ffdshow. it does not change the volume as aggressively, and retain more of the original dynamic range.

to sum it up, this is a matter of personal preference,
both can be used simultaneously.

p.s.
AC3 DRC (100%) is not a new option, it's just moved from the bottom of the codec page, the new option is 1-99%.


Will this be part of Beta 6?

Haruhiku wrote earlier that he prefers not to include this in beta 6.

[fastplayer]

:thanks:
This is useful information, so I'll try to add this to the wiki.

[Soulhunter]

I have a problem; When I activate "AC3 (S/PDIF encode mode)" in the output options of the audio decoder, the decoder isn't used (not for AVIs with 5.1 AC3 streams, neither for MP3s etc... MPC also shows me the "no audio" icon in the bottom right corner like when playing a AVI with video stream only). When I disable AC3 encoding, the decoder works. Reconfiguring the decoder to do AC3 encoding while playback works as well (my receiver jumps from 2ch PCM -> 5.1 AC3). Is this a known problem?

Ps. Tested with rev2033_20080705_clsid and rev2477_20081211_clsid


Tia n Bye

[tal.aloni]

Soulhunter,
this is something with your settings, or a very rare bug.
please provide the following information:
1. screen-shot of the output (audio) page.
2. selected AC3 codec (codecs page)
3. selected settings under "uncompressed" (codecs page)
4. output speaker configuration (mixer page)

Tal

[Soulhunter]

Soulhunter,
this is something with your settings, or a very rare bug.
please provide the following information:
1. screen-shot of the output (audio) page.
2. selected AC3 codec (codecs page)
3. selected settings under "uncompressed" (codecs page)
4. output speaker configuration (mixer page)

Tal

1. Defaults. except checking AC3 (S/PDIF encode mode) (http://img300.imageshack.us/img300/9246/clipboard01rb4.png)
2. Deafult one, liba52...
3. Can be disabled without changing the result
4. Default for 5.1 (so, 3/0/2 and LFE checked)


Additional Info:

- Windows XP Pro + SP3
- Soundblaster X-Fi Xtreme Audio
- Player doesn't seem to matter (MPC, MPC-HT, mplayer2...)


Tia n Bye

[tal.aloni]

Soulhunter,
I still can't recreate this,
(the phenomenon you're describing indicates that ffdshow rejects the input stream or, more likely, that the "default direct-sound device" rejects ffdshow)
1. do you have more than one sound-card enabled?
2. maybe it's related to a specific demuxer, It would be helpful if you load the file into graphedit, and see what feeds ffdshow audio decoder.
3. also, please try remux the content into .mkv and play it with haali media splitter.
4. a sample would be also helpful (you can cut one from avi using virtualdub).

Tal

[Atak_Snajpera]

Since we have oblivion.exe and morrowind.exe in 'Do not use in' section we should also add fallout3.exe :) (the same engine)

[fastplayer]

It is already blacklisted.

[Soulhunter]

Soulhunter,
I still can't recreate this,
(the phenomenon you're describing indicates that ffdshow rejects the input stream or, more likely, that the "default direct-sound device" rejects ffdshow)
1. do you have more than one sound-card enabled?
2. maybe it's related to a specific demuxer, It would be helpful if you load the file into graphedit, and see what feeds ffdshow audio decoder.
3. also, please try remux the content into .mkv and play it with haali media splitter.
4. a sample would be also helpful (you can cut one from avi using virtualdub).

Tal

1. I'm sure onboard-sound is disabled in the BIOS, but I'll check with next reboot to make sure

2-4. I'll do this after the weekend (busy right now...), tho I already reproduced this behavior with non AVI files, ie. MP3s


Tia n Bye

[roozhou]

Here are questions about crop / resize filters in ffdshow:

1) If you specify "Crop" in Crop & zoom page, the cropped video is resized to orginal size so the resolutionn remains unchanged. How can I do actual cropping without resizing, as what avisynth cropper does, and keep PAR unchanged?

2) Is there a way to resize but keeping DAR unchanged?
e.g. Resize 1920x1080 to 1440x1080 while keeping DAR to 16:9 and setting SAR to 4:3.

[jmartinr]

Here are questions about crop / resize filters in ffdshow:

1) If you specify "Crop" in Crop & zoom page, the cropped video is resized to orginal size so the resolutionn remains unchanged. How can I do actual cropping without resizing, as what avisynth cropper does, and keep PAR unchanged?

2) Is there a way to resize but keeping DAR unchanged?
e.g. Resize 1920x1080 to 1440x1080 while keeping DAR to 16:9 and setting SAR to 4:3.

Take a look here: http://forum.doom9.org/showthread.php?p=1218742#post1218742

[roozhou]

Take a look here: http://forum.doom9.org/showthread.php?p=1218742#post1218742

Thanks but this does not answer my 2nd question.

i need to resize the resolution while keeping DAR unchanged without adding black border and without manually setting PAR.

e.g. Resize 1920x1080 to 720x480 and keep DAR as 16/9(play at 853x480). If I choose "keep original aspect ratio", ffdshow just letterboxes it.

[Soulhunter]

Soulhunter,
...
2. maybe it's related to a specific demuxer, It would be helpful if you load the file into graphedit, and see what feeds ffdshow audio decoder.
3. also, please try remux the content into .mkv and play it with haali media splitter.
4. a sample would be also helpful (you can cut one from avi using virtualdub).

2.
- Without AC3 encoding (http://img399.imageshack.us/img399/4074/grapheditnoac3encbn1.png)
- With AC3 encoding enalbled (ffdshow audio decoder refuses, cinemater decoder jumps in) (http://img178.imageshack.us/img178/1696/grapheditwithac3encyb4.png)
- With AC3 encoding enabled + Cinemaster decoder removed (ffdshow refuses... audio is not rendered at all) (http://img178.imageshack.us/img178/4496/grapheditwithac3encnocisz1.png)

3.
Also no audio playback...
But at least it throws me a error (http://img399.imageshack.us/img399/6226/ac3encodemkvvo4.png) now!

4.
Here is a short sample of one of the random files I tried... (http://www.megaupload.com/?d=X8R2ETY9)


Ps.
Is GTA4 already blacklisted? Seems to cause problems >.>


Tia n Bye

[Leak]

Ps.
Is GTA4 already blacklisted? Seems to cause problems >.>
Any details on that one?

I managed to play it just fine - unless you mean that craptastic Rockstar Games Social Club "feature" they shoved down PC users' throats were somehow involved - but who in their right minds uses that anyway?

(Rockstar Games ought to be shot for forcing you to activate the game online, install Games for Windows live 2.0 plus their own RGSC crap, having to create and logging into two accounts and have the DVD in your drive before you even can play the freaking single player game... WHAT WERE THEY THINKING?!? Oh, and what's with the ugly dithered shadows, anyway?)

np: Benni Hemm Hemm - Steinn Um Morgun (Ein Í Leyni)

[Soulhunter]

Any details on that one?

I managed to play it just fine - unless you mean that craptastic Rockstar Games Social Club "feature" they shoved down PC users' throats were somehow involved - but who in their right minds uses that anyway?
Social club is running, but I'm not sure its the reason...

When I don't block ffdshow's audio decoder the game crashes after 1-3 minutes. But when I block it, I can play for hours... I'll try to figure out more!



(Rockstar Games ought to be shot for forcing you to activate the game online, install Games for Windows live 2.0 plus their own RGSC crap, having to create and logging into two accounts and have the DVD in your drive before you even can play the freaking single player game... WHAT WERE THEY THINKING?!? Oh, and what's with the ugly dithered shadows, anyway?)

I started installing it at 19:00, and went to bed at 23:00 without playing a single second... >.<

01. Installing the game (16GB or something, yay)
02. Installing Rockstar Social Club
03. Making a account for it
04. Installing Windows Live
05. Making a account for it
06. Registering the game online
07. Starting the game
08. Getting a error because I didn't have SP3
09. Downloading SP3 and installing it
10. Noticing my custom theme etc. went away
11. Downloading a SP3 compatible theme patcher
12. Bringing back everything as it was before SP3
13. Too frustrated to actually play the game


Bye

[rack04]

Is anyone else experiencing ~2x playback speed using libavcodec for mp3 in ffdshow tryouts mt svn 2484? Plays fine using libmad.

[jmartinr]

i need to resize the resolution while keeping DAR unchanged without adding black border and without manually setting PAR.

e.g. Resize 1920x1080 to 720x480 and keep DAR as 16/9(play at 853x480). If I choose "keep original aspect ratio", ffdshow just letterboxes it.

Through the avisynth filter you can get the DAR, resize and reset the DAR to the old value.

But I'm quite positive that you can also achieve what you want by using the resize & aspect filter with "keep original aspect ratio" and "process pixel aspect ratio internally" enabled.

[clsid]

When I don't block ffdshow's audio decoder the game crashes after 1-3 minutes. But when I block it, I can play for hours... I'll try to figure out more!
Let me know the name of the executable and I will add it to the blacklist.

[_xxl]

Is anyone else experiencing ~2x playback speed using libavcodec for mp3 in ffdshow tryouts mt svn 2484? Plays fine using libmad.
Confirmed.

[leeperry]

sorry to ask but I haven't seen any infos about it...what is "MT" in the MT versions exactly ?
:thanks:

[rack04]

sorry to ask but I haven't seen any infos about it...what is "MT" in the MT versions exactly ?
:thanks:

Multi-threaded. H264 and MPEG1/2 only.

[leeperry]

Multi-threaded. H264 and MPEG1/2 only.
but I was told a while ago that regular versions already had the CABAC/slices MT stuff ?

[tal.aloni]

Soulhunter,
I had no problem using AC3 Encoder right from the start with my hardware. (including with the sample you provided).
I also reviewed the related code, it seemes free of any bugs.

I think it maybe related to another installed audio device,
(I had a similar problem with DXVA), I believe the "Default DirectSound Device" only shows the common features of all installed audio devices at first, and only after the connection is made you can see the specific features of each device.

please screen-shot what's listed under "audio renderers" in graph edit (when you add filter), so we could verify this theory.

p.s. I'm assuming you can't pass-through AC3 right from the start as well, am I correct?

Tal

[clsid]

but I was told a while ago that regular versions already had the CABAC/slices MT stuff ?
They do. The ffmpeg-mt branch uses frame based MT, which is far more scalable, meaning much better performance. It is still a "work in progress" though.

[whurlston]

A couple of executables that can be added to the whitelist:
PVRX2.exe
Config.exe

(GBPVR executables)

[leeperry]

They do. The ffmpeg-mt branch uses frame based MT, which is far more scalable, meaning much better performance. It is still a "work in progress" though.
but still only for h264/MPEG2 decoding, right ?

[clsid]

Eventually maybe also for MPEG-4 and other formats.

[tal.aloni]

Albain, clsid, Haruhiku,
a while ago I reported that 44,100 DTS tracks are playing back too fast when passing through, and I found the cause (TSampleFormat.cpp):


CMediaType mt=TsampleFormat(SF_PCM16,48000,2).toCMediaType();



SPDIF interface supports three standard sample rates: 48 kHz, 44.1 kHz and 32 kHz.


when I modify the frequency to 44,100, playback of those files is back to normal speed. do you have any suggestion how to auto-select the frequency when creating the sample format? I tried, but I don't have the required knowledge.

Thanks,
Tal

[Soulhunter]

Let me know the name of the executable and I will add it to the blacklist.

Im not sure if its just "GTAIV.exe" or if "LaunchGTAIV.exe" is also involved, I blocked both!


I think it maybe related to another installed audio device,
(I had a similar problem with DXVA), I believe the "Default DirectSound Device" only shows the common features of all installed audio devices at first, and only after the connection is made you can see the specific features of each device.

please screen-shot what's listed under "audio renderers" in graph edit (when you add filter), so we could verify this theory.


Made a screenshot of all audio renderes... (http://img511.imageshack.us/img511/557/00001zf8.png)


p.s. I'm assuming you can't pass-through AC3 right from the start as well, am I correct?
Thats true, video will play without audio and MPC shows there is no audio stream!

[tal.aloni]

Soulhunter,
Please test AC3Filter, and see if you get a similar behavior.

Tal

[Atak_Snajpera]

Im not sure if its just "GTAIV.exe" or if "LaunchGTAIV.exe" is also involved, I blocked both!
i wonder why GTAIV crashes? FFdshow does not load if you do not accept it in pop-up window. Fallout3 does not crash but that pop-up window may annoy some gamers.

[Soulhunter]

Soulhunter,
Please test AC3Filter, and see if you get a similar behavior.

Tal

- Activating AC3filter's passtrough while playback -> Works, just like in ffdshow (Receiver switches from 2ch PCM -> 5.1 AC3)

- Starting playback with already activated passtrough -> Outputs a signal my receiver accepts as AC3, but its just noise/crackling

- Changing the default audio renderer to WaveOut -> Playback with already activated passtrough works! (Guess I'll use this solution for now...)

- Changing ffdshow's output to WaveOut (because it worked for AC3filter) -> Outputs a signal my receiver accepts as AC3, but audio + video playback is choppy


Bye

[Soulhunter]

i wonder why GTAIV crashes? FFdshow does not load if you do not accept it in pop-up window. Fallout3 does not crash but that pop-up window may annoy some gamers.
What popup window? ^^;


Bye

[clsid]

If you enable the whitelist, then a "compatibility manager" dialog appears whenever some unknown application tries to load ffdshow. It can easily be disabled in the options. The whitelist is disabled by default anyway so most people will never see such a dialog.

[Atak_Snajpera]

What popup window? ^^;
http://img262.imageshack.us/img262/1672/new1rc7.th.png (http://img262.imageshack.us/my.php?image=new1rc7.png)

you have to enable these 2 options

The whitelist is disabled by default anyway so most people will never see such a dialog.
is there any reason why it is disabled by default. Forgive me but my common sense tell me that it should be enabled by default to avoid crashes in new games.

[fastplayer]

We can't whitelist all existing apps/games. There are just too many. If we enable the whitelist, then we would exclude tons of apps/games that have no problem with ffdshow whatsoever.

[Atak_Snajpera]

then we would exclude tons of apps/games that have no problem with ffdshow whatsoever.
in this case you will see pop-up window to enable decoding or disable decoding by ffdshow. it's better than adding manually each time .exe to 'Don't use' section when the game crashes. Many users do not even know that crash is caused by ffdshow. Instead they blame game programmers.

[_xxl]

The whitelist is disabled by default anyway so most people will never see such a dialog.
We can't whitelist all existing apps/games. There are just too many. If we enable the whitelist, then we would exclude tons of apps/games that have no problem with ffdshow whatsoever.
I would like the whitelist to be enabled by default.

[leeperry]

well, set the whitelist to your media players only...and you're good to go?

[fastplayer]

it's better than adding manually each time .exe to 'Don't use' section when the game crashes.
In a perfect world, you would not need to patch your game. Unfortunately, we live in an imperfect one, and you have to patch your game and sometimes even the video drivers to keep it from crashing and doing other abnormal things. Heck, game publishers release patches even before the game gets on the market! So, if you can patch your game and upgrade the video drivers, you can certainly update ffdshow.
Many users do not even know that crash is caused by ffdshow. Instead they blame game programmers.
Why does ffdshow get called in a game in the first place? Maybe to display in-game video sequences, maybe for audio playback? Isn't it possible to do that in a DirectShow-compliant way?
I'm more interested in the cause of the crashes than playing The Blame Game™...

I've just taken a look at our whitelisted/blacklisted apps that get reported via the compatibility manager.
Reported since Nov, 1st until today:
- Whitelist: 2173 (including duplicates: 4830)
- Blacklist: 629 (including duplicates: 908)
This should give you an rough idea of the dimensions we're dealing with here.

[roozhou]

Through the avisynth filter you can get the DAR, resize and reset the DAR to the old value.

But I'm quite positive that you can also achieve what you want by using the resize & aspect filter with "keep original aspect ratio" and "process pixel aspect ratio internally" enabled.

So i need to manually calculate PAR myself? Is there an automatical way? I mean adding a "keep PAR unchanged" in crop filter, and "keep DAR unchanged" in resize & aspect.

[jmartinr]

So i need to manually calculate PAR myself? Is there an automatical way? I mean adding a "keep PAR unchanged" in crop filter, and "keep DAR unchanged" in resize & aspect.
Do use the avisynth filter for cropping. In my experience that's the only way to automatically keep the PAR unchanged in ffdshow whilst cropping.

[CruNcher]

2460

09.12.2008

Added support for FourCC WMVA

Finally :) that took a long time though
http://forum.doom9.org/showthread.php?p=1192845#post1192845
2 month adding a FourCC ?

[clsid]

Actually someone else recently also requested it. I thought ffdshow already supported that FourCC, but it turned out it didn't.

[roozhou]

Do use the avisynth filter for cropping. In my experience that's the only way to automatically keep the PAR unchanged in ffdshow whilst cropping.

Why not implement this in ffdshow internally? Consider this as a feature request.

[Atak_Snajpera]

Heck, game publishers release patches even before the game gets on the market! So, if you can patch your game and upgrade the video drivers, you can certainly update ffdshow.
tell that to angry gamers amigo! Please update drivers , .Net , Visual C++ and the most important part kids is installing latest ffdshow :) have fun! Do you really what to blame every game developer for calling DirectShow filter/codec ??? We can easlly avoid that by setting whitelist by default. If app is not listed then let's ask user for permission. I had white list enabled from the beginning and never had problems with crashing games.

[tal.aloni]

Albain, clsid, Haruhiku,
a while ago I reported that 44,100 DTS tracks are playing back too fast when passing through, and I found the cause.


I was able to fix this,
+ Added support for SPDIF sample rates different than 48,000.
(pass-through of 44.1Khz AC3/DTS streams will now be played back correctly)

Guys, please test this release, I'm now able to pass-through everything correctly.

Note: some work is still needed on encoding to 44.1 kHz AC3, my patch only cover pass-through issues.
(currently, encoding 44.1 kHz AC3 will result in choppy playback, so it's recommended to resample to 48kHz before, this is not a new issue)

patch:
http://iknowu.net/files/public/ffdshow/SPDIF/2486-SPDIF.patch

build:
http://iknowu.net/files/public/ffdshow/SPDIF/ffdshow_rev2486-SPDIF_20081210.exe

Tal

[tal.aloni]

We can easlly avoid that by setting whitelist by default.

I'm against it as well.

[CruNcher]

@clsid
would it be possible to support Elecards Mpeg and Mp4 Demultiplexers :) watching RAW bitstreams (Annex B Progressive AVC for example) with ffdshow with them isn't really nice CoreAVC, Cyberlink and DivX are interoperable with them ffdshow, MPCs Video Decoder and Arcsoft have problems (garbaged output,black screen, no connection) :(

[clsid]

tell that to angry gamers amigo! Please update drivers , .Net , Visual C++ and the most important part kids is installing latest ffdshow :) have fun! Do you really what to blame every game developer for calling DirectShow filter/codec ??? We can easlly avoid that by setting whitelist by default. If app is not listed then let's ask user for permission. I had white list enabled from the beginning and never had problems with crashing games.
Enabling the whitelist causes it own share of problems. Mainly lots of confused people that unexpectedly get a pop-up dialog about ffdshow. Games may still show problems due to the dialog. Hiding the dialog by default is also not a good option.
Changing the whitelist settings also isn't going to solve problems for people running old versions of ffdshow.
Only few games use DirectShow in a way where ffdshow could interfere. All popular ones are already blacklisted. A problem is that many people have outdated blacklists. I think should hardcode part of the blacklist (mostly games) to solve that issue.

[clsid]

@clsid
would it be possible to support Elecards Mpeg and Mp4 Demultiplexers :) watching RAW bitstreams (Annex B Progressive AVC for example) with ffdshow with them isn't really nice CoreAVC, Cyberlink and DivX are interoperable with them ffdshow, MPCs Video Decoder and Arcsoft have problems (garbaged output,black screen, no connection) :(
Sorry, I can't do that. Haruhiko knows more about that. If you can supply him those filters and some samples files, then maybe he can take a look at it for you.

[Atak_Snajpera]

Games may still show problems due to the dialog.
Dialog disappears after 20 seconds so I see no problem.
Mainly lots of confused people that unexpectedly get a pop-up dialog about ffdshow
Between two evils I would choose stability in new game over pop-up window which in fact automatically disappears. Do you really want to maintain blacklist to the rest of your days? It's like fighting with viruses. You will always be one step behind.

[haruhiko_yamagata]

I was able to fix this,
+ Added support for SPDIF sample rates different then 48,000.
(pass-through of 44.1Khz AC3/DTS streams will now be played back correctly)

Guys, please test this release, I'm now able to pass-through everything correctly.
Good work. Please commit it to the trunk. We'll merge it to beta6 branch before release.Note: some work is still needed on encoding to 44.1 kHz AC3, my patch only cover pass-through issues.
(currently, encoding 44.1 kHz AC3 will result in choppy playback, so it's recommended to resample to 48kHz before, this is not a new issue)
Yes, it's necessary. I've been too lazy to fix it. :thanks:

[fastplayer]

Added to changelog.

[Shinigami-Sama]

Dialog disappears after 20 seconds so I see no problem.

Between two evils I would choose stability in new game over pop-up window which in fact automatically disappears. Do you really want to maintain blacklist to the rest of your days? It's like fighting with viruses. You will always be one step behind.

you've never tried to play a game and have it crash from ffdshow hanging it for those 20 seconds then have you?

[tal.aloni]

currently, encoding 44.1 kHz AC3 will result in choppy playback, so it's recommended to resample to 48kHz before, this is not a new issue)


I've invested a few hours today to find the root cause of this issue.
eventually, I found out that it's a bug in ffmpeg,
ffmpeg simply cannot produce valid 44.1kHz AC3 streams.
(48kHz and 32kHz are fine)

this issue affects BeHappy as well (ffmpeg AC3 Decoder).

Edit:
it's more complicated,
I can pass-through the AC3 created with BeHappy and it plays fine,
the one created with ffdshow is choppy.
both are choppy when decoded with AC3Filter.

[tal.aloni]

I've commited a tiny improvement to the AC3 Encode mode,
as I see it, in some rare occasions, a sample would be unnecessary delayed.


Index: src/audioFilters/TaudioFilterOutput.cpp
===================================================================
--- src/audioFilters/TaudioFilterOutput.cpp (revision 2492)
+++ src/audioFilters/TaudioFilterOutput.cpp (working copy)
@@ -179,7 +179,7 @@
TbyteBuffer::iterator inputsamples=ac3inputbuf.begin();
int inputsize=(int)ac3inputbuf.size();
int ac3framesize=avctx->frame_size*fmt.blockAlign();
- while (inputsize>ac3framesize)
+ while (inputsize>=ac3framesize)
{
int ret=libavcodec->avcodec_encode_audio(avctx,ac3buf,AC3_MAX_CODED_FRAME_SIZE,(const short*)&*inputsamples);
HRESULT hr;

[nautilus7]

It's really good that someone is taking care of all these small bugs. Thank you.

[tal.aloni]

Commited as rev. 2495:

+ Updated FIR filter description
+ Added tooltip to AC3 encode mode, detailing the supported sample rates.

(http://iknowu.net/files/public/ffdshow/2491-Hint.patch)

I hope this is a good work-around for now, another one would be to automatically resample to 48kHz before encoding.
(this is less prefered since in the future, when 44,100 will be supported, it may start causing problems to some users with equipment that does not support 44,100kHz)

[Jeremy Duncan]

link (https://sourceforge.net/tracker/index.php?func=detail&aid=2436501&group_id=173941&atid=867363)

To the ffdshow developers. I have made a thread in the sourceforge website for a requested feature.

And for some reason I can't get ffdshow audio to let me use windows media player for mp3. I use vista 32 bit premium and xp pro.
I tried various versions of ffdshow. These are my ffdshow audio settings.

________ FFdshow Audio Decoder ________

Codecs tab
- AC3 Tab
Decoder liba52
Do Not Check "Dynamic Range compression"
Do Not Check Use SPDIF when AC3 output set

- DTS Tab
Decoder libdts
Do Not Check "Dynamic range compression"
Do not Check "...for DTS in WAV"
Do Not Check Use SPDIF when AC3 output set

- Uncompressed Tab
Set it to "all supported"

Mixer tab
- 5.1, or stereo

Output tab,
analog.) 24 bit sound,

[rack04]

Is anyone else experiencing ~2x playback speed using libavcodec for mp3 in ffdshow tryouts mt svn 2484? Plays fine using libmad.

This problem still exists with ffdshow-mt revision 2497.

[clsid]

And for some reason I can't get ffdshow audio to let me use windows media player for mp3. I use vista 32 bit premium and xp pro.That is because WMP uses its own DMO decoder for MP3 files. No solution for that, except to go harass MS.

[haruhiko_yamagata]

This problem still exists with ffdshow-mt revision 2497.
Is the trunk build OK?

[rack04]

Is the trunk build OK?

libavcodec plays mp3 at normal speed using ffdshow rev2498.

[clsid]

Selecting the option in the installer to reset the ffdshow settings only applies to the current Windows user account. However, it is of course desirable to reset the settings for all user accounts. It is technically not possible to do that from the installer, so it has to be implemented into ffdshow. I propose the following scheme:

The installer creates to following registry value (when reset option is enabled):
HKLM\Software\GNU\ffdshow, ResetSettingsIfOlderThanRevision: dword

Whenever ffdshow loads, it checks if the above registry value exists. If the value exists, then it should check if this value also exists:
HKCU\Software\GNU\ffdshow, SettingsResetAtRevision: dword
Settings should be reset when the above value does not exist, or if it has a value that is smaller than ResetSettingsIfOlderThanRevision.

Resetting the settings means deleting the registry keys
HKCU\Software\GNU\ffdshow*
And then create value SettingsResetAtRevision with value that equals ResetSettingsIfOlderThanRevision.

This should all be done when ffdshow initializes, and before it reads any settings.
It may be tricky if the audio/video decoder are loading simultaneously. So a critical section or some other solution may be needed.

Opinions? Comments?
Is there anyone that has time to implement this scheme?

[leeperry]

I was just trying the 2488 build of ffdshow-mt

first, if you don't install the VFW components you get an error msg that "pthreadGC2.dll was not installed" :(

also it's not ICL10 compiled so ffdshow audio code is not optimized as much for my Q6600 I guess.

anyway results on a test h264 file are pretty impressive....I guess CoreAVC will soon have to support CUDA otherwise it's gonna become more and more useless :o

CoreAVC 1.85 + ffdshow Avisynth/sharpening :
User: 8s, kernel: 1s, total: 10s, real: 13s, fps: 48.6, dfps: 37.7
User: 8s, kernel: 2s, total: 10s, real: 13s, fps: 48.9, dfps: 37.7
User: 8s, kernel: 1s, total: 10s, real: 13s, fps: 48.4, dfps: 37.7

ffd 2447 icl10 :
User: 8s, kernel: 2s, total: 10s, real: 14s, fps: 46.1, dfps: 34.5
User: 8s, kernel: 2s, total: 10s, real: 14s, fps: 46.6, dfps: 34.6
User: 8s, kernel: 2s, total: 10s, real: 14s, fps: 46.5, dfps: 34.6

ffd 2488 mt :
User: 8s, kernel: 2s, total: 10s, real: 13s, fps: 48.9, dfps: 37.2
User: 8s, kernel: 1s, total: 10s, real: 13s, fps: 48.1, dfps: 37.3
User: 8s, kernel: 2s, total: 10s, real: 13s, fps: 47.5, dfps: 37.1

[fastplayer]

Opinions? Comments?
Why not take this one step further? Allow during setup to choose between per user (HKCU) vs. global settings (HKLM).

Edit: Regarding ffdshow_prebeta6_rev2504_20081217.exe (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_prebeta6_rev2504_20081217.exe):
Looks like Beta 6 is 32-bit-only. No 64-bit version planned, right?

[clsid]

Why not take this one step further? Allow during setup to choose between per user (HKCU) vs. global settings (HKLM).That would require major changes to ffdshow. Also, regular user accounts can't write to HKLM. Storing settings in an INI file would be a better alternative. But I doubt anyone is willing to implement that, so forget about it.

Looks like Beta 6 is 32-bit-only. No 64-bit version planned, right?64-bit builds are not stable yet

[Atak_Snajpera]

I was just trying the 2488 build of ffdshow-mt

first, if you don't install the VFW components you get an error msg that "pthreadGC2.dll was not installed"

also it's not ICL10 compiled so ffdshow audio code is not optimized as much for my Q6600 I guess.

anyway results on a test h264 file are pretty impressive....I guess CoreAVC will soon have to support CUDA otherwise it's gonna become more and more useless
What is still missing in MT version? Will normal version be replaced by MT soon?

[fastplayer]

64-bit builds are not stable yet
OK, I'll update the new homepage accordingly. Haruhiko wasn't quite sure when I asked whether there'll be a 64-bit build...

[clsid]

What is still missing in MT version? Will normal version be replaced by MT soon?
Not anytime soon. It may take several more months before it is ready. Certainly since its developer is not very active.

[fastplayer]

What is still missing in MT version?
http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt/blobs/master/mt-work/todo.txt

[LoRd_MuldeR]

http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt/blobs/master/mt-work/todo.txt

But do any of these TODO's actually affect ffdshow? Are there any known regressions?

I switched over to ffdshow-MT a while ago and didn't notice any problems, at last no additional problems (compared to "normal" branch). Seems pretty stable :)

So far I only saw one H.264 sample that had display errors (was posted in this thread) and that issue could be fixed by settings threads to 1.

Well, I certainly don't use/test any single aspect of ffdshow, so there might be problems I don't notice...

[tal.aloni]

it is of course desirable to reset the settings for all user accounts.

I tend to disagree,
why does another user should have the power to reset my equalizer settings? I think another user should be able to reset his own settings and the "common" settings. this should be able to ensure a "clean slate" with minimum damage to other users.

[Mr VacBob]

But do any of these TODO's actually affect ffdshow? Are there any known regressions?

I switched over to ffdshow-MT a while ago and didn't notice any problems, at last no additional problems (compared to "normal" branch). Seems pretty stable :)

So far I only saw one H.264 sample that had display errors (was posted in this thread) and that issue could be fixed by settings threads to 1.


Well, that is a regression.

I had no time to work on it during school, but now I can again, and I think I found the problem with that sample (some problem with Picture.ref_index). I'll try to fix it soon.

Even after I fix everything in the todo, there are some API and philosophical issues to work out before submitting it to mainline again, though.

edit: actually, it was because the dequant matrix changes in the middle of the stream

[squid_80]

I guess CoreAVC will soon have to support CUDA otherwise it's gonna become more and more useless :o
Before jumping on the GPU decoding bandwagon I suggest you run benchmarks comparing the decoding speed of DGAVCDecNV vs. ffdshow-MT/CoreAVC. (I don't meaning disabling the display in DGAVCIndexNV and pressing F6, it's not an accurate benchmark.)

[cca]

i was just trying the 2488 build of ffdshow-mt

first, if you don't install the vfw components you get an error msg that "pthreadgc2.dll was not installed" :(



That's strange, haruhiko fixed that in revision 2353, do we have a regression?

[haruhiko_yamagata]

I had no time to work on it during school, but now I can again, and I think I found the problem with that sample (some problem with Picture.ref_index). I'll try to fix it soon.Wonderful news. And nice to see you in this thread.

[leeperry]

That's strange, haruhiko fixed that in revision 2353, do we have a regression?
yeah, that's how I found out that I had to install the VFW components...some hiccup in the installer I guess.
Before jumping on the GPU decoding bandwagon I suggest you run benchmarks comparing the decoding speed of DGAVCDecNV vs. ffdshow-MT/CoreAVC. (I don't meaning disabling the display in DGAVCIndexNV and pressing F6, it's not an accurate benchmark.)
well if it lets my GPU do the job, this will leave my CPU alone for HD post-processing(gamut conversion/LSF etc) :D

[saint-francis]

well if it lets my GPU do the job, this will leave my CPU alone for HD post-processing(gamut conversion/LSF etc) :D

The catch is that decoding with CUDA seems to use no fewer CPU cycles than coreavc. So it's a moot point.

[clsid]

Once Mr VacBob fixes that one known decoding error in ffmpeg-mt, then the remaining issues are:
* Frame accurate seeking. Reported by CruNcher. Details (http://forum.doom9.org/showthread.php?p=1216287#post1216287). Although this might not be a problem specific to ffmpeg-mt. If not, it is not a regression, and thus not a show stopper.
* Which decoders currently use the new MT API in ffmpeg-mt? I vaguely remember a report about mpeg-2 decoding issues with multiple threads. But I don't know if that was with ffmpeg-mt or regular builds.

[clsid]

I tend to disagree,
why does another user should have the power to reset my equalizer settings? I think another user should be able to reset his own settings and the "common" settings. this should be able to ensure a "clean slate" with minimum damage to other users.
That other user is the administrator. The admin has the power to install/uninstall ffdshow and should imo also be able to reset the settings for all users. A regular user won't be able to reset your settings. And we could add a checkbox "for all users" to the installer, so that the admin can choose to only reset its own settings.

[clsid]

Since ffdshow is now able to decode RealVideo, it is finally possible to play RealMedia files in 64-bit players. That's pretty useful since there is not even a 64-bit version of RealPlayer. However, a single problem remains. There is no decoder for Cook audio yet. Our version of libavcodec already contains the decoding code and ffdshow also already has some cook related code, but there is no option yet in the GUI to enable it. I don't know why such option is missing, possibly because it did not work properly long time ago. Does anyone here has some time to look at it and add the missing option?

[squid_80]

The catch is that decoding with CUDA seems to use no fewer CPU cycles than coreavc. So it's a moot point.
Oh it does that alright. Just that the top speed is nowhere near CoreAVC unless you're on a low-end cpu. (Atom anyone?)

[Mr VacBob]

Once Mr VacBob fixes that one known decoding error in ffmpeg-mt, then the remaining issues are:
* Frame accurate seeking. Reported by CruNcher. Details (http://forum.doom9.org/showthread.php?p=1216287#post1216287). Although this might not be a problem specific to ffmpeg-mt. If not, it is not a regression, and thus not a show stopper.


H264 can already have large unpredictable frame delay (up to 16 frames), but frame threading makes it worse. Basically you should use reordered_opaque, and then pass in future frames until you get back the one that was being seeked to (and then NULL frames at the end of the file).

If you don't have future frames available, then you're stuck - this is the API issue I have to work out.


* Which decoders currently use the new MT API in ffmpeg-mt? I vaguely remember a report about mpeg-2 decoding issues with multiple threads. But I don't know if that was with ffmpeg-mt or regular builds.

MPEG2 doesn't use frame-threading, since all 480p MPEG2 has at least 30 slices per frame.

[leeperry]

The catch is that decoding with CUDA seems to use no fewer CPU cycles than coreavc. So it's a moot point.
you're saying that CUDA h264 decoding uses as much CPU as CoreAVC/ffdshow-mt ?
so how come x264 encoding from a h264 source is faster w/ neuron2's software then ?
I was under the impression that it was offering the same kind of performance as DXVA :o

[DigitalDeviant]

you're saying that CUDA h264 decoding uses as much CPU as CoreAVC/ffdshow-mt ?
so how come x264 encoding from a h264 source is faster w/ neuron2's software then ?
I was under the impression that it was offering the same kind of performance as DXVA :o

Core's initial benchmarks (look in the CoreAVC thread) only showed a decent fps increase in single core CPUs. I don't know about actual cycles. Dual core's showed a negligible increase less than 10% I believe and quad core's really took a hit with CUDA enabled. It's not full acceleration so far as anyone has hinted from Core. They say they're working on multicore improvements.

[nm]

Core's initial benchmarks (look in the CoreAVC thread) only showed a decent fps increase in single core CPUs. I don't know about actual cycles. Dual core's showed a negligible increase less than 10% I believe and quad core's really took a hit with CUDA enabled. It's not full acceleration so far as anyone has hinted from Core. They say they're working on multicore improvements.
However, hardware decoding on a GPU does leave the CPU almost completely unused, so leeperry has a point in combining CUDA video decoding with software postprocessing. Also custom GPU postprocessing is possible since video decoding is done in a unit separate from the stream processors. Limited decoding throughput is not a problem for realtime playback.

[STaRGaZeR]

Well, that is a regression.

edit: actually, it was because the dequant matrix changes in the middle of the stream

Which sample? I don't know if it's the same you're refering to, but this one also has decoding artifacts that disappear when only 1 thread is used. It comes from Blu-ray:

http://www.megaupload.com/?d=90KHBJTQ (42MB)

(It's the same I sent to you Haruhiko)

[Snowknight26]

Any plans to implement multithreaded decoding for interlaced H.264 streams apart from in ffdshow-mt (if in there at all)?

[CruNcher]

However, hardware decoding on a GPU does leave the CPU almost completely unused, so leeperry has a point in combining CUDA video decoding with software postprocessing. Also custom GPU postprocessing is possible since video decoding is done in a unit separate from the stream processors. Limited decoding throughput is not a problem for realtime playback.

Exactly and that makes it pretty fast (Energy Efficient) and not as CPU utilizing as CUDA itself so the way CoreAVC implements it is suboptimal, Donald is the only one yet that does it right :)
Though no one says that it isn't possible to create a Interface via ffdshow to Nvcuvid API and use it to render on any surface you can think of being fully independent of DXVAs restrictions :)
Jesus Nvidia gave every Developer the opportunity to leverage the VP2 Decoding Power for Encoding/Decoding it's all in the SDK available to everyone, and currently Donald is doing a lot of debugging work with the Doom9 Users and Nvida Engineers to improve it's capabilities and squash bugs, only requirement is Direct3D currently and a supported VP2 Nvidia Card leveraging it on the Linux side is also possible via VDPAU.
All these improvements help the whole Nvidia Video Ecosystem every 3rd party Developer can leverage from that improvements and with Doom9 Users backing it it should be soon the most stable GPU Decoder solution available it already is more advanced and stable then libavcodec (H264,VC-1) :)

And if you already have the capabilities of using this you should because everytime you load a blu-ray on such a VP2 capable machine with CoreAVC or libavcodec you throw out massive amount of Energy into to the AIR.

[Mr VacBob]

Which sample? I don't know if it's the same you're refering to, but this one also has decoding artifacts that disappear when only 1 thread is used. It comes from Blu-ray:

http://www.megaupload.com/?d=90KHBJTQ (42MB)

(It's the same I sent to you Haruhiko)

Right, I meant that one. It's fixed in the git repository now.

Any plans to implement multithreaded decoding for interlaced H.264 streams apart from in ffdshow-mt (if in there at all)?

It works the same whether it's interlaced or not; ffdshow-mt handles it fine, and mainline handles it fine if it was encoded with slices.

[Snowknight26]

What about the current trunk? I'm asking because with with the current trunk a 20Mbps 1080i25 sample I have is being decoded at 15-20fps (1 core is used), while 35Mbps 1080p24 content decodes at the proper fps yet it uses more than 1 core.

[nm]

What about the current trunk? I'm asking because with with the current trunk a 20Mbps 1080i25 sample I have is being decoded at 15-20fps (1 core is used)
Then it's probably not sliced and you need frame-based threading (ffdshow-mt). Interlacing shouldn't matter.

[Snowknight26]

Last I heard, H.264 Blu-rays used slice coding.

[nm]

Could you upload a sample?

[Snowknight26]

http://stfcc.org/misc/00000.cut.m2ts

[nm]

The actual problem is this, as given by the decoder: "Cannot parallelize deblocking type 1, decoding such frames in sequential order"
To disable deblocking across slices and enable multithreading, you'll need to use the FFmpeg parameter "-flags2 fast" (I don't know how to set it in ffdshow).

[Snowknight26]

Heh, another issue with my infamous 1080i25 video (same as the link above). After being about 1:30:00 into it, the current frame # is up in the upper 500000s. It seems that when I check Grab and have it save every frame, the frame number increments by 5 each time.

Also, although this is probably a libavcodec issue, I didn't know where else to bring it up. That 1080i25 stream is PAFF if I remember correctly. Parts of it are interlaced, parts aren't. The parts that are interlaced are deinterlaced fine when deinterlacing is turned on. However, the parts that aren't interlaced are still deinterlaced with deinterlacing turned on, regardless of having 'Process frames flagged as progressive' unchecked (unless it means the opposite of what I'm thinking).

http://stfcc.org/misc/deinterlacing.ffdshow.off.png
http://stfcc.org/misc/deinterlacing.ffdshow.on.png
And just for kicks, http://stfcc.org/misc/deinterlacing.mpc-hc.png using DXVA with hardware deinterlacing.

[haruhiko_yamagata]

H264 can already have large unpredictable frame delay (up to 16 frames), but frame threading makes it worse. Basically you should use reordered_opaque, and then pass in future frames until you get back the one that was being seeked to
In DirectShow, decoders receive compressed frame from the splitter, find the entry point (ffdshow searches IDR or GDR by decoding the SEI by custom code) and start decoding, start presenting where the timestamp given by the splitter is bigger than 0.
It's working correctly except the garbled image I get when I seek in premiere-paff.ts.
And ffdshow use reordered_opaque to reorder timestamps.
I can't reproduce what CruNcher has said.

(and then NULL frames at the end of the file).
ffmpeg-mt branch of ffdshow does this correctly. I know I should have applied it to our trunk, but I've been to lazy.

If you don't have future frames available, then you're stuck - this is the API issue I have to work out.
I have not experienced this issue.

//EDIT
The seeking is not working perfectly in the trunk build. Though it is more noticeable in the mt build, it may not related to multithreading.

[haruhiko_yamagata]

though stability compared to commercial decoder seems still low i sometimes lose up to 4 frames of the original source input (beginning,end) :( in different rendering scenarios (AVC,ASP,Mpeg-2), also frame exact seeking is still bad too. Using the same Splitter Haali's for all of them ffdshow always loses frames or endsup @ the wrong frame when for example requesting a b-frame compared to CoreAVC,DivX,Elecard,Cyberlink,Arcsoft,Nero :( I lost hope that the Libavcodec guys gonna ever improve that but i wonder if it can't be done via a workaround over dshow forceing it somehow.Sorry for late reply.
Please read the post above.
Please separate AVC,ASP and MPEG-2.
What do you mean by "frame exact seeking"?

I know seeking is broken for libavcodec-MPEG2.
Perhaps we have to give up using CODEC_FLAG_TRUNCATED.
Doesn't it work for AVC (except when we get garbled image)?

Frames lost at the beginning? Could you send us some samples?

As for the last frame, ffmeg-mt branch has the code to handle it properly. I'll port it to trunk when I have time.

[haruhiko_yamagata]

Heh, another issue with my infamous 1080i25 video (same as the link above). After being about 1:30:00 into it, the current frame # is up in the upper 500000s. It seems that when I check Grab and have it save every frame, the frame number increments by 5 each time.

Also, although this is probably a libavcodec issue, I didn't know where else to bring it up. That 1080i25 stream is PAFF if I remember correctly. Parts of it are interlaced, parts aren't. The parts that are interlaced are deinterlaced fine when deinterlacing is turned on. However, the parts that aren't interlaced are still deinterlaced with deinterlacing turned on, regardless of having 'Process frames flagged as progressive' unchecked (unless it means the opposite of what I'm thinking).

http://stfcc.org/misc/deinterlacing.ffdshow.off.png
http://stfcc.org/misc/deinterlacing.ffdshow.on.png
And just for kicks, http://stfcc.org/misc/deinterlacing.mpc-hc.png using DXVA with hardware deinterlacing.
The OSD issue is basically same as the 108fps problem. Low priority but should be fixed someday.
As for the interlacing flags, are you sure that the stream has correct flags?

[haruhiko_yamagata]

@clsid
would it be possible to support Elecards Mpeg and Mp4 Demultiplexers :) watching RAW bitstreams (Annex B Progressive AVC for example) with ffdshow with them isn't really nice CoreAVC, Cyberlink and DivX are interoperable with them ffdshow, MPCs Video Decoder and Arcsoft have problems (garbaged output,black screen, no connection) :(If you provide me a set of files, I'm ready to work on it.

[CruNcher]

If you provide me a set of files, I'm ready to work on it.

http://elecard.ru/products/products-pc/sdk/codec-sdk/

emp4demux.ax
empgdmx.ax

you can just use any simple AVC bitstream and for MP4 any .mp4 (mp4muxer,mp4box) including ASP or AVC getting as much formats to work with ffdshow is the goal .mpg(vob,evo) (Mpeg-1,Mpeg-2,AVC) .ts (Mpeg-2,AVC) ect empgdmx virtually supports everything ISO specified + Blu-Ray :)

[fastplayer]

Can somebody with a high-res TFT (1680x1050 and higher) check out the new ffdshow homepage? Is the font size too small?
http://ffdshow-tryout.sourceforge.net/index2.php

[haruhiko_yamagata]

http://elecard.ru/products/products-pc/sdk/codec-sdk/

emp4demux.ax
empgdmx.ax

you can just use any simple AVC bitstream and for MP4 any .mp4 (mp4muxer,mp4box) including ASP or AVC getting as much formats to work with ffdshow is the goal .mpg(vob,evo) (Mpeg-1,Mpeg-2,AVC) .ts (Mpeg-2,AVC) ect empgdmx virtually supports everything ISO specified + Blu-Ray :)
$299...
If anyone is willing to donate a license.

[thuan]

Well I'm on 1680x1050 and the page looks just fine on my monitor I think the font is 10 or around that. Pretty standard. If you feel it's too small just use zooming feature of your browser.

[fastplayer]

$299...
If anyone is willing to donate a license.
Not if you enter the discount code :p
Then it's only $209.30! :D

[XhmikosR]

Can somebody with a high-res TFT (1680x1050 and higher) check out the new ffdshow homepage? Is the font size too small?
http://ffdshow-tryout.sourceforge.net/index2.php

With 1920x1200, it looks normal.:)

[fastplayer]

Well I'm on 1680x1050 and the page looks just fine on my monitor I think the font is 10 or around that. Pretty standard. If you feel it's too small just use zooming feature of your browser.
With 1920x1200, it looks normal.:)
Thanks for confirmation, guys! As long as it's readable and you don't need to zoom, I'm OK with it.

Any chance you can PM me or post here a screenshot? I'm still tinkering with the floats and padding...

[XhmikosR]

http://img210.imageshack.us/img210/3586/19122008134124cb7.th.png (http://img210.imageshack.us/my.php?image=19122008134124cb7.png)

[fastplayer]

http://img210.imageshack.us/img210/3586/19122008134124cb7.th.png (http://img210.imageshack.us/my.php?image=19122008134124cb7.png)
Thanks! Looks better than expected :)
By the way, don't browse the page with IE6... :D

[XhmikosR]

I don't use IE6, only Firefox.:)

[fastplayer]

I don't use IE6, only Firefox.:)
I wasn't implying that you were. It's just that the page renders correctly in all browsers that deserve to be called like that. All - except IE6... :D

[STaRGaZeR]

Right, I meant that one. It's fixed in the git repository now.

And in ffdshow-MT now too. Thanks :)

The only issues I have with the MT branch are:

- The known garbled image when seeking to certain points.
- ffdshow crashes randomly when seeking in consecutive steps, in my case 5s. I can't reproduce it when seeking using MPC's slider, probably because I can't hit problematic points with its precision. Also this only happens with unknown encoders (i.e. Blu-ray), x264 streams seems to be perfectly fine regarding this issue.

[Kurtnoise]

Can somebody with a high-res TFT (1680x1050 and higher) check out the new ffdshow homepage? Is the font size too small?
http://ffdshow-tryout.sourceforge.net/index2.php
looks ok for me too.


btw, you should add also a link to the FFmpeg website (http://ffmpeg.org)...:)



just my 2€ cents...

[fastplayer]

btw, you should add also a link to the FFmpeg website (http://ffmpeg.org)...:)
Thanks!
There's a link to FFmpeg right on the start page in the 2nd paragraph. I can add it to the link section too, of course.

[Kurtnoise]

you're right...did'nt see it. :p

@haruhiko :

http://pix.nofrag.com/e/3/6/7648861117e32a357206d3e0c1d91.png (http://pix.nofrag.com/e/3/6/7648861117e32a357206d3e0c1d91.html)

[nautilus7]

As long as it's readable and you don't need to zoom, I'm OK with it.Well, it's readable, but i would like it a bit bigger. I think it is a click smaller than normal. I am on 1680x1050 20" monitor (maybe on 21"-22" there's no problem).

[STaRGaZeR]

Sample for testing double speed playback with libavcodec MP3. So far this is the only one I have that has this problem. It doesn't matter the container, you can also demux it.

http://www.megaupload.com/?d=OA592VG2 (29MB)

EDIT: Oops I didn't see your last commit Haruhiko, sorry.

[LoRd_MuldeR]

Well, that is a regression.

I had no time to work on it during school, but now I can again, and I think I found the problem with that sample (some problem with Picture.ref_index). I'll try to fix it soon.

Even after I fix everything in the todo, there are some API and philosophical issues to work out before submitting it to mainline again, though.

edit: actually, it was because the dequant matrix changes in the middle of the stream

Thank you for the info :thanks:

And I can confirm that the "freedom EP1" sample now plays flawlessly with ffdshow-MT r2515 :)

[STaRGaZeR]

The only issues I have with the MT branch are:

- The known garbled image when seeking to certain points.
- ffdshow crashes randomly when seeking in consecutive steps, in my case 5s. I can't reproduce it when seeking using MPC's slider, probably because I can't hit problematic points with its precision. Also this only happens with unknown encoders (i.e. Blu-ray), x264 streams seems to be perfectly fine regarding this issue.

OK I've been able to find a sample that has both problems. I can always reproduce them at the same frame:

- With Haali's Splitter:

When seeking to frame 160 --> Garbled frames.
When seeking to frame 163 --> Video stops, and if you do anything else with the player it hangs and you have to kill it with task manager. If only 1 thread is used then it does something strange but doesn't hang.

- With MPC's internal Matroska splitter:

The same but seeking to frames 159 and 167 respectively.

You can use Ctrl+G in MPC to go directly to those frames.

http://www.megaupload.com/?d=E8X3WSST (55MB)

[clsid]

Release candidate for the official beta 6:
download (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_prebeta6_rev2527_20081219.exe?use_mirror=)
Please test. If no major issues are reported, then this build will become beta6 tomorrow.

This build includes several H.264 related changes that were made in the past few days. Decoding performance has improved with 4-10% (depending on CPU) :)

[clsid]

A few people have reported an issue with the x64 builds of ffdshow where ffdshow uses an unusually high amount of CPU cycles, resulting in bad playback (stuttering, frame drops). This issue is present for a long time now, so not related to any recent changes.

Weird thing is that the CPU usage returns to normal when the OSD is enabled in ffdshow video decoder.

Does anyone have an idea what might cause this problem, and why the OSD makes a difference?

I myself am unable to reproduce the issue on a clean install of Vista x64.

[LoRd_MuldeR]

This build includes several H.264 related changes that were made in the past few days. Decoding performance has improved with 4-10% (depending on CPU) :)

Do these changes only apply to the "normal" branch or do they effect the MT branch to?

In the latter case I'd need to do new benchmarks :cool:

[LoRd_MuldeR]

Weird thing is that the CPU usage returns to normal when the OSD is enabled in ffdshow video decoder.

Got a similar problem with recent builds (normal and MT, but not x64) when playing interlaced MPEG-2 and using Yadif.
With Yadif enabled (internal version -or- Avisynth version) I get "slow motion" playback, which disappears when the OSD is enabled!
Had a lot of private discussion with haruhiko_yamagata about that problem already, but no solution yet.

It came down to the following result:
* The time ffdshow spends in Yadif is always okay.
* When the slow motion happens, then ffdshow spends a very long time (much too long) in the "convert" function!
* The "convert" time is back to normal with OSD enabled.

Note that there was no such problem in rev2347, seems it started around rev2391 ...

[fastplayer]

Do these changes only apply to the "normal" branch or do they effect the MT branch to?
Both.
In the latter case I'd need to do new benchmarks :cool:
Oh, you shouldn't have said that :D
We desperately need someone who is willing to test one of the pre-Beta 6 builds for our FAQ. The current FAQ entry (http://ffdshow-tryout.wiki.sourceforge.net/FAQ#perf_filters) is based on build 802... :eek:

[LoRd_MuldeR]

Some new numbers:

E:\HD\freedom EP1 sample.mkv, 1920x1080, High@L4.1

[ffdshow, rev2033, Beta-5, 4 threads]
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 153.4, dfps: 27.1
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 148.8, dfps: 27.0 <-- 100%
User: 3s, kernel: 0s, total: 4s, real: 25s, fps: 143.4, dfps: 24.1

[ffdshow, rev2509, 4 threads]
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 142.8, dfps: 27.2
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 142.8, dfps: 27.2 <-- 100%
User: 3s, kernel: 0s, total: 4s, real: 25s, fps: 140.8, dfps: 24.2

[ffdshow, rev2527, Pre-Beta 6, 4 threads]
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 149.3, dfps: 27.5
User: 3s, kernel: 0s, total: 3s, real: 22s, fps: 155.2, dfps: 27.4 <-- 101%
User: 3s, kernel: 0s, total: 4s, real: 24s, fps: 147.1, dfps: 24.9

[ffdshow-MT, rev2515, 4 threads]
User: 2s, kernel: 0s, total: 2s, real: 8s, fps: 219.0, dfps: 68.7
User: 2s, kernel: 0s, total: 2s, real: 8s, fps: 252.7, dfps: 68.7 <-- 254%
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 220.2, dfps: 67.2

[CoreAVC, Version 1.8.5]
User: 0s, kernel: 0s, total: 0s, real: 7s, fps: 679.7, dfps: 82.3
User: 0s, kernel: 0s, total: 1s, real: 7s, fps: 616.0, dfps: 82.1 <-- 304%
User: 0s, kernel: 0s, total: 0s, real: 7s, fps: 691.6, dfps: 82.0

[DivX H.264 Decoder, Beta-3]
User: 1s, kernel: 0s, total: 1s, real: 6s, fps: 458.4, dfps: 88.4
User: 1s, kernel: 0s, total: 1s, real: 6s, fps: 512.0, dfps: 88.4 <-- 327%
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 499.0, dfps: 87.6


Can't say that the "normal" branch of ffdshow became significant faster between Beta-5 (r2033) and Beta-6 (r2527) on my system...

[leeperry]

We desperately need someone who is willing to test one of the pre-Beta 6 builds for our FAQ. The current FAQ entry (http://ffdshow-tryout.wiki.sourceforge.net/FAQ#perf_filters) is based on build 802... :eek:
if you can provide the generic/GCC/ICL 10.1 SSE/ICL 10.1 SSE2 builds of the same rev, I can run compares on h264 HD decoding + sharpening in RGB32HQ on an o/c Q6600(I'm also a Remoulade beta tester)

[clsid]

Can't say that the "normal" branch of ffdshow became significant faster between Beta-5 (r2033) and Beta-6 (r2527) on my system...Since beta5 there were also some fixes regarding compliance to the H.264 specification. Some of those had a negative performance impact.

r2527 is 4% faster on my system than builds from last week. CPUs with SSE2 should get bigger gains.

Your results show a smaller increase in performance because you tested with 4 threads. Test the non-MT builds with 1 thread.

[clsid]

if you can provide the generic/GCC/ICL 10.1 SSE/ICL 10.1 SSE2 builds of the same rev, I can run compares on h264 HD decoding + sharpening in RGB32HQ on an o/c Q6600(I'm also a Remoulade beta tester)
Generic and ICL10 builds are online. GCC build is no longer officially supported.

[LoRd_MuldeR]

You results show a smaller increase in performance because you tested with 4 threads. Test the non-MT builds with 1 thread.

I don't get this. If the latest revision really runs faster than the older revision with one single thread, why should this speed-up (difference) suddenly go away with several threads?

Especially when both versions compared use the very same "old" multi-threading implementation...

[laserfan]

Is there any way to identify the version of ffdshow (libavcodec in particular) via a .cmd line?

[fastplayer]

I don't get this. If the latest revision really runs faster than the older revision with one single thread, why should this speed-up go away with several threads?

Especially when both versions compared use the very same "old" multi-threading implementation...
My guess:
Thread creating, spawning, switching etc. are all operations that require themselves a bunch of CPU cycles, cache, latency etc. Apparently, these "costs" are so high on quad core that they totally negate any performance gain.

[leeperry]

Generic and ICL10 builds are online. GCC build is no longer officially supported.
ok, but I guess the idea is to benchmark beta6 ?
so if you wouldn't mind to build it in icl10/generic, I'll be happy to try them :)

there used to be separate sse1/sse2 ICL versions, but that doesn't existe in ICL 10.1 anymore ? when yesgrey3 built ICL10.1 versions of the Reclock resampler, some of them were much faster than others...I could ask him for the best settings.

also, that'd be good to take audio PP in account, because that's where the ICL10 versions shine IMO...and timecodec can't benchmark that..

[LoRd_MuldeR]

Apparently, these "costs" are so high on quad core that they totally negate any performance gain.

If that was the case, then multiple threads would run slower than one thread (in the none-MT version) on my Machine.

But in fact the none-MT version never uses uses more than two threads for H.264. And, although it can't keep up with the MT version, the two thread patch gives some speed-up!

I don't see why this should no longer be the case (and even turn to the opposite), after further optimizations have arrived...

[roozhou]

If that was the case, then multiple threads would run slower than one thread (in the none-MT version).

But in fact the none-MT version never uses uses more than two threads for H.264. And, although it can't keep up with the MT version, the two thread patch gives some speed-up!

I don't see why this should no longer be the case (and even turn to the opposite), after further optimizations have arrived...

What CPU are you using? Recently Dark Shikari has merged some of x264's SSE2 codes into ffmpeg. If you are using non-Phenom AMD CPU, it won't give you significant speedup.

[LoRd_MuldeR]

What CPU are you using? Recently Dark Shikari has merged some of x264's SSE2 codes into ffmpeg. If you are using non-Phenom AMD CPU, it won't give you significant speedup.

See "My Specs" in my signature. SSE2 is supported by my CPU.

[clsid]

@leeperry,
I am not going to make any more builds. Four is enough for today. SSE2 showed no gain in the past over SSE with the ICL builds, so I am not going to waste my time on that again.
Use the trunk builds.

@LoRd_MuldeR,
I never said that there won't be any speedup with >1 threads. I just said that testing with 1 thread gives a better picture that isn't clouded by the effect of a crappy MT implementation.

[LoRd_MuldeR]

@LoRd_MuldeR,
I never said that there won't be any speedup with >1 threads. I just said that testing with 1 thread gives a better picture that isn't clouded by the effect of a crappy MT implementation.

Okay. I will do another test later and I will explicitly enforce one single thread. Right now a capture is in progress...

[fastplayer]

If that was the case, then multiple threads would run slower than one thread (in the none-MT version).
I think you misunderstood me. In this particular situation the performance gains that have been achieved by the FFmpeg guys, are not enough to overcome the cost that is associated with spawning a 2nd, 3rd or 4th thread. Either that or the changes they made are just less SMP-friendly...

[LoRd_MuldeR]

I think you misunderstood me. In this particular situation the performance gains that have been achieved by the FFmpeg guys, are not enough to overcome the cost that is associated with spawning a 2nd, 3rd or 4th thread. Either that or the changes they made are just less SMP-friendly...

Sure. But if two threads already run faster than one thread, which is the case on my system (even with the none-MT version), then I hardly can imagine how further optimizations can make the "one thread" variant run faster, while there is no noticeable speed-up for the "two threads" variant. I'd rather assume that these optimizations don't help my Core2 as much as other CPUs. But as said before, I will do more tests later.

[fastplayer]

Generic and ICL10 builds are online. GCC build is no longer officially supported.
You mean GCC is not used anymore for compiling ffdshow.ax, correct?

[yesgrey]

when yesgrey3 built ICL10.1 versions of the Reclock resampler, some of them were much faster than others...I could ask him for the best settings.

The best settings are always application dependent...
For the resampler the best settings were to not use any Intel extensions...
Maybe with the new code the result is different, but I don't believe it.

[tetsuo55]

A few people have reported an issue with the x64 builds of ffdshow where ffdshow uses an unusually high amount of CPU cycles, resulting in bad playback (stuttering, frame drops). This issue is present for a long time now, so not related to any recent changes.

Weird thing is that the CPU usage returns to normal when the OSD is enabled in ffdshow video decoder.

Does anyone have an idea what might cause this problem, and why the OSD makes a difference?

I myself am unable to reproduce the issue on a clean install of Vista x64.

Just based on the description this seems to be the inversion of the bug i reported earlier. OSD enabled causes it to show 100% CPU when combined with auto-post processing.

I think the OSD is broken in more ways than one resulting in unexpected behaviour in several parts of ffdshow
In the case you mention it helps, it the case i mentioned it hurts.

Imho it should get a higher priority than it has at the moment

[fastplayer]

I'd rather assume that these optimizations don't help my Core2 as much as other CPUs.
M. Niedermayer made quite a few H.264-related commits in the past few days and he's running a Merom CPU (castrated C2D):
http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2008-December/018415.html

[tetsuo55]

Yeah all those h264 commits look great, all those 0.? speedups have to combine into a nice ?.? somewhere.

According to the changelog the speedups where measured on a pentium dual. Also a lot of unneeded checks and calculations where dropped.

This means on a per sample and per system basis the increase in FPS can be pretty high(probably never more than 10% though)

Also there seems to be more work done on realmedia 30 and 40, hopefully there should be less problems with it now and i hope that its soon fully able to replace realplayer.

[Snowknight26]

As for the interlacing flags, are you sure that the stream has correct flags?

I don't know how to find that out, but here (http://stfcc.org/misc/00000.cut2.m2ts) is a sample of where it changes from progressive to interlaced and vice versa.

[STaRGaZeR]

I don't know how to find that out, but here (http://stfcc.org/misc/00000.cut2.m2ts) is a sample of where it changes from progressive to interlaced and vice versa.

Your sample is MBAFF. That means it's interlaced at macroblock level. In the same frame it may be macroblocks coded as interlaced and others as progressive. In order to view this correctly the entire stream has to be deinterlaced, just like it is now.

BTW Tiesto rules :p

[haruhiko_yamagata]

Some new numbers:

[...]

Can't say that the "normal" branch of ffdshow became significant faster between Beta-5 (r2033) and Beta-6 (r2527) on my system...
Beta6 is 5 - 12% faster for me. Please make sure you get the new pre-beta6.
Revision 16239 - Directory Listing
Modified Fri Dec 19 13:45:13 2008 UTC (10 hours, 15 minutes ago) by darkshikari

Port x264 deblocking code to libavcodec. This includes SSE2 luma deblocking code and both MMXEXT and SSE2 luma intra deblocking code for H.264 decoding. This assembly is available under --enable-gpl and speeds decoding of Cathedral by 7%.

[Snowknight26]

Your sample is MBAFF. That means it's interlaced at macroblock level. In the same frame it may be macroblocks coded as interlaced and others as progressive. In order to view this correctly the entire stream has to be deinterlaced, just like it is now.

Since thats the case, when I enable the deinterlacer, it shouldn't be deinterlacing the progressive macroblocks... but it does anyway.

[haruhiko_yamagata]

when I enable the deinterlacer, it shouldn't be deinterlacing the progressive macroblocksThis is wrong. A macroblock encoded using progressive algorithm may require deinterlacing.

[fastplayer]

300-tlr2_h1080p.mov | terminatorsalvation-tlr2_h1080p.mov | Madagascar.avi
2033: 44.7 | 43.2 | 198.2
2527: 45.4 | 44.9 | 202.5
2527 ICL: 45.4 | 45.0 | 202.4

- All results in dfps
- First 2 trailers: 1920x800 H.264, 3rd one: 1280x720 DX50
- CPU: Athlon64 3500+

[Snowknight26]

This is wrong. A macroblock encoded using progressive algorithm may require deinterlacing.

May require. If it doesn't require it, does it still get deinterlaced? Might I remind you of the screenshots I previously posted (#5721 (http://forum.doom9.org/showpost.php?p=1225749&postcount=5721)).

[haruhiko_yamagata]

May require. If it doesn't require it, does it still get deinterlaced? Might I remind you of the screenshots I previously posted (#5721 (http://forum.doom9.org/showpost.php?p=1225749&postcount=5721)).Anyway, the decoder flagged the frame correctly.
Deinterlace or not is choice of deinterlacers. If you use a good deinterlacer, you will have satisfactory results.

[LoRd_MuldeR]

Beta6 is 5 - 12% faster for me. Please make sure you get the new pre-beta6.

I use the latest version. Re-downloaded, just to be sure. File from 2008-12-19, 18:01.
This time I ran the comparison with only one single thread, so the multi-threading code can't have any impact.
However there still is no remarkable difference between Beta-5 and preBeta-6. See:

E:\HD\freedom EP1 sample.mkv, 1920x1080, High@L4.1

[ffdshow, rev2033, Beta-5, 2008-07-05, 1 thread]
User: 31s, kernel: 0s, total: 31s, real: 30s, fps: 19.8, dfps: 20.0
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 20.0, dfps: 20.0
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 20.0, dfps: 19.9

[ffdshow, rev2527, Pre-Beta 6, 2008-12-19, 1 thread]
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 20.0, dfps: 20.0
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 19.9, dfps: 20.0
User: 31s, kernel: 0s, total: 31s, real: 30s, fps: 19.7, dfps: 19.9

[ffdshow-MT, rev2525, 2008-12-20, 1 thread]
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 20.1, dfps: 20.0
User: 31s, kernel: 0s, total: 31s, real: 31s, fps: 19.6, dfps: 19.5
User: 31s, kernel: 0s, total: 31s, real: 31s, fps: 19.5, dfps: 19.5

[ffdshow-MT, rev2525, 2008-12-20, 4 threads]
User: 2s, kernel: 0s, total: 2s, real: 8s, fps: 244.9, dfps: 71.5
User: 2s, kernel: 0s, total: 2s, real: 8s, fps: 236.1, dfps: 71.3
User: 2s, kernel: 0s, total: 2s, real: 8s, fps: 244.9, dfps: 71.0

[CoreAVC, Version 1.8.5]
User: 0s, kernel: 0s, total: 0s, real: 7s, fps: 625.8, dfps: 83.2
User: 0s, kernel: 0s, total: 0s, real: 7s, fps: 773.0, dfps: 83.0
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 588.4, dfps: 82.3

[DivX H.264 Decoder, Beta-3]
User: 1s, kernel: 0s, total: 1s, real: 6s, fps: 499.0, dfps: 89.4
User: 1s, kernel: 0s, total: 1s, real: 6s, fps: 433.2, dfps: 89.0
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 486.7, dfps: 88.0


Another sample, just to be sure. But same result:

E:\HD\Crowd Run 2160p UHD CRF22 x264-CtrlHD.mkv

[ffdshow, rev2033, Beta-5, 2008-07-05, 1 thread]
User: 121s, kernel: 0s, total: 121s, real: 121s, fps: 4.1, dfps: 4.1
User: 121s, kernel: 0s, total: 121s, real: 121s, fps: 4.1, dfps: 4.1
User: 121s, kernel: 0s, total: 121s, real: 121s, fps: 4.1, dfps: 4.1

[ffdshow, rev2527, Pre-Beta 6, 2008-12-19, 1 thread]
User: 120s, kernel: 0s, total: 120s, real: 120s, fps: 4.1, dfps: 4.1
User: 120s, kernel: 0s, total: 120s, real: 120s, fps: 4.1, dfps: 4.1
User: 121s, kernel: 0s, total: 121s, real: 120s, fps: 4.1, dfps: 4.1

[ffdshow-MT, rev2525, 2008-12-20, 4 threads]
User: 8s, kernel: 0s, total: 8s, real: 35s, fps: 61.1, dfps: 14.2
User: 7s, kernel: 0s, total: 8s, real: 35s, fps: 62.4, dfps: 14.2
User: 7s, kernel: 0s, total: 7s, real: 35s, fps: 62.9, dfps: 14.2

[DivX H.264 Decoder, Beta-3]
User: 3s, kernel: 0s, total: 4s, real: 28s, fps: 121.7, dfps: 17.5
User: 4s, kernel: 0s, total: 4s, real: 28s, fps: 104.6, dfps: 17.5
User: 4s, kernel: 0s, total: 4s, real: 28s, fps: 118.5, dfps: 17.4

[Snowknight26]

Deinterlace or not is choice of deinterlacers. If you use a good deinterlacer, you will have satisfactory results.
Which deinterlacer that comes with ffdshow would qualify as being 'good?'

[Dark Shikari]

I use the latest version. Re-downloaded, just to be sure. File from 2008-12-19, 18:01.
This time I ran the comparison with only one single thread, so the multi-threading code can't have any impact.
However there still is no remarkable difference between Beta-5 and preBeta-6. See:Are you sure the person who compiled your copy of ffdshow had yasm installed? Otherwise, none of the new assembly code will get used... :rolleyes:

(it also requires --enable-gpl...)

[haruhiko_yamagata]

@LoRd_MuldeR
It may dependent on samples. Please try premiere-paff.ts or bbc-japan_1080p.mov.

[fastplayer]

Here are more results on my single-core Athlon64, this time with various filters applied:

http://i40.tinypic.com/2pyamhk.pnghttp://i41.tinypic.com/30vbpxe.png
http://i40.tinypic.com/2ep4l1x.pnghttp://i39.tinypic.com/9scor4.png

Looks like the MSVC compilers have caught up with ICL. Or ICL just doesn't like AMD CPU's :D

H.264 decoding performance has increased by 1.5-4% when comparing Beta 5 and pre-Beta 6.

[clsid]

Are you sure the person who compiled your copy of ffdshow had yasm installed? Otherwise, none of the new assembly code will get used... :rolleyes:

(it also requires --enable-gpl...)
Yasm 0.7.2, so don;t worry ;)

Beta5 is from before Michael's major H.264 compliance fixes. Which have had some impact on performance. So that is why prebeta6 should not be compared with it, but with a build from say last week.

I have seen speedups varying from 1% to 11% on a Core2.

[clsid]

Looks like the MSVC compilers have caught up with ICL. Or ICL just doesn't like AMD CPU's :D
I use patched ICL libs. Without that performance would even be worse on AMD.
ICL only shows benefit in just a few filters, like xsharpen. Perhaps you could test some more processing filters to see if there are more that benefit?

[haruhiko_yamagata]

I use patched ICL libs. Without that performance would even be worse on AMD.
ICL only shows benefit in just a few filters, like xsharpen. Perhaps you could test some more processing filters to see if there are more that benefit?As for xsharpen, MSVC9 does better job than expected.
Another problem was equalizer. Is it better now?

[leeperry]

FF.MKV (1080p h264)
720p spline resize/unsharp masking/LSF/ConvertToRGB32()

ffdshow_rev2447_20081208_clsid_sse_icl10.exe :
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 46.0, dfps: 25.9
User: 1s, kernel: 0s, total: 2s, real: 3s, fps: 43.5, dfps: 25.9
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 43.8, dfps: 26.0

ffdshow_rev2527_20081219_clsid_sse_icl10.exe :
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 44.5, dfps: 26.5
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 44.2, dfps: 26.3
User: 2s, kernel: 0s, total: 2s, real: 3s, fps: 43.5, dfps: 26.4

ffdshow_rev2527_20081219_clsid.exe :
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 45.3, dfps: 26.5
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 43.8, dfps: 26.5
User: 1s, kernel: 0s, total: 2s, real: 3s, fps: 43.5, dfps: 26.5

ffdshow_rev2488_20081213_xxl_mt.exe :
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 27.4, dfps: 22.9
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 26.9, dfps: 22.9
User: 3s, kernel: 0s, total: 3s, real: 3s, fps: 27.4, dfps: 23.0

ffdshow_rev2527_20081219_clsid_sse_icl10.exe + CoreAVC 1.8.5 :
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 47.2, dfps: 28.0
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 47.2, dfps: 28.0
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 45.6, dfps: 27.8

ffdshow_rev2527_20081219_clsid_sse_icl10.exe + Remoulade beta3 :
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 44.2, dfps: 27.6
User: 2s, kernel: 0s, total: 2s, real: 3s, fps: 40.9, dfps: 27.7
User: 1s, kernel: 0s, total: 1s, real: 3s, fps: 44.2, dfps: 27.7


Death.and.Life.of.Bobby.Z.mkv (720p 2.35 h264)
unsharp masking/LSF/ConvertToRGB32()

ffdshow_rev2447_20081208_clsid_sse_icl10.exe :
User: 8s, kernel: 2s, total: 11s, real: 14s, fps: 44.3, dfps: 34.2
User: 8s, kernel: 2s, total: 10s, real: 14s, fps: 46.2, dfps: 35.4
User: 8s, kernel: 2s, total: 10s, real: 14s, fps: 46.9, dfps: 35.3

ffdshow_rev2527_20081219_clsid_sse_icl10.exe :
User: 8s, kernel: 2s, total: 11s, real: 14s, fps: 45.4, dfps: 35.5
User: 8s, kernel: 2s, total: 10s, real: 14s, fps: 46.3, dfps: 35.5
User: 8s, kernel: 2s, total: 10s, real: 14s, fps: 46.5, dfps: 35.4

ffdshow_rev2527_20081219_clsid.exe :
User: 8s, kernel: 2s, total: 11s, real: 14s, fps: 44.8, dfps: 34.2
User: 8s, kernel: 2s, total: 11s, real: 14s, fps: 44.2, dfps: 34.2
User: 8s, kernel: 2s, total: 11s, real: 14s, fps: 44.1, dfps: 34.2

ffdshow_rev2488_20081213_xxl_mt.exe :
User: 8s, kernel: 2s, total: 10s, real: 13s, fps: 48.4, dfps: 37.1
User: 8s, kernel: 2s, total: 10s, real: 13s, fps: 47.1, dfps: 36.9
User: 8s, kernel: 1s, total: 10s, real: 13s, fps: 46.2, dfps: 36.4

ffdshow_rev2527_20081219_clsid_sse_icl10.exe + CoreAVC 1.8.5 :
User: 8s, kernel: 1s, total: 10s, real: 13s, fps: 49.2, dfps: 37.8
User: 8s, kernel: 1s, total: 10s, real: 13s, fps: 48.7, dfps: 37.8
User: 8s, kernel: 1s, total: 10s, real: 13s, fps: 48.4, dfps: 38.0

ffdshow_rev2527_20081219_clsid_sse_icl10.exe + Remoulade beta3 :
User: 8s, kernel: 2s, total: 10s, real: 12s, fps: 46.9, dfps: 38.7
User: 9s, kernel: 1s, total: 11s, real: 13s, fps: 44.3, dfps: 38.1
User: 8s, kernel: 2s, total: 10s, real: 12s, fps: 46.1, dfps: 38.9


Dila_720p.mkv (720p 1.78 h264)
unsharp masking/LSF/ConvertToRGB32()

ffdshow_rev2447_20081208_clsid_sse_icl10.exe :
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 21.8, dfps: 19.0
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.5, dfps: 18.9
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.2, dfps: 19.2

ffdshow_rev2527_20081219_clsid_sse_icl10.exe :
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.2, dfps: 19.8
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 23.9, dfps: 19.8
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.7, dfps: 19.9

ffdshow_rev2527_20081219_clsid.exe :
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.1, dfps: 19.8
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 21.9, dfps: 19.8
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 23.7, dfps: 19.6

ffdshow_rev2488_20081213_xxl_mt.exe :
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.7, dfps: 20.3
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 23.4, dfps: 20.1
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.7, dfps: 20.1

ffdshow_rev2527_20081219_clsid_sse_icl10.exe + CoreAVC 1.8.5 :
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 23.9, dfps: 20.3
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 23.9, dfps: 20.5
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 23.4, dfps: 20.3

ffdshow_rev2527_20081219_clsid_sse_icl10.exe + Remoulade beta3 :
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.7, dfps: 20.1
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 22.7, dfps: 20.1
User: 1s, kernel: 0s, total: 2s, real: 2s, fps: 23.5, dfps: 20.1

notes :
1)-test were conducted on a 3.3Ghz Q6600(8*415)
2)-the ffdshow MT version failed with the FF.mkv 1080p sample, I've uploaded it here :
http://www.megaupload.com/?d=YGJA8GE2
3)-even though Remoulade sometimes has higher dfps, its fps is lower than CoreAVC...and CoreAVC seems to offer better realtime performance, so I'm not sure that the dfps figure is the only one to care for?
4)-timecodec doesn't measure ffdshow audio performance(which is higher w/ ICL10 builds)
5)-I've set timecodec to the highest priority on 4 cores w/ as little background processes as possible(in low priority on single cores) + short h264 samples to measure the decoding speed, not the computer throughput

[fastplayer]

By the way, don't browse the page with IE6... :D
Christmas is around corner, I'm in a generous mood. So here's one last gift to you IE6-diehards:
ffdshow's new homepage (http://ffdshow-tryout.sourceforge.net/index2.php) now displays correctly on your "browser"! :D

Well, it's readable, but i would like it a bit bigger. I think it is a click smaller than normal. I am on 1680x1050 20" monitor (maybe on 21"-22" there's no problem).
I've made some improvements to the homepage which should please - not everyone - but most of us:

Helvetica and Trebuchet MS are used for improved readability
Font size and line height have been increased:
Should look sexier now on high-res displays. On resolutions of 1024x768 and less it looks a bit too bulky but I'm just too lazy to let font size adjust itself dynamically based on screen resolution... :p

[haruhiko_yamagata]

Got a similar problem with recent builds (normal and MT, but not x64) when playing interlaced MPEG-2 and using Yadif.
With Yadif enabled (internal version -or- Avisynth version) I get "slow motion" playback, which disappears when the OSD is enabled!
Had a lot of private discussion with haruhiko_yamagata about that problem already, but no solution yet.

It came down to the following result:
* The time ffdshow spends in Yadif is always okay.
* When the slow motion happens, then ffdshow spends a very long time (much too long) in the "convert" function!
* The "convert" time is back to normal with OSD enabled.

Note that there was no such problem in rev2347, seems it started around rev2391 ...The slow down is caused by very slow V-RAM access. It's a bug of video driver. ffdshow is just triggering it.
Does "High quality YV12 to RGB conversion" matter?

[STaRGaZeR]

Just to confirm this issue (http://forum.doom9.org/showpost.php?p=1225914&postcount=5744) with the MT branch, Snowknight26's Tiesto sample (http://forum.doom9.org/showpost.php?p=1226004&postcount=5770) has the sample problem in at least frame 538 or surrounding frames using MPC's internal MPEG PS/TS/PVA splitter, same freeze, same behaviour. Using only 1 thread fixes it again.

[LoRd_MuldeR]

The slow down is caused by very slow V-RAM access. It's a bug of video driver. ffdshow is just triggering it.

I wonder how ffdshow can be effected by V-RAM access. It doesn't access the graphics card directly, it just sends over the decoded frame to the next filter in graph, right? So I would think that the "convert" time only measures the time to convert the frame internally (in ffdshow) and send it to the next filter (most likely a renderer), but nothing more. Even if it had to wait for a "slow" renderer, that problem would disappear as soon as queuing is on. But it doesn't. Also as mentioned before, the problem isn't there in older revision and it reproducible appears as soon as I install a newer revision. And last but not least: How should the renderer detect that Yadif is used and then decide to do a "slow" V-RAM access now? While it does "fast" V-RAM access with KernelBob in use. Crazy, isn't it?

Does "High quality YV12 to RGB conversion" matter?

Nope. Makes no difference.

It's only "OSD" that for some reason makes a difference :confused:


Are you sure the person who compiled your copy of ffdshow had yasm installed? Otherwise, none of the new assembly code will get used... :rolleyes:

I took clsid's build from ffdshow's sourceforge site. And I think he knows what he does :)

[LoRd_MuldeR]

@LoRd_MuldeR
It may dependent on samples. Please try premiere-paff.ts or bbc-japan_1080p.mov.

Okay, tried again with the "premiere-paff.ts" sample. But still the difference between Beta-5 (r2033) and preBeta-6 (r2527) is negligible:

E:\HD\premiere-paff.ts

[ffdshow, rev2033, Beta-5, 2008-07-05, 1 thread]
User: 29s, kernel: 0s, total: 30s, real: 30s, fps: 39.8, dfps: 39.4
User: 29s, kernel: 0s, total: 29s, real: 30s, fps: 39.9, dfps: 39.4
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 39.7, dfps: 39.2

[ffdshow, rev2033, Beta-5, 2008-07-05, 4 threads]
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 341.1, dfps: 87.5
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 315.8, dfps: 87.3
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 335.2, dfps: 87.2

[ffdshow, rev2527, Pre-Beta 6, 2008-12-19, 1 thread]
User: 29s, kernel: 0s, total: 29s, real: 30s, fps: 40.0, dfps: 39.7
User: 29s, kernel: 0s, total: 29s, real: 30s, fps: 40.2, dfps: 39.7
User: 29s, kernel: 0s, total: 29s, real: 30s, fps: 40.2, dfps: 39.7

[ffdshow, rev2527, Pre-Beta 6, 2008-12-19, 4 threads]
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 317.1, dfps: 87.7
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 353.8, dfps: 87.3
User: 3s, kernel: 0s, total: 3s, real: 13s, fps: 321.1, dfps: 87.0

[ffdshow-MT, rev2525, 2008-12-20, 1 thread]
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 39.4, dfps: 39.1
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 39.5, dfps: 39.0
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 39.6, dfps: 39.0

[ffdshow-MT, rev2525, 2008-12-20, 4 threads]
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 457.6, dfps: 130.2
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 446.9, dfps: 130.0
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 404.3, dfps: 129.3

[CoreAVC Decoder, v1.8.5]
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 1032.6, dfps: 160.2
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 899.0, dfps: 159.2
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 1091.7, dfps: 158.9

[DivX H.264 Decoder, Beta-3]
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 858.6, dfps: 169.8
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 771.9, dfps: 169.0
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 734.8, dfps: 168.7

[ash925]

With versions 2503 and 2527 I am getting a black or green output in virtualdub(1.8.6)though the videos run fine in mediaplayer classic(patched build).Version 2033 runs video fine, I want to know is there any way to get proper output in virtualdub(any settings that need to be changed). The problem exists with h264 videos in avi or mp4 container(mp4 plugin is used of course).

[LoRd_MuldeR]

With versions 2503 and 2527 I am getting a black or green output in virtualdub(1.8.6)though the videos run fine in mediaplayer classic(patched build).Version 2033 runs video fine, I want to know is there any way to get proper output in virtualdub(any settings that need to be changed).

Media players access ffdshow through the DirectShow interface, while VirtualDub uses the VfW interface only.
Goto "ffdshow" -> "VFW configuration" and make sure all required video decoders (Codecs) are enabled on the "Decoder" tab.
Also make sure the desired color format(s) are checked on the "Output" page.

BTW: About what video formats we are talking here?

[ash925]

Was trying to update the Format thing but for some reason the site became tooo slow.
H264 videos in avi or mp4 videos.
I had the h264 option in vfw enabled each time.

[LoRd_MuldeR]

H264 videos in avi or mp4 videos.

VirtualDub doesn't support MP4 files. Unless a new MP4 input plugin was released recently...

I had the h264 option in vfw enabled each time.

Then it should work. At least it does here.

[clsid]

Try pressing F9 (show input pane).

[ash925]

@LoRd_MuldeR:"VirtualDub doesn't support MP4 files. Unless a new MP4 input plugin was released recently..."
Well I found a plugin and it seems to work(at least upto now).
@clsid:Input and ouput pane both are enabled.

It seems strange that MPC can use it, but virtualdub can't.

[LoRd_MuldeR]

It seems strange that MPC can use it, but virtualdub can't.

MPC is a DirectShow-baes player, VirtualDub uses VFW Codecs. These are two completely different things!

The only reason why ffdshow works in VDub at all is that it provides a special VfW interface for such "legacy" applications.

[ash925]

Thanks for the clarification LoRd_MuldeR.
BTW problem solved, I accidentally put a matroska file in Virtualdub and the video shows just fine, must have something to do with Haali Splitter.

[LoRd_MuldeR]

...must have something to do with Haali Splitter.

Impossible. As said before, VirtualDub doesn't use DirectShow. Hence it doesn't use any DirectShow filters, such as Haali Splitter.
VirtualDub only supports VfW Codecs and it's limited to AVI files, using it's own internal AVI splitter.
Other containers than AVI can only be opened in VDub through special VDub Input Plugins and even that feature was only added recently.

[squid_80]

There is a directshow input plugin...

[LoRd_MuldeR]

There is a directshow input plugin...

Okay. But unless explicitly stated, we must assume that he doesn't use that input plugin and tried to access ffdshow through its VfW interface...

[squid_80]

There's no other way to open matroska files directly in virtualdub (for now ;)). So the plugin must be on his system.

[ikarad]

what is the difference between beta 6 branch and generic branch? Is it the same or not?

[fastplayer]

what is the difference between beta 6 branch and generic branch? Is it the same or not?
FAQ: What is the difference between official releases and SVN builds? (http://ffdshow-tryout.wiki.sourceforge.net/FAQ#releases)

[haruhiko_yamagata]

OK I've been able to find a sample that has both problems. I can always reproduce them at the same frame:

- With Haali's Splitter:

When seeking to frame 160 --> Garbled frames.
When seeking to frame 163 --> Video stops, and if you do anything else with the player it hangs and you have to kill it with task manager. If only 1 thread is used then it does something strange but doesn't hang.

I can't reproduce with your sample. I'm not sure if the problem is the same as premiere-paff.ts.
The garbling with Haali's splitter and premiere-paff.ts is explained here (http://forum.doom9.org/showthread.php?p=1226434#post1226434).

[Reino]

Could you devs please have a look at FFDShow's theora support?

A_New_Computer--med.ogg (http://polycrystal.org/lego/movies/A_New_Computer--med.ogg) OGG[Theora+Vorbis] - Works okay with FFDShow. (upon time-seeking, the image still hangs for ±3seconds, but this is a splitter issue)

transparency.ogg (http://cdn.novell.com/cached/xglrelease/transparency.ogg) OGG[Theora+Vorbis] - Fails with FFDShow (but also fails with the built-in MPC Video Decoder!)
With MONOGRAM GraphStudio the file-loading takes ± 10seconds, then only the FFDShow Audio Decoder is connected to the MKV Splitter (the FFDShow Video Decoder refuses on connecting manually), and finally refushed to render anything at all. Maybe this is a splitter-issue afterall.

Theora+AAC.mkv (http://www.turboupload.com/files/get/FHxLfZku4k/theoraaac.mkv) MKV[Theora+AAC]- Works okay with the MPC Video Decoder, but the FFDShow Video Decoder refuses to connect to the MKV Splitter, so I guess this not the MKV Splitter to blame. In fact, when I mux both streams of A_New_Computer--med.ogg and transparency.ogg into a MKV-container, both files play perfectly with the MPC Video Decoder (incl. time-seeking!!). Way to go on the MKV Splitter! ;)

[tetsuo55]

I did some RMVB tests with ffdshow as the decoder.
the result is better than i expected, all the samples worked, but the CPU usage is massive when compared to the realmedia decoder.

mplayer scored worse here because some samples got displayed incorrectly

Hope the ffmpeg team can still optimize rv40 decoding

[STaRGaZeR]

I can't reproduce with your sample. I'm not sure if the problem is the same as premiere-paff.ts.
The garbling with Haali's splitter and premiere-paff.ts is explained here (http://forum.doom9.org/showthread.php?p=1226434#post1226434).

It seems to be the same as premiere-paff.ts, here you have a screenshot of what happens after seeking to frame 160 with Haali's splitter (and EVR/EVR Custom):

http://thumbnails8.imagebam.com/2150/88785821499227.gif (http://www.imagebam.com/image/88785821499227)

EDIT: Interesting, this only happens with EVR and EVR Custom. Also the freeze only happens with those renderers. VMR9 and the others are problem free. That's probably why you can't reproduce. Can you confirm?

[ikarad]

FAQ: What is the difference between official releases and SVN builds? (http://ffdshow-tryout.wiki.sourceforge.net/FAQ#releases)

thnaks but I didn't see the answer of my question in the faq.
beta 6 is it an official release?

[LoRd_MuldeR]

thnaks but I didn't see the answer of my question in the faq.
beta 6 is it an official release?

There is no "official" release of ffdshow ever! It's an OpenSource project and development goes on continuously. Changes are applied every single day.

If you want the latest features and improvements (and if you aren't afraid to face new bugs) go with the latest "SVN" build.
And if you need a more tested (but usually somewhat older) build, you should take the latest "beta" version.

Right now "Beta 6" has just been released. So at the moment there is no noteworthy difference between latest "Beta" and current "SVN" ;)

[tetsuo55]

I just read on Kostya's blog (the guy who made the rv40 and rv30 ffmpeg decoders), that the realvideo decoders can be faster than the binary decoder from real itself

he says

When I switch motion compensation functions from C implementations to optimised H.264 counterparts (they are slightly different so the picture quality gets worse) native decoder becomes faster than binary one by several percents on x86 and even faster on PPC. Conclusion: if you want fast decoding then submit SIMD versions of motion compensation functions.


source:http://codecs.multimedia.cx/

[fastplayer]

thnaks but I didn't see the answer of my question in the faq.
beta 6 is it an official release?
It's as official as it can get:
http://ffdshow-tryout.sourceforge.net/

[Atak_Snajpera]

is there any reason why Cubic interpolation is selected by default instead of YADIF?

[LoRd_MuldeR]

is there any reason why Cubic interpolation is selected by default instead of YADIF?

Because it's a very simple, very fast and artifact-free deinterlacer, maybe?

[oddball]

Using ffdshow_prebeta6_rev2527_20081219.exe

Problem: Selecting '3/2/1 - 6 channel' in the 'Mixer' and encoding 6 channel AAC from a Quicktime video to AC3 output results in no audio whatsoever being sent to the SPDIF out.

Setting to 'Same as input' results in it encoding and outputting AC3 fine, as does changing to 'Quad' and a couple of others in the Mixer drop down options.

[Atak_Snajpera]

Because it's a very simple, very fast and artifact-free deinterlacer, maybe?
and very ugly compared to YADIF. Have you ever seen artifacts in YADIF????

[LoRd_MuldeR]

and very ugly compared to YADIF. Have you ever seen artifacts in YADIF????

At least no "combing" artifacts, as you see them with KernelDeinterlacer now and then.

But CPU usage of Yadif is significant higher then Cubic interpolation. Without deinterlacer CPU usage is ~5%, with cubic interpolation it is ~7%, with Yadif it's ~20% :eek:

[STaRGaZeR]

Have you ever seen artifacts in YADIF????

Yes, and quite a few.

[Atak_Snajpera]

Yes, and quite a few.
show me screenshot

But CPU usage of Yadif is significant higher then Cubic interpolation. Without deinterlacer CPU usage is ~5%, with cubic interpolation it is ~7%, with Yadif it's ~20%
Correct me if i'm wrong but it seems that YADIF is multi-threaded.

.mts (AVCHD ~15 Mbps comcorder footage) Q6600@3Ghz
http://img128.imageshack.us/img128/1517/new1kk8.th.png (http://img128.imageshack.us/my.php?image=new1kk8.png)

[LoRd_MuldeR]

Correct me if i'm wrong but it seems that YADIF is multi-threaded.

So what? Multi-threading doesn't lower the required CPU time at all. It simply helps to distrubue the CPU time over several cores.
Yadif still requires significant more CPU time than a simple deinterlacer, like Cubic interpolation. Especially for 1080i stuff it is very demanding!

And keep in mind: Not any ffdshow user has got an up-to-date multi-core CPU :p

[Atak_Snajpera]

And keep in mind: Not any ffdshow user has got an up-to-date multi-core CPU
If you don't have at least 2 cores you can also forget about playing 1080i footage :)

It simply helps to distrubue the CPU time over several cores.
So what? If I have two or more cores why not to use them?

[LoRd_MuldeR]

If you don't have at least 2 cores you can also forget about playing 1080i footage :)

If you have an old CPU, it will be at high load, even for SD content and even without deinterlacing.

In that case you certainly don't want to use a complex deinterlacer, but a simple one.

The other way around there is no problem though: Using a fast deinterlacer on a fast CPU is okay.

So what? If I have two or more cores why not to use them?

Because you are running other tasks in the background, maybe :rolleyes:

It all comes down to one conclusion:
The default deinterlacer shouldn't be the slowest one available in ffdshow, but a fast and simple one.

In case the user prefers a slower deinterlacer, (s)he can choose one at any time...

[Atak_Snajpera]

Because you are running other tasks in the background
Like what? folding@home :) Come on! When I watch movie I don't care if app running in background gets more or less cpu cycles. All I care is video quality. Besides 2 cores is minimum these days if you haven't noticed that. Video decoding/encoding , even games like Far Cry 2 requires 2 cores (on 1 core game is unplayable - massive drop in fps!)

[haruhiko_yamagata]

It seems to be the same as premiere-paff.ts, here you have a screenshot of what happens after seeking to frame 160 with Haali's splitter (and EVR/EVR Custom):

http://thumbnails8.imagebam.com/2150/88785821499227.gif (http://www.imagebam.com/image/88785821499227)

EDIT: Interesting, this only happens with EVR and EVR Custom. Also the freeze only happens with those renderers. VMR9 and the others are problem free. That's probably why you can't reproduce. Can you confirm?
Interesting, then the timing the renderer calls back 'Run' matters. Still can't reproduce though.

[STaRGaZeR]

show me screenshot

http://thumbnails9.imagebam.com/2154/445a5221532760.gif (http://www.imagebam.com/image/445a5221532760) http://thumbnails5.imagebam.com/2154/a206ee21532761.gif (http://www.imagebam.com/image/a206ee21532761) http://thumbnails9.imagebam.com/2154/7013f821532762.gif (http://www.imagebam.com/image/7013f821532762) http://thumbnails13.imagebam.com/2154/22b25021532765.gif (http://www.imagebam.com/image/22b25021532765)

And the same one with ATI's deinterlacer, just for the lulz:

http://thumbnails6.imagebam.com/2154/264c5921532766.gif (http://www.imagebam.com/image/264c5921532766)

Yadif is the best ffdshow deinterlacer, but it's not perfect. Those 4 screenshots in motion look ugly, I tell you!

Interesting, then the timing the renderer calls back 'Run' matters. Still can't reproduce though.

Not even the freeze?

[LoRd_MuldeR]

What I see on your screenshot doesn't look like a "combing" artifact. It's more the way Yadif interpolates that doesn't look "perfect" here.

I'm yet to see any "combing" artifacts with Yadif, like you see them with KernelDeint/KernelBob or TDeint here and there...

[STaRGaZeR]

What I see on your screenshot doesn't look like a "combing" artifact. It's more the way Yadif interpolates that doesn't look "perfect" here.

I'm yet to see any "combing" artifacts with Yadif, like you see them with KernelDeint/KernelBob or TDeint here and there...

Since when the word "artifact" as Atak_Snajpera wanted means combing? An artifact is an artifact, and those are artifacts.

[LoRd_MuldeR]

Since when the word "artifact" as Atak_Snajpera wanted means combing? An artifact is an artifact, and those are artifacts.

The reason why we need to deinterlace at all are "combing" artifacts and these also are the most annoying artifacts with the classic adaptive deinterlacers (SmartDeint, KernelDeint, TDeint, etc)
I just wanted to point out that one of the great things about Yadif is that it doesn't let any of these "combing" artifacts slip through. Sure it isn't perfect. But which deinterlacer is? ^^
And I still think "Yadif" and "Greedy 2 Frame" are the most satisfying real-time s/w deinterlacers. At least for medium-compressed "real life" footage...

[Atak_Snajpera]

Sure it isn't perfect. But which deinterlacer is? ^^
looks like ati's deinterlacer :) As long as you don't watch anime you can safely use Yadif.

[STaRGaZeR]

The reason why we need to deinterlace at all are "combing" artifacts and these also are the most annoying artifacts with the classic adaptive deinterlacers (SmartDeint, KernelDeint, TDeint, etc)
I just wanted to point out that one of the great things about Yadif is that it doesn't let any of these "combing" artifacts slip through. Sure it isn't perfect. But which deinterlacer is? ^^
And I still think "Yadif" and "Greedy 2 Frame" are the most satisfying real-time s/w deinterlacers...

And I just wanted to show Atak_Snajpera artifacts when deinterlacing with Yadif. If it removes the combing leaving that sh*t on screen it means that the deinterlacer is not doing its job properly in that concrete scene. The goal of any deinterlacer is to convert the image form interlace to progressive and to get rid of any interlace derived artifacts, that means combing, random white pixels or whatever. AFAIK there are 0 perfect smart deinterlacers. No big deal, just some presets and you're done.

looks like ati's deinterlacer :) As long as you don't watch anime you can safely use Yadif.

Nah, ATI has little problems with F1 footage in small areas (combing) too. But I agree, Yadif is just damn good almost always.

[Leak]

I'm yet to see any "combing" artifacts with Yadif, like you see them with KernelDeint/KernelBob or TDeint here and there...
Not to mention that deinterlacing anime is absolutely the wrong thing to do when fieldmatching and decimation are in order...

np: Kid606 - Umbilical Bullets (Die Soundboy Die)

[Leak]

The reason why we need to deinterlace at all are "combing" artifacts and these also are the most annoying artifacts with the classic adaptive deinterlacers (SmartDeint, KernelDeint, TDeint, etc)
Use KernelBob and turn the threshold down to 0 or just slightly above it. That should eliminate any residual combing, and still look great in motion - just don't take screenshots with those settings.

np: Kid606 - Umbilical Bullets (Die Soundboy Die)

[LoRd_MuldeR]

Use KernelBob and turn the threshold down to 0 or just slightly above it. That should eliminate any residual combing, and still look great in motion - just don't take screenshots with those settings.

KernelBob is a pretty good bobber, but even with threshold as low as 3 it shows ugly combing artifacts from time to time. Also static areas tend to flicker at such low threshold. Therefore I usually prefer Yadif in "Double Framerate" mode. Also Yadif produces more smooth edges, while KernelBob tends to show stairs...

[Anima123]

At ffdshow-tryout beta6 - audio decoder configuration - Dolby decoder, what does "Apply Dolby Pro Logic II decoding to all stereo sources" actually mean? It act the same as the switch to activate/deactivate Dolby decoder itself. I'm wondering if it tend to be the switch to bypass Dolby decoder process in case the audio stream is pure stereo as I've requested.

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).

Cheers.

[Inventive Software]

At ffdshow-tryout beta6 - audio decoder configuration - Dolby decoder, what does "Apply Dolby Pro Logic II decoding to all stereo sources" actually mean? It act the same as the switch to activate/deactivate Dolby decoder itself. I'm wondering if it tend to be the switch to bypass Dolby decoder process in case the audio stream is pure stereo as I've requested.

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).

Cheers.

RV40 decoding AFAIK is complete, as it's now fully committed in ffmpeg. RV30 is partially complete and in ffmpeg, but samples are welcome to the codec developer (NOT US!): www.ffmpeg.org

[tetsuo55]

At ffdshow-tryout beta6 - audio decoder configuration - Dolby decoder, what does "Apply Dolby Pro Logic II decoding to all stereo sources" actually mean? It act the same as the switch to activate/deactivate Dolby decoder itself. I'm wondering if it tend to be the switch to bypass Dolby decoder process in case the audio stream is pure stereo as I've requested.

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).

Cheers.

For RV40 see my post here: http://forum.doom9.org/showthread.php?p=1226503#post1226503

[MatMaul]

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).
I get jerky playback with RV40 too.
I don't think it comes from the ffmpeg decoder, the images themself are fine.

sample :
http://samples.mplayerhq.hu/real/VC-RV40/spygames-2MB.rmvb

[tetsuo55]

Anima123, Inventive Software, MatMaul
Read my previous post to see why RV40 performance is sub-optimal
For those who know how to program it even states how to fix the perfomance problems, and even improve perfomance beyond that of real-alternative

[MatMaul]

that's not a performance problem, my cpu is under 30%, and all frames seem to be decoded correctly.

[tetsuo55]

that's not a performance problem, my cpu is under 30%, and all frames seem to be decoded correctly.
Okay interesting.

In my testing of mplayer for windows i had the same jerkeyness andf high cpu usage when compared to mpc+real alternative

Also mplayer had aspect ratio problems.

The problem must be ffmpeg then...

[STaRGaZeR]

Not to mention that deinterlacing anime is absolutely the wrong thing to do when fieldmatching and decimation are in order...

Not suitable for watching hundreds of diffferent videos, with different settings for each one :rolleyes:

[haruhiko_yamagata]

Not even the freeze?No, I can't.
I'm adding workaround for the field matching issue, but it is impossible to recover dropped non ref frames.
I'll send you a test build when I'm ready.

[haruhiko_yamagata]

Not suitable for watching hundreds of diffferent videos, with different settings for each one :rolleyes:
After all, does that video need IVTC rather than deinterlacing?

[haruhiko_yamagata]

I wonder how ffdshow can be effected by V-RAM access. It doesn't access the graphics card directly, it just sends over the decoded frame to the next filter in graph, right? ffdshow (or any DirectShow video decoder) writes to V-RAM directly.
ffdshow calls getBuffer on the downstream. Downstream prepare buffer and give it to ffdshow. If the downstream is a video renderer, it will give V-RAM as buffer.

[fastplayer]

@all devs and builders

I'd like to propose some changes to the download page on SF.net (https://sourceforge.net/project/showfiles.php?group_id=173941).
Right now, the "Package" category looks like this:


Official ffdshow beta releases
Old beta releases
SVN builds by albain
SVN builds by clsid
SVN builds by xxl


Comments:
1.) "ffdshow beta" is redundant: A beta release is an official release.
2.) Older releases should be put under 1.) in a subgroup "Older releases" or something like that
3.-5.) Any chance we consolidate all 3 into one?

How about something like this (proposal #1)?

Official releases

<link to the latest and greatest release>
Older releases

...
...


SVN builds

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



Or better (proposal #2):

ffdshow

<link to the latest and greatest release>
Older releases

...
...


ffdshow (unstable)

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



The advantage of the latter approach is that the "Release" category would carry actual version resp. revision numbers which is more conventional and less confusing than what we have now.

What would top this all off is, if all filenames would follow a consistent and descriptive pattern:

Official releases: ffdshow-<version>-<opt>.exe
SVN builds: ffdshow-SVN-<revision>-<opt>.exe

Placeholder:

<version> - An actual version number. Even a mix of 1.0.<revision> would be an improvement... To denote that it's an actual beta, <opt> could be used like for example: ffdshow-1.0.2527-beta.exe.
<revision> - The SVN revision number. Optionally with "rev" as a prefix. Example for an ICL10 build: ffdshow-SVN-2527-ICL10.exe.
Alternatively, "SVN" could be replaced by "unstable" if proposal #2 is used.
<opt> - For official releases optional (until we get stable 64-bit releases). For generic 32-bit SVN builds it can be omitted otherwise flags should be used - like we do now - that indicate what type of SVN build it is (ICL10, MT, 64-bit etc.).

Any other additional information like builder and date should be added to the file properties.

What do you think?

[STaRGaZeR]

No, I can't.
I'm adding workaround for the field matching issue, but it is impossible to recover dropped non ref frames.
I'll send you a test build when I'm ready.

OK, but I'll be around one week away from my computer. I'll test when I came back. On a side note I had the crash once with VMR9 renderless today.

After all, does that video need IVTC rather than deinterlacing?

No, this one is not hard telecined, simple IVTC would not work.

[tetsuo55]

@all devs and builders

I'd like to propose some changes to the download page on SF.net (https://sourceforge.net/project/showfiles.php?group_id=173941).
Right now, the "Package" category looks like this:


Official ffdshow beta releases
Old beta releases
SVN builds by albain
SVN builds by clsid
SVN builds by xxl


Comments:
1.) "ffdshow beta" is redundant: A beta release is an official release.
2.) Older releases should be put under 1.) in a subgroup "Older releases" or something like that
3.-5.) Any chance we consolidate all 3 into one?

How about something like this (proposal #1)?

Official releases

<link to the latest and greatest release>
Older releases

...
...


SVN builds

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



Or better (proposal #2):

ffdshow

<link to the latest and greatest release>
Older releases

...
...


ffdshow (unstable)

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



The advantage of the latter approach is that the "Release" category would carry actual version resp. revision numbers which is more conventional and less confusing than what we have now.

What would top this all off is, if all filenames would follow a consistent and descriptive pattern:

Official releases: ffdshow-<version>-<opt>.exe
SVN builds: ffdshow-SVN-<revision>-<opt>.exe

Placeholder:

<version> - An actual version number. Even a mix of 1.0.<revision> would be an improvement... To denote that it's an actual beta, <opt> could be used like for example: ffdshow-1.0.2527-beta.exe.
<revision> - The SVN revision number. Optionally with "rev" as a prefix. Example for an ICL10 build: ffdshow-SVN-2527-ICL10.exe.
Alternatively, "SVN" could be replaced by "unstable" if proposal #2 is used.
<opt> - For official releases optional (until we get stable 64-bit releases). For generic 32-bit SVN builds it can be omitted otherwise flags should be used - like we do now - that indicate what type of SVN build it is (ICL10, MT, 64-bit etc.).

Any other additional information like builder and date should be added to the file properties.

What do you think?

seconded

[Leak]

No, this one is not hard telecined, simple IVTC would not work.
So what is it then?

Soft telecined? (Which could be IVTCed just the same)
Video only?
24/30FPS mixed?

np: Tocotronic - Meine Freundin Und Ihr Freund (Digital Ist Besser)

[STaRGaZeR]

So what is it then?

As I don't know how to name it, the best is to see it for yourself:

http://www.megaupload.com/?d=TM593MS6 (67MB)

Soft telecined? No.
Video only? No.
24/30FPS mixed? I have several of these and they certainly don't look like this one. 30FPS with parts that look perfect without any filter, parts that need deinterlacing, no repeated fields or frames...

[haruhiko_yamagata]

@all devs and builders

I'd like to propose some changes to the download page on SF.net (https://sourceforge.net/project/showfiles.php?group_id=173941).

I agree. No other projects use builder's name for the name of package. Casual users don't know the name of builders.
But if we want to keep their names written, they can be written in the filenames. It is less confusing than current mess.

[haruhiko_yamagata]

As I don't know how to name it, the best is to see it for yourself:

http://www.megaupload.com/?d=TM593MS6 (67MB)

Soft telecined? No.
Video only? No.
24/30FPS mixed? I have several of these and they certainly don't look like this one. 30FPS with parts that look perfect without any filter, parts that need deinterlacing, no repeated fields or frames...
Two consecutive combing and three consecutive good image: It's the hard telecine.
Hope Leak will post a script to make it right.

[STaRGaZeR]

Two consecutive combing and three consecutive good image: It's the hard telecine.
Hope Leak will post a script to make it right.

There are several consecutive seconds that look good, and several consecutive seconds that have combing.

Mpeg2source("VTS_10_1.d2v")
ColorMatrix(interlaced=true)
tfm(order=1)
tdecimate(mode=1)


Usual script that works perfectly for telecined material, but not in this one. Are you sure this is hard telecined? I think it's not.

[haruhiko_yamagata]

Usual script that works perfectly for telecined material, but not in this one. Are you sure this is hard telecined? I think it's not.Your script works for me. Please make sure you set "Buffer ahead" 12.
http://ffdshow-tryout.wiki.sourceforge.net/AviSynth

[STaRGaZeR]

Yes, I have it. There are parts that are hard telecined and parts that are not. At segs 16-20 and 22-29 the video is choppy because there is no hard telecine in those frames. Between segs 1-5 the video is perfect because those are hard telecined, hence IVTC works OK here.

[haruhiko_yamagata]

OK, but I'll be around one week away from my computer. I'll test when I came back. On a side note I had the crash once with VMR9 renderless today.
I've committed to the trunk. Please test when you come back. If it works for Haali's splitter, I'll add gabest's matroska splitter to the workaround.

[Leak]

Yes, I have it. There are parts that are hard telecined and parts that are not. At segs 16-20 and 22-29 the video is choppy because there is no hard telecine in those frames. Between segs 1-5 the video is perfect because those are hard telecined, hence IVTC works OK here.
In that case you need to add "hybrid=1" to TFM so it'll blend those video segments down to 24 FPS which should look smoother than dropping a random frame.

np: Tocotronic - Samstag Ist Selbstmord (Live) (Nach Der Verlorenen Zeit)

[tetsuo55]

has anyone tried ffdshow on a core i7 yet, i bet the 8 threads could give a nice speedup

[DigitalDeviant]

In that case you need to add "hybrid=1" to TFM so it'll blend those video segments down to 24 FPS which should look smoother than dropping a random frame.

I don't suppose there is any method out there that would leave those sections undecimated since blending frames isn't an optimal solution? I have the same problem with a few discs myself.

[Leak]

I don't suppose there is any method out there that would leave those sections undecimated since blending frames isn't an optimal solution? I have the same problem with a few discs myself.
Not if you want the telecined sections (which usually make up the bigger part of anime) to not stutter - because you'd have to run your display at 24FPS for those and would have to switch your display to 30 Hz and back depending on the content - and we all know how long displays take to switch between two video modes nowadays...

np: Tocotronic - Original Single Mix (Pure Vernunft Darf Niemals Siegen / Remixe)

[DigitalDeviant]

My display is stuck at 60Hz and I'd rather deal with jitter than blends.

[Leak]

My display is stuck at 60Hz and I'd rather deal with jitter than blends.
In that case just use TFM without TDecimate; that gets rid of the combing but leaves the duplicate frames in, thus keeping the original frame rate.

np: Tocotronic - Kapitulation (Kapitulation)

[DigitalDeviant]

In that case just use TFM without TDecimate; that gets rid of the combing but leaves the duplicate frames in, thus keeping the original frame rate.

np: Tocotronic - Kapitulation (Kapitulation)

Thanks, but that's still not what I want though that does work OK if the 24fps material is soft telecined. I want to decimate the telecined parts to 24fps and leave the 30fps parts at 30fps, just deinterlaced. I know avisynth wasn't meant to produce vfr so I suppose that it's just not possible.

[Leak]

Thanks, but that's still not what I want though that does work OK if the 24fps material is soft telecined. I want to decimate the telecined parts to 24fps and leave the 30fps parts at 30fps, just deinterlaced. I know avisynth wasn't meant to produce vfr so I suppose that it's just not possible.
No, it isn't possible. And even if you managed to do it in an AviSynth filter any audio/video synchronization would immediately go the way of the dodo because ffdshow wouldn't know about the framerate change...

Also, why deinterlace the 30fps parts? Fieldmatching should get rid of the combing there just as well as with the 24fps parts... (i.e. I wouldn't call fieldmatching deinterlacing, since the combing isn't a result of every field being from a different point in time)

np: Kid606 - Live at Ultrahang Fest (Live at Ultrahang Fest)

[iSunrise]

Since this is my first post on this forum, and before I file my first bug report, I wanna express my deepest respect to all the people who have kept ffdshow alive since milan´s disappearance. Now for the on-topic stuff.

Bug report - Volume / Normalize - ffdshow beta6 / 2527

description:
If "Volume" and "Normalize" in the ffdshow audio decoder is enabled and the user changes "Max. amplification" while an audio file is playing, the current amplification drops down to a value that represents only the first digit of the value that the user wants to enter.

e.x.:
200% is enabled, user wants to change this to 400% and enters "400" => 4% is now the current value (the last 2 digits will get ignored).
To make matters worse: This can only be undone with reloading the current file.

to reproduce this step by step:
- open your media player of choice (mpc-/hc, zoomplayer)
- play e.x. an mp3 of your choice with ffdshow as audio decoder
(this should also happen with all other files that the ffdshow audio decoder can handle, however, to simplify that, use an mp3)
- while the file is playing, go into "ffdshow audio decoder" properties
- enable "Volume" and go into the volume properties
- in "Max. amplification", enter e.x. 200%
- uncheck "Regain volume" and "Reset on seek"
- enable "Normalize" (output will now be normalized to max. 200%)
- in "Max. amplification again, enter e.x. 400%

=> The output will now be normalized to max. 4%, so the audio is almost completely silent now. <=

(This is probably best handled by tal.aloni, since he extended ffdshow´s normalization feature, which this bug seems to be related to.)

[Leak]

200% is enabled, user wants to change this to 400% and enters "400" => 4% is now the current value (the last 2 digits will get ignored).
Last time I encountered this ffdshow was applying the new value in that box right after each keypress - so you'd get a limit of 4% followed by 40% and 400%. And since the volume is regained at a snails pace (which is why I wanted to be able to configure that speed, or have it accelerate over time) it'll take ages to get back to full again.

Either the value should only be applied when, well, "Apply" is clicked, or at least only when the field loses focus - though I'd find the former more logical, to be honest...

np: School Of Seven Bells - Sempiternal/Amaranth (Alpinisms)

[iSunrise]

Last time I encountered this ffdshow was applying the new value in that box right after each keypress - so you'd get a limit of 4% followed by 40% and 400%.
The big problem now is that you can type e.x. 40 or 400 in that box, but it has no effect, since only the first digit seems to get recognized ("Current:" will stay at "4%"). To make it even worse, trying to input a second value won´t work, because the whole box now just stops working altogether and it will always stick to the first digit value.

To save you guys some time I´ve just went through all past revisions and I found out that from rev2232 on the above has stopped working. The last and working revision was rev2225.

Either the value should only be applied when, well, "Apply" is clicked, or at least only when the field loses focus - though I'd find the former more logical, to be honest...
These were my thoughts, too, but that shouldn´t be necessary if the original behaviour of that box (check rev2225 or rev2222) is back again.

[yesgrey]

Recently, there was a significant update in this (http://forum.doom9.org/showthread.php?p=1227281#post1227281) thread.

With the function described, we can create a 3D LUT file to color correct our display RGB primaries colors.

It would be great if ffdshow allowed us to use this file for performing the correction. I think it's a very simply thing to do, it's just loading the 3D LUT into memory, and, after the YUV->RGB conversion, just map the RGB value in the 3D LUT and then output the value indicated by the 3D LUT.

For the interface, I was thinking in something like this:
-create a directory in ffdshows install dir called "3Dluts"
-put there all the 3D LUT files we want to use
-create in the "RGB Conversion" dialog the option "Use 3D LUT"
-create in the "RGB Conversion" dialog a drop down list which lists all 3D LUTs (file name) available in the dir "3Dluts"

Currently, we can use the ffdshow Avisynth for doing it, but it would be better the integration in ffdshow, because then we could use custom contrast values.

[tetsuo55]

Actually, i was hoping we could take this a step further.

FFdshow basically has all the data needed to guesstimate the source colorspace/levels/gamma.
We already have:
-Resolution to decide between BT.709(721x577 and higher) and BT.601(720x480 and lower)
-Resultion to decide between BT.601 EBU (PAL)(720x576) or BT-601 SMPTE-C (NTSC)(720x480)
-FPS to decide between BT.601 EBU (PAL)(25) or BT-601 SMPTE-C (NTSC)(30) and even BT.709(24)
-Video codec/container type (for detecting full-level video like fraps)

Besides this there are also colorspace dection programs avaialble, at least for images, their functioniality might also be possible for video.

The user would enable/disable the automatic detection and change some defaults. The available fields would be:
-Enable/Disable automatic Color/Level/Gamma
-Target Colorspace(default sRGB)
-Target Level(default 0-255)
-Target Gamma(default 2.2)
-Target RGB primaries(default sRGB primaries)

Selecting the desired colorspace would automatically adjust the 4 target values to the ones that are needed for that colorspace. There should be an option to lock each individual setting however, so filled in primaries do not have to be re-entered with every change.

Simply enabling the option will result in an accurate image for non-calibrated monitors. While changing the settings will allow advanced users and people with calibrated monitors/tv's/projectors to get the most out of their hardware.

A lot of the non-programmers here or I could provide a lot more information to anyone willing to actually code this into ffdshow and/or MPC

[tal.aloni]

If "Volume" and "Normalize" in the ffdshow audio decoder is enabled and the user changes "Max. amplification" while an audio file is playing, the current amplification drops down to a value that represents only the first digit of the value that the user wants to enter.

yea, I saw that too, but I was too lazy to do something about it at that time,
thanks for bringing that up, I'll see what I can do.

Tal

[yesgrey]

tetsuo55,
Your idea is good, but I think that with the presets and what I have requested, I think we can almost do all that, or something very similar...

[yesgrey]

A new version of libsamplerate is coming...
Go here (http://forum.doom9.org/showthread.php?p=1227961#post1227961) for more details, and if you want to try it in ffdshow. I have built a ff_samplerate.dll with this new version.

[yesgrey]

I have analysed the "Preset autoload conditions" dialog, and I think it would be better if the edit boxes are enabled only if the corresponding check box is enabled. Currently, the edit boxes are always enabled.

I also would like to request the addition of a new condition, the screen resolution.
Why? Because I use two screens with my PC, my monitor and my projector, and I want to load different presets for them and the only thing that differentiate them are the screen resolution and refresh rate. I think the resolution is more indicated for the selection...
:thanks:

[leeperry]

I have analysed the "Preset autoload conditions" dialog, and I think it would be better if the edit boxes are enabled only if the corresponding check box is enabled. Currently, the edit boxes are always enabled.
I personally like it the way it is right now, I can leave the data written in there and toggle it if I want to.

[yesgrey]

I personally like it the way it is right now, I can leave the data written in there and toggle it if I want to.

But disabling the edit boxes does not delete what is written there, only greys it. You still can see what is there, but for changing it you have to check the box.
The way it is right now, is a bit confusing, because you don't know which edit box belong to which check box, the bellow or the above; you have to look to the last to know.

[leeperry]

But disabling the edit boxes does not delete what is written there, only greys it. You still can see what is there, but for changing it you have to check the box.
The way it is right now, is a bit confusing, because you don't know which edit box belong to which check box, the bellow or the above; you have to look to the last to know.
well you can cut/paste arguments to other profiles w/o enabling/disabling it(and maybe forgetting to disable it afterwards)...I like it how it is, and don't see what's so annoying about it :p

[TheShadowRunner]

A small question/request for Haruhiko, is it technically possible to have ffdshow prevent the loading of Directvobsub when FFDShow's internal Subtitles feature is enabled?
The reason is the following: I use FFDshow for divx/xvid and like to use the internal Subtitle feature for those video streams. But I use CoreAVC for h264 so i need to have Directvobsub autoloading version enabled too.
The problem is that with this setup, when I play divx/xvid files, both the internal ffdshow subtitles and Directvobsub subtitles are loaded and displayed at once. So I was thinking a solution could probably be an option in FFDshow Subtitles setting page: "Prevent Directvobsub". When enabled, FFDshow would connect directly to the video renderer and prevent Directvobsub from being used.
Would this be possible at all?
See you,

TSR
I had also thought of a different approach to solve the issue: a feature in DirectvobSub (http://sourceforge.net/tracker2/?func=detail&aid=2301026&group_id=170561&atid=854654) to not load if specified filter is present in graph. If DirectvobSub had such a blacklist to prevent it from loading, I could set FFDshow there to make sure Directvobsub never loads when FFDshow is used. Maybe it's a better solution compared to the request above, as it's more global?

[Eragon4ever]

You could set "Raw video" -> "all supported" and use ffdshow's subtitles with CoreAVC as decoder.

But I have a question: How do you get VSFilter to work with CoreAVC? It loads but no subtitles are displayed. Only ffdshow's subtitles are working but I'd prefer VSFilter...

[TheShadowRunner]

No, I do not wish FFDshow to be always loaded.

Hmm VSfilter works just fine with CoreAVC, connects automatically between decoder and renderer and works as usual.
See you,

TSR

[Eragon4ever]

Ok, I found the problem. If I set "Raw video" -> "disabled" (instead of "all supported"), it's working.

The subtitles just don't get send to VSfilter but to ffdshow (even if ffdshow's subtitles are disabled). Could it be that subtitles are always send to the last filter in the graph that accepts them? If so shouldn't ffdshow refuse the connection if internal subtitles are disabled?

Edit: Why do you want VSfilter for H.264? Using a different subtitle renderer based on video codec does not make any sense to me. On the other hand, how do you even manage to make bouth work at the same time? If ffdshow is decoding the video, the subs are send to VSfilter here because it is last filter for them in the graph. ffdshow doesn't get any and displays nothing even with internal subtitles enabled...

[TheShadowRunner]

If so shouldn't ffdshow refuse the connection if internal subtitles are disabled?

No it shouldn't refuse as this wouldn't allow the Subtitles toggle to work in real time (the graph would need to be rebuild so you would need to stop the video, enable Subtitles in ffdshow and restart the video).
It's fine the way it is now.

Why do you want VSfilter for H.264? Using a different subtitle renderer based on video codec does not make any sense to me.

What? What else would i use for subs over h264 with coreavc if not Vobsub?

On the other hand, how do you even manage to make bouth work at the same time? If ffdshow is decoding the video, the subs are send to VSfilter here because it is last filter for them in the graph. ffdshow doesn't get any and displays nothing even with internal subtitles enabled...

Again, i don't really see what you're talking about. Subs aren't "sent" anywhere, let alone to the "last filter" :confused:.

When Vsfilter is set to autoload embedded and external subs, it will always load in the graph, that's it.
If it so happens that you use the FFDshow internal Subtitles feature, then when playing a video stream that you've set ffdshow to decode, both the internal Subtitles engine and Directvobsub will work at the same time, so they appear twice on the picture. My request is to automatize a way around that.
Later,

TSR

[Eragon4ever]

No it shouldn't refuse as this wouldn't allow the Subtitles toggle to work in real time (the graph would need to be rebuild so you would need to stop the video, enable Subtitles in ffdshow and restart the video).
It's fine the way it is now.
There you've got a point. Then perhaps only if another subtitles render is present in the graph? Don't know if that's possible.

What? What else would i use for subs over h264 with coreavc if not Vobsub?
ffdshow's subtitles renderer, maybe? My suggestion from before was CoreAVC -> ffdshow(subs) -> Video Renderer.

When Vsfilter is set to autoload embedded and external subs, it will always load in the graph, that's it.
If it so happens that you use the FFDshow internal Subtitles feature, then when playing a video stream that you've set ffdshow to decode, both the internal Subtitles engine and Directvobsub will work at the same time, so they appear twice on the picture. My request is to automatize a way around that.
What you say sounds logical but rendering a file in Graphedit shows me something different, here.
As you can see below, the subtitle pin is not connected with ffdshow but only with 0002(which is VSfilter). It's the other way around for a graph like CoreAVC -> VSfilter -> ffdshow -> Video Renderer.
If there's anything wrong with my conclusions from what I can observe, please tell me what.
http://www.pictureshoster.com/files/zhmx7hcg1g879ogl9fc.png

[TheShadowRunner]

ffdshow's subtitles renderer, maybe? My suggestion from before was CoreAVC -> ffdshow(subs) -> Video Renderer.

Well, ok i see what you mean, but no, I'd rather use VSFilter for h264. ^^;;

What you say sounds logical but rendering a file in Graphedit shows me something different, here.
As you can see below, the subtitle pin is not connected with ffdshow but only with 0002(which is VSfilter). It's the other way around for a graph like CoreAVC -> VSfilter -> ffdshow -> Video Renderer.
If there's anything wrong with my conclusions from what I can observe, please tell me what.

There's nothing wrong with your conclusion, it's rather incomplete. The graph above works OK for embedded subs, but external subs will load both in ffdshow and vsfilter!

If ffdshow could be set to prevent Vobsub from loading altogether (when ffdshow internal Subtitles feature is enabled), of if VSFilter could be set to *not* load if filter X or Y is already present in the graph, that would solve the problem beautifully.
See you,

TSR

[Eragon4ever]

There's nothing wrong with your conclusion, it's rather incomplete. The graph above works OK for embedded subs, but external subs will load both in ffdshow and vsfilter!
Ah, ok. If that's true, everything makes sense. I just don't have any external subs:p

[EpsilonX]

Hi guys !
Newbie here, currently I'm using rev2527 ICL10...
Been having grab issues from the last 4-5 builds if i recall correctly...
FFDShow would crash while grabbing screenshots using Grab...
Tried with ZoomPlayer and MPC, so it seems it's not a player related problem...
Narrowed the problem's cause, it only happens when Resize is active...
Changing the resize method didn't seem to help...
Any confirmation about this problem..?
Thanx in advance !

[Ryokurin]

You could set "Raw video" -> "all supported" and use ffdshow's subtitles with CoreAVC as decoder.

But I have a question: How do you get VSFilter to work with CoreAVC? It loads but no subtitles are displayed. Only ffdshow's subtitles are working but I'd prefer VSFilter...

CoreAVS is probably calling haali's media splitter in the directshow stream, so you'll have to go into the splitter's properties and tell it to auto load subtitles. It's not enabled by default.

[haruhiko_yamagata]

A small question/request for Haruhiko, is it technically possible to have ffdshow prevent the loading of Directvobsub when FFDShow's internal Subtitles feature is enabled?ffdshow can refuse to connect to VSFilter, but it doesn't guarantee that ffdshow can connect to video renderer instead.
The applications should be able to handle it, shouldn't be done in ffdshow.
It should be possible to "passthrough" subtitle to VSFilter if ffdshow is connected to it.

[turbojet]

Is there any way for ffdshow to decode <link removed, fixed> 480i m2ts from a retail BD?

[Eragon4ever]

CoreAVS is probably calling haali's media splitter in the directshow stream, so you'll have to go into the splitter's properties and tell it to auto load subtitles. It's not enabled by default.
No, as I wrote VSfilter did get loaded but just didn't display anything. Like I wrote, the problem was the following:

CoreAVC -> VSfilter -> ffdshow -> Video Renderer

In this graph VSfilter doesn't receive the subtitles so it can't display anything. ffdshow receives the subtitles and obviously nothing shows up if internal subtitles are disabled.

Kicking ffdshow out of the graph by setting "Raw video" -> "disabled" makes VSfilter work.

[haruhiko_yamagata]

Recently, there was a significant update in this (http://forum.doom9.org/showthread.php?p=1227281#post1227281) thread.
[...]

I would love to, but I have too many things to do.
If I have time, but I can't promise.

[yesgrey]

Ok, for me is good enough. I will wait and hope you could have a little time for it...
Do you think it's better adding it to ffdshow's feature requests tracker?
:thanks:

[haruhiko_yamagata]

Do you think it's better adding it to ffdshow's feature requests tracker?
:thanks:Yes, please do so.

[Kurtnoise]

@devs: could you remind me why wavpack support has been dropped ? I don't remember exactly why and it's not mentioned in the FAQ or in the bugtracker.

[fastplayer]

According to the SVN log it was "incomplete".

[STaRGaZeR]

I've committed to the trunk. Please test when you come back. If it works for Haali's splitter, I'll add gabest's matroska splitter to the workaround.

Just tested with all renderers and the garbled frames in premiere-paff.ts are gone, great work.
The only ones that are still bad are those like MF06.mkv, the garbled frames are still there with EVR/EVR Custom only. One more example:

http://thumbnails2.imagebam.com/2198/9a39e721972659.gif (http://www.imagebam.com/image/9a39e721972659)

Will test the freeze a soon as someone uploads an updated MT build.

[MatMaul]

I've committed to the trunk. Please test when you come back. If it works for Haali's splitter, I'll add gabest's matroska splitter to the workaround.
I think it would be better to ask for a fix in the mpc-hc thread if the mpc splitter is also concerned.

[haruhiko_yamagata]

Just tested with all renderers and the garbled frames in premiere-paff.ts are gone, great work.
The only ones that are still bad are those like MF06.mkv, the garbled frames are still there with EVR/EVR Custom only. One more example:

Will test the freeze a soon as someone uploads an updated MT build.
I found I could reproduce the freeze and garbling using the MT branch + EVR Custom.
Trunk works for me.

[fastplayer]

I think it would be better to ask for a fix in the mpc-hc thread if the mpc splitter is also concerned.
I was thinking the same. If this issue is 100% splitter-related, then it should be fixed right there and not in the decoder.

[haruhiko_yamagata]

I don't have the proof that MPC's splitters are concerned.

[STaRGaZeR]

I found I could reproduce the freeze and garbling using the MT branch + EVR Custom.
Trunk works for me.

For me trunk doesn't have any freezes, but the corrupted frames with EVR Custom are there. In fact my previous screenshot was produced with rev2537.

[Sharc]

Is there any way for ffdshow to decode this (http://www.mediafire.com/download.php?mvjnmva5kmn) 480i m2ts from a retail BD?

No problem at all with the playback using MPC, MPC-HC, graphstudio and ffdshow here .....
It's purely interlaced, TFF.

[G_M_C]

Guys i've got a strange problem;

I use MPC-HC for playing my videos. Currently i use CoreAVC for AVC playback. I've set MPC to VMR9 (renderless), and full-screen to my secondary display (TV, atm connected through S-Video). When i use CoreAVC, switching to full-screen the secondary display works fine, but i cant get subtitles to work correctly. But i want the subtitles to work on the full-screen mode ...

So i loaded the latest beta (6) of ffdshow_tryouts. Set it up to decode AVC, and set it up to generate subtitles. When in "normal PC-screen" mode, all works fine. Subs show up, and are drawn as i set up, but the problem starts when i try to switch over to full screen .... When i switch over to full screen, on my secondary display, i get a freeze-frame with subtitle (also frozen). The audio keeps playing though. Switching rendering modes give various effects, most of them the same frozen frame others dont give an image/signal at all. Overlay mode gives an image thats 1/2 hight (somehow DAR/SAR isnt transmitted properly it seems, (on CoreAVC i do get the full-screen/hight image).

What setting can i change to get full-screen video with subs through ffdshow / get the whole thing working ?

[MatMaul]

@h_yamagata : I think you should add the microsoft mpeg2 demultiplexer to the "h264_on_MPEG2_system" workaround because it is used by some DVB softwares (at least the OS ones like MeuhMeuhTV or PouchinTV).
patch :
Index: src/ffdshow_mediaguids.h
===================================================================
--- src/ffdshow_mediaguids.h (revision 2547)
+++ src/ffdshow_mediaguids.h (working copy)
@@ -374,6 +374,7 @@
DEFINE_GUID(CLSID_AVIDec ,0xcf49d4e0, 0x1115, 0x11ce, 0xb0, 0x3a, 0x00, 0x20, 0xaf, 0x0b, 0xa7, 0x70);
DEFINE_GUID(CLSID_EnhancedVideoRenderer ,0xfa10746c, 0x9b63, 0x4b6c, 0xbc, 0x49, 0xfc, 0x30, 0x0e, 0xa5, 0xf2, 0x56);
DEFINE_GUID(CLSID_VideoMixingRenderer9 ,0x51b4abf3, 0x748f, 0x4e3b, 0xa2, 0x76, 0xc8, 0x28, 0x33, 0x0e, 0x92, 0x6a);
+DEFINE_GUID(CLSID_MPEG2Demultiplexer ,0xafb6c280, 0x2c41, 0x11d3, 0x8a, 0x60, 0x00, 0x00, 0xf8, 0x1e, 0x0e, 0x4a);
DEFINE_GUID(CLSID_DirectVobSubFilter ,0x93a22e7a, 0x5091, 0x45ef, 0xba, 0x61, 0x6d, 0xa2, 0x61, 0x56, 0xa5, 0xd0);
DEFINE_GUID(CLSID_DirectVobSubFilter2 ,0x9852a670, 0xf845, 0x491b, 0x9b, 0xe6, 0xeb, 0xd8, 0x41, 0xb8, 0xa6, 0x13);
DEFINE_GUID(CLSID_HaaliVideoRenderer ,0x760a8f35, 0x97e7, 0x479d, 0xaa, 0xf5, 0xda, 0x9e, 0xff, 0x95, 0xd7, 0x51);
Index: src/TffdshowVideoInputPin.cpp
===================================================================
--- src/TffdshowVideoInputPin.cpp (revision 2547)
+++ src/TffdshowVideoInputPin.cpp (working copy)
@@ -265,7 +265,7 @@
connectedSplitter = Haali_Media_splitter;
else if (ref == CLSID_MPC_MpegSourceFilter || ref == CLSID_MPC_MpegSplitterFilter)
connectedSplitter = MPC_mpegSplitters;
- else if (ref == CLSID_DVBSourceFilter)
+ else if (ref == CLSID_DVBSourceFilter || ref == CLSID_MPEG2Demultiplexer)
connectedSplitter = DVBSourceFilter;

#if 0

[haruhiko_yamagata]

@h_yamagata : I think you should add the microsoft mpeg2 demultiplexer to the "h264_on_MPEG2_system" workaround because it is used by some DVB softwares (at least the OS ones like MeuhMeuhTV or PouchinTV).
patch :

Last time I tried it in graphedit on Windows Xp, I get video but no audio.
But if it's working, it's OK.

[haruhiko_yamagata]

Guys i've got a strange problem;

I use MPC-HC for playing my videos. Currently i use CoreAVC for AVC playback. I've set MPC to VMR9 (renderless), and full-screen to my secondary display (TV, atm connected through S-Video). When i use CoreAVC, switching to full-screen the secondary display works fine, but i cant get subtitles to work correctly. But i want the subtitles to work on the full-screen mode ...

So i loaded the latest beta (6) of ffdshow_tryouts. Set it up to decode AVC, and set it up to generate subtitles. When in "normal PC-screen" mode, all works fine. Subs show up, and are drawn as i set up, but the problem starts when i try to switch over to full screen .... When i switch over to full screen, on my secondary display, i get a freeze-frame with subtitle (also frozen). The audio keeps playing though. Switching rendering modes give various effects, most of them the same frozen frame others dont give an image/signal at all. Overlay mode gives an image thats 1/2 hight (somehow DAR/SAR isnt transmitted properly it seems, (on CoreAVC i do get the full-screen/hight image).

What setting can i change to get full-screen video with subs through ffdshow / get the whole thing working ?
I can't reproduce. Does it matter primary or secondary screen?
What is your video card?

[v0lt]

BUG: I found a bug in VFW MJPG-decoder in ffdshow-mt after rev2353. I open file in VirtualDub and get blue color instead of red.
my file - http://rapidshare.com/files/176589107/test_MJPEG.avi.html
ffdshow-mt rev2353 - no bug
ffdshow-mt rev2368 and above - bug
common ffdshow x86 - no bug

sorry for my English

[yesgrey]

BAG: ... sorry for my English

Just to inform you... It's BUG.;)

[v0lt]

Just to inform you... It's BUG.;)
facepalm
...fixed)

[mark0077]

Hey guys,

Im almost 100% moved to using ffdshow video and audio for everything as I find no problems with it now compared to a while ago.

The two questions I have are
ffdshow video: What de-interlacer is "best" or what do most people find the best. I have been using yadif but it is buggy especially when moving from say a progressive dvd menu, to interlaced video, I think it gets mixed up and I get ugly looking screens, or sometimes black screens for a few seconds.

ffdshow audio: Is there a way to tell the mixer, when I am playing a stereo source, mirror the front left, to rear left, and front right, to rear right. The expand surround seems to do more than this which I do not want.

THX!

[TheShadowRunner]

Ok thanks for your answer Haruhiko (regarding the double subtitle issue, ffdshow + VSfilter both displayed at once).
I reckon the best way to deal with this would be from within VSfilter, would you know if Casimir is still today the principal coder for VSfilter?
See you,

TSR

[iSunrise]

ffdshow audio: Is there a way to tell the mixer, when I am playing a stereo source, mirror the front left, to rear left, and front right, to rear right. The expand surround seems to do more than this which I do not want.
Enable the "2/0/2 - quadro" preset in the mixer tab, enable "custome matrix" and input "1" into both L -> BackL and R -> BackR fields.
That should do the trick.

[mark0077]

Thanks for that, but my aim is to have my complete setup automated and this is one of the final steps I need to get around.

Is there any way to automate this in the mixer?

[MatMaul]

Last time I tried it in graphedit on Windows Xp, I get video but no audio.
But if it's working, it's OK.
I can't test because my computer is way too slow to decode 1080 ts samples but it can't hurt to enable it : this splitter is only used for mpeg2 streams.

[haruhiko_yamagata]

I can't test because my computer is way too slow to decode 1080 ts samples but it can't hurt to enable it : this splitter is only used for mpeg2 streams.
Well, do you mean the patch is not tested?
It should work without your patch as long as the splitter set filename in its API context. DVBSource does not set filename, and that's why it's listed there.

[MatMaul]

It should work without your patch as long as the splitter set filename in its API context. DVBSource does not set filename, and that's why it's listed there.
the same applies for the microsoft demuxer in DVB playback context since no filename is available.
What I meant is that it is a MPEG2 demultiplexer only so if h264 is detected you can be sure the "h264_on_MPEG2_system" case applies, so there is no drawback to automatically activate it when this splitter is detected.

[Jong]

I have a problem which I am pretty sure is limited to beta6. Sometimes in TheaterTek video fails to start when ffdshow is being used as a post-processor to Nvidia's MPEG-2 decoder. Audio plays but there is a black screen.

TheaterTek says ffdshow is loaded, but its icon does not appear in systray, although it does when all is working.

It happens maybe one time in 6-8 attempts. Other times all is OK. I have just regressed to beta 5 and in 20+ attempts couldnot get it to happen. I have never seen it before upgrading.

Any ideas?

[G_M_C]

I can't reproduce. Does it matter primary or secondary screen?
What is your video card?

Sorry, i was out and have to go out to work again. Will help again when i return. To rule out other possibilities, i'll update drivers and MPC-HT to newest, and report back about settings etc. Thanx in advance.

[turbojet]

No problem at all with the playback using MPC, MPC-HC, graphstudio and ffdshow here .....
It's purely interlaced, TFF.

Oh seems to play ok in ffdshow 2537 but not in ffdshow-mt 2548 from xvidvideo.ru could someone involved with ffdshow-mt take a look at <link removed, fixed>?

[EpsilonX]

Hi guys !
Newbie here, currently I'm using rev2527 ICL10...
Been having grab issues from the last 4-5 builds if i recall correctly...
FFDShow would crash while grabbing screenshots using Grab...
Tried with ZoomPlayer and MPC, so it seems it's not a player related problem...
Narrowed the problem's cause, it only happens when Resize is active...
Changing the resize method didn't seem to help...
Any confirmation about this problem..?
Thanx in advance !

Still no confirmation... :(
Anyone able to reproduce this problem..?

[haruhiko_yamagata]

BUG: I found a bag in VFW MJPG-decoder in ffdshow-mt after rev2353. I open file in VirtualDub and get blue color instead of red.
my file - http://rapidshare.com/files/176589107/test_MJPEG.avi.html
ffdshow-mt rev2353 - no bug
ffdshow-mt rev2368 and above - bug
common ffdshow x86 - no bug

sorry for my English
I can't reproduce because unknown MJPEG decoder is used instead of ffdshow in VFW mode. I'm trying to uninstall the unknown MJPEG decoder, no success for now.
Is there other way to reproduce the bug?

[haruhiko_yamagata]

Hi guys !
Newbie here, currently I'm using rev2527 ICL10...
Been having grab issues from the last 4-5 builds if i recall correctly...
FFDShow would crash while grabbing screenshots using Grab...
Tried with ZoomPlayer and MPC, so it seems it's not a player related problem...
Narrowed the problem's cause, it only happens when Resize is active...
Changing the resize method didn't seem to help...
Any confirmation about this problem..?
Thanx in advance !
@tal.aloni
Could you take a look at this?

[haruhiko_yamagata]

Oh seems to play ok in ffdshow 2537 but not in ffdshow-mt 2548 from xvidvideo.ru could someone involved with ffdshow-mt take a look at it (http://www.mediafire.com/download.php?mvjnmva5kmn)?
It crashes because s.obmc_scratchpad is NULL in mc_part_weighted (luma-only case).
Mr VacBob, I hope you find this.

[tetsuo55]

I just wanted to point out that this post has revealed several problems with the Mpeg2 decoders in ffdshow

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

I do not know if these where already known, nor do i know if these are ffdshow or ffmpeg bugs

[Sharc]

Could someone have a look to this file? I was not able to decode it with ffdshow. It seems to consist of a mixture of progressive and frame interlaced content.
The only way I found to decode it properly was with the DGVC1IndexNV suite.

http://www.mediafire.com/?sharekey=f4754089d1b37e86d2db6fb9a8902bda

[v0lt]

I can't reproduce because unknown MJPEG decoder is used instead of ffdshow in VFW mode. I'm trying to uninstall the unknown MJPEG decoder, no success for now.
Is there other way to reproduce the bug?
:confused: I only chose libavcodec in settings of VFW decoder...
ffdshow-mt rev. 2530
http://img244.imageshack.us/img244/6029/bluepianoem9.th.jpg (http://img244.imageshack.us/img244/6029/bluepianoem9.jpg)

internal MJPEG decoder
http://img508.imageshack.us/img508/6230/redpianota1.th.jpg (http://img508.imageshack.us/img508/6230/redpianota1.jpg)

[ikarad]

I don't know if anybody know this problem with AC3 codec but I give you the link of this problem (random desynchronisation of sound with 5.1 soundtrack when AC3 codec is used with XFI titanium under xp sp3).
http://ac3filter.net/forum/viewtopic.php?p=2530#2530

If anybody know how to correct this problem or if a new version of ac3 codec will correct this bug.

[haruhiko_yamagata]

:confused: I only chose libavcodec in settings of VFW decoder...
ffdshow-mt rev. 2530
http://img244.imageshack.us/img244/6029/bluepianoem9.th.jpg (http://img244.imageshack.us/img244/6029/bluepianoem9.jpg)

internal MJPEG decoder
http://img508.imageshack.us/img508/6230/redpianota1.th.jpg (http://img508.imageshack.us/img508/6230/redpianota1.jpg)OK I've managed to reproduce it.

[EpsilonX]

Hi guys !
Newbie here, currently I'm using rev2527 ICL10...
Been having grab issues from the last 4-5 builds if i recall correctly...
FFDShow would crash while grabbing screenshots using Grab...
Tried with ZoomPlayer and MPC, so it seems it's not a player related problem...
Narrowed the problem's cause, it only happens when Resize is active...
Changing the resize method didn't seem to help...
Any confirmation about this problem..?
Thanx in advance !

A little update...
It seems it only crashed with 16:9 (Widescreen) content...
Capturing 4:3 content works fine...
But another problem arise...
The captured frame looks like this...

http://img224.imageshack.us/img224/6830/grab00600ay1.th.jpg (http://img224.imageshack.us/my.php?image=grab00600ay1.jpg)

Portion of the left part is cropped and "stitched" to the right part...
Currently using rev2547...

[leeperry]

is there a way to zoom the picture in ffdshow/avisynth ?
I've tried the "Crop & zoom" ffdshow filter but it doesn't seem to work like the 3/9 keys in MPC.

Haali's Renderer internal scaler also does ghost lines with nvidia cards so I can't use it.
a "zoom" slider in the resize filter would be really great, so all the postprocessing would be done on the zoomed picture :)

I also would like to request the addition of a new condition, the screen resolution.
Why? Because I use two screens with my PC, my monitor and my projector, and I want to load different presets for them and the only thing that differentiate them are the screen resolution and refresh rate.
yeah, that'd be neato, I do 1280*768 resize on my pj and 1024*768 on my CRT...atm I've got a manual DOS batch that messes with the registry :
[HKEY_CURRENT_USER\Software\GNU\ffdshow\SD]
"resizeDx"=dword:00000400

[HKEY_CURRENT_USER\Software\GNU\ffdshow\SD]
"resizeDx"=dword:00000500

[Pulstar]

I know this has been asked before, but why doesn't the postproc option in ffdshow affect AVC videos? Is it because postproc is "builtin" in the H.264 spec? If that's the case is there a way to "strengthen" AVC postproc?

[J_Darnley]

No, altering the behaviour of AVC's in-loop filter can cause horrible artefacts because the filtered frames are used as the reference frames.

[Snowknight26]

When seeking through MPEG-2 content, libavcodec causes garbage for a couple frames (till a keyframe?); seeking is almost instant. With libmpeg2, seeking takes longer but there is no garbage.

[Atak_Snajpera]

FFDshow r2547 + Yadif (double frame rate unchecked) + this mpeg2 sample (http://www.mediafire.com/?inezy2yzjgi) = jerky frame rate (something like half of 29.97) . When I check double frame rate then frame rate is ok (59.94)

[Pulstar]

No, altering the behaviour of AVC's in-loop filter can cause horrible artefacts because the filtered frames are used as the reference frames.

Okay thanks for clearing it up for me! I thought the Youtube/Google MP4s looked a bit blocky even for <500kbps videos.

[Dark Shikari]

Okay thanks for clearing it up for me! I thought the Youtube/Google MP4s looked a bit blocky even for <500kbps videos.This is because skal's Youtube h.264 encoder uses an extremely low deblocking strength (as low as -6:-6) because he thinks it "looks better."

Blame him :p

[Pulstar]

This is because skal's Youtube h.264 encoder uses an extremely low deblocking strength (as low as -6:-6) because he thinks it "looks better."

Blame him :p

Hehe you bet I will blame him :p

[EpsilonX]

The Grab issue haven't been resolved yet, and I got another "problem"... :D
I currently have a 1 TS file with AAC Audio...
The show itself is 5.1 AAC, while the commercial is 2.0 AAC...
During playback, FFDShow didn't decode the AAC 2.0 at all...
So the commercial is muted...
Any workaround to this..?
Thanx !

[lych_necross]

Ever since yadif was added to ffdshow tryouts, I started thinking how nice it would be if Decomb was also incorporated. It would be very handy if users were able to inverse telecine video without having to use external plugins.

I had another idea also. I would like to see an option added to ffdshow's avisynth tab that automatically sets appropriate values for the "Buffer back/ahead" settings. Simply clicking the current button will change the values to what is currently requested; however, it would be nice if these values were determined automatically.
:thanks:

[haruhiko_yamagata]

I currently have a 1 TS file with AAC Audio...
The show itself is 5.1 AAC, while the commercial is 2.0 AAC...
During playback, FFDShow didn't decode the AAC 2.0 at all...
So the commercial is muted...
Any workaround to this..?
Thanx !It's a know issue to me, I have tried to fix it and given up.
Now that libavcodec can decode AAC (not in ffdshow), it may be a good idea to try it with libavcodec.

[lexor]

So the commercial is muted...
Any workaround to this..?
Thanx !

Umm... you don't like that the commercial is muted? I'd call that a feature, personally, and a very good one.

[STaRGaZeR]

When seeking through MPEG-2 content, libavcodec causes garbage for a couple frames (till a keyframe?); seeking is almost instant. With libmpeg2, seeking takes longer but there is no garbage.

After reading this post I gave libavcodec MPEG-2 another chance. And I'm very pleased with it so far. Haruhiko, I remember you saying that libavcodec requires 2 keyframes to resume after seeking, but even with that as Snowknight26 says it's faster. And I confirm there are some frames with blocking here too with all renderers after seeking.

Umm... you don't like that the commercial is muted? I'd call that a feature, personally, and a very good one.

Indeed :p

[tal.aloni]

EpsilonX, Thanks for bringing up the grab + resize bug,
it was my own doing, sorry.
I'm also sorry for the long time it took me to check it, my monitor went dead.

commited as rev. 2559:
+ Bugfix: ffdshow would crash when using the grab filter together with the resize filter with aspect ration correction

[EpsilonX]

Umm... you don't like that the commercial is muted? I'd call that a feature, personally, and a very good one.

LOL...
In some way it's amazing... :D
But I happen to like the CM in Japanese show... :D
If I wanna skip the commercial, CoreAAC handles it very well...
When I use CoreAAC, somehow the video just fast forward when playing the CM part, and resumes normal playback speed when the commercial ends... :D

[Kurtnoise]

According to the SVN log it was "incomplete".
keep in mind that the current lavc aac decoder doesn't support heaac v1 & heaac v2 yet. However, it's already included in ffdshow...;) So, why not wavpack too ?

[Jeremy Duncan]

link (https://sourceforge.net/tracker/index.php?func=detail&aid=2436501&group_id=173941&atid=867363)

To the ffdshow developers. I have made a thread in the sourceforge website for a requested feature

:sly:

[clsid]

I don't think it is a good idea to add functionality that only works half of the time. That is why I removed Wavpack in the past. As a result people are simply forced to use an alternative filter (that does work properly) instead of complaining to us about why it doesn't work.

[tal.aloni]

@developers,
I'm struggling with making the "Max. Amplification" Textbox not to be applied immediately, do you have any idea how can I make the apply button enabled without binding the Max. Amplification textbox?

Thanks,
Tal

EDIT:
parent->setChange() seems to do the trick.

[fastplayer]

@developers,
I'm struggling with making the "Max. Amplification" Textbox not to be applied immediately,...
Wouldn't it be better to remove the "on-the-fly" apply?
It goes against any UI guideline there is...

Edit: Never mind. I misread.

[leeperry]

:sly:
I don't think it's the proper attitude to get anything done buddy ;)

I personally would love to see :
1)-proper OzoneMP support that doesn't freeze on new files(I've even asked a friend to make a debug winamp2 plugin in order to help Haruhiko..who told me that he saw what the problem was)
2)-a "screen resolution" condition in the profiles(as yesgrey3 suggested)
3)-have the subs less blurry(maybe let you choose how blurry you want them with a slider?)

...but Haruhiko has his own priorities, live with it or learn C++ :p

besides spline64 is said to be more ringy than spline36 I think...blackmanresize I can't tell.

but hopefully MT 0.7 will be updated for Avisynth 2.58, so you'll get native support for these 2 resize algorithms in ffdshow soon enough :cool:

[tetsuo55]

I don't think it is a good idea to add functionality that only works half of the time. That is why I removed Wavpack in the past. As a result people are simply forced to use an alternative filter (that does work properly) instead of complaining to us about why it doesn't work.

Are all the wavpack bugs/lack of features known with the ffmpeg devs?

I respect that you wouldn't want to enable all possible decoders for all end users.
But having the decoder available also means more bug-reports for ffmpeg
(I mean this in general for all codecs not just wavpack which i personally do not use)

[tal.aloni]

Applied as rev. 2562:
+ UI Improvement: Normalization filter: max. amplification will only be applied after pressing "apply". (or OK)

Patch:
http://iknowu.net/files/public/ffdshow/2662-Max%20Anplification.patch

[Kurtnoise]

I don't think it is a good idea to add functionality that only works half of the time. That is why I removed Wavpack in the past. As a result people are simply forced to use an alternative filter (that does work properly) instead of complaining to us about why it doesn't work.
well...I understand. Then, you (I mean any ffdshow contributors) should add some comments about that in the FAQ at least (codecs non complete yet).

[clsid]

Hardly anyone reads the FAQ.
WavPack support is just incomplete. It has been for a long time. That is known with the FFmpeg devs. But that doesn't mean they have any plans to implement the remaining features.
There is a good working open-source decoder (CoreWavPack), which also includes a parser (for .wv files), so I don't see any reason for including a broken/incomplete decoder to ffdshow. It would be a different situation if no alternative was available.

[haruhiko_yamagata]

FFDshow r2547 + Yadif (double frame rate unchecked) + this mpeg2 sample (http://www.mediafire.com/?inezy2yzjgi) = jerky frame rate (something like half of 29.97) . When I check double frame rate then frame rate is ok (59.94)I can reproduce the problem. Thanks.

[Kyle_Katarn]

Where can I download some post-2555 rev ?

[tal.aloni]

Kyle,
latest builds can also be found at xvidvideo.ru.

[Kyle_Katarn]

thanks !

[tetsuo55]

Does anyone know if there is a list somewhere with the status of all the included codecs?

There is a wiki that lists all the codecs that have to eventually be added to libavcodec but it says nothing about the current status.
http://wiki.multimedia.cx/index.php?title=Main_Page

I think a clear overview of each codec and its status is usefull for both end users and programmers.

[Inventive Software]

I'm considering suggesting a small clean-up of common codecs in ffdshow, grouping them together. Notably, the MPEG-4 ones could be chucked together, and ffdshow's fourCCs added to the "other" category. QuickTime ones could be lumped together, as could the Flash ones less H.264.

[clsid]

I can imagine that there are people that want to be able to configure them individually. So I vote against grouping.

[Snowknight26]

Any word on being able to use a negative delay for audio?

[haruhiko_yamagata]

It is not possible.
Delay video instead.

[Snowknight26]

That would require the ability to delay the video. ;)

[EpsilonX]

That would require the ability to delay the video. ;)

IIRC FFDShow have delay video in setting the Queue part...

[EpsilonX]

I personally would love to see :
1)-proper OzoneMP support that doesn't freeze on new files(I've even asked a friend to make a debug winamp2 plugin in order to help Haruhiko..who told me that he saw what the problem was)
2)-a "screen resolution" condition in the profiles(as yesgrey3 suggested)
3)-have the subs less blurry(maybe let you choose how blurry you want them with a slider?)

Would like to hear some opinion from the developers if its possible... :D
Is it possible for FFDShow to detect which monitor its active on..?

[Snowknight26]

IIRC FFDShow have delay video in setting the Queue part...

Good eye, didn't see it earlier.

Now that I'm looking at the Queue & misc panel, I notice that it isn't aligned with the other panels. Switch between Queue & misc and Overlay and you'll see what I mean.

[haruhiko_yamagata]

Would like to hear some opinion from the developers if its possible... :D
Is it possible for FFDShow to detect which monitor its active on..?
It's easy if we ignore multiple monitor system. But the request is posted probably because there are multiple monitors.
It may be possible to get the resolution of the screen where the video window is placed, but at least it's hard. Patches welcome.

[Jong]

So, is no one else seeing this problem? Is there anything I can do to provide useful diagnostic info? I am currently stuck on beta5.I have a problem which I am pretty sure is limited to beta6. Sometimes in TheaterTek video fails to start when ffdshow is being used as a post-processor to Nvidia's MPEG-2 decoder. Audio plays but there is a black screen.

TheaterTek says ffdshow is loaded, but its icon does not appear in systray, although it does when all is working.

It happens maybe one time in 6-8 attempts. Other times all is OK. I have just regressed to beta 5 and in 20+ attempts couldnot get it to happen. I have never seen it before upgrading.

Any ideas?

[yesgrey]

It's easy if we ignore multiple monitor system. But the request is posted probably because there are multiple monitors.

I requested it because I have a monitor and a projector, but I only use ffdshow with one at a time. When I am using the monitor the projector is disabled, and when I am using the projector the monitor is disabled.

It may be possible to get the resolution of the screen where the video window is placed, but at least it's hard.
ffdshow is already getting the resolution of the screen in the resize options, if we select "resize to screen resolution", so I think the code is already there...

Patches welcome.
I'd love to help, but don't know how. I only know C and have worked with Win32 API, no C++ and no COM. Could you tell me what should I learn to be able to help in ffdshow development?

[EpsilonX]

I requested it because I have a monitor and a projector, but I only use ffdshow with one at a time. When I am using the monitor the projector is disabled, and when I am using the projector the monitor is disabled.


ffdshow is already getting the resolution of the screen in the resize options, if we select "resize to screen resolution", so I think the code is already there...


I'd love to help, but don't know how. I only know C and have worked with Win32 API, no C++ and no COM. Could you tell me what should I learn to be able to help in ffdshow development?

Maybe getting the screen resolution is not the problem.
I think the problem is the detection of which monitor FFDShow's active at.
With the current "Resize to screen resolution", no matter what your secondary monitor's resolution...
FFDShow will always resize to the main monitor's resolution, even though you play your video at your secondary monitor...
A code to detect which monitor an application is running should be possible though, it's used in almost all multi-monitor application...
CMIIW... :D

[haruhiko_yamagata]

I'd love to help, but don't know how. I only know C and have worked with Win32 API, no C++ and no COM. Could you tell me what should I learn to be able to help in ffdshow development?When I started coding for ffdshow, I didn't know much about C++ and com. Just start, we will help you :D.

[haruhiko_yamagata]

A code to detect which monitor an application is running should be possible though, it's used in almost all multi-monitor application...
As you say, the detection code in the resize is crappy.
The application's main window is not always in the same screen as video window.
VMR has interface to get such information IIRC. But it's hard to code that for all video renderers...

[haruhiko_yamagata]

I have a problem which I am pretty sure is limited to beta6. Sometimes in TheaterTek video fails to start when ffdshow is being used as a post-processor to Nvidia's MPEG-2 decoder. Audio plays but there is a black screen.

TheaterTek says ffdshow is loaded, but its icon does not appear in systray, although it does when all is working.

It happens maybe one time in 6-8 attempts. Other times all is OK. I have just regressed to beta 5 and in 20+ attempts couldnot get it to happen. I have never seen it before upgrading.

Any ideas?Sorry, I have not tested yet, because I don't have TheaterTek.

[leeperry]

It's easy if we ignore multiple monitor system. But the request is posted probably because there are multiple monitors.
It may be possible to get the resolution of the screen where the video window is placed, but at least it's hard. Patches welcome.
in single monitor setups of course, many ppl switch from one display to the other(monitor>projector)...no need for dual display detection :)

BTW, do you think you might have time to look at the OzoneMP freezing situation some day?
should I ask Vincent Burel for more help to find out what's wrong?

and a slider to choose how blurry you want the subs would be awesome...or maybe simply make them less blurry ? they really don't look sharp atm..

sorry to be repeating myself & :thanks: for your fantastic work on ffdshow http://forum.slysoft.com/images/smilies/clap.gif

[yesgrey]

Just start, we will help you :D.
It would be a good help if you point me some good links to start digging...;) If you prefer, PM me, but I believe it's not very OT...

As you say, the detection code in the resize is crappy.
But works for the situation I have described above... so, why not putting also that "crappy" code in the presets selection? Later, it could be improved, but now it can be very useful to some people...:)

[haruhiko_yamagata]

It would be a good help if you point me some good links to start digging...;) If you prefer, PM me, but I believe it's not very OT...I don't know proper homepage as I learned C++ from a book. Read a book and then begin reading about DirectShow on MSDN, and finally begin reading code of ffdshow...
It's a long way, but if you enjoy, it's not too hard.

But works for the situation I have described above... so, why not putting also that "crappy" code in the presets selection? Later, it could be improved, but now it can be very useful to some people...:)
Maybe better than nothing. If I have time.

[haruhiko_yamagata]

BTW, do you think you might have time to look at the OzoneMP freezing situation some day?For the time being, no. Please don't repeat this.

should I ask Vincent Burel for more help to find out what's wrong?
No, I know what's wrong. Basically it's impossible to use winamp plugins from DirectShow filter.

and a slider to choose how blurry you want the subs would be awesome...
I don't have plan to implement this.

[ikarad]

When I see a DVD movie, subtitle function of ffdshow doesn't work if I use "open dvd" function of MPC-HC. To see subtitle with ffdshow when i see a dvd movie I must open .vob file if not subtitles aren't displayed.

[leeperry]

For the time being, no. Please don't repeat this.
No, I know what's wrong. Basically it's impossible to use winamp plugins from DirectShow filter.

I don't have plan to implement this.
well last time I asked you about the OzoneMP fix was on the 9th of November in PM(when Vincent Burel made that winamp2 debug plugin)...so 2 months ago, you said you'd see what you can do "when you have time".

same for the blurry subs issue, you told me a few weeks ago that you'd look at it "when you have time"...and now you say you won't implement it at all.

maybe in the future that'd be better to simply say "NO" to bugfixes/feature requests instead of "when I have time"...or maybe it was just a polite way to refuse that I dumbly overlooked http://forum.slysoft.com/images/smilies/doh.gif

I might try to ask Seb.26 for the OzoneMP fix if you don't mind telling me what the exact issue is....it works fine with FFX-4, why not OzoneMP :(

:thanks:

[tetsuox]

well last time I asked you about the OzoneMP fix was on the 9th of November in PM...so 2 months ago, you said you'd see what you can do "when you have time".

same for the blurry subs issue, you told me a few weeks ago that you'd look at it "when you have time"...and now you say you won't implement it at all.

maybe in the future that'd be better to say simply "NO" to bugfixes/feature requests instead of "when I have time"...or maybe it was just a polite way to refuse that I dumbly overlooked http://forum.slysoft.com/images/smilies/doh.gif
What if he says "No" but some time in the future he hypothetically fixes all the high priority problems, and adds high priority features, then the medium priority ones, and he suddenly has free time and inspiration to do what you request, you'll be accusing him of going back on his word again. What's the point?

This is an open source project with very few active developers who are doing a splendid job I might add, you can't expect them to prioritize your Ozone request, which I think less than 1% of ffdshow users even use.

You can always undertake a more active role, teach yourself C++ and study ffdshow yourself and help out if you want these features so much.

[clsid]

I think MPC-HC has code for detecting the active monitor.

But preset functionality should ideally also be adjusted to re-select a preset every X seconds. That would be useful when there are changes in the input (number of audio channels, video resolution) and output (screen res of active monitor).

For example with an extended desktop config, people may start a video on monitor 1 and drag it to monitor 2.

[leeperry]

you can't expect them to prioritize your Ozone request, which I think less than 1% of ffdshow users even use.
well many of my friends use OzoneMP in ffdshow if that's something you were worried about...this thing just sounds too good to be passed out :eek:

I've asked Vincent Burel for a debug winamp2 plugin coz Haruhiko said it would help to see why it's freezing when we open new files.

anyhow, I will bug Seb.26 for that OzoneMP fix if Haruhiko can tell me where the "glitch" is....Seb.26 is a friend of mine and he knows his C++ sh*t(being a professional coder and all)....it's just that he told me that the ffdshow audio code was a hell of a mess, so any pointer would be greatly appreciated http://forum.slysoft.com/images/smilies/agreed.gif

I think MPC-HC has code for detecting the active monitor.
very basic resolution condition would do you know :D
no need for realtime monitor detection IMHO.

[Inventive Software]

I can imagine that there are people that want to be able to configure them individually. So I vote against grouping.

Isn't there a hard limit in the number of codecs listed anyway?

[iSunrise]

Applied as rev. 2562:
+ UI Improvement: Normalization filter: max. amplification will only be applied after pressing "apply". (or OK)
Thanks a lot for fixing this.

[clsid]

Isn't there a hard limit in the number of codecs listed anyway?
Nope.

[Inventive Software]

OK, fair enough.

I have another "bug" to report. In de-interlacing, the kernel deinterlacers (blend and bob) are both broken as performance has gone completely to pot. Kernel bob used to be my favourite deinterlacer, now I can't use it cos it's not fast enough. What changed?

[EpsilonX]

I think MPC-HC has code for detecting the active monitor.

But preset functionality should ideally also be adjusted to re-select a preset every X seconds. That would be useful when there are changes in the input (number of audio channels, video resolution) and output (screen res of active monitor).

For example with an extended desktop config, people may start a video on monitor 1 and drag it to monitor 2.

There seems to be a little "bug" that prevents the video to be scaled correctly if we change the resize setting during playback...
For example, the screen resolution is 1680x1050, the resize is set at 1360x768...
When I switch the resize setting to "Screen resolution", the video will be resized to screen's resolution, but with the wrong aspect ratio...
This only happens when "Keep original aspect ratio" is chosen...
Is this an expected behavior..?

[Mixer73]

Hey guys,

Hope this is the right place to post this.

I just installed the x64 version (2547) but I already had 32bit version installed at that time. It was working really nicely under Vista 64bit.

After realising I had both installed, I uninstalled 32bit version and rebooted, and I don't think the 64bit version is working. When I play videos the performance is bad (I have xvid codec installed), and FFDShow settings don't seem to have any effect, plus I don't have the FFDShow icons for video or audio on the task bar.

Would installing 64bit version alongside 32bit version cause an improper installation? What's the best procedure for a complete uninstallation so I can fix the install?

Thanks for your help.

[tetsuox]

Hey guys,

Hope this is the right place to post this.

I just installed the x64 version (2547) but I already had 32bit version installed at that time. It was working really nicely under Vista 64bit.

After realising I had both installed, I uninstalled 32bit version and rebooted, and I don't think the 64bit version is working. When I play videos the performance is bad (I have xvid codec installed), and FFDShow settings don't seem to have any effect, plus I don't have the FFDShow icons for video or audio on the task bar.

Would installing 64bit version alongside 32bit version cause an improper installation? What's the best procedure for a complete uninstallation so I can fix the install?

Thanks for your help.

You can install both, I have both 32 and x64 bit installed on my system. I only use the x64 for testing purposes only. Also remember that if you want to use x64 version, your entire filter chain has to be x64 all the way to MPC-HC. Say if you open a video in MPC-HC32, it will auto load ffdshow32. Likewise for MPC-HC64.

As for changing the settings for ffdshow with both installed, say you wanted to change settings for ffdshow32, there would 2 copies of "Video Decoder Configuration" in your Start Menu. When you mouse over it, the 32bit one would show something like "rundll (C:\Windows\SysWOW64)" in the tooltip, clicking on this will open ffdshow video config for the 32bit version.

As for the x64 version, the tooltip will be "rundll (C:\Windows\system32)".

It also looks to me that you're not using MPC-HC x64, which is why the ffdshow systray icons aren't showing up after you installed the 32-bit version.

If you want to uninstall, just run the ffdshow uninstaller from the Start Menu, again there should be 2. Furthermore, there should also be 2 ffdshow folders, one under "C:\Program Files\ffdshow" for the x64 version, and one under "C:\Program Files (x86)\ffdshow" for the 32 bit version.

In any case, you should be able to just reinstall the x64 version, uninstall it, if you're missing the uninstaller. Then reinstall the 32-bit version and stick with that.

IMO stick to the 32-bit version only unless you have a good reason to use the x64 version. I have the x64 version of ffdshow installed for use with Windows Media Encoder x64.

You don't need to reboot, just make sure any applications that use ffdshow are closed.

[Leak]

I have another "bug" to report. In de-interlacing, the kernel deinterlacers (blend and bob) are both broken as performance has gone completely to pot. Kernel bob used to be my favourite deinterlacer, now I can't use it cos it's not fast enough. What changed?
ff_kernelDeint.dll is a separate Visual Studio project and is usually only recompiled once in a blue moon with Intel's compiler when anything in the Kernel Deint sources itself changes - which it hasn't for some time now.

So either something else in some other part of ffdshow changed recently that makes it run slow, or you're using a build/an installer where a ff_kernelDeint.dll compiled with debug settings was included instead of the ICL compiled one... :confused:

I'll try a recent build when I get home tonight - where did you get yours? xvidvideo.ru?

[haruhiko_yamagata]

When I see a DVD movie, subtitle function of ffdshow doesn't work if I use "open dvd" function of MPC-HC. To see subtitle with ffdshow when i see a dvd movie I must open .vob file if not subtitles aren't displayed.Media player classic, the old one, works for me.

Please ask in MPC-HC thread.

[albain]

It's easy if we ignore multiple monitor system. But the request is posted probably because there are multiple monitors.
It may be possible to get the resolution of the screen where the video window is placed, but at least it's hard. Patches welcome.

It is possible to get the resolution of the current screen, I added it in the resize filter "Resize to screen resolution". So this is not too difficult to implement to presets auto-loading section.

The following MS API is used to do this : GetSystemMetrics
But it works on the primary monitor (which is the one that will hold the video)

But what would be the benefit of this feature ?

[clsid]

There seems to be a little "bug" that prevents the video to be scaled correctly if we change the resize setting during playback...
For example, the screen resolution is 1680x1050, the resize is set at 1360x768...
When I switch the resize setting to "Screen resolution", the video will be resized to screen's resolution, but with the wrong aspect ratio...
This only happens when "Keep original aspect ratio" is chosen...
Is this an expected behavior..?
No, that seems wrong to me. But Haruhiko is the expert with regard to the resize implementation, so wait until he comments on this issue.

[tetsuo55]

there has been an interesting RV40(realvideo) commit to the ffdshow svn:

Revision 16419 - Directory Listing
Modified Sun Jan 4 01:36:11 2009 UTC (38 hours, 36 minutes ago) by cehoyos
Use H264 MMX chroma functions to accelerate RV40 decoding.

Patch by Mathieu Velten (matmaul A gmail)

Those interested should try a new build and see if that solves the random stuttering or at the very least lowers CPU%

[Leak]

The following MS API is used to do this : GetSystemMetrics
But it works on the primary monitor (which is the one that will hold the video)
Are you really sure about that? MPCs Direct3D renderer doesn't really care which screen is the primary one - it'll go fullscreen without problems on any monitor...

np: Other People's Children - Suicide Common (A Number Of Small Things (Disc 2))

[Inventive Software]

ff_kernelDeint.dll is a separate Visual Studio project and is usually only recompiled once in a blue moon with Intel's compiler when anything in the Kernel Deint sources itself changes - which it hasn't for some time now.

So either something else in some other part of ffdshow changed recently that makes it run slow, or you're using a build/an installer where a ff_kernelDeint.dll compiled with debug settings was included instead of the ICL compiled one... :confused:

I'll try a recent build when I get home tonight - where did you get yours? xvidvideo.ru?

clsid's builds on the SF page. Something from about 3-4 months ago works, but I can't remember which revision. Something in the past month or 2 has broken it I think.

[STaRGaZeR]

clsid's builds on the SF page. Something from about 3-4 months ago works, but I can't remember which revision. Something in the past month or 2 has broken it I think.

You can try xvidvideo.ru builds one by one to find where the problem is, thus localizing the problem if there is any.

[clsid]

SF also has a few hundred old builds:
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=436746

[yesgrey]

But what would be the benefit of this feature ?
Well, I want to use ffdshow to correct the primaries of my display.
See this (http://forum.doom9.org/showpost.php?p=1227911&postcount=5868) post a few pages back.

Currently, I have to use an Avisynth filter for it, but I already suggested the addition of the 3D LUT to ffdshow.
And each display have different primaries, so, for each display, I have to use a different 3D LUT. That's why I need the preset selection by the screen resolution... or I have to change it manually each time I switch between my monitor and my projector...:(

[STaRGaZeR]

One thing I've noticed in the installer:

There are several formats that have two possible decoders, like MPEG-2 for example. However, most of these formats don't have two suboptions in the installer, they're either checked or unchecked. This means that if for example you select wmv9 decoder for WMV3/9 and then you install a new build, as the installer doesn't have an option for wmv9 it defaults to "checked". And when you actually look at WMV3/9 in the new installed build, it's configured as libavcodec, the first choice. There are quite a few formats affected by this, like Xvid, WMV1/7, WMV2/8, WMV3/9,etc.

Also both MPEG-2 decoders seek perfectly now, libmpeg2 a bit faster with the recent changes.

[Snowknight26]

Seeking using libavcodec on H.264 videos (r2583) sometimes gives horrible desync and crazily fluctuating frames per second till about 5-10 seconds in.. when it levels out and goes back to being synchronized.