ffdshow tryouts project: Discussion & Development

[Sebastiii]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

Hi clsid :)

I can reproduce this issue in graphstudio and mediaportal too.
With different source splitter (Haali/LAV/MPC Matroska), i made my test on mkv.

On the all combination (all crash when i remove FFDShow DXVA):
http://dl.dropbox.com/u/10536084/FFDShow_DXVACrash/Crash1_DXVA_FFDShow.jpg
http://dl.dropbox.com/u/10536084/FFDShow_DXVACrash/Crash2_DXVA_FFDShow.jpg
http://dl.dropbox.com/u/10536084/FFDShow_DXVACrash/Crash3_DXVA_FFDShow.jpg

I do like Hoborg, set EVR Renderer as High merit to be the one loaded first.

If we disconnect output pin of FFDShow DXVA before remove filter = no crash :)

This is strange that you can't get it.
Thanks.

[hoborg]

Hi.
I noticed there is an ugly pixelation on some h.264 video streams if FFDShow DXVA decoder is in use.
This pixelation wasn't here before, so i did some research. I tracked down that the relase 3883 introduce the pixelation, becouse 3882 is ok.
Here is video sample (http://www16.zippyshare.com/v/37666086/file.html).
Normal FFDshow video decoder is not affected.

[clsid]

Sample link is broken.

[hoborg]

Sample link is broken.

Sample link is fixed now, sorry...

[Sven75]

The following CVID in MOV container is still not working with current LAVFilter and ffdShow:

http://www.mediafire.com/?1nr37wujo5g8c65

See this posting (http://forum.doom9.org/showthread.php?p=1509376#post1509376) for more details.

[clsid]

@hoborg
DXVA decoding issue is fixed.

@Sven75
Decoding with the Cinepak VFW codec of Windows is fine too.
I don't know what is wrong, so you have to ask nevcariel to check what changed in ffmpeg.

[hoborg]

@hoborg
DXVA decoding issue is fixed.

:thanks:

[JEEB]

libavcodec/h261.c
libavcodec/h261dec.c
libavcodec/h261dec.c: In function 'h261_decode_frame':
libavcodec/h261dec.c:623:1: error: 'Picture' has no member named 'pict_type'
libavcodec/h261dec.c:623:1: error: 'Picture' has no member named 'pict_type'
libavcodec/h261dec.c:624:1: error: 'Picture' has no member named 'pict_type'
make: *** [../../obj/MinGW32/ffmpeg/libavcodec/h261dec.o] Error 1
It seems like I cannot build a debug ffmpeg.dll at the moment, can anyone replicate this (r3936)? Normal compilation works fine.

[Dstruct]

Some ffdshow crash that I'm getting in VirtualDub:

VirtualDub crash report -- build 34610 (release)
--------------------------------------

Disassembly:
6d1b0e00: 140f adc al, 0fh
6d1b0e02: 85f9 test ecx, edi
6d1b0e04: fd std
6d1b0e05: ff db 0ffh
6d1b0e06: ff83c4205b5e inc dword ptr [ebx+5e5b20c4]
6d1b0e0c: 5f pop edi
6d1b0e0d: 5d pop ebp
6d1b0e0e: c3 ret
6d1b0e0f: 90 nop
6d1b0e10: 55 push ebp
6d1b0e11: 57 push edi
6d1b0e12: bf08000000 mov edi, 00000008
6d1b0e17: 56 push esi
6d1b0e18: 89fe mov esi, edi
6d1b0e1a: 53 push ebx
6d1b0e1b: 83ec24 sub esp, 24h
6d1b0e1e: 8b5c244c mov ebx, [esp+4ch]
6d1b0e22: 8b6c2448 mov ebp, [esp+48h]
6d1b0e26: 8b4c2438 mov ecx, [esp+38h]
6d1b0e2a: 8b542440 mov edx, [esp+40h]
6d1b0e2e: 29df sub edi, ebx
6d1b0e30: 29ee sub esi, ebp
6d1b0e32: 89f8 mov eax, edi
6d1b0e34: 0fafc6 imul eax, esi
6d1b0e37: 0faffd imul edi, ebp
6d1b0e3a: 0faff3 imul esi, ebx
6d1b0e3d: 0fafdd imul ebx, ebp
6d1b0e40: 8b6c2444 mov ebp, [esp+44h]
6d1b0e44: 89442408 mov [esp+08h], eax
6d1b0e48: 897c240c mov [esp+0ch], edi
6d1b0e4c: 89742410 mov [esp+10h], esi
6d1b0e50: 85ed test ebp, ebp
6d1b0e52: 895c2414 mov [esp+14h], ebx
6d1b0e56: 0f8ea7020000 jle 6d1b1103
6d1b0e5c: 8b44243c mov eax, [esp+3ch]
6d1b0e60: 89d6 mov esi, edx
6d1b0e62: c7442418000000 mov dword ptr [esp+18h], 00000000
00
6d1b0e6a: f7de neg esi
6d1b0e6c: 8d742600 lea esi, [esi+00h]
6d1b0e70: 0fb638 movzx edi, byte ptr [eax]
6d1b0e73: 0faf7c2408 imul edi, [esp+08h]
6d1b0e78: 897c2404 mov [esp+04h], edi
6d1b0e7c: 0fb67801 movzx edi, byte ptr [eax+01h]
6d1b0e80: 0faf7c240c imul edi, [esp+0ch]
6d1b0e85: 897c241c mov [esp+1ch], edi
6d1b0e89: 0fb66c1001 movzx ebp, byte ptr [eax+edx+01h] <-- FAULT
6d1b0e8e: 01d0 add eax, edx
6d1b0e90: 8d1c30 lea ebx, [eax+esi]
6d1b0e93: 891c24 mov [esp], ebx
6d1b0e96: 0fb639 movzx edi, byte ptr [ecx]
6d1b0e99: 0faf6c2414 imul ebp, [esp+14h]
6d1b0e9e: 897c2420 mov [esp+20h], edi
6d1b0ea2: 0fb63c13 movzx edi, byte ptr [ebx+edx]
6d1b0ea6: 0faf7c2410 imul edi, [esp+10h]
6d1b0eab: 8d7c3d1c lea edi, [ebp+edi+1ch]
6d1b0eaf: 8b6c2420 mov ebp, [esp+20h]
6d1b0eb3: 037c2404 add edi, [esp+04h]
6d1b0eb7: 037c241c add edi, [esp+1ch]
6d1b0ebb: c1ff06 sar edi, 06h
6d1b0ebe: 8d7c3d01 lea edi, [ebp+edi+01h]
6d1b0ec2: d1ff sar edi, 1
6d1b0ec4: 89fb mov ebx, edi
6d1b0ec6: 0fb67901 movzx edi, byte ptr [ecx+01h]
6d1b0eca: 8819 mov [ecx], bl
6d1b0ecc: 8b1c24 mov ebx, [esp]
6d1b0ecf: 897c2404 mov [esp+04h], edi
6d1b0ed3: 0fb66c1302 movzx ebp, byte ptr [ebx+edx+02h]
6d1b0ed8: 0fb67c1301 movzx edi, byte ptr [ebx+edx+01h]
6d1b0edd: 0faf6c2414 imul ebp, [esp+14h]
6d1b0ee2: 0faf7c2410 imul edi, [esp+10h]
6d1b0ee7: 8d7c3d1c lea edi, [ebp+edi+1ch]
6d1b0eeb: 0fb66c3001 movzx ebp, byte ptr [eax+esi+01h]
6d1b0ef0: 0faf6c2408 imul ebp, [esp+08h]
6d1b0ef5: 8d2c2f lea ebp, [edi+ebp]
6d1b0ef8: 0fb67c3002 movzx edi, byte ptr [eax+esi+02h]
6d1b0efd: 0f db 0fh
6d1b0efe: af scasd
6d1b0eff: 7c db 7ch

Built on Althena on Sat Jun 18 14:40:53 2011 using compiler version 1400

Windows 5.1 (Windows XP x86 build 2600) [Service Pack 3]
Memory status: virtual free 1942M/2048M, commit limit 4967M, physical total 2046M

EAX = 02a9ce50
EBX = 00000081
ECX = 01d75ed0
EDX = 000001b0
EBP = 0000205c
ESI = fffffe50
EDI = 00000000
ESP = 0012f6e8
EIP = 6d1b0e89
EFLAGS = 00010296
FPUCW = ffff027f
FPUTW = ffffaaaa

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'ffmpeg'...

...reading address 02A9D001.

Pointer dumps:

EAX 02a9ce50: 81818181 81818181 81818181 81818181 83838383 83838383 83838383 83838383
ECX 01d75ed0: 81818181 81818181 81818181 81818181 83838383 83838383 83838383 83838383
ESP 0012f6e8: 02a9cca0 00002040 00000040 00000000 00000000 00000000 00000007 00000000
0012f708: 00000081 01c962a0 00000000 01cb25c0 00000000 6d1a29b2 01d75300 02a9c280
0012f728: 000001b0 00000008 00000000 00000000 00000000 fffff4c4 00000000 fffff884
0012f748: 00000000 00000000 00000000 00000000 000002c0 01d160e0 00006428 000002c0

Thread call stack:
6d1b0e89: ffmpeg!av_vc1_decode_frame [6d000000+1ade00+3089]
6d1ab778: ffmpeg!avcodec_default_get_buffer [6d000000+19cb70+ec08]
016dcde0: ffdshow!configureEnc [01590000+1013b0+4ba30]
016dcd20: ffdshow!configureEnc [01590000+1013b0+4b970]
6d2204ef: ffmpeg!av_vc1_decode_frame [6d000000+1ade00+726ef]
6d147a8f: ffmpeg!av_h264_decode_frame [6d000000+a8b50+9ef3f]
6d078f29: ffmpeg!avcodec_get_encoder_info [6d000000+71030+7ef9]
6d1ad0c8: ffmpeg!avcodec_default_get_buffer [6d000000+19cb70+10558]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c92019b: ntdll!RtlAllocateHeap [7c910000+100c4+d7]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c92019b: ntdll!RtlAllocateHeap [7c910000+100c4+d7]
7c9201db: ntdll!RtlAllocateHeap [7c910000+100c4+117]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c920222: ntdll!RtlAllocateHeap [7c910000+100c4+15e]
7c92019b: ntdll!RtlAllocateHeap [7c910000+100c4+d7]
7c9201db: ntdll!RtlAllocateHeap [7c910000+100c4+117]
6d19c421: ffmpeg!avcodec_decode_video2 [6d000000+19c390+91]
017be45c: ffdshow!configureEnc [01590000+1013b0+12d0ac]
016d57f8: ffdshow!configureEnc [01590000+1013b0+44448]
7e383416: USER32!EditWndProc [7e360000+23000+416]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
7c9200b8: ntdll!RtlFreeHeap [7c910000+ff2d+18b]
7c920041: ntdll!RtlFreeHeap [7c910000+ff2d+114]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
017cbd66: ffdshow!DllGetClassObject [01590000+236d60+5006]
7c9201db: ntdll!RtlAllocateHeap [7c910000+100c4+117]
017cec6a: ffdshow!DllGetClassObject [01590000+236d60+7f0a]
017bee3a: ffdshow!configureEnc [01590000+1013b0+12da8a]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
017bf071: ffdshow!configureEnc [01590000+1013b0+12dcc1]
7c92005d: ntdll!RtlFreeHeap [7c910000+ff2d+130]
017cbd66: ffdshow!DllGetClassObject [01590000+236d60+5006]
017bf1dd: ffdshow!configureEnc [01590000+1013b0+12de2d]
00c52ed1: ff_vfw!DriverProc [00c50000+2c40+291]
75ec1938: MSVFW32!ICSendMessage [75ec0000+190d+2b]
75ec4df4: MSVFW32!ICDecompress [75ec0000+4db7+3d]
10005d0a: WMV!VDGetPluginInfo [10000000+4010+1cfa]
10005ed2: WMV!VDGetPluginInfo [10000000+4010+1ec2]
004eb8c4: VDVideoSourcePlugin::streamGetFrame()
0043bdc0: VDFilterFrameVideoSource::RunRequests()
00437965: VDFilterAccelUploader::RunRequests()
00447af2: FilterSystem::Run()
0046ff78: VDProject::UpdateFrame()
7e36882a: USER32!GetDC [7e360000+86c7+163]
7e3689cd: USER32!GetWindowLongW [7e360000+88a6+127]
7e3689ea: USER32!GetWindowLongW [7e360000+88a6+144]
7e37a43b: USER32!PeekMessageA [7e360000+1a340+fb]
00472ba3: VDProject::Tick()
0045facc: WinMain@16()
005e2df6: __tmainCRTStartup()
7c817077: kernel32!RegisterWaitForInputIdle [7c800000+1702e+49]

-- End of report

VirtualDub 1.10.1-test11
fccHandler WMV Plugin 2.5 for VirtualDub
ffdshow tryouts 1.1.3919


Crashing file example:

General
Format : Windows Media
File size : 335 MiB
Duration : 30mn 55s
Overall bit rate mode : Constant
Overall bit rate : 1 514 Kbps
Maximum Overall bit rate : 1 612 Kbps
Encoded date : UTC 2011-07-06 20:54:49.364

Video
ID : 2
Format : VC-1
Format profile : AP@L1
Codec ID : WVC1
Codec ID/Hint : Microsoft
Description of the codec : VC-1 - VC-1 Advanced Profile
Duration : 30mn 55s
Bit rate mode : Constant
Bit rate : 1 500 Kbps
Width : 852 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.122
Stream size : 332 MiB (99%)
Language : English (US)

Audio
ID : 1
Format : WMA
Format version : Version 2
Codec ID : 161
Codec ID/Info : Windows Media Audio
Description of the codec : Windows Media Audio 9.2 - 96 kbps, 44 kHz, stereo 2-pass CBR
Duration : 30mn 55s
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 21.2 MiB (6%)
Language : English (US)

[clsid]

Does it also crash in DirectShow?
I doubt I can fix it, but please post a sample file anyway.

[Dstruct]

Does it also crash in DirectShow?

Doesn't seem to crash in MPC-HC + ffdshow.


I doubt I can fix it, but please post a sample file anyway.

I'll send you a link when uploaded ....

[god_md5]

ffdshow_rev3933_20110712_clsid.exe

問題簽章:
問題事件名稱: APPCRASH
應用程式名稱: mpc-hc.exe
應用程式版本: 1.5.2.3314
應用程式時間戳記: 4e110c47
錯誤模組名稱: ffmpeg.dll
錯誤模組版本: 0.0.0.0
錯誤模組時間戳記: 4e1b9114
例外狀況代碼: c0000005
例外狀況位移: 0024e3a0
作業系統版本: 6.1.7601.2.1.0.256.1
地區設定識別碼: 3076
其他資訊 1: 0a9e
其他資訊 2: 0a9e372d3b4ad19135b953a78882e789
其他資訊 3: 0a9e
其他資訊 4: 0a9e372d3b4ad19135b953a78882e789

[clsid]

Need more info. You did not even mention what kind of file it is.

If it only crashes with a particular file, then I need a sample.

[Dstruct]

Doesn't seem to crash in MPC-HC + ffdshow.




I'll send you a link when uploaded ....

Upload done!

[alexins]

Need more info. You did not even mention what kind of file it is.

If it only crashes with a particular file, then I need a sample.

Hi! This happens when the video is done through NV12. When NV12, disabled, everything works without errors. I got it going on on any video files (avi, mkv, mpg, ts, ...). ffdshow x86/x64 rev. 3932, 3933, 3934, 3935, 3936, 3937.

[clsid]

Fixed

[_xxl]

I can't compile with MinGW GCC 4.3.3. What version is supported?
http://i55.tinypic.com/2v8ob53.jpg

[clsid]

You need at least 4.4.0, or enable SSE.

[_xxl]

Can you please provide a link all in one for MinGW GCC?

[JEEB]

Can you please provide a link all in one for MinGW GCC?Use xhmikosr (http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=)'s base full msys/mingw package? And then get a 4.5.3 mingw package from either komisar or xvidvideo.ru (and use /etc/fstab to make another folder be mounted as /mingw) >_>

...or just use the included 4.6.1 if that works for you.

[TONPumper]

So when will a new stable release come out?

[Octo-puss]

So when will a new stable release come out?
When it's done.

[madshi]

Hmmmm... I'm currently trying to compile 32bit ffmpeg. It seems that ffdshow uses a custom config.h for compilation. I've found that the following switches are different from the config.h file I'm getting:

#define HAVE_CMOV 1
#define HAVE_EBP_AVAILABLE 1
#define HAVE_FAST_CLZ 0
#define HAVE_FAST_CMOV 1
#define HAVE_ISATTY 0
#define HAVE_MEMALIGN 1
It that an intentional change and if so what purpose does it have to change these defines, if I may ask?

Also I'm wondering: Is it recommended to change the CFLAGS? E.g. I've seen people use "-march=i686 -mmmx -msse -msse2 -mfpmath=sse". Is that a good idea, when using GCC?

Thanks!!

[nevcairiel]

In general, using sse fpmath can be a good idea, however i've had some weird issues with it in ffmpeg, so i stick to "-march=i686 -mmmx"

HAVE_MEMALIGN is wrong on Win32, windows doesn't have the required functionality.
Not sure about the others, i stick to the ffmpeg configure script and use what it creates for me - never run into any problems with that.

This is my current build script - alot of those configure options are probably default, but shrug.
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=build_ff_win32.sh;hb=refs/heads/video

[JEEB]

Hmmmm... I'm currently trying to compile 32bit ffmpeg. It seems that ffdshow uses a custom config.h for compilation. I've found that the following switches are different from the config.h file I'm getting:

#define HAVE_CMOV 1
#define HAVE_EBP_AVAILABLE 1
#define HAVE_FAST_CLZ 0
#define HAVE_FAST_CMOV 1
#define HAVE_ISATTY 0
#define HAVE_MEMALIGN 1
It that an intentional change and if so what purpose does it have to change these defines, if I may ask?
Config.h is usually generated by the configure script in ffmpeg, so those settings are usually either picked by system checks and configure settings. You shouldn't be touching it by yourself in most cases :3

The only one that matters here is --enable-memalign-hack (which is HAVE_MEMALIGN methinks Edit: no, it wasn't), which should be used on 32bit windows at least (64bit Windows doesn't seem to need it). Otherwise you should see configure output with your configure line and see if the configuration matches what you are hoping to achieve.

Example configure output with just --enable-memalign-hack on my msys/mingw system:
jeeb@patchouli ~/libav
$ ./configure --enable-memalign-hack
install prefix /usr/local
source path .
C compiler gcc
ARCH x86 (generic)
big-endian no
runtime cpu detection no
yasm yes
MMX enabled yes
MMX2 enabled yes
3DNow! enabled yes
3DNow! extended enabled yes
SSE enabled yes
SSSE3 enabled yes
AVX enabled yes
CMOV enabled no
CMOV is fast no
EBX available yes
EBP available no
debug symbols yes
optimize for size no
optimizations yes
static yes
shared no
postprocessing support no
new filter support yes
network support yes
threading support pthreads
SDL support no
Sun medialib support no
libdxva2 enabled no
libva enabled no
libvdpau enabled no
AVISynth enabled no
frei0r enabled no
libdc1394 support no
libdirac enabled no
libfaac enabled no
libgsm enabled no
libmp3lame enabled no
libnut enabled no
libopencore-amrnb support no
libopencore-amrwb support no
libopencv support no
libopenjpeg enabled no
librtmp enabled no
libschroedinger enabled no
libspeex enabled no
libtheora enabled no
libvo-aacenc support no
libvo-amrwbenc support no
libvorbis enabled no
libvpx enabled no
libx264 enabled no
libxavs enabled no
libxvid enabled no
zlib enabled yes
bzlib enabled yes

<List of enabled stuff too long for the post it seems>

License: LGPL version 2.1 or later
Creating config.mak and config.h...
libavutil/avconfig.h is unchanged

Also I'm wondering: Is it recommended to change the CFLAGS? E.g. I've seen people use "-march=i686 -mmmx -msse -msse2 -mfpmath=sse". Is that a good idea, when using GCC?I don't usually edit these flags for optimizational purposes.

My current configure to build static libraries filled with old stuff (TM):
./configure --prefix=/mingw/i686-pc-mingw32 --enable-gpl --enable-postproc --enable-filters \
--disable-network --enable-memalign-hack --extra-cflags='-U__STRICT_ANSI__' \
--enable-runtime-cpudetect --enable-pthreads --extra-cflags='-DPTW32_STATIC_LIB' \
--disable-hwaccelsPostproc should be now enabled with --enable-gpl, and in my case --enable-pthreads was default as well. Network functions and hardware accelerated stuff isn't needed by me, so I leave them disabled. -U__STRICT_ANSI__ and -DPTW32_STATIC_LIB were needed for ffms and friends when making a library, possibly. Not sure if either is needed any more :/

[nevcairiel]

The only one that matters here is --enable-memalign-hack

That option is auto-detected by the configure script these days, a plain call to ./configure will build you a working ffmpeg these days.

[JEEB]

That option is auto-detected by the configure script these days, a plain call to ./configure will build you a working ffmpeg these days.Ha! Kind of thought that'd happen :P Scratch one configure option off my lines.

[madshi]

Thanks for the comments, guys.

I've done some experiments and if I just use the standard config.h produced by "configure bla bla" then multi threaded h264 video decoding is a bit slower than ffdshow's latest build. On my PC a h264 trailer pushes the CPU to 85% with standard ffmpeg, while ffdshow only consumes 75%. Changing those config options I listed in my previous post reproduces the same results as ffdshow. So at least on my PC, modifying the config.h file to match ffdshow noticeably improves performance. FWIW, ffdshow also has a different "mem.c" compared to standard ffmpeg. ffdshow's mem.c uses "__mingw_aligned_malloc" which is nowhere to be found in the latest ffmpeg. Maybe that explains why the ffdshow config.h uses "HAVE_MEMALIGN"?

[clsid]

Yes, ffdshow uses those mingw functions instead of the memalign hack. I didn't know its performance benefit was that big. Maybe it is useful for LAV Filters as well? Or better yet, ask the FFmpeg developers to detect these functions and use them.

[madshi]

I don't think the mingw functions alone make the difference. They did seem to help a bit, but I found some of the other config "tweaks" to improve performance, too. E.g. CPU consumption went down noticeably by setting "HAVE_EBP_AVAILABLE 1" and "HAVE_ISATTY 0". Didn't separate those two so I don't know which one did it.

[nevcairiel]

Sadly manually modifying the config.h after the ./configure would really break my process.

I should check the configure script and see how it detects those things.

FWIW, i doubt HAVE_ISATTY makes such a big difference. EBP on the other hand adds an additional register to the assembly, which on pure x86 can make a difference.

I should get my decoder running good enough for performance tests. ;)

Edit:
Numbers!

EBP adds around 10% single-threaded performance here. 50fps becomes 55fps. The memalign thing doesn't change a thing, but i suppose its nicer then using the hack, so i'll go with that.

Too bad i suck at configure scripting, or i would somehow code a detection for this and try to push it upstream.

[jeremy33]

There is a problem with h264 interlaced content since ffmpeg-mt was integrated to libavcodec.

Now the h264 interlaced video stutters. Is it the same for you ?

Here is a 1080i sample part 1 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part1.rar) & part 2 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part2.rar)

[dann23]

after the recent changes to ffdshow, subtitles do not work with wmp12 on windows 7 64 bit. it appears just for some seconds and after that nothing. If I seek it appears again for some seconds. I tried with lav splitter and with matroska splitter from mpc-hc.

[clsid]

There is a problem with h264 interlaced content since ffmpeg-mt was integrated to libavcodec.

Now the h264 interlaced video stutters. Is it the same for you ?

Here is a 1080i sample part 1 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part1.rar) & part 2 (http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_dolby_digital_plus_channel_check_lossless.part2.rar)That is not because of the integration. A recent fix in the FFmpeg/Libav code is the cause of this performance regression. One of the devs has been notified, so hopefully the situation can be improved.

after the recent changes to ffdshow, subtitles do not work with wmp12 on windows 7 64 bit. it appears just for some seconds and after that nothing. If I seek it appears again for some seconds. I tried with lav splitter and with matroska splitter from mpc-hc. Afaik, that bug has been there for a long time already. Without more devs I don't see it being fixed any time soon.

[TheShadowRunner]

I see mention of a stable release, before it happens if any coder knows his way around the resize/crop code to fix this bug: http://sourceforge.net/tracker/?func=detail&aid=3221231&group_id=173941&atid=867360 that'd be great!

[jeremy33]

That is not because of the integration. A recent fix in the FFmpeg/Libav code is the cause of this performance regression. One of the devs has been notified, so hopefully the situation can be improved.
Ok thank you.

[TONPumper]

When it's done.

Well is it still Beta 7 or has there been a new stable release?

[clsid]

@JEEB
Have you had any more contact with Ronald with regard to the H.264 performance regression?

I took a look at Lord's 10bit patch and it looks good. You guys were talking about too little room for more colorspaces, but isn't there still room for 3 additional ones? Enough for the 9-bit stuff. I have a patch to extends the enum to 64-bits, adding room for 32 more colorspaces. Let me know if you need it. I will probably commit it soon.

Are there any known problems with the current patch? For example, does DXVA still work?

[Blight]

Small question:
Is there a performance hit if I set the video decoder's 'number of decoding threads' to "4" on a 2-Core system (or even a single core system)?
And if the answer is 'Yes', then how big is the hit?

[nevcairiel]

Over-taxing the CPU does not decrease performance, in fact it usually still speeds it up.

For example, i have a i7 with 8 threads (4 cores + 4 HT).
On one sample i get around 220fps with 8 threads. Increase that to 12 or even 16 threads, i get 250 fps. The gain won't be large once you hit the limit, but it certainly won't be slower.

If you do this when transcoding, and running at 100% all the time, you might impact the responsiveness of the system, however. :)
During playback, i see no harm setting it like that.

[e-t172]

The gain won't be large once you hit the limit, but it certainly won't be slower.

To a point, obviously. If you set 100 threads then you'll have horrible performance because of all the context switches and related cache misses. The only way to know the correct number of threads to use is to mesure it.

[madshi]

In my tests I had worse performance with 4 threads than with 2 threads on my dual core CPU. But maybe that's just me, and I didn't test very long.

[Underground78]

I did some tests a few days ago using the new MPC-HC branch with updated internal decoders and I did see an improvement when using 4 threads even with my dual core CPU: http://pastebin.com/NkmM3jCg.

[Blight]

Thanks everyone for the input on the thread counts, much appreciated.

e-t172:
Of course, I just worried that context switching would have a negative affect even at 4 cores (on a 2 core system).

[cyberbeing]

For a 2-core AMD X2 (939), setting threads to "3" gives higher frame-rate than "2". Setting threads to "4" or higher has around the same performance as "3" threads but with slightly higher CPU usage. Each additional thread beyond "3" seems to add slightly higher CPU usage with no performance benefit, so if you set the thread count too high you might notice it.

[Atak_Snajpera]

For a 2-core AMD X2 (939), setting threads to "3" gives higher frame-rate than "2". Setting threads to "4" or higher has around the same performance as "3" threads but with slightly higher CPU usage. Each additional thread beyond "3" seems to add slightly higher CPU usage with no performance benefit, so if you set the thread count too high you might notice it.
x264 encoder also uses 1.5*cores formula = optimal number of threads

[JEEB]

@JEEB
Have you had any more contact with Ronald with regard to the H.264 performance regression?Yes, pinged him a few times, and he is still quite occupied with other things for the moment -- thus no updates on that front yet.

I took a look at Lord's 10bit patch and it looks good. You guys were talking about too little room for more colorspaces, but isn't there still room for 3 additional ones? Enough for the 9-bit stuff. I have a patch to extends the enum to 64-bits, adding room for 32 more colorspaces. Let me know if you need it. I will probably commit it soon.Lord wasn't sure if we could put it that much up safely -tryouts-wise, so we kept to just 10bit so far. I see the 64bit'ification patch went in already, after we get filters etc. related stuff working more properly'ish we'll move over to the 64bit side and adding possible 9bit colorspaces into the mix.

Are there any known problems with the current patch? For example, does DXVA still work?There are various problems not related to just playback, such as the filter problems, but these are under work atm.

Also, btw -- is it a known problem that in case of no installed Avisynth on the system the Avisynth filter, when enabled, just crashes? This seems to have come up while testing various filters.

[sumawo13]

Does ffdshow-tryouts have official support for 4:4:4 H.264 yet? I've encoded some clips with x264 and, when viewed using ffdshow-tryouts, the chroma is noticeably quartered in resolution, as though it's 4:2:0 up-sampled with a point filter.

[JEEB]

Does ffdshow-tryouts have official support for 4:4:4 H.264 yet? I've encoded some clips with x264 and, when viewed using ffdshow-tryouts, the chroma is noticeably quartered in resolution, as though it's 4:2:0 up-sampled with a point filter.
-tryouts defaults all H.264 to 4:2:0 output (it basically is hardcoded to "If this is H.264, it's 4:2:0. QED."). And yes, the default swscale flags have SWS_POINT, as well as lack full precision. Not usually visible because the swscale codepaths get used very rarely :)

Lord has worked around the 4:2:0 hardcoding in H.264, and I got to editing the swscale flags, the first is in Lord's 10bit H.264 patch at the moment, and the latter is in a separate commit atm on my github repo's blitzkrieg branch.

[clsid]

I noticed Avisynth crash as well. A fix for that would be useful.

When adding 9-bit, also add 10-bit 4:2:2.