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 > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 12th March 2012, 18:44   #9821  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by DragonQ View Post
I assumed that YADIF processing was on a separate thread to the decoding anyway?
You assumed wrong.
That isn't really all that trivial, because the decoder likes to re-use the same data buffer, so it need to wait until YADIF is done.

Changing that so that i can feed the decoder with its own buffer is kinda tricky.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 12th March 2012, 18:54   #9822  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Try this version, it adds multi-threading support to YADIF itself, in a rather simple way using OpenMP.

http://files.1f0.de/lavf/LAVFilters-0.49-yadifmt.zip

Performance went from 70 to 90 fps for me.
If i can move processing into a worker thread, it can probably make the yadif process nearly transparent.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 12th March 2012 at 18:57.
nevcairiel is offline   Reply With Quote
Old 12th March 2012, 19:31   #9823  |  Link
jmonier
Registered User
 
Join Date: Oct 2008
Posts: 187
Quote:
Originally Posted by nevcairiel View Post
Try this version, it adds multi-threading support to YADIF itself, in a rather simple way using OpenMP.

http://files.1f0.de/lavf/LAVFilters-0.49-yadifmt.zip

Performance went from 70 to 90 fps for me.
If i can move processing into a worker thread, it can probably make the yadif process nearly transparent.
This version makes things better but not good enough. It starts out with no dropped frames and the queues are filling up better but never fill up totally (as they do normally). After a few seconds, the dropped frames start to appear and continue to increase.

I can't help thinking that there's something here that's using more cpu than it should (especially since ffdshow works fine with the same components).

I haven't used GraphStudio before so I'll try to get setup and check with that as soon as I can.
jmonier is offline   Reply With Quote
Old 12th March 2012, 19:50   #9824  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
You aren't using RGB32 output in combination with YADIF, are you?

I have a 2600k myself, and it plays just fine. But it gets slow when i use RGB output.

PS:
GraphStudio doesn't need much setup, just run the tool and select "View -> Decoder Performance" in the menu. Make sure renderer is null renderer, select file and LAV Video as decoder, and go.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 12th March 2012 at 19:56.
nevcairiel is offline   Reply With Quote
Old 12th March 2012, 19:56   #9825  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 934
If you are using RGB32, definitely try turning that off cos it was certainly much slower in a few tests I did with LAV a while ago.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7
DragonQ is offline   Reply With Quote
Old 12th March 2012, 20:24   #9826  |  Link
jmonier
Registered User
 
Join Date: Oct 2008
Posts: 187
I got GraphStudio running. All output formats were checked but I unchecked RGB32 and RGB24 just to be safe and there was no difference.

With the NEW build I get 45 fps without YADIF and 66 fps with. I have no idea why mine should be so much slower than yours although mine is the non-K version. I remember something about the K version allowing access to the on-chip video, but I don't know what difference that would make and I could be mistaken anyway. In any case, I have the P67 chipset so I wouldn't have access to on-chip video. At least we know what the difference is between your's and mine even if we don't know why it should be.

CORRECTION: These numbers are on my i7-950 test machine. I still don't think that it should be that much slower, however. Later this afternoon (evening for you?), I'll get numbers off the i7-2600 machine.

Last edited by jmonier; 12th March 2012 at 20:30.
jmonier is offline   Reply With Quote
Old 12th March 2012, 20:42   #9827  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
For the record, i just benchmarked ffdshow on that VC-1 sample with wmv9 and YADIF, and i only get 63 fps (90 fps for LAV).

Maybe you don't have "Double Framerate" checked in ffdshows YADIF? (its off by default)
If thats the case, you can set LAV to 25/30p to get the same effect. It'll need only half the processing power that way.

I'm now working on moving YADIF onto a worker thread to see what happens. Will be a while though, Inter-Thread-Communication is always a headache.

PS:
Its already evening.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 12th March 2012 at 20:45.
nevcairiel is offline   Reply With Quote
Old 12th March 2012, 22:49   #9828  |  Link
jmonier
Registered User
 
Join Date: Oct 2008
Posts: 187
"Double Framerate" in ffdshow WAS off, however I set it on and everything still worked OK even on my i7-950. It benchmarked at 45 fps either way, so apparently "Double Framerate" is not working (or is done at no cost somehow?). It's fairly recent (3964 Jan 3 2012), what version are you using?

I checked decoding on my i7-2600 and it was 53 fps with YADIF off and 60 with YADIF on using 0.49. It went up to 80 using 0.49-yadifmt. It works perfectly with that build - no dropped frames and queues full (or almost) at all times.

I think that we're on the same page now. It looks like your 2600K is about 10% faster than my 2600 (and that made all the difference). Maybe it's overclocked?

For anyone reading this, I should emphasize that, in my experience, many vc1 interlaced files will work fine even with the original 0.49 build, but others won't. I don't know how to tell in advance which is which, however. It is very dependent on cpu speed. The Microsoft wmv decoder (even outside LAV Video) will have trouble with some vc1 interlaced files with all but the fastest cpu's.
jmonier is offline   Reply With Quote
Old 12th March 2012, 22:50   #9829  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by jmonier View Post
I've tried several different settings in madVR (including no, no, no, fw(s)) with no change. Basically the madVR queues are always almost empty indicating that LAV Video is not able to keep up.
I just checked your clip and, yes, I do see what you see.

LAV CUVID + HW interlacing : plays smooth
LAV (WMO) + Madvr (deinterlacing) : smooth
LAV (WMO) + yadif :
the first half of the clip, I see no dropped frames.
However, I see the decoder queue going down. Normally it stays at 15-16 (complete filled).
The second half of the clip, I notice a very low decoder queue (6 and lower) and at 80% of the clip, it starts dropping frames.

My first thought was it 's because both the WMO decoder and LAV-yadif are not multi-threaded.
Without yadif, the WMO decoder tops on 105 fps on my system, so that would mean that yadif is taken *a lot* resources.

The ffdshow implementation of Yadif is however MT IIRC, that's probably the reason why it runs smoother with the DMO decoder.

To make it simple for now, just disable yadif and let Madvr or EVR do the de-interlacing : it's faster and will give a superior result compared to yadif.

Nev : is making yadif multi-threaded still on your to do list ?

Last edited by Pat357; 12th March 2012 at 22:56.
Pat357 is offline   Reply With Quote
Old 12th March 2012, 23:26   #9830  |  Link
dead_screem
Registered User
 
Join Date: Jan 2005
Posts: 105
Is it just me or is the "Use Stream Aspect Ratio" option in LAV Video broke? Even with it checked, it always uses the container AR. I would think with that option checked it should be ignoring the container AR (passed from the splitter), right?

Last edited by dead_screem; 12th March 2012 at 23:29.
dead_screem is offline   Reply With Quote
Old 13th March 2012, 00:00   #9831  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by jmonier View Post
I think that we're on the same page now. It looks like your 2600K is about 10% faster than my 2600 (and that made all the difference). Maybe it's overclocked?

For anyone reading this, I should emphasize that, in my experience, many vc1 interlaced files will work fine even with the original 0.49 build, but others won't. I don't know how to tell in advance which is which, however. It is very dependent on cpu speed. The Microsoft wmv decoder (even outside LAV Video) will have trouble with some vc1 interlaced files with all but the fastest cpu's.
That's why it's nice to have HW accelerated video using your GPU.

Tested with GraphstudioNext :
CUVID + HW interlacing 50/60 : 138 fps
DXVA-CB (no deinterlacing) : 69 fps
DXVA-CB + yadif MT (LAV) : 137 fps

It seems that yadif MT on my system can keep up with 69 fps coming in from VP and outputting 2*69 = 138 fps.
In this combination there is no noticeable slowdown because of yadif mt anymore.
It seems in general if the HW-modes can handle the stream, they don't suffer from performance degradation with certain VC-1 files like the WMO does.
Pat357 is offline   Reply With Quote
Old 13th March 2012, 00:00   #9832  |  Link
jmonier
Registered User
 
Join Date: Oct 2008
Posts: 187
Quote:
Originally Posted by Pat357 View Post
I just checked your clip and, yes, I do see what you see.

My first thought was it 's because both the WMO decoder and LAV-yadif are not multi-threaded.
Without yadif, the WMO decoder tops on 105 fps on my system, so that would mean that yadif is taken *a lot* resources.

The ffdshow implementation of Yadif is however MT IIRC, that's probably the reason why it runs smoother with the DMO decoder.

To make it simple for now, just disable yadif and let Madvr or EVR do the de-interlacing : it's faster and will give a superior result compared to yadif.

Nev : is making yadif multi-threaded still on your to do list ?
A lot of what you say has been covered in posts subsequent to the one of mine that you replied to.

I'm fully aware of the value of the madVR de-interlacer. I use Zoomplayer and in order to use subtitles I need the de-interlacing done prior to the renderer so it's not an option for general use right now. I do use the wmv decoder directly to the madVR de-interlacer for vc1 right now since there is very little vc1 interlaced material and thus the subtitle problem is not a big one. I'd rather use LAV Video for everything, however, so that's why I was trying this solution.
jmonier is offline   Reply With Quote
Old 13th March 2012, 00:03   #9833  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by dead_screem View Post
Is it just me or is the "Use Stream Aspect Ratio" option in LAV Video broke? Even with it checked, it always uses the container AR. I would think with that option checked it should be ignoring the container AR (passed from the splitter), right?
If the stream has an aspect ratio, it should take this one.
Even when that option is checked and the stream has no aspect ratio, then it has no choice then take the one from the container.
Pat357 is offline   Reply With Quote
Old 13th March 2012, 00:07   #9834  |  Link
jmonier
Registered User
 
Join Date: Oct 2008
Posts: 187
Quote:
Originally Posted by Pat357 View Post
That's why it's nice to have HW accelerated video using your GPU.
It's fine if Nvidia works for you. For reasons unrelated to video decoding, it doesn't work for me. DXVA on ATI/AMD is not as clean so I prefer software decoding.
jmonier is offline   Reply With Quote
Old 13th March 2012, 00:15   #9835  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by jmonier View Post
A lot of what you say has been covered in posts subsequent to the one of mine that you replied to.

I'm fully aware of the value of the madVR de-interlacer. I use Zoomplayer and in order to use subtitles I need the de-interlacing done prior to the renderer so it's not an option for general use right now. I do use the wmv decoder directly to the madVR de-interlacer for vc1 right now since there is very little vc1 interlaced material and thus the subtitle problem is not a big one. I'd rather use LAV Video for everything, however, so that's why I was trying this solution.
Is dxva-cb + yadiff or cuvid with HW deinterlacing not an option ?
Ah.. you must have a GPU with slow copy back : ATI ?
On Nvidia, you would have the above very fast options.

Edit : you were a tad faster then me

Last edited by Pat357; 13th March 2012 at 00:19.
Pat357 is offline   Reply With Quote
Old 13th March 2012, 03:10   #9836  |  Link
magic144
Registered User
 
Join Date: May 2005
Posts: 395
@dead_screem - I think it very much depends on the player and the settings therein...

which player are you using
I had to take the time to learn what all the settings in ZP did recently, and how they interacted with LAV re: AR.
magic144 is offline   Reply With Quote
Old 13th March 2012, 04:03   #9837  |  Link
dead_screem
Registered User
 
Join Date: Jan 2005
Posts: 105
Quote:
Originally Posted by magic144 View Post
@dead_screem - I think it very much depends on the player and the settings therein...

which player are you using
I had to take the time to learn what all the settings in ZP did recently, and how they interacted with LAV re: AR.
MPC-HC.

And player shouldnt matter, at all.

for instance a file can have two different aspect ratios stored, one in the container and the one in the video stream. If a file has for instance 16:9 aspect in the container and 4:3 in the video stream. LAV Splitter will pass the 16:9 aspect from the container to the video decoder, but LAV Video just passes on the 16:9 container aspect to the Renderer instead of ignoring it and passing 4:3 what was in the video stream to the renderer. I tested with MPEG-2 and H.264/MPEG-4 AVC.

Ofcourse LAV would have no way to determine which aspect in the file is correct, thats what I thouht this option was for. But it doesn't appear to do anything.
dead_screem is offline   Reply With Quote
Old 13th March 2012, 05:13   #9838  |  Link
magic144
Registered User
 
Join Date: May 2005
Posts: 395
@dead_screem
hmm, I had the opposite experience with ZP...
I wanted to remux an h.264 stream so as to set a container AR to override the stream's AR (which had been wrongly encoded)
if I unchecked the LAV setting it would work, and if I checked it, it would further depend on some ZP-specific interpretation options...

on the other hand, I tried the newly remuxed file in MPC-HC and it just used the container's AR - using the built-in decoder

EDIT - just tried MPC-HC with LAV Video on my test clip - it seems to behave as you would want - i.e. if I check the LAV setting, the video is rendered at the stream AR, but if I uncheck it, it uses the container AR...

MPC-HC 1.6.0.4014, LAV 0.49, EVR...
magic144 is offline   Reply With Quote
Old 13th March 2012, 05:27   #9839  |  Link
dead_screem
Registered User
 
Join Date: Jan 2005
Posts: 105
Quote:
Originally Posted by magic144 View Post
EDIT - just tried MPC-HC with LAV Video on my test clip - it seems to behave as you would want - i.e. if I check the LAV setting, the video is rendered at the stream AR, but if I uncheck it, it uses the container AR...

MPC-HC 1.6.0.4014, LAV 0.49, EVR...
What format of video is your test clip? small enough to put online somewhere so I can test?
dead_screem is offline   Reply With Quote
Old 13th March 2012, 05:38   #9840  |  Link
magic144
Registered User
 
Join Date: May 2005
Posts: 395
This is it (it's only 3MB):-
http://www.mediafire.com/download.php?yje5lzz1wqkqvun

the vid stream is 1024*720, but needs to be displayed at 16:9 AR...
(I set the container display options to 1280*720)
magic144 is offline   Reply With Quote
Reply

Tags
decoders, directshow, filters, splitter

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 22:27.


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