ffdshow tryouts project: Discussion & Development

[therealjoeblow]

@Blight

What are the hardware requirement for DXVA (minimum ATI/NVIDIA/INTEL model required) ?

I have an NVIDIA 7600GT and the DXVA filter wont even connect to the EVR.
Also, why is H.264/VC1 disabled (unchecked) by default on the "Hardware Acceleration" tab, Isn't the whole purpose of a separate DXVA filter to ensure that DXVA wont interfere with standard usage of ffdshow?

For ATI Cards:

http://en.wikipedia.org/wiki/Unified_Video_Decoder#UVD_enabled_GPUs

For NVIDIA Cards:

http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs

[STaRGaZeR]

(the latter setting is what triggers DXVA to be initiated for DVD/MPEG2 decoding).

Nope, it doesn't trigger DXVA, just hardware deinterlacing.

[tal.aloni]

OK, i finished test right now.
The sample i posted to you works just fine in 3198 like others VC-1 samples i have.
In 3200 sample i sended to you are broken, but rest of VC-1 videos i have seems to be OK.

the "bug" is related to B frame ordering (bReorderBFrame variable),
MPC-HC filter behaves differently for each splitter,
I'm hoping for a better solution: I hope a common ground can be reached on how the splitter should behave. (reorder B frames or not).
however, I'm not sure I have a full understanding of the issue at hand, please correct me if I'm wrong in any way.

Regards,
Tal

[tal.aloni]

albain,
you may already know this, but:

1. I think the colorspace in the flat DXVA decoded buffer is NV12: 8-bit Y plane followed by an interleaved U/V plane with 2x2 subsampling.
however, it seems that each plane is drawn in blocks, I had some experience with a similar format in the past, so I can try to help in deciphering the format if all else fails.

2. I'm not sure what's the best route to convert it to FFDShow.

3. It would be indeed best to "templetize" the copy mechanism, so you could use SSE 4 / SSE 2 / memcpy, I don't know how, but I think that there are a few examples already in ffdshow.

sorry for not being of more assistance,
Tal

[Jeremy Duncan]

:thanks: Jeremy Duncan for Wiki :)

I'll try to try :)
Seb.

Your welcome. I have updated the wiki again; this time I described how to build icl11 builds.

link (http://ffdshow-tryout.sourceforge.net/wiki/devel:building#prerequisite_software)

And to clsid, visual studio pro as described by me in the wiki can compile kerneldeint, tomsmocomp, xvidcore. libmpeg2.
I will post my ffdshow I build today, 3202 using SE't patch and where visual studio built kerneldeint, libmpeg2, tomsmocomp, xvidcore, so you can test it to see if it's ok and the wiki is fine since my build is fine.

link (http://www.mediafire.com/?zzg5ky4qoyt)

[albain]

albain,
you may already know this, but:

1. I think the colorspace in the flat DXVA decoded buffer is NV12: 8-bit Y plane followed by an interleaved U/V plane with 2x2 subsampling.
however, it seems that each plane is drawn in blocks, I had some experience with a similar format in the past, so I can try to help in deciphering the format if all else fails.

2. I'm not sure what's the best route to convert it to FFDShow.

3. It would be indeed best to "templetize" the copy mechanism, so you could use SSE 4 / SSE 2 / memcpy, I don't know how, but I think that there are a few examples already in ffdshow.

sorry for not being of more assistance,
Tal

1. The current implementation uses NV12 colorspace, but NV12 is far from being the best colorspace compared to RGB ones.
I hope that we can use others with DXVA. But for the moment indeed I assume that we have NV12 buffers

2. I have made a patch. Here is the link (http://damienbt.free.fr/dxva_patch.diff). I cannot test it because I am at work and my laptop does not support dxva.
The project file is updated because a new macro (DXVA_INSIDE_FFDSHOW) adds DXVA decoding and dialogs inside FFDSHow video filter.

I have copied the decompress method from TvideoCodecLibavcodec and splitted into 2 methods
.
The processFrame method is called at the end (after DXVA or software decoding for a given frame) and from the AVFrame (frame) will analyze it and create a TffPict (uncompressed picture) to process it through the FFDShow internal filters.
What I have done is to fill the AVFrame structure with the DXVA buffers that I have copied back from the GPU.
I took my inspiration from TvideoCodecUncompressed class that received flat uncompressed buffers too.
Then it should work.


This should work but what I am not sure about what the MPC patch affect or not : there may be some missing parameters in the AVFrame (I have set a few such as the pix_fmt, the type of frame).

If you have time to review the patch thank you !

[Jeremy Duncan]

libmpeg2_ff.dll shouldn't be compiled by MinGW GCC because they are slower than MSVC 2008.

I ran a test using the timecodec on the ffdshow wiki and here are the test result.
One build using the visual 2008 compiler the other one uses msys, both built in xp mce.

icl 11, 3202, vmr7, 720p, libmpeg2 built in msvc
user: 5
kernel: 3
total : 8
real: 91
fps: 492.7
dfps: 47.7

icl 11, 3202, vmr7, 720p, libmpeg2 built in gcc msys
user: 5
kernel: 3
total : 8
real: 89
fps: 500.7
dfps: 48.8

ffdshow video codec settings
Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Avisynth tab checked
YV12 checked,
Add FFdshow Video source Unchecked,
3:2 Pulldown box: Ignore Pulldown checked,
check Buffer back/Ahead: 3, 3

setmtmode(2)
Last=ffdshow_source()
setmemorymax(550)
setmtmode(2)
a= last
b=a.Spresso()
SeeSaw(a,b)
LimitedSharpenFaster(strength=11)
LimitedSharpenFaster(strength=11)
distributor()

Resize & aspect tab checked
Process whole image checked
Specify horizontal and vertical Resize: 1280, 720
Process Pixel aspect ratio internally checked
No aspect ratio correction checked
spline
Luma Sharpen: 0.00
Luma Guassian Blur 0.50
Accurate rounding checked

Output tab
rgb32 checked
high quality yv12 to rgb conversion checked

rgb conversion tab
ycbcr: itu-bt 601
high quality yv12 to rgb conversion checked
Dithering checked
contrast: standard
Output levels: Tv/Projector

The test clip was a mpeg2 made into a avi using virtual dub, standard definition resolution for ntsc movies.

ffdshow libmpeg2 built using msys (http://www.mediafire.com/?cmvm0inz3mm)
ffdshow libmpeg built using msvc (http://www.mediafire.com/?zzg5ky4qoyt)

[Cheesegeezer]

Hey there guys, I could really do with some help.

I'm using win 7 32bit and i'm trying to use FFDShow Video to decode both SD Live TV and BBC HD.

I've disabled the M$ DVD-DTV video and audio decoders along with the MP3 one. I've set merit of FFDShow to max in Radlight filter manager.

In the FFDShow Video Config, I have set MPEG2 to libmpeg2 and MPEG in AVI to libmpeg2 and Raw Video to all Supported.

Im using graph studio and remotely connecting to win7MCE, I'm using a DVB-S2 TV Card, but for the life of me FFDShow can't be inserted into the graph for MPEG2 streams or the h264 stream. Graphstudio simply refuses to insert the FFDShow Video Filter.

Have I missed something or is FFDShow not compatible with live TV in win7.

Any help would be greatly appreciated.

Many Thanks

Dave

[Jeremy Duncan]

2. I have made a patch. Here is the link (http://damienbt.free.fr/dxva_patch.diff). I cannot test it because I am at work and my laptop does not support dxva.
The project file is updated because a new macro (DXVA_INSIDE_FFDSHOW) adds DXVA decoding and dialogs inside FFDSHow video filter.

I can build a ffdshow for you using the patch and post it here for people to test. But I have a few questions first.

Reading the diff file it goes into the folder where the ffdshow_2008.vcproj is?
And I would build ffdshow_2008.vcproj not ffdshow_2008.sln?
May I ask that you supply a patch that's built with the sln version as I know I can do that easily?

[tal.aloni]

@Jeremy,
1. Thanks for the offer, but the patch is not doing anything significant right now, it was only meant for review.

@everyone
unfortunately, the reading speed of the decoded DXVA frame is not fast enough to process 720p24 on CPUs without SSE 4.1, so Phenom, Athlon and Pentium 4 could not use full frame DXVA post processing.

however, writing speed to the frame is much faster,
so it seems we can overlay osd / subtitles (write only)
or blend them (little read involved) fast enough for the older CPUs to handle.

[albain]

Yes, afterwards we will make performance tests to figure out if :

1/ DXVA decoding + copy back to system memory + FFDShow software processing

is faster than

2/ FFDSHow software decoding + processing

So at the end the DXVA filter will still be useful to develop dedicated DXVA internal postprocessing filters

Status : FFDSHow postprocessing work now on DXVA decoded picture copied back to system memory (including resize) but there is a deadlock

[Reino]

Perhaps I'm missing something, but does anyone know where the OSD-profile bar has gone? I've had rev.1341 installed untill today (today I updated till latest one) and already with rev.1341 the ability to save OSD-profiles has been removed as well.
I'd like to know why it has been removed and if it's coming back at all?
http://img29.imageshack.us/img29/4310/ffdshowosd.png

[clsid]

OSD settings are now stored as part of your Profile/Preset.

[tal.aloni]

1/ DXVA decoding + copy back to system memory + FFDShow software processing

is faster than

2/ FFDSHow software decoding + processing

my phenom is fast enough for 2, but can't handle 1. (I'm guessing it will be different for SSE 4.1 capable CPUs)

however, overlaying OSD / Subtitles works quite well.

[Jeremy Duncan]

The svn is not downloading the files properly, please fix it. :)
I have a question, if I make a 64 bit ffdshow.ax, does the gcc files need to be 64 bit also, or can I use the custom mingw 32 bit to build the gcc files and use them with a 64 bit ffdshow.ax?

[clsid]

Everything must be 64-bit. You need MinGW64.

[Jeremy Duncan]

Everything must be 64-bit. You need MinGW64.

If I installed your 64 bit ffdshow then took the gcc files:libavcodec, mplayer, ffmpeg and put the in the bin folder to build my ffdshow would that work?

Edit, and if I used mingw64 myself, which would I install? Can you please link to the one I would use in Windows 7 64 bit, the download link? I don't use mingw usually so I have no clue on which one I need.

Edit, I found these instructions by Casimir666,

I have finally find a way to compile x64 edition with GCC http://smileys.inzenet.org/repository/Content/U_JUMP%7E1.GIF.

To do this, you should have :
- Download MingW64 chaintool for i686-mingw platform
(http://sourceforge.net/project/showfiles.php?group_id=202880&package_id=245516&release_id=546049)
- Download MSys, and configure it with MingW64 with postinstall script (http://sourceforge.net/project/showfiles.php?group_id=2435)
- Patch MSys with latest release of CoreUtils and Bash
- Install Subversion command line client from http://subversion.tigris.org (and add path in msys.bat if necessary)

To compile ffmpeg, start MSys and execute script : ..\mpcvideodec\ffmpeg_x64\buildffmpeg.sh

DO NOT copy manually libgcc.a and libmingwex.a to mpc "lib64" folder, the script will do it for you. The reason it's so complicated is that MingW64 libraries should be compiled with -fno-leading-underscore option to be link statically with Visual Studio.

If somebody want to compare performance between VS build and GCC build i have uploaded a release here :
http://www.zshare.net/download/17954266d7edd8f9/

link (http://forum.doom9.org/showthread.php?p=1177589#post1177589)

I have a few questions. Do I install mingw 64 before downloading the "MingW64 chaintool for i686-mingw platform". If so please link to the download fo both files because I don't know which one to choose.
Once I get that step down I'll try to figure the rest out myself. :thanks:

[clsid]

Those instructions are not needed for ffdshow.
Just unzip MinGW64 and add its /bin dir to your PATH environment variable.
I am using the 4.4.0 MinGW64 build.

[albain]

The svn is not downloading the files properly, please fix it. :)
I have a question, if I make a 64 bit ffdshow.ax, does the gcc files need to be 64 bit also, or can I use the custom mingw 32 bit to build the gcc files and use them with a 64 bit ffdshow.ax?

I had problems too with the repository lately when trying to work on a branch (too many files to deal with)
So I gave up on branching

[Andy o]

Hey guys does the Dolby Digital Plus decoder support 7.1 right now? I'm playing a Dolby test bluray and ffdshow only outputs 5.1:

http://forum.doom9.org/attachment.php?attachmentid=10679&stc=1&d=1263699710

Not a big deal since there's virtually no DD+ blurays besides that test disc AFAIK. Just wanted to know.

Using MPC-HC 1453 and ffdshow 3181. Could it be the splitter? I'm using the internal one.

[tal.aloni]

Hey guys does the Dolby Digital Plus decoder support 7.1 right now?

no. there are no new DD+ 7.1 releases anyway.

[Andy o]

Yeah, no big deal, was just curious.

[Jeremy Duncan]

I had problems too with the repository lately when trying to work on a branch (too many files to deal with)
So I gave up on branching

It's something to do with Boost. I tried to download files from the svn and the trunk is corrupt and the bitstreaming branch is corrupt too.

If I download to my c: drive it doesn't show a error but if I download to my desktop I get a error every time with boost.
The files I download to my c:\ drive won't let me make xvidcore in msvc, or ffdshow.ax.

This is on windows 7 64 bit using the 64 bit tortoise svn.

[Lam3rD]

Hey, guys.

I've found some buggy things in ffdshow_sar/dar/setsar/setdar. Would you mind telling me in which file/project their code is located, so I can check it out an see what goes wrong and (hopefully) fix it. I did go through the SVN for like 20-30 minutes, with no success finding the code of these functions, so I thought I'd ask here.

[CruNcher]

It plays fine with rev. 3195+.
make sure you have checked H.264 acceleration under DXVA settings.

Tal

Got it finally to work nobody told me that there is a "ffdshow DXVA Video Decoder" now :P i thought it was part of the normal Decoder so i had to add it to the list :)

Though there are heavy artifacts appearing on playback with 3204 in some parts

[tal.aloni]

Albain and I have combined effort and managed to enable post-processing with our stand alone DXVA filter.

it's an early beta, some parts are not yet optimized,
look for the new "post processing" option.

There are 3 modes of operation (besides disabled, which is the fastest), only two are implemented ATM:
overlay - this should be used for older systems that must have subtitles
blend - same as overlay, but with alpha blending, slightly more uncacheable memory bandwidth is required. (not implemented right now)
full post processing - you can try it if you have SSE 4.1 capable CPU, and please tell me what happens (seriously, I'm not sure if it will handle 720p / 1080p)

build:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/ffdshow_rev3206_20100118-DXVA-Post-Processing-Beta%201.exe

patch:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/3206-DXVA%20PostProcessing-Beta1.patch

[rsd78]

Albain and I have combined effort and managed to enable post-processing with our stand alone DXVA filter.

it's an early beta, some parts are not yet optimized,
look for the new "post processing" option.

There are 3 modes of operation (besides disabled, which is the fastest), only two are implemented ATM:
overlay - this should be used for older systems that must have subtitles
blend - same as overlay, but with alpha blending, slightly more uncacheable memory bandwidth is required. (not implemented right now)
full post processing - you can try it if you have SSE 4.1 capable CPU, and please tell me what happens (seriously, I'm not sure if it will handle 720p / 1080p)

build:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/ffdshow_rev3206_20100118-DXVA-Post-Processing-Beta%201.exe

patch:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/3206-DXVA%20PostProcessing-Beta1.patch

Amazing work!

Any idea on the rough cpu power required for the Overlay option? Is it equivalent to when "normal" dxva is activated or does it add a bit of overhead?

[albain]

Thank you Tal, but you made most of the work :thanks:

[tal.aloni]

rsd78, Thanks,
DXVA post processing does add some overhead, but it's mostly associated with memory operations. (besides filter processing, of course).

I'm still waiting to hear reports regarding the "full post processing" with SSE 4.1.

Thanks!
Tal

[STaRGaZeR]

And my PC is on repairs... :mad:

Will test it as soon as I can, great stuff :eek:

[CruNcher]

rsd78, Thanks,
DXVA post processing does add some overhead, but it's mostly associated with memory operations. (besides filter processing, of course).

I'm still waiting to hear reports regarding the "full post processing" with SSE 4.1.

Thanks!
Tal

Nice im gonna test it on SSE2/3 Athlon 64 here and see if it's same performance then CoreAVCs CUDA (nvcuvid.dll) memory copy :)

Wow tal.aloni this build is totally buggy even without any postprocesing the artifact count tripled now :( XP 32 bit Nvidia VP2 (8800 GT) Forceware 195.94
Full Post Processing is as expecting crashing immediately here on Athlon 64 ;)

trying a non patched 3206 now
artifacts here and there but not as bad as in the patched 3206 build :) still MPC-HC internal bitstream decoder is stable though when it runs the whole system becomes very laggy (even as cpu and kernel utilization are roughly 5%) but the Video/Audio playbacks Realtime and without any artifacts or delays (VMR7)

[roozhou]

@albain
A feature request: Is it possible to do full post-processing after HW deinterlacing? It is easy for modern CPU to decode high bitrate AVC contents, but so far there is no real-time software deinterlacer that can compete with HW deinterlacer.

[albain]

Nice im gonna test it on SSE2/3 Athlon 64 here and see if it's same performance then CoreAVCs CUDA (nvcuvid.dll) memory copy :)

Wow tal.aloni this build is totally buggy even without any postprocesing the artifact count tripled now :( XP 32 bit Nvidia VP2 (8800 GT) Forceware 195.94
Full Post Processing is as expecting crashing immediately here on Athlon 64 ;)

trying a non patched 3206 now
artifacts here and there but not as bad as in the patched 3206 build :) still MPC-HC internal bitstream decoder is stable though when it runs the whole system becomes very laggy (even as cpu and kernel utilization are roughly 5%) but the Video/Audio playbacks Realtime and without any artifacts or delays (VMR7)


Artifacts are mostly due to uncompatible videos : DXVA is quite strict on which formats and encoding levels it can handle.
You should try another video that doesn't give any artifacts.

Sorry, I can't test for now (@work, old laptop)

@roozhou : normally the DXVA decoding and deinterlacing are done before postprocessing, but I am not 100% sure

[VipZ]

Albain and I have combined effort and managed to enable post-processing with our stand alone DXVA filter.

it's an early beta, some parts are not yet optimized,
look for the new "post processing" option.

There are 3 modes of operation (besides disabled, which is the fastest), only two are implemented ATM:
overlay - this should be used for older systems that must have subtitles
blend - same as overlay, but with alpha blending, slightly more uncacheable memory bandwidth is required. (not implemented right now)
full post processing - you can try it if you have SSE 4.1 capable CPU, and please tell me what happens (seriously, I'm not sure if it will handle 720p / 1080p)

build:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/ffdshow_rev3206_20100118-DXVA-Post-Processing-Beta%201.exe

patch:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/3206-DXVA%20PostProcessing-Beta1.patch

Thanks for all this hard work :)

I have tried to test few things for you.
Overlay: Colours are fine and OSD works well.
Full Processing: Frames are extremely corrupted, OSD working fine over corrupted frame though, very unstable with most seeks crashing MPC
All: Subs never connect to ffdshow DXVA and seeking can crash MPC (Even with processing disabled)

Pic of corruption
http://img508.imageshack.us/img508/116/sampley.jpg

[ACrowley]

I cant see any Info about DXVA when it should be active ?
Theres only Decoder : ffmpeg-mt h264 ?
My CPU laod is still at the same Levels as witout DXVA so i assume its inactive. The Files are fully compliant.
I set DXVA for h264 and VC1 in the DXVA options

EDIT:
Ah, Sorry, DXVA Decoder is standalone
Will it be merged so that we can simply change the Decoder to DXVA in the Main Video Decoder Settings ?

[tal.aloni]

VipZ, Thanks,
Which CPU did you use?
(EDIT: checked your profile, the Q6600 does not have SSE 4.1)

All: Subs never connect to ffdshow DXVA
DXVA 1.0 post processing can only handle ffdshow own filters.
(theoretically DXVA 2.0 is not limited, but we're settling on the lowest common denominator)

anybody with SSE 4.1?

[Jeremy Duncan]

SEt's patch here: link (http://forum.doom9.org/showthread.php?t=148117) I updated it here: link (http://www.mediafire.com/?bteig4mmzkn) I talked to IanB about it here: link (http://forum.doom9.org/showthread.php?goto=newpost&t=152144). The gnu requires me to post the new code so I am posting it. The code is flawed, but it works and that's all that matters.

ffdshow I built using diff file. In windows 7 64 bit install this as administrator. (http://www.mediafire.com/?wmwzz0wzzzk)

[VipZ]

VipZ, Thanks,
Which CPU did you use?
(EDIT: checked your profile, the Q6600 does not have SSE 4.1)


DXVA 1.0 post processing can only handle ffdshow own filters.
(theoretically DXVA 2.0 is not limited, but we're settling on the lowest common denominator)

anybody with SSE 4.1?

No problem.
I thought it was just a matter for speed for the SSE4.1, Didn't realise it would be corrupted if no SSE4.1 instructions are available. CPU was at aprox 5-10% when trying this.
For the subtitles I was referring to ffdshow subtitles, the graph didn't connect to ffddshow for subs. Also in graphedit there is no Pin In for the splitter to connect to.

[tal.aloni]

VipZ,
it is a matter of speed,
SSE 4.1 boosts uncacheable memory reading speed by a factor of up to 12.
the corruption occurs when the frame has not been delivered to the renderer in time. (because of post processing).

if you have a very low resolution video, I'm pretty sure you can use full post processing on it successfully even with no SSE 4.1.

[VipZ]

Tal,
I tried a few lower res files, they are either almost totally just a black screen or crash MPC HC immediately and if it doesn't crash, OSD doesn't display either. All the files work fine with ffdshow dxva rev 3206 on normal compatibility mode.

Below is some info on a file I recoded to test with a very low res, it works with dxva rev 3206 but crashes immediately with the post processing beta.
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L1.2
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Muxing mode : Container profile=Unknown@1.2
Codec ID : V_MPEG4/ISO/AVC
Duration : 3mn 33s
Bit rate : 214 Kbps
Width : 320 pixels
Height : 160 pixels
Display aspect ratio : 2.000
Frame rate : 29.970 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.139
Stream size : 5.44 MiB (39%)


If you want me to run any other tests let me know.

[tal.aloni]

ok, I'll check some low-res files when I get home,
Thanks,
Tal

[HeadlessCow]

Core i7 920
Radeon 4670

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 45mn 29s
Bit rate mode : Variable
Bit rate : 2 569 Kbps
Maximum bit rate : 11.1 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.116
Stream size : 836 MiB (100%)
Writing library : x264 core 68 r1183M f21daff
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=9 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=12 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=2569 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=50000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00


Overlay works fine at 24fps.
Full postprocessing drops it to ~18fps and the color is off.

Skipping around in the file at all crashes MPC-HC.

[HeadlessCow]

Core i7 920
Radeon 4670

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 24mn 10s
Bit rate mode : Variable
Bit rate : 1 151 Kbps
Maximum bit rate : 3 059 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.156
Stream size : 199 MiB (100%)
Writing library : x264 core 80 r1376M 3feaec2
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=0.4:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=5 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=2 / keyint=250 / keyint_min=25 / scenecut=40 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1151 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=17500 / vbv_bufsize=14000 / ip_ratio=1.40 / aq=1:0.60



Overlay is perfect.
Full postprocessing keeps up with the framerate but looks like this:
http://headlesscow.com/doom9/corruption.png

[tal.aloni]

Thanks!
I gues I should focus on "merge" for the time being,
It would be perfect for subtitles / OSD / Bitmap overlay.

I'm still wondering why we couldn't get more speed out of the core i7... the intel docs have demonstrated sufficient theoretical speed.
maybe albain could figure it out / optimize.
(perhaps it's not related to speed at at.. maybe the last example tied to colorspace issues)

Tal

[albain]

It may be due to the colorspace.

I can't test it right now but in my (non working) patch I added 2 conversions functions in src/imgFilters/ffImgfmt.h.

And I called csp_planar2packed(FF_CSP_NV12) which gives FF_CSP_NV12|FF_CSP_FLAGS_YUV_ADJ|FF_CSP_FLAGS_YUV_ORDER. This is (I think) the value that we should use when initializing TffPict


static __inline int csp_planar2packed(int csp)
{
switch (csp)
{
case FF_CSP_YUY2:return FF_CSP_YUY2;break;
case FF_CSP_YVYU:return FF_CSP_YVYU;break;
case FF_CSP_UYVY:return FF_CSP_UYVY;break;
case FF_CSP_VYUY:return FF_CSP_VYUY;break;
case FF_CSP_CLJR:return FF_CSP_CLJR;break;
case FF_CSP_444P:return FF_CSP_444P;break;
case FF_CSP_422P:return FF_CSP_422P;break;
case FF_CSP_411P:return FF_CSP_411P;break;
case FF_CSP_410P:return FF_CSP_410P;break;
case FF_CSP_Y800:return FF_CSP_Y800;break;
case FF_CSP_NV12:return FF_CSP_NV12|FF_CSP_FLAGS_YUV_ADJ|FF_CSP_FLAGS_YUV_ORDER;break;
case FF_CSP_PAL8:return FF_CSP_PAL8|FF_CSP_FLAGS_VFLIP;break;
}
}

static __inline int csp_packed2planar(int csp)
{
switch (csp)
{
case FF_CSP_YUY2:return FF_CSP_YUY2;break;
case FF_CSP_YVYU:return FF_CSP_YVYU;break;
case FF_CSP_UYVY:return FF_CSP_UYVY;break;
case FF_CSP_VYUY:return FF_CSP_VYUY;break;
case FF_CSP_CLJR:return FF_CSP_CLJR;break;
case FF_CSP_444P:return FF_CSP_444P;break;
case FF_CSP_422P:return FF_CSP_422P;break;
case FF_CSP_411P:return FF_CSP_411P;break;
case FF_CSP_410P:return FF_CSP_410P;break;
case FF_CSP_Y800:return FF_CSP_Y800;break;
case FF_CSP_NV12|FF_CSP_FLAGS_YUV_ADJ|FF_CSP_FLAGS_YUV_ORDER:return FF_CSP_NV12;break;
case FF_CSP_PAL8|FF_CSP_FLAGS_VFLIP:return FF_CSP_PAL8;break;
}
}

EDIT : this code has been inspired from TvideoCodecUncompressed::beginDecompress code where FFDShow receives packed colorspaces as in DXVA.
In the method the packed colorspace is obtained from the input format, including :
case CODEC_ID_NV12:csp=FF_CSP_NV12|FF_CSP_FLAGS_YUV_ADJ|FF_CSP_FLAGS_YUV_ORDER;break;

[tal.aloni]

I found a bug in full processing mode.

pStore += pitch - width;

(should be divided by 16)

I'll keep working on it in a few hours.

[albain]

Hi Tal,

back home. I am building it with the fix on 16 division

I'll post results in a moment

[tal.aloni]

another bug on full post processing (SSE 2 and 4.1):
some random crashes results from addresses not aligned to 16 bytes. _mm_stream_si128 will crash.

[albain]

Okay, the video is very slow with compression artifacts (not green lines) and I have a 50% CPU charge on my Q9450 (2.66Ghz).

In overlay mode I have 22% CPU

I saw that you made some colorspaces conversions : there is a converter (with optimized CPU instructions). I don't know if it can handle the source & dest colorspace that you want

[clsid]

The FFmpeg devs are working on further improving their H.264 code. Their latest patches are not compatible with the slice based multi-threaded decoding patch that we use in ffdshow's libavcodec.

Here is a patch with the latest changes:
http://pastebin.com/m11865032

Should I remove the slice based multi-threading patch? Or is there anyone willing/able to fix it?

Edit: new patch