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

albain

18th January 2010, 19:33

You are already using optimized code. I don't know what else could be done to improve the perfs. The big problem comes from the GPU to system memory copy

@clsid : this is okay, we are not affected by the patch in DXVA mode (if your question was addressed to us)

tal.aloni

18th January 2010, 19:35

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

also, there are still a few issues with the full processing methods (add support when input buffer pointer not aligned to 64, support of inputs with width which is not mod 64)

I wonder if it's worth the effort (full processing). (I'm also wondering if executing the copy in a different stage of the decoding would give us more time)

THX-UltraII

18th January 2010, 19:59

The ATI HD5670 was released a few days ago and is already in stock here in the Netherlands. Will this card give any problems with Bitstream support?

rsd78

18th January 2010, 20:18

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

My hunch is that it may not be worth while performance wise for the full performance method.

I'm a little surprised that in overlay mode it still took 22% CPU, albain. How does that compare to software decoding mode for the same file?

albain

18th January 2010, 20:48

also, there are still a few issues with the full processing methods (add support when input buffer pointer not aligned to 64, support of inputs with width which is not mod 64)

I wonder if it's worth the effort (full processing). (I'm also wondering if executing the copy in a different stage of the decoding would give us more time)

This may be multithreaded with boost as it seems that there are several frames in the buffer when we have to display them, but this is a huge amount of work

albain

18th January 2010, 21:09

With software mode only (no DXVA) I have 30-40% of CPU charge

rsd78

18th January 2010, 22:10

With software mode only (no DXVA) I have 30-40% of CPU charge

Thanks Albain. What is the rough cpu usage using ffdshow's dxva but without any overlay? Just to get an idea of the comparative differences we are talking about here. Thanks again for all you and the others have done. Between bitstreaming, and dxva + subtitles I'm in heaven :)

albain

18th January 2010, 22:48

Thanks Albain. What is the rough cpu usage using ffdshow's dxva but without any overlay? Just to get an idea of the comparative differences we are talking about here. Thanks again for all you and the others have done. Between bitstreaming, and dxva + subtitles I'm in heaven :)

7%

But this is normal as there is no one-way and return to the GPU.

Also there are in overlay mode colorspaces conversions

mark0077

18th January 2010, 23:21

Can anyone confirm de-interlacing with yadif + double frame rate, no longer doubles frame rate. I have forced de-interlacing with many types of content, even non interlaced. I cannot get ffdshow to double the frame rate anymore. It does de-interlace content fine so it is being enabled, it just leaves the frame rate as is.

Mr VacBob

19th January 2010, 07:40

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

If you mean frame, I'll fix it tomorrow - slice threading was broken but fixed again in ffmpeg. Splitting the decoder files completely confused git, so I'll have to do a quite large merge by hand. Meant to do it over the weekend but people kept asking me to do other stuff…

THX-UltraII

19th January 2010, 08:49

The ATI HD5670 was released a few days ago and is already in stock here in the Netherlands. Will this card give any problems with Bitstream support?

any thoughts?

Cheesegeezer

19th January 2010, 10:01

Do you mean in terms of MPC and FFDShow or via PDVD 9 Ultra.

Anyway that doesn't really matter as I can't see any reason why it would cause any problems, it uses the same audio chip across the whole HD5xxx series right upto the HD5970.

Jeremy Duncan

19th January 2010, 10:05

the ffmpegmt won't compile in the 3027 trunk build. I worked once then I couldn't get it to compile again.

XhmikosR

19th January 2010, 10:25

It compiles just fine.

tal.aloni

19th January 2010, 11:18

any thoughts?

I'm pretty confident it would support bitstream.

alexins

19th January 2010, 11:56

It compiles just fine.

I confirm!

THX-UltraII

19th January 2010, 12:16

Just picked up a 5670 and wondering what I need to make bitstreaming dd, dts, dts-ma and true-hd:

- 9.12, 9.12 hotfix or 10.1 beta?
- Realtek driver or not?
- mpc-hc: select 'MPC audio renderer as output'?
- latest ffdshow with all bitstream boxes checked? Anything else in ffdshow that needs to be selected or changed?

I use W7

Andy o

19th January 2010, 12:43

Most of us are using 9.12 hotfix w/Realtek 2.39 HDMI driver. The ATI-provided driver has the silent stream issue, and also the Realtek driver works with 32-bit output with ReClock and WASAPI exclusive, the ATI driver only does 16-bit. I don't see any upside to the ATI driver.

The Default DirectSound renderer works fine, or the ATI HDMI output also works. MPC audio renderer does exclusive mode, and last I tried (MPC-HC 1489 I believe) you had to disable audio switcher, which then doesn't let you switch audio tracks. Everything else works at default too, but just in case make sure you have mpeg PS/TS/PVA in the internal filters checked. Ffdshow needs you to select the bitstream boxes, I don't think anything else has to be done.

BTW the audio discussion specific to this was branched off to here (http://forum.doom9.org/showthread.php?t=151151).

clsid

19th January 2010, 15:47

If you mean frame, I'll fix it tomorrow - slice threading was broken but fixed again in ffmpeg. Splitting the decoder files completely confused git, so I'll have to do a quite large merge by hand. Meant to do it over the weekend but people kept asking me to do other stuff…
I didn't mean ffmpeg-mt. I was waiting for you to update your git tree before I merge that into ffdshow trunk. ;)
We use an old mt patch for slices in our normal libavcodec. That got broken due to the updates. At first it crashed, after the fix by Michael you mentioned, it no longer crashes, but there still are some decoding problems.

mark0077

19th January 2010, 19:55

dann23

19th January 2010, 20:15

is it possible to add mpeg2 to dxva decoding? I have some movies in mpeg2 (in mkv container) and bitrate of 17000 kbps.

rsd78

19th January 2010, 20:31

7%

But this is normal as there is no one-way and return to the GPU.

Also there are in overlay mode colorspaces conversions

Thanks again Albain. Will the current implementation of Overlay work automatically with Media Control? Or do you need to modify something (either ffdshow or Media Control)?

Any chance someone will provide some benchmarks in comparison to existing solutions (i.e. software decoding, dxva, CUDA) for various files/systems? I'm just curious as to the results. I'm a little surprised the DXVA with Overlay used 3x as much CPU as regular DXVA but it's hard to judge without that overall context and baseline measurements.

Gleb Egorych

19th January 2010, 21:36

Just for info: new ForceWare 195.55 broke NV12 support for some files. Output using NV12 is wrong with different codecs including ffdshow.
Fixed in 196.21 WHQL.

JarrettH

19th January 2010, 21:54

is it possible to add mpeg2 to dxva decoding? I have some movies in mpeg2 (in mkv container) and bitrate of 17000 kbps.

exactly what i was asking before too! :devil:

mpc-hc should be just as nice for playing back dvds. the internal deinterlacer is not very good

cca

19th January 2010, 22:18

Revision 3207 introduced a bug on the DVD navigation, menu options no longer highlight on mouse over. Revision 3204 works fine.

Nyquist

19th January 2010, 22:19

exactly what i was asking before too! :devil:

mpc-hc should be just as nice for playing back dvds. the internal deinterlacer is not very good

Set the output to NV12 and interlaced to auto and let libavcodec or libmpeg2 doing the decoding.

tal.aloni

19th January 2010, 23:01

Beta 2 improves overlay mode visibility, and also adds Blend mode,
I'm not really sure if blend mode is very useful, because those read operations are very resource-hungry.
[full-processing-mode seems less and less practical, it's not fully implemented in this beta (and the previous one)]

build
http://iknowu.net/files/public/ffdshow/DXVAPostProc/ffdshow_rev3208_20100119-DXVA-Post-Processing-Beta2.exe

patches
http://iknowu.net/files/public/ffdshow/DXVAPostProc/3208-DXVA-Post-Processing-Beta2.patch

http://iknowu.net/files/public/ffdshow/DXVAPostProc/3208-RefractorProcessDecodedSample.patch

Regards,
Tal

albain

19th January 2010, 23:19

Thanks again Albain. Will the current implementation of Overlay work automatically with Media Control? Or do you need to modify something (either ffdshow or Media Control)?

Any chance someone will provide some benchmarks in comparison to existing solutions (i.e. software decoding, dxva, CUDA) for various files/systems? I'm just curious as to the results. I'm a little surprised the DXVA with Overlay used 3x as much CPU as regular DXVA but it's hard to judge without that overall context and baseline measurements.

It should work but you have to replicate the same settings in FFDShow DXVA configuration (in the remote & keyboard settings).

For now we are stuck on a serious problem : the copy from the GPU to system memory take too much time (80ms for one 720p frame), more time than it should according to intel's article.
Multithreading the copy did worse (120ms)

Even if we do the copies in parallel, the copy time will most likely exceed the playback time. Anyway I will give it a shot.
So for now full postprocessing with DXVA decoding consumes more than full software decoding and processing.

As Tal pointed out, there is something that we should have missed

I don't understand why it would take so much time

mark0077

20th January 2010, 00:53

To follow up on yadif not doubling frame rate. None of the ffdshow de-interlacers that can double frame rate now do. The frame rate doesn't change even though visually it does look de-interlaced, its just the same frame rate.

I have narrowed down the problem being introduced between build 3205 and 3207, as 3204 and before performs double frame rate de-interlacing perfectly.

Does anyone know somewhere I can get build 3205 and 3206, and how to contact either tal_aloni or drevil_xxl, as they are the people who made changes in these builds.

Revision 3207 - Directory Listing
Modified Mon Jan 18 14:41:19 2010 UTC (33 hours ago) by drevil_xxl
minor fix

Revision 3206 - Directory Listing
Modified Sun Jan 17 22:16:10 2010 UTC (2 days, 1 hour ago) by tal_aloni
bugfix related to rev. 3105

Revision 3205 - Directory Listing
Modified Sun Jan 17 20:17:30 2010 UTC (2 days, 3 hours ago) by tal_aloni
Internal: separation between video sample processing and sample delivery. (it's now possible to process video sample without delivering it)

I suspect 3205 or 3206 work by tal_aloni on deinterlacing related files will be the cause of the bug.

XhmikosR

20th January 2010, 02:00

Check the link in my signature for r3206. r3205 caused a blank video screen for me so I didn't uploaded. (I actually reported this to tal.aloni via IRC and he committed r3206 which fixed the problem).

HeadlessCow

20th January 2010, 06:55

For both of my test samples (see previous posts), overlay and blend worked perfectly with the beta2 build.

CPU usage on the 720p video was 1% with post-processing disabled, 4% with overlay, 6% with blend and 12.5% (1 fully loaded core) with full-postprocessing.

For the 720p sample, full post-processing caused color corruption and the FPS dropped down to 18fps. After a few seconds, visual corruption also occurred (image turned blocky and the blocks kinda randomly moved around). For the other sample, full post-processing took 8% of the CPU and ran at full framerate, but still had the same green lines as before.

For a 1080p sample, I resized the source of the smaller vid and encoded it to a resolution of 1920x1080 with similar settings as the 720p vid. Playback used 2% CPU. Enabling overlay or blend increased that to 8%.

Also of note, the ATI 4670 cannot handle 5 ref frames in DXVA mode with 1080p video.

tal.aloni

20th January 2010, 07:39

I suspect 3205 or 3206 work by tal_aloni on deinterlacing related files will be the cause of the bug.

Thanks for letting me know,
Edit:
I'll fix that today.

Tal

HeadlessCow

20th January 2010, 08:04

When the MPC DXVA filter detects subtitles (or the presence of DirectVobSub, I dunno how it really works) it doesn't load, allowing the subs to be handled by DirectVobSub. I think that the ffdshow DXVA filter should do the same thing if internal subtitle handling is turned off. As it is, there is just a NullTextRenderer inserted into the graph and the subtitles go nowhere :'(

Actually, I can't get ffdshow (direct or not) to load my subtitles embedded in an mkv file, so maybe I'm just doing something wrong here :-D

CiNcH

20th January 2010, 08:52

Does anybody know where one can quickly get a MKV sample with H.264 4.1 video and subtitles in a format that ffdshow can read (so no PGS please)?

tal.aloni

20th January 2010, 09:51

HeadlessCow,
I've been meaning to fix that in future betas:
currently, the DXVA decoder does not have input pin for subtitles.
also, when DXVA is loaded, DirectVobSub cannot operate. (it cannot post-process DXVA, only internal ffdshow filters can)

also, thanks for the cpu utilization tests.

p.s.
I'm debating whether to fix those full-post-processing bugs (the colorspace issue is one of them),
or just remove this mode.
as albain noted, our performance tests shows that we're only achieving 2% of the theoretical bandwidth,
but I can't figure out anything wrong we're doing.

HeadlessCow

20th January 2010, 14:21

Yeah, I know you can't have DXVA and DirectVobSub, but the way I've been running is to have the MPC-HC DXVA filter set up to use DXVA with fallback to ffmpeg. When a file has no subtitles, it'll decode using DXVA, when there are subs present it uses the ffmpeg decoder and DirectVobSub is able to do its job. It'd be nice if the ffdshow DXVA decoder did the same thing.

rsd78

20th January 2010, 15:26

STaRGaZeR

20th January 2010, 16:38

Any chance you guys could contact the author of the intel article? They list the name but not an email. Just a guess but maybe he is a fellow enthusiast as he references mpc-hc in it :).

I'd do that. DXVA + full postprocessing is worth the effort IMO.

MatMaul

20th January 2010, 20:01

@albain :
http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=6e3d7762f1d54dcaa783b67e370fb77ad73c8e79
:)

dann23

20th January 2010, 20:14

I have a problem with some movies when using dxva.some of them are not working with matroska splitter from mpchc website. the movie seems to play but the image is black. Should I post a sample?
And two suggestion.
1. please add support for MPEG2 in dxva.
2. this one is more complicated. don't know if it's possible. What I like about DXVA is that a cheap graphic card can decode the movie without much trouble. For me it;s about power consumption and silence. My card is a radeon 3850 with passive cooling and a 125w athlon x2 proccesor. You realize that using the CPU to watch movies is very loud. Not to mentions that the cpu is most of the time at 100% but the vga card is at 4-6% doing the same thing. So my suggestions is if it is possbile to make subtitles go directly to dxva render (not using overlay). Using no post processing takes 6-10% from cpu, but when using overlay it goes to 30-40%. Hope it is possible and somebody is willing to implement this for people like me.
And thank you for your hard work.

Nyquist

20th January 2010, 21:28

Beta 2 improves overlay mode visibility, and also adds Blend mode,
I'm not really sure if blend mode is very useful, because those read operations are very resource-hungry.
[full-processing-mode seems less and less practical, it's not fully implemented in this beta (and the previous one)]

While in Beta 1 the subs were working, in Beta 2 they don't.

On a Q9300 I get about 20% CPU load with Overlay, 22% with Blend and only about 10% using ffmpeg-mt.

tal.aloni

20th January 2010, 21:31

mark0077,
the doubling frames bug is fixed with rev. 3211,
I updated 4 filters: DGBob, KernelBob, Yadif, Framerate Doubler.
if there are any other filters that adds frames, let me know.

dann23,
are you referring to my beta2?
please clarify what exactly are you saying / asking.

regarding overlay / blend mode in beta 2:
I have to confess that there is some room for optimizations:

1. osd / subtitles are rendered 3 times for each frames instead of 1,
this is necessary to create opacity map without modifying or rewriting the osd / subtitles filter.

2. Right now the CPU is likely caching all overlay / blend reads and writes, this can be optimized more easily, but I don't have the time right now.

keep in mind that those optimizations are not very significant for a modern CPU (1-2%).

much more important IMO is to enable the text input pin for the DXVA decoder.

Tal

noee

20th January 2010, 22:16

if there are any other filters that adds frames, let me know.

I use avisynth to double framerate with the following script:

setmtmode(2)
Last=ffdshow_source()
setmemorymax(550)
setmtmode(2)
SeeSaw(sstr=1.45)
super = MSuper(pel=2,hpad=4,vpad=4)
backward_vec = MAnalyse(super,chroma=false, blksize=16, isb = true, search=5, searchparam=1)
forward_vec = MAnalyse(super, chroma=false, blksize=16)
MBlockFps(super, backward_vec, forward_vec, num=FramerateNumerator(last)*2, den=FramerateDenominator(last)*1, mode=1)
distributor()

This was broken after 3204 like the others. Might be worth a look too?

therealjoeblow

20th January 2010, 22:31

Also of note, the ATI 4670 cannot handle 5 ref frames in DXVA mode with 1080p video.

That's correct, ATI strictly enforces the H.264 profile/level High@L4.1 for HD content as developed/approved by the associations responsible for the HD DVD and BluRay Disc standards. Nvidia doesn't so they can generally decode L5.1@1080p video with DXVA.

If you are interested in all of the compliant combinations of resolution, ref. frames, b frames and b-pyramids, you can look at this page on AVS Forum:

http://www.avsforum.com/avs-vb/showthread.php?t=972503

Cheers,
The REAL Joe

albain

20th January 2010, 23:17

@albain :
http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=6e3d7762f1d54dcaa783b67e370fb77ad73c8e79
:)

Great, we will make the merge once we will have a stable version

tal.aloni

20th January 2010, 23:29

While in Beta 1 the subs were working, in Beta 2 they don't.

I've PMed Nyquist, the issue is solved.

Mr VacBob

21st January 2010, 00:31

I've changed the delay reporting API in ffmpeg-mt. Instead of the delay being has_b_frames + thread_count - 1, it's just has_b_frames now, matching mainline ffmpeg. I don't know if overestimated delay will cause a problem for you or not anyway.

tal.aloni

21st January 2010, 09:30

regarding VC-1 DXVA:
the "bug" is related to B frame ordering (bReorderBFrame variable),
MPC-HC filter behaves differently for each splitter,

we have started to imitate this behavior with rev. 3212
I would still like to implement a better solution, but it would require modifying some of the splitters involved.

CiNcH

21st January 2010, 10:58

Even though nobody here wants to communicate with me I want to point you to where Casimir once implemented Access Unit parsing for H.264 and VC-1 but did not release it, see MPCVideoDecFilter.cpp >= line 1524 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/mpcvideodec/MPCVideoDecFilter.cpp?revision=1540&view=markup).