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

tal.aloni

27th January 2010, 15:15

What does the internal subtitle renderer of MPC-HC use? That works with DXVA and has low overhead.

that's the first thing I asked casimir,
1. they are using Direct3D, they create a seperate DX surface and let the hardware merge the two surfaces using DX, however, in order to do so, they are using a custom renderer.
I believe you can only do it their way if you develop a custom renderer. (or serving a custom allocator presenter to the VMR9 renderer)

2. they get this great performace because they're not filling the entire surface, they're only drawing on a surface big enough to draw the subtitles [I think they are using multiple small surfaces] (you can't do it easily in ffdshow, especially not if the OSD is involved).

HeadlessCow

27th January 2010, 15:34

Oh yeah, one more thing. When playing VC1, the OSD showed up briefly when the video loaded, but wasn't visible after that.

Jeremy Duncan

27th January 2010, 16:17

What do you mean ? Do yo have his contact information ?

mike(insert at here)haali.net

rsd78

27th January 2010, 16:51

Anyone else able to report back any CPU usage comparison between latest beta (DXVA + Overlay) and just DXVA? Thanks

CiNcH

27th January 2010, 17:09

Beta 3 is great! With beta 2 I experienced a lot of judder with subtitles being used and an increase in CPU usage from < 10% to > 40% on a C2D E6420. With beta 3 now, playback seems perfect with a CPU usage of only < 20%, effectively cutting it in half.

rsd78

27th January 2010, 17:12

Also @Albain/Tal.Aloni,

Would Media Control now work with Beta3 to control subtitles? Thanks

onomatopellan

27th January 2010, 17:41

Great work with beta 3! :thanks:

It's very unstable (can't close the MPCHC without crashing like you said, cant' use Graphedit without crash) but I fixed it just replacing libavcodec.dll with the rv3217 XhmikosR's version. (rv3218 still crash BTW)

Overlay mode is very good, good quality and fast! In my AthlonXP2800 now I can watch 720p movies with subtitles with ~50% cpu usage (30% more than without Post processing) and karaoke is very fluid, awesome!
http://i49.tinypic.com/316kyyu.png

Something I've noticed is that in subs with fading (karaoke) the subtitles are somewhat transparent. These should be completely white for example:
http://i49.tinypic.com/snnxw0.png

Text input pin indeed has been enabled and I can use it now in Graphedit but it does detect the embedded sub in some mkv files and in some doesn't. External sub works without problem though. :confused:

tal.aloni

27th January 2010, 18:30

Something I've noticed is that in subs with fading (karaoke) the subtitles are somewhat transparent. These should be completely white for example:

well, oddly enough, that's actually on purpose,
you see, in YV12 / NV12 colorspace, 4 pixels (2x2) share the same color information (chroma), so if I would write the luma everytime I write the chroma, it would effectively limit the resolution by a factor of 1/4. (I've tried that, it looks aweful).

I guess I can write the chroma if I'm modifying 4 out of 4 pixels, it's not as fast though. I'm still experimenting.

Text input pin indeed has been enabled and I can use it now in Graphedit but it does detect the embedded sub in some mkv files and in some doesn't.
this shouldn't be different than the software decoder, regarding which format supported and which are not, I'm not an expert.
but I guess that now that we have DXVA with subs, we will have to improve.

tal.aloni

27th January 2010, 18:33

Guys, The crash starts with 3218!

Edit:
it seems pretty obvious why the crash is occuring @ 3218+ (w32thread.c):
if avcodec_thread_execute2 is called with count of 1 thread, than no thread would be allocated, and when trying to release with avcodec_thread_free, the crash would occur.

// One thread for DXVA mode
int numthreads=1;
libavcodec->avcodec_thread_init(avctx,threadcount=numthreads);

Edit:
I talked to the ffmpeg. I'll commit a fix soon.

HeadlessCow

27th January 2010, 18:45

this shouldn't be different than the software decoder, regarding which format supported and which are not, I'm not an expert.
but I guess that now that we have DXVA with subs, we will have to improve.

libass here we come! ;)

t seems pretty obvious why the crash is occuring @ 3218+:
if avcodec_thread_execute2 is called with count of 1 thread, than no thread would be allocated, and when trying to release with avcodec_thread_free, the crash would occur.

Nice find on the crash!

albain

27th January 2010, 19:17

Great work with beta 3!
Text input pin indeed has been enabled and I can use it now in Graphedit but it does detect the embedded sub in some mkv files and in some doesn't. External sub works without problem though. :confused:

It shouldn't, maybe some media types are missing

Could you post a sample and eventually debugview logs with working + non working samples ?

About Media Control, it should work with DXVA filter (the remote/keyboard filter is enabled)

arestarh

27th January 2010, 19:46

albain
Hello!
I'm again about problems with translation:
I can't open in translation mode dialogs:
http://i044.radikal.ru/0912/8c/4f224226244at.jpg (http://radikal.ru/F/i044.radikal.ru/0912/8c/4f224226244a.png.html)
And even I manually edit file of localization(add necessary strings), *Add* and *Reset* buttons in both dialogs and also dialog *Use ffdshow only in* is not appeared in GUI:
http://i056.radikal.ru/1001/8f/c5f527d8a0e5t.jpg (http://radikal.ru/F/i056.radikal.ru/1001/8f/c5f527d8a0e5.png.html)
simply, I can't translate this elements...

And about section of Subtitles in configuration dialog.
I can't translate this dialog:
http://s001.radikal.ru/i195/1001/5a/a492876a1c84t.jpg (http://radikal.ru/F/s001.radikal.ru/i195/1001/5a/a492876a1c84.png.html)

Edit:
Also, I can't translate following header(language file contains string "configuration=translation_of_this_header"):
http://i081.radikal.ru/1001/8b/9c44bb460e6dt.jpg (http://radikal.ru/F/i081.radikal.ru/1001/8b/9c44bb460e6d.png.html)

tal.aloni

27th January 2010, 19:47

crashing problem is fixed in rev. 3232
I've talked to ffmpeg devs, they have explained that avcodec_close() calls avcodec_thread_free(), so there's no need to call avcodec_thread_free() for the second time. (that's what caused the crash)

tal.aloni

27th January 2010, 23:28

Oh yeah, one more thing. When playing VC1, the OSD showed up briefly when the video loaded, but wasn't visible after that.

Thanks, this is fixed in beta 4,
however, there are still issues with VC-1, now the osd / subs will be shown only after ~100 frames. I'm not sure why.

also: overlay will not be "transparent" anymore, it now also writes chroma when 3 or 4 (out of 4) pixels (luma) are being written.
(it should be slightly slower, but not much)

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

patch
http://iknowu.net/files/public/ffdshow/DXVAPostProc/3233-DXVA-Post-Processing-Beta4.patch

HeadlessCow

28th January 2010, 00:33

now the osd / subs will be shown only after ~100 frames. I'm not sure why.

LOL! Tricky software! I'll check out the build tonight after celebrating my mom's birthday!

Jeremy Duncan

28th January 2010, 02:39

3233 patch for accurate frame seeking in avisynth (http://www.mediafire.com/?mdc4zzzo4tm)
generic beta (http://www.mediafire.com/?5zttvztwznt)
icl11 beta (http://www.mediafire.com/?qdhkd2jniyn)

leeperry

28th January 2010, 02:45

3233 patch for accurate frame seeking in avisynth (http://www.mediafire.com/?mdc4zzzo4tm)
generic beta (http://www.mediafire.com/?5zttvztwznt)
icl11 beta (http://www.mediafire.com/?qdhkd2jniyn)
thanks Jeremy, I'll look into them and report back!

the current official beta crashes sometimes at opening...but if I open it again, then it's fine?! it happens very rarely IME anyway, I'd say it works 99.99% of the time...good enough to me considering I use ColorMatrix(SD only)/LSF/GrainF3 on all my videos :devil:

CruNcher

28th January 2010, 07:59

littleD

28th January 2010, 10:03

Thanks, this is fixed in beta 4,
however, there are still issues with VC-1, now the osd / subs will be shown only after ~100 frames. I'm not sure why.
Here, subs may have slight delay. OSD shows immediately.

also: overlay will not be "transparent" anymore, it now also writes chroma when 3 or 4 (out of 4) pixels (luma) are being written.
(it should be slightly slower, but not much)
Yes, subs are white all the time.

Some vc-1 videos get cpu at 100%. And no crashes ofc.

onomatopellan

28th January 2010, 19:06

Testing beta4 and it's the best so far: no transparent subs, more stable and fast... great work!

@albain/tal.aloni: After testing lots of mkv files I have discovered in 80% of my collection embedded subs are not detected. So the problem maybe is not in ffdshow but in splitter (I'm using last haali) or something in the graph connection. Ffdshow software decoder detects the embedded sub without problem.

I noticed this: When subs are not shown I only have to delete de subtitle->In Text connection in GraphStudio and reconnect it again, and then the subs are shown without problem. :confused:
I have tried with all the problematic video files and now all the embedded subtitles are detected using the 'trick' above.

That's using GraphStudio/Graphedit, in MPC-HC embedded subs are not detected though.

These are the Debugview logs while using GraphStudio (playing the same video file):
LOG WHEN SUBS ARE NOT SHOWN (http://onomatopellan.pastebin.com/m2d7af829)

LOG WHEN SUBS ARE SHOWN (trick) (http://onomatopellan.pastebin.com/m7ffc8c22)

albain

28th January 2010, 20:45

tal.aloni

28th January 2010, 22:24

I commited DXVA post-processing to rev. 3237
The problem with VC-1 should be fixed.

Thanks to the beta testers, and especially thanks for Albain, who initiated this effort, and took a significant part of it along the way.

hardware blending is the only other viable option IMO besides surface overlay, the easiest implementation for ffdhow is by using DXVA 2.0 substreams (supported by ATI \ Nvidia).
(the DXVA 1.0 alternative is not supported by ATI \ Nvidia)

at the very least, now we have a method to fall back to.

albain

28th January 2010, 23:02

Thanks Tal, you're the best !

You did all the job, I just added a text pin lol :)

rsd78

28th January 2010, 23:21

I think this comes from the media types

I removed uncompress mediatypes but this is not a good idea because I guess that FFDShow DXVA may not be consulted for subtitles connection

Hi Albain,

My apologies but I couldn't quite decipher your answer. Did you change just now the way subs are handled with ffdshow dxva or that was something you had done before which may be the cause of the problem of embedded ones not being recognized?

If the latter, is this something that can be fixed?

Thanks!

albain

28th January 2010, 23:43

Hi Albain,

My apologies but I couldn't quite decipher your answer. Did you change just now the way subs are handled with ffdshow dxva or that was something you had done before which may be the cause of the problem of embedded ones not being recognized?

If the latter, is this something that can be fixed?

Thanks!

No I was referring to the very first version of ffdshow dxva that I made.

It has always been like that, and this is a supposition as I think that there is no reason why the dxva filter acts differently than the software decoder, at least for the connection part

I will digg this around but first a sample file would help

Sebastiii

29th January 2010, 00:06

Great men you are :)

So i'll need to test last version :)
Thx :)

onomatopellan

29th January 2010, 03:40

I will digg this around but first a sample file would help
This file has embedded subs and are shown in MPC-HC using ffdshow software decoder. If I use ffdshow DXVA then embedded subs are not detected though.

http://www.mediafire.com/?wnumkztyneo

thuan

29th January 2010, 05:33

Thanks to albain and tal.aloni that implemented DXVA and sub rendering with DXVA in ffdshow. I still have 2 problems with it though.

Sub bleeding and blocky
http://xs.to/thumb-ECA3_4B626276.jpg (http://xs.to/share-ECA3_4B626276.html)

And broken image when seeking that happens sometimes
http://xs.to/thumb-A38D_4B62643C.jpg (http://xs.to/share-A38D_4B62643C.html)

Tested at work on Intel G45, Windows Vista 64bit up to date BTW. I view my videos with Haali splitter. I also have the 9800GT with Windows 7 64bit at home and the 2nd problem happens there, too. I will check whether the first problem happens at my home computer configuration after work.

Thank you guys for the continuous development.

CruNcher

29th January 2010, 09:02

thuan

29th January 2010, 09:44

Unfortunately I haven't tested ffdshow DXVA decoder extensively enough to say the blocking problem also happens under normal playback, I will check later tonight or tomorrow.

clsid

29th January 2010, 14:27

@thuan, tal.aloni , albain, clsid
this kind of artifacting is exactly the problem i meant that isn't happening with MPC-HCs DXVA Decoder under heavy load 1080p 60 FPS but happens with ffdshow DXVA without even seeking @ all just in a normal playback situation especially after scene changes :)
There have been a lots of changes to the H.264 code in FFmpeg in the past two weeks. Maybe it is related to that and the DXVA code needs some work as well to adapt to the changes. MPC still uses a slightly older FFmpeg code base, as that is updated less often.

On a related note, libavcodec and ffmpeg-mt should give better performance now compared to any 2009 build. The gain is supposed to be a few %. It would be interesting to see some benchmarks.

clsid

29th January 2010, 14:36

I have a suggestion to make ffdshow DXVA a bit more robust. My idea is to adjust the "DirectShow control" functionality in the DXVA filter:
- Remove blacklist and compatibility manager
- Use an obligatory whitelist, which by default only contains the most commonly used players, and not the same huge list that the rest of ffdshow currently uses

The reason why I propose restricting the use of DXVA to known compatible applications is because DXVA is unreliable. For example bad drivers can cause video corruption and various other problems that do not occur with normal software playback. Another major issue are multiple decoder instances, DXVA only works in one instance at a time.

So DXVA should only be used in players, and not in any random DirectShow app, such as games and Explorer (thumbnailing). That way things stay within a controlled environment.

A side benefit of a small whitelist would also be that it is easier for a user to edit it, for example to only use DXVA in a specific player.

We also need to implement a good method to handle multiple decoder instances, so that only the first instance is allowed to use DXVA. Perhaps a mutex?

fastplayer

29th January 2010, 14:52

On a related note, libavcodec and ffmpeg-mt should give better performance now compared to any 2009 build. The gain is supposed to be a few %. It would be interesting to see some benchmarks.
Yep but there's something "odd" - in a good way - about libavcodec: CPU-load behavior is now very similar to ffmpeg-mt. In previous builds the CPU load would be like 80%/20% on core0/core1 when playing 1080p AVC content with libavcodec. Now both cores are evened out load-wise just like with ffmpeg-mt.

mark0077

29th January 2010, 15:08

clsid, could, when a second instance of ffdshow dxva fails to work, revert to non dxva. ie. don't use any mutex's, just try and if it fails, revert to non dxva?

HeadlessCow

29th January 2010, 16:05

Tested at work on Intel G45, Windows Vista 64bit up to date BTW. I view my videos with Haali splitter. I also have the 9800GT with Windows 7 64bit at home and the 2nd problem happens there, too. I will check whether the first problem happens at my home computer configuration after work.

Thank you guys for the continuous development.

thuan: could you do me a favor and try out the beta1 or beta2 build with the full processing mode to see if it drops frames like crazy? If the Intel guy wrote his code with an Intel graphics card, maybe you'll have better performance than the rest of us did. That would at least explain why he was able to get performance that is so much better than when tal.aloni used the code in ffdshow.

Caroliano

29th January 2010, 16:42

FFDShow's quantizer visualization and maybe also the "Frame mean quantizer" OSD info seems to be broken with H.264. Acording to Darkshikari:

The quantizer is only coded in the bitstream if there's coded coefficients in the block. This means that empty blocks (skip or otherwise) are displayed, when using the OSD, as using the quantizer of the previous block in raster-scan order.

I think that the correct behaviour would be to say that it is a empty block, maybe with an "/" instead of the number, for example. Any plans to correct this? FFDShow's OSD and visualizations is one of the main features of ffdshow for me (besides decoding, of course). It is really unfortunate that it is not displaying correct information, making it misleading and thus partially useless....

Original discussion and pictures: http://forum.doom9.org/showthread.php?t=152399

clsid

29th January 2010, 17:55

Yep but there's something "odd" - in a good way - about libavcodec: CPU-load behavior is now very similar to ffmpeg-mt. In previous builds the CPU load would be like 80%/20% on core0/core1 when playing 1080p AVC content with libavcodec. Now both cores are evened out load-wise just like with ffmpeg-mt.
The old slice based multi-threading patch has been disabled in libavcodec. Maybe it is related to that. But then I would expect all (decoding) load on a single core, instead of things being evened out. But keep in mind that the graphs in the Windows Task Manager will not always give a accurate view of reality. A single thread whose execution is constantly moved around between cores by the scheduler could for example show nicely evenly balanced graphs, while in reality all one core is doing all the work.

clsid, could, when a second instance of ffdshow dxva fails to work, revert to non dxva. ie. don't use any mutex's, just try and if it fails, revert to non dxva? Sure, if we can make it work like that it would of course be fine too. But keep in mind that this must be done during pin connection, so that can deny connection and give another filter a chance. Last time I tested in with MPC, playback just failed. I assume ffdshow will have the same problem, haven't tried yet. So the current implementation does not yet handle the situation adequately.

buletti

29th January 2010, 20:16

Now that there is a breakthrough in using DXVA with subtitles, is it likely that there will be real post processing, too? Applying actual video filters, especially via Avisynth, would be awesome and most beneficial (decode by GPU to save CPU cycles for post processing).
I understand that some post processing operations like scaling, color space or frame rate conversion will probably never ever work with DXVA. However, sharpening and denoising operations could probably work and would be greatly appreciated.

HeadlessCow

29th January 2010, 20:27

Well, right now it can't read the frame, just pass in something to put over the frame. Sharpening and denoising kinda need to know what the original video looks like :)

ikarad

29th January 2010, 20:35

No I was referring to the very first version of ffdshow dxva that I made.

It has always been like that, and this is a supposition as I think that there is no reason why the dxva filter acts differently than the software decoder, at least for the connection part

I will digg this around but first a sample file would help

Do you plan to add support of PGs subtitle because ffdshow doesn't recognized subtitles from blu-ray?

tal.aloni

29th January 2010, 20:44

sharpening and denoising operations could probably work and would be greatly appreciated.

HeadlessCow was right on the money.
the DXVA decoded frame ends up being written to USWC memory,
which was not designed for fast reading operations.

sharpening and denoising can be made to work with the beta 2, but you'll learn that it's unstable, and the CPU usage is greater than software decoding.

dann23

29th January 2010, 20:51

do you plan to add MPEG2 to be decoded using DXVA?

tal.aloni

29th January 2010, 21:01

do you plan to add MPEG2 to be decoded using DXVA?

I think that albain would share my view that if casimir (MPC-HC) will implement it, we will import it as well, but I don't really think it's worth the effort. mpeg2 decoding does not require much cpu power.

albain

29th January 2010, 21:02

Yes, also MPEG2 does not consume a lot of CPU

And MPEG2HD is a dead end (HDDVD)

hoborg

29th January 2010, 21:35

Hi.
By some reason i am not able to make DXVA + subtitles (and OSD) work.
Haali <-> FFDShow DXVA decoder Pin is connected, but no subtitles are displayed (EVR as renderer).
No problem in "normal" FFDShow.

Win7 + ATI 4770

EDIT:
Same result on XP:
http://www.volny.cz/hoborg/dxva+subs.jpg

tetsuo55

29th January 2010, 22:14

I think that albain would share my view that if casimir (MPC-HC) will implement it, we will import it as well, but I don't really think it's worth the effort. mpeg2 decoding does not require much cpu power.We already added it in http://sourceforge.net/apps/trac/mpc-hc/changeset/1552

dann23

29th January 2010, 22:38

We already added it in http://sourceforge.net/apps/trac/mpc-hc/changeset/1552

yes :D thank you. hope that albain will change his mind :)

tal.aloni

29th January 2010, 22:43

Hi.
By some reason i am not able to make DXVA + subtitles (and OSD) work.

have you enabled post-processing? (configuration > hardware acceleration)

Mr VacBob

29th January 2010, 23:08

On a related note, libavcodec and ffmpeg-mt should give better performance now compared to any 2009 build. The gain is supposed to be a few %. It would be interesting to see some benchmarks.

It should be more than 10% so far (it's not done yet). r21455 should improve high bitrates, but I didn't push it into mt yet.

There's also some MMX/SSE/2 inlined directly into the decoder now, so you'll see further improvements (~3%) if you can build with --cpu=i686 or higher.