ffdshow tryouts project: Discussion & Development [Archive] - Page 275

RealSnoopyDog

24th June 2011, 10:06

Just a positive feedback for the new version 3904: On my notebook, with a nVidia 1600M onboard, i never could use the DXVA decoder for H.264 playback because it is stuttering for some reason. So i need to use the "non DXVA" decoder. On all previous builds up to 3892 i had 90-99% CPU load when playing back some material in full HD 1920x1080. With the new build 3904, i constantly have 75-80% CPU load with the same material! This is a great improvement. Just had no time to check, if the artefacts with H.264 DXVA are gone now.

clsid

24th June 2011, 14:12

Good to hear. Perhaps you were using libavcodec instead of ffmpeg-mt in the past? That would explain the performance difference.

fastplayer

24th June 2011, 18:06

@clsid:
The "ffmpeg-mt" reference in the tooltip for "Number of decoding threads" (under "Decoder options") is obsolete.

I was wondering what the long-term plans are for liba52 and libdts. If we're gonna remove them at some point (as discussed a few months ago), how about switching to libavcodec as the new default for now and see what it all breaks?
This is under the assumption that libavcodec >= liba52/libdts in terms of features and stability, of course.

clsid

24th June 2011, 18:55

I will update that tooltip.

Here is at least one reason to keep libdts:
http://forum.doom9.org/showthread.php?p=1482937#post1482937

I think we should first release a new official stable, and after that change the default for AC3.

fastplayer

24th June 2011, 18:59

Here is at least one reason to keep libdts:
http://forum.doom9.org/showthread.php?p=1482937#post1482937
Ouch. I remember trying that sample, too.

I think we should first release a new official stable, and after that change the default for AC3.
I agree. Let's see how the current builds act in the wild and then go from there.

fastplayer

24th June 2011, 19:27

While we're talking about a new stable release, here's the current changelog:
* Added hardware-accelerated DXVA decoders for H.264 and VC-1.
/* Added experimental multithreading support for VP3, Theora, HuffYUV, and MPEG-4.*/
* Added support for bitstreaming E-AC3, DTS-HD, and TrueHD.
* Added support for Blu-ray subtitles (PGS).
* Added VP8/WebM support.
* Added partial support for Cook audio.
* Updated FFmpeg/Libav library. Brings many fixes and improvements.
* Removed several encoders. The interface that ffdshow provided for these encoding libraries was unmaintained, outdated, and buggy. The ffdshow development team recommends using the official encoders instead (such as x264VFW and Xvid). Those are always up-to-date, stable, and fully functional.
/* Improved multithreaded H.264 decoder (ffmpeg-mt). Used now by default on multi-core CPUs.*/
* Improved (performance of) Deband filter. Now also works properly in 64-bit builds.
* Floating point output for libavcodec MP1/2/3, AC3, E-AC3, DTS, Vorbis, and AAC decoder.
* Adjusted colorspace priority lists.
* Removed some obsolete colorspaces from output settings in ffdshow video decoder.
* "Set interlaced flags in output media type" no longer disables YV12 output.
* High quality YV12/NV12/YUY2 to RGB32 conversion is now enabled by default.
* The RAW video decoder now stores its preset settings separately from the regular video decoder.
* Added an option for giving embedded subtitles priority over external subtitle files.
* Lots of subtitle-related fixes and improvements.
* Some S/PDIF-related fixes.
* Updated application blacklist and whitelist.
* Updated libsamplerate to version 0.1.7.
* Updated RAR library to version 4.0.
* libavcodec.dll has been renamed to ffmpeg.dll.
* Removed ffmpeg-mt which has been integrated into libavcodec.
* Removed mp3lib, libtheora, libmplayer, realaac, and tremor.
* Code cleanup and other minor improvements.

PetitDragon

25th June 2011, 04:08

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

Hi clsid,

I found all revisions that integrated ffmpeg-mt into libavcodec have problem to deinterlace (bob) h-264 1080i content (big performance hit). Before integration ffmpeg-mt has no such problem. Libavcodec in rev. 3886 deinterlaces fine too.

Please check.

Atak_Snajpera

25th June 2011, 10:24

I did a tests on my Q6600@3ghz with .mts (AVCHD 24mbps 1920x1080i50)
1) without Yadif double framerate I have cpu utilization at ~42 %
2) with Yadif double framerate i have cpu utilization at ~62 %

I also tested with rev. 3886 (ffmpeg-mt) and results are almost identical.

PetitDragon

25th June 2011, 12:55

Hi clsid and Atak_Snajpera,

Sorry I forgot to memtion the deinterlacing problem is for HW deinterlacing (that set in the "Output" menu), not for yadif or other SW deinterlacer.

clsid

25th June 2011, 14:55

JEEB

25th June 2011, 15:17

I was wondering what the long-term plans are for liba52 and libdts. If we're gonna remove them at some point (as discussed a few months ago), how about switching to libavcodec as the new default for now and see what it all breaks?
This is under the assumption that libavcodec >= liba52/libdts in terms of features and stability, of course.
I personally think the libavcodec decoders are more upkept and at least on the level of the specific decoding libraries.

We tested the libavcodec option at CCCP some time ago, but unfortunately it seemed to bork DTS-ES in -tryouts (LAVAudio worked fine).

No other problems were reported during the (relatively short) testing period.

clsid

25th June 2011, 15:38

Might be a bug in the audio parsing code of ffdshow. You could poke around a bit in there.

me7

25th June 2011, 15:57

Same situation as with H.264 10-bit, it requires support for additional colorspaces in ffdshow.

Is 10-bit support planned for the near future? AFAIK libav already supports it.
I don't mean to rush anybody, just curious when I can start to make use of the additional efficiency x264 gains that way.

mark0077

25th June 2011, 16:19

Guys, when using things like avisynth frame interpolation in ffdshow, is it upto ffdshow or avisynth to correctly set the pin out details.

I frame interpolate everything to 50.00fps using avisynth, yet madVR video renderer reports "movie 23.974 fps (says source filter)". ffdshow pin out also says the following, rather than the correct output rate of 50.00 fps

Filter : ffdshow Video Decoder - CLSID : {04FE9017-F873-410E-871E-AB91661A4EF7}

- Connected to:

CLSID: {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
Filter: madVR Renderer
Pin: Input

- Connection media type:

Video: YV12 2048x1080 (16:9) 23.97fps

Just bumping one more time guys, it seems to me like it might be easy to fix, and seems more cosmetic than anything else, but would anyone suggest what I should do regarding this issue, should I post it as an official bug report or would you know how to fix clsid? I actually notice today, even with input of 29.97 interlaced into lavcuvid, output as 59.94 fps to ffdshow, ffdshows pin in says 59.94 in, 29.97 out so it seems to be just outputting some value its reading from somewhere higher up in the stream rather than the correct value..

Eliminateur

25th June 2011, 17:39

latest x64 revision from xhmikosr crashes mpc on EVERY H264 video in win7 x64

ffdshow_rev3911_20110624_xhmikosr_x64.exe

i've updated mpc-hc to latest and problem persists, not using DXVA and RGB32 output no other filters enabled.

now i've downgraded to my old version and the problem persists :S, something in latest ffdshow has broken my system

edit2: old non-h264 vids work fine i've tried full HD and HD h264 vids to no avail they all crash
i'm also getting render pin failures on videos i could play before(only decode audio):
Media Type 0:
--------------------------
Video: CCV1 1920x1080 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31564343-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 171

i've checked decode, codecs settings and everything is the same as i had before

PetitDragon

25th June 2011, 17:47

I don't see how the ffmpeg changes could have any effect on the HW deinterlacing stuff. And when you say performance hit, are you talking about CPU or GPU performance? It more likely seems some kind of driver issue.

Hi clsid (attention to Atak_Snajpera),

I did the testing for h-264 1080i deinterlacing problem again:

1, For 1080i50 content

With libavcodec and ffmpeg-mt in Rev. 3886 (before integration), it plays fine at steady 50fps using whether yadif (FD) or HW bob deinterlacer.

With libavcodec integrated with ffmpeg-mt after Rev. 3886, it plays fine too at steady 50fps using whether yadif (FD) or HW bob deinterlacer.

2, For 1080i60 content

With libavcodec and ffmpeg-mt in Rev. 3886 (before integration), it plays fine at steady 60fps using whether yadif (FD) or HW bob deinterlacer.

With libavcodec integrated with ffmpeg-mt after Rev. 3886, it plays stutterly at 4x-5x fps keeping frame dropping using whether yadif (FD) or HW bob deinterlacer.
------------

So it seems the new libavcodec integrated with ffmpeg-mt has problem to deal with h-264 1080i60 content. All tests were done with ffdshow x86 ICL12 versions, and the NV video driver was always the same during tests. I am wondering why the ffmpeg changes could have any effect on the deinterlacing stuff too.

fastplayer

25th June 2011, 18:22

@PetitDragon:
Can you please test 1080i60 with the regular (non-ICL) builds?
Try this one:
http://xhmikosr.1f0.de/ffdshow/ffdshow_rev3911_20110624_xhmikosr.exe

PetitDragon

25th June 2011, 18:29

@PetitDragon:
Can you please test 1080i60 with the regular (non-ICL) builds?
Try this one:
http://xhmikosr.1f0.de/ffdshow/ffdshow_rev3911_20110624_xhmikosr.exe

With the rev. you suggested, it plays stutterly at 4x-5x fps keeping frame dropping using whether yadif (FD) or HW bob deinterlacer. Same problem.

fastplayer

25th June 2011, 18:37

OK, that rules out some Intel compiler quirks.
Another thing you might try is limit the number of cores/threads under "Decoder options". If you're on quad-core try limit it to 3 or 2 decoding threads.
Other than that, I'm out of ideas... :(

PetitDragon

25th June 2011, 19:08

Hi fastplayer,

Unfortunately changing the number of cores/threads under "Decoder options" still doesn't help. Thanks anyway.

It seems the new integrated libavcodec switches to single thread mode when decoding H-264 interlaced content?! I guess.

fastplayer

25th June 2011, 19:20

I don't think so because your 1080i50 results are totally fine.
Have you checked CPU load during playback of 1080i60 content? Does it get close to 100% on any one of your CPU's cores?
I hope clsid has another idea. :)

Eliminateur

25th June 2011, 21:28

ok, more testing(bear in mind 3911 broke ffmpeg-mt for me even after downgrading):
mpc-hc x64 3262
ffdshow r3755 x64 msvc2010:
H264 SD & HD
*) ffmpeg MT: reproduced ~0.2S and crashes
*) libavcodec: works fine
other codecs work fine(libavcodec)

ffdshow r3911 x64 msvc2010:
H264 SD/HD:
*) pin fails to render or mpc-hc crashes
Other codecs:
*) mpc-hc crash
only internal mpc-hc filter works
only ffd audio works

any ideas...... i'm still unable to play anything as even a downgrade is broken now.....

should i uninstall and delete folders and then reinstall to make this work?
also, is there a way to export ONLY one part of the config?, i want to export with ffdshow audio config for backup as i a use a complex custom output matrix that's a pain to recreate.

edit1:
did a full uninstall and then reinstall of 3911 resetting settings and everything is still broken

clsid

26th June 2011, 00:32

@Eliminateur,
Please try my x64 build. Crashes might be toolchain related.

Eliminateur

26th June 2011, 01:03

@Eliminateur,
Please try my x64 build. Crashes might be toolchain related.
downloaded r3904 x64 from your sig link, everything working as expected!
much smooches to you clsid! :thanks:

@xhmikosr: there's something in your x64 build that's chrashing stuff on my pc

Atak_Snajpera

26th June 2011, 12:24

@PetitDragon
Do you have NV12 selected?
http://www.picamatic.com/show/2011/06/26/03/24/7653322_591x503.png

I did more tests on my second machine with Q8200@2,8Ghz + Radeon 4850 (Ati Catalyst 11.2) + Windows 7 x64 +ffdshow_rev3904_20110623_clsid.exe

1920x1080i50 (AVCHD 24mbps) with NV12 checked (GPU deinterlacing) cpu utilization is ~21%
1920x1080i50 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and no yadif cpu utilization is ~28%
1920x1080i50 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and yadif (double framerate) cpu utilization is ~48%

1920x1080i60 (AVCHD 24mbps) with NV12 checked (GPU deinterlacing) cpu utilization is ~23%
1920x1080i60 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and no yadif cpu utilization is ~29%
1920x1080i60 (AVCHD 24mbps) with NV12 unchecked (RGB32 used) and yadif (double framerate) cpu utilization is ~51%

PetitDragon

26th June 2011, 13:13

@Atak_Snajpera

Yeah I tried both yv12 and nv12 outputs. When playing H-264 1080i60 content it keeps frame dropping with ffdshow_rev3904_20110623_clsid.exe. Switching to rev. 3886 it plays rock solid at steady 60fps. Both tests the cpu utilization is ~23%, like yours.

26th June 2011, 13:15

There was a discussion about postprocessing filter more that year ago:
Is it normal that the postprocessing filter is applicable only to the following codecs :
Raw codecs, then :
case CODEC_ID_MPEG1VIDEO:
case CODEC_ID_MPEG2VIDEO:
case CODEC_ID_LIBMPEG2:
case CODEC_ID_MPEG4:
case CODEC_ID_MSMPEG4V1:
case CODEC_ID_MSMPEG4V2:
case CODEC_ID_MSMPEG4V3:
case CODEC_ID_H263:
case CODEC_ID_SVQ1:
case CODEC_ID_FLV1:
case CODEC_ID_INDEO2:
case CODEC_ID_INDEO3:
case CODEC_ID_XVID4:
case CODEC_ID_MJPEG:
case CODEC_ID_MJPEGB:
case CODEC_ID_MSVIDEO1:
case CODEC_ID_CINEPAK:
case CODEC_ID_VP5:
case CODEC_ID_VP6:
case CODEC_ID_VP6F:
For example it is disabled for H264 formats
and now I have small question: why PP disabled for WMV formats? I've got several "blocky" wmv videos, and thinking that PP might help in this case

andybkma

28th June 2011, 03:13

Hi, dumb question... what is the difference between icl12 and VS2010 builds as displayed on XvidVideo.RU page? I have both XP and Windows 7 (both 32-bit) machines. Is icl12 or VS2010 build preferable over the other? Reason I ask is because I don't see those types of builds on the Sourceforge page (https://sourceforge.net/projects/ffdshow-tryout/files/)

Thank you kindly...

fastplayer

28th June 2011, 08:09

Read the FAQ:
http://ffdshow-tryout.sourceforge.net/wiki/faq

clsid

28th June 2011, 13:54

Generic = VS2010 (VS2008 in the past)

ICL builds have little benefit for most users.

fastplayer

28th June 2011, 13:59

@clsid:
Can you release rev3912 builds as release candidates? Or do you wanna wait and choose a different rev?

djonline

28th June 2011, 16:28

How to enable FFV1 with slices ?

clsid

28th June 2011, 16:39

For decoding: goes automatic.
For encoding: there doesn't seem to be an option to control it.

arestarh

28th June 2011, 17:13

Hello!

In last revisions of ffdshow hints in configure dialog don't appear (when I call configure dialog through link in Start menu), I see only following hints:
http://i047.radikal.ru/1106/2b/0a79637655f0t.jpg (http://radikal.ru/F/i047.radikal.ru/1106/2b/0a79637655f0.jpg.html)

But when other application call ffdshow.ax, configure dialog looks like this:
http://i006.radikal.ru/1106/4e/e1e76d27cf81t.jpg (http://radikal.ru/F/i006.radikal.ru/1106/4e/e1e76d27cf81.jpg.html)

Windows XP SP3, ffdshow build 3912.
Maybe it's problem at my side. I don't know for sure.

fastplayer

28th June 2011, 17:25

Confirmed on XP SP3 (Win7 is OK). Tooltips don't appear when calling ffdshow's configuration dialogs via start menu shortcuts.

Edit: Narrowed it down to rev3897-->tooltips OK, rev3899-->tooltips broken.
Edit#2: It's not just the tooltips but obviously the manifests are broken too for XP SP3.

clsid

28th June 2011, 18:57

Manifests are installed again in 3913. Embedded one doesn't work properly on XP. Will probably also fix the tooltips.

arestarh

30th June 2011, 12:19

Manifests are installed again in 3913. Embedded one doesn't work properly on XP. Will probably also fix the tooltips.
It helped. Thanks.

clsid
Updated Russian translation:
http://www.mediafire.com/?38zgb35hkur8f4g

Snowknight26

2nd July 2011, 20:05

More Fraps regressions (tested with r3914):

FPS1 -> RGB32 has inverted chroma planes.
FPS1 -> YV12/NV12 has a 16 pixel-wide bright bar on the very right side of the video.
FPS1 -> YUV2/UYVY is fine.

Sample: http://stfcc.org/misc/ffplay_fraps_video_stutter_with_audio.avi

3rd July 2011, 00:16

There was a discussion about postprocessing filter more that year ago:
and now I have small question: why PP disabled for WMV formats? I've got several "blocky" wmv videos, and thinking that PP might help in this case

Em, bump?

clsid

3rd July 2011, 00:23

Hypernova

3rd July 2011, 07:35

Hi,

So, from my skimming the past 10 pages, audio un-sync problem with multithread is still a known problem, correct? In my case it only happen with avi. H264 in mkv works fine for me.

clsid

3rd July 2011, 12:08

It was not known in case of H.264. But if it also happens, then that sucks. A good reason to avoid H.264 in AVI.

Atak_Snajpera

3rd July 2011, 12:56

In my case it only happen with avi.
Smart people don't use ancient avi (http://en.wikipedia.org/wiki/Audio_Video_Interleave#Limitations) container with h.264 stream. See also this http://en.wikipedia.org/wiki/Comparison_of_container_formats#Video_formats_supported

clsid

3rd July 2011, 13:38

Does anyone have a sample where the sync issue is really noticeable?

I can limit the number of threads in case of AVI to a number where the sync issue isn't noticeable anymore.

Hypernova

3rd July 2011, 19:13

Does anyone have a sample where the sync issue is really noticeable?

I can limit the number of threads in case of AVI to a number where the sync issue isn't noticeable anymore.

I have at least two examples of h264 in AVIs that has noticable lag (~500ms). It's quite old anime fansubs, Cyber Formula Double-one by Ayu and Akazukin ChaCha by the group I don't know the name. If you need help to get a hold of that please let me know. Noted that I do notice the lag even in 2 threads (out of 8) though.

Smart people don't use ancient avi (http://en.wikipedia.org/wiki/Audio_Video_Interleave#Limitations) container with h.264 stream. See also this http://en.wikipedia.org/wiki/Comparison_of_container_formats#Video_formats_supported

I'm not the one who create the file, so it's not really a choice on my part.