Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th January 2010, 20:45   #10521  |  Link
albain
Media Control author
 
Join Date: Dec 2006
Location: Paris
Posts: 1,014
Quote:
Originally Posted by onomatopellan View Post
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.
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

LOG WHEN SUBS ARE SHOWN (trick)
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
albain is offline   Reply With Quote
Old 28th January 2010, 22:24   #10522  |  Link
tal.aloni
Registered User
 
Join Date: Sep 2008
Posts: 496
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.
tal.aloni is offline   Reply With Quote
Old 28th January 2010, 23:02   #10523  |  Link
albain
Media Control author
 
Join Date: Dec 2006
Location: Paris
Posts: 1,014
Thanks Tal, you're the best !

You did all the job, I just added a text pin lol
albain is offline   Reply With Quote
Old 28th January 2010, 23:21   #10524  |  Link
rsd78
Registered User
 
Join Date: Jan 2009
Posts: 73
Quote:
Originally Posted by albain View Post
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!
rsd78 is offline   Reply With Quote
Old 28th January 2010, 23:43   #10525  |  Link
albain
Media Control author
 
Join Date: Dec 2006
Location: Paris
Posts: 1,014
Quote:
Originally Posted by rsd78 View Post
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

Last edited by albain; 28th January 2010 at 23:46.
albain is offline   Reply With Quote
Old 29th January 2010, 00:06   #10526  |  Link
Sebastiii
Registered User
 
Join Date: Oct 2009
Location: France
Posts: 615
Great men you are

So i'll need to test last version
Thx
__________________
HTPC : i7 920 6Go Win10(x64) / Nvidia 1050Ti / P6T Deluxe / Harman-Kardon AVR-355.
Sebastiii is offline   Reply With Quote
Old 29th January 2010, 03:40   #10527  |  Link
onomatopellan
Registered User
 
Join Date: Jan 2010
Posts: 47
Quote:
Originally Posted by albain View Post
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
onomatopellan is offline   Reply With Quote
Old 29th January 2010, 05:33   #10528  |  Link
thuan
Registered User
 
Join Date: Sep 2005
Location: Vietnam, HCM City
Posts: 262
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


And broken image when seeking that happens sometimes


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.

Last edited by thuan; 29th January 2010 at 10:14.
thuan is offline   Reply With Quote
Old 29th January 2010, 09:02   #10529  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,926
@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
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 29th January 2010 at 09:07.
CruNcher is offline   Reply With Quote
Old 29th January 2010, 09:44   #10530  |  Link
thuan
Registered User
 
Join Date: Sep 2005
Location: Vietnam, HCM City
Posts: 262
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.
thuan is offline   Reply With Quote
Old 29th January 2010, 14:27   #10531  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,643
Quote:
Originally Posted by CruNcher View Post
@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.
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 29th January 2010, 14:36   #10532  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,643
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?
__________________
MPC-HC 2.1.7.2

Last edited by clsid; 29th January 2010 at 14:38.
clsid is offline   Reply With Quote
Old 29th January 2010, 14:52   #10533  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
Quote:
Originally Posted by clsid View Post
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.
fastplayer is offline   Reply With Quote
Old 29th January 2010, 15:08   #10534  |  Link
mark0077
Registered User
 
Join Date: Apr 2008
Posts: 1,106
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?
mark0077 is offline   Reply With Quote
Old 29th January 2010, 16:05   #10535  |  Link
HeadlessCow
Registered User
 
Join Date: Nov 2002
Posts: 131
Quote:
Originally Posted by thuan View Post
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.
HeadlessCow is offline   Reply With Quote
Old 29th January 2010, 16:42   #10536  |  Link
Caroliano
Registered User
 
Join Date: Feb 2005
Location: São Paulo, Brazil
Posts: 392
FFDShow's quantizer visualization and maybe also the "Frame mean quantizer" OSD info seems to be broken with H.264. Acording to Darkshikari:

Quote:
Originally Posted by Dark Shikari View Post
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
Caroliano is offline   Reply With Quote
Old 29th January 2010, 17:55   #10537  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,643
Quote:
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.

Quote:
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.
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 29th January 2010, 20:16   #10538  |  Link
buletti
Registered User
 
Join Date: Jun 2007
Posts: 42
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.
buletti is offline   Reply With Quote
Old 29th January 2010, 20:27   #10539  |  Link
HeadlessCow
Registered User
 
Join Date: Nov 2002
Posts: 131
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
HeadlessCow is offline   Reply With Quote
Old 29th January 2010, 20:35   #10540  |  Link
ikarad
Registered User
 
Join Date: Apr 2008
Posts: 546
Quote:
Originally Posted by albain View Post
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?
ikarad is offline   Reply With Quote
Reply

Tags
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.