LAV Filters - DirectShow Media Splitter and Decoders [Archive] - Page 184

nevcairiel

17th February 2012, 16:04

Hi nev, http://www.gokuai.com/f/664h14hU3p6dN440

CUVID, ok
copy back, failed
native,failed

Other dxva decoders I have are ok.

Fixed, the profile check wasn't 100% correct for constrained baseline.

I'll test with the WM ASF Reader when i get home, thanks for the hint that its causing the issues.
Fixed playback with the WM ASF Reader too.

wanezhiling

17th February 2012, 16:31

:thanks:Excellent!

CruNcher

17th February 2012, 16:34

What exactly is the problem playing that file on ATi's cards in DXVA mode with any decoder (MS DS, LAV, CoreAVC) ?

I didn't see any.

Im talking about Quicksync not ATI or Nvidia (ehh btw why do we still call it ATI), with Quicksync only Arcsoft and Mirillis does it correct all the other ISV fail :P

As i already said DXVA implementations can be very different and need adaption for some DSPs :)

nevcairiel

17th February 2012, 17:38

Small regression here. LAV Video, when using QS, causes MPEG-2 playback to be choppy inside DVBViewer. H.264 channels are fine, and MPEG-2 outside DVBViewer is fine too. It doesn't happen with the software decoder, so I'm guessing a timestamp issue with QS here.

Seems fine here.
Maybe its a deinterlacing field-order issue? In that case, i couldn't do anything, would have to complain to Eric - but its certainly possible its just encoded with wrong flags.

wanezhiling

17th February 2012, 17:44

nev, since native dxva has been implemented, so would you like to use "DXVA" FourCC for NV12 subtype as what CoreAVC 3.0.1 has done.:)
http://corecodec.com/products/coreavc/changelog
Use "DXVA" FourCC for NV12 subtype when it's used for DXVA connections
http://i.imgur.com/KFJJR.png

nevcairiel

17th February 2012, 17:48

nev, since native dxva has been implemented, so would you like to use "DXVA" FourCC for NV12 subtype as what CoreAVC 3.0.1 has done.:)
http://corecodec.com/products/coreavc/changelog

http://i.imgur.com/KFJJR.png

But why? Its NV12. :p

Pat357

17th February 2012, 17:48

The x86 version of the LAV video decoder makes the graphedt.exe from the Windows SDK crash when clicking on "DirectShow Filters" in the filter selection dialog. This is not the case for the x64 version.
You mean using graphedit64 with lav 64 bit does not crash ?

The crashing with lav32 installed is a known problem with graphedit 32b anyway; it's a bug in graphedit.

I thought graphedit64 would also crash, but I never tested it.

wanezhiling

17th February 2012, 18:03

:p Just looks pretty in PP.

Ignore me, ignore me.:p

Pat357

17th February 2012, 18:24

I'm using LAVF to serve avisynth for encoding but I'm noticing blocks with progressive VC-1 with a 9600GT (VP2) cuda enabled, here's a sample (http://www.mediafire.com/?mf493kovfh9da0p).
I used this method to deinterlace interlaced video. I noticed too that the first 2 frames where not perfect, but thought at that time it could be due buffering issues in "directshowsource".
(I used directshowsource with a .grf file, probably you did so too).
The result was fine : I got a progressive video to encode in x264, and I trimmed away the to bad frames in the beginning.
After I bought DGNV (well, did a donation at Neuron:D), I used this instead ; it can deinterlace too and works for h264/mpeg2/VC1 using CUVID decoding.
This way I don't need any CPU cycles to do the decoding and encoding goes faster.
I don't see any advantage to use LAV for avisynth anymore.

aufkrawall

17th February 2012, 18:57

LAV video decoder crashes when used via Avisynth DirectShowSource while decoding x264 RGB:
http://www.ld-host.de/uploads/thumbnails/23e0ff5e005124a7633fc3ebfa0a9599.png (http://www.ld-host.de/show/23e0ff5e005124a7633fc3ebfa0a9599.png)

Tested with latest nightly and 0.44.

nevcairiel

17th February 2012, 19:04

STaRGaZeR

17th February 2012, 19:04

Seems fine here.
Maybe its a deinterlacing field-order issue? In that case, i couldn't do anything, would have to complain to Eric - but its certainly possible its just encoded with wrong flags.

Nope, it isn't. I tried disabling all deinterlacing and it's still choppy, but this time around 25 fps instead of 50 ofc. The issue goes away if I revert this change: http://git.1f0.de/gitweb?p=lavfsplitter.git;a=commit;h=5bc0008be139ab10b599b2327cf04d7318f90d18, that's why 0.46 is fine.

Using lastest QS from trunk BTW.

nevcairiel

17th February 2012, 19:05

Nope, it isn't. I tried disabling all deinterlacing and it's still choppy, but this time around 25 fps instead of 50 ofc. The issue goes away if I revert this change: http://git.1f0.de/gitweb?p=lavfsplitter.git;a=commit;h=5bc0008be139ab10b599b2327cf04d7318f90d18

Blame Eric then, all i do is use his default settings. :p

aufkrawall

17th February 2012, 19:06

Works fine here. Outputs RGB32 like its supposed to.
It always seems to crash at the same position.
Is there a chance to get more debug data and send it to you?

mkanet

17th February 2012, 19:14

For some reason my media player (SageTV) wont playback a video media file at all if there's a subtitle stream embedded in the mkv or m2ts file.

So basically, any media file that causes the "Internal Script Command Renderer" filter to connect the LAV Splitter's Subtitle pin, my media player will just not playback the media file. I have no idea why; and, there's no way to fix this in the player since it doesn't have subtitle support.

Is there any way for me to disable the LAV Splitter's Subtitle pinout permanently? If I ever need to play a media file with subtitles, I just use TMT 5.

nevcairiel

17th February 2012, 19:16

STaRGaZeR

17th February 2012, 19:24

Blame Eric then, all i do is use his default settings. :p

But you did override the default settings before to make things run fine :sly:

Anyway I confirmed it, QS default is 16, choppy. 8 is fine. He changed it in r39. Reporting :p

nevcairiel

17th February 2012, 19:30

But you did override the default settings before to make things run fine :sly:

That was before he changed the settings to make that property independent from the timestamp setting. :D
There is also a slight problem there, reducing it back to 8 cuts quite a bit into H264 performance. Maybe it should be dependent on the codec? Anyhow, i'll let Eric add that logic in the decoder. ;)

mkanet

17th February 2012, 20:07

Thanks for the quick reply. BTW, just now, I added ffdshow's subtitle functionality via YV12 raw video. I am not at home right now (did this via RDP). I'm pretty sure this will allow me to have subtitle support even if SageTV doesn't support subtitles. I think I can even map subtitle options to my SageTV remote control (using Girder) if ffdshow supports hotkeys.

I just one one more question:
How do I configure LAV Splitter to ONLY and automatically display English subtitles during non-english speaking parts of the movie. I don't want to see subtitles for any other circumstance unless I manually change the setting. Did I configure it correctly below?

http://i67.photobucket.com/albums/h283/mkanet/th_LAV.jpg (http://i67.photobucket.com/albums/h283/mkanet/LAV.jpg)

Update to 0.46, it should be fixed.

STaRGaZeR

17th February 2012, 20:19

That was before he changed the settings to make that property independent from the timestamp setting. :D
There is also a slight problem there, reducing it back to 8 cuts quite a bit into H264 performance. Maybe it should be dependent on the codec? Anyhow, i'll let Eric add that logic in the decoder. ;)

Ah yes, idd :p. I think Eric is really pushing the speed thingy. The number of queues seems to affect both performance and stability, the need for different settings for different formats might just be hidding a bigger problem in how the whole thing is handled.

nevcairiel

17th February 2012, 20:33

Well the big difference for Live TV is that data isn't readily available when you need it, so the decoder has to be able to process every frame without much delay. With file-based playback, this isn't required, because you will always have enough data to completely fill the decoders queues, which smoothes out any spikes it may produce.

Maybe Eric did do some too drastic changes there.

Pat357

17th February 2012, 20:42

:p Just looks pretty in PP.
Ignore me, ignore me.:p
Just try to play an i444 (AYUV, NV24) or even better an Y410 (10 bit 4:4:4) file in PP with MadVR : PP crashes like hell !
I currently stopped using PP until this is fixed.
I you see in filters, there is always some "filter adapter" between Lav-video and MadVR.
My guess it that this thing can't handle 4:4:4, but there's no way to get rid of this, while it's completely obsolete there as it serves no function.

Pat357

17th February 2012, 21:46

Nev,

Is there a difference between the normal DXVA mode and DXVA copy back (besides copying frames of course) ?
I ask because I have something bizarre :
Do you remember that I had "green" screens on certain files with DVXA-CB (282.62 driver) ?
Well I am still on this driver (did not update) and with the normal DXVA mode, these files play just fine !!
I did try again with DXVA-CB --> all green screens.
normal DXVA -> all play OK !!
Each time I checked that DXVA was "active" and only for one file fall-back to softw happened, but for all other files DXVA was "active".

So this brings me to wonder whether the 285.36 driver is really the cause of the green screens.
Why can DXVA play these files while DXVA-CB can not ?
In fact i'm far more interested in DXVA-CB because of MadVR.

Can you please check why DXVA-CB fails and DXVA does not ?

Until now I mostly use CUVID for interlaced stuff (excellent deinterlacing, especially for VC1 as there is no "good" softw alternative.. oh, I forgot WM DMO, but...you know.. :rolleyes:).
For progressive content I mostly use SW because my of my very fast CPU. Also using CUVID puts my GTX-570 in highest power-state and as you know this is a serious overkill and very inefficient way just to watch some progressive video.
My CPU stays below 10% even for H264 1080p@60fps with 16 refs.

nevcairiel

17th February 2012, 21:52

Can you please check why DXVA-CB fails and DXVA does not ?

While i had that driver installed, i even tested Microsofts DXVA codec, and it too failed (black instead of green, but i can easily make it black if you wish)
Its just a driver bug, install another one if you want to use DXVA-CB. Not really worth spending my limited time on.

Debugging why DXVA fails is impossible, its a closed API, and only the driver developers could potentially tell you whats going on.

Mercury_22

17th February 2012, 22:05

nevcairiel

17th February 2012, 22:07

Nev can you add an ini file for settings (like with MPC-HC) cause this way it will be more easy to test different settings (SW DXVA DXVA-CB...) or even use different settings for x64 & x86 builds or ... make LAV "portable" :)

This seems like a bad idea. Too many headaches involved for a mostly useless feature.
No offense intended. :)

Mercury_22

17th February 2012, 22:17

This seems like a bad idea. Too many headaches involved for a mostly useless feature.
No offense intended. :)

Ok !
I was thinking to test the new DXVA but I was also trying to find a solution not to crash my system in case of bug since there are not separate settings (trying to test the new dxva only with the x86 version since the x64 version can crash explorer in case of a bug ...(like the last time :) )

nevcairiel

17th February 2012, 22:18

Explorers thumbnail thingy will never use a hardware decoder (not anymore, anyway)
I might separate 32 and 64-bit some time in the future, not sure yet if i want to.

Pat357

17th February 2012, 23:45

While i had that driver installed, i even tested Microsofts DXVA codec, and it too failed (black instead of green, but i can easily make it black if you wish)
Its just a driver bug, install another one if you want to use DXVA-CB. Not really worth spending my limited time on.

Debugging why DXVA fails is impossible, its a closed API, and only the driver developers could potentially tell you whats going on.

OK, I understand and agree with your point of view.
I also tested other DXVA decoders on the files that showed only green screens with LAV DXVA copy back.

ArcSoft decoder : h264/mpeg2 and wmv files play fine in dxva mode
Mainconcept decoders : h264/mpeg2 files play fine in dxva mode, wmv's falls back to softw in VC1 decoder.
Cyberlink PDVD9 decoder : h264/mpeg2 files play fine in DXVA and HAM mode. It looks that the HAM mode is somewhat similar to DXVA-CB ?
FFDshow DXVA : h264 files play fine, WMV didn't even connect.

Conclusion is that the above DXVA decoders do well on these files. Because the "direct" DXVA mode from LAV also plays these files OK, it's not clear as to why LAV DXVA-CB breaks on these files with the latest WHQL driver v285.36.
A newer driver seems to solve all problems with dxva-cb, so to me it seems that neither the driver or LAV-CB is the cause, but somehow in the interaction between LAV-CB and the 285.36 driver .

Nev, can you somehow check what info really goes to the renderer, or is this hidden due the DXVA API (like you send in a black box, but what happens after this is actually hidden).
Is it somehow possible to dump and read the dxva stream ?

nevcairiel

18th February 2012, 08:25

The DXVA decoder doesn't even indicate failure, it just produces a green image, but happily returning success.
It gives me no point to start looking.

Like i said before, its one broken driver, and there is no way to look into the driver what its doing there.
Its even listed as a documented bug in that driver.

It is quite interesting that native mode works (and the MS decoder doesn't), but i guess we should just be happy that it does work and not question the logic.
Maybe the copy-back mechanic is just broken for some reason, the driver only returns zeros when copying the frame - and in native mode it doesn't copy it.

jmone

18th February 2012, 09:05

I've not had the HW to try this (soon will)... what is the go with 3D BD playback in the direct show world these days or is it still only available from the commercial players?

NikosD

18th February 2012, 10:04

Signature System:

Two issues:

1) LAV DXVA native doesn't HW accelerate ANY H.264 clip of the type below (I have a lot of them as it is popular for movie trailers).
Movie Trailer (https://rapidshare.com/files/3984043544/Paranormal_Activity.mkv)

2) In latest DXVA checker 2.7.0, when you provide a non HW accelerated clip - like High10 H.264 - it enumerates LAV Video as "Unsupported", although it is supported of course in software mode.

It would be more convenient, if LAV Video was listed like CoreAVC, enumerating the supported restricted modes without red colour aka DXVA acceleration.

Try a High10 H.264 in DXVA checker to see what I mean.

nevcairiel

18th February 2012, 10:12

1) LAV DXVA native doesn't HW accelerate ANY H.264 clip of the type below (I have a lot of them as it is popular for movie trailers).
Movie Trailer (https://rapidshare.com/files/3984043544/Paranormal_Activity.mkv)

Fixed.

2) In latest DXVA checker 2.7.0, when you provide a non HW accelerated clip - like High10 H.264 - it enumerates LAV Video as "Unsupported", although it is supported of course in software mode
The software fallback has to be as reliable as possible, which means it'll fallback as early as possible. I won't be changing this for a "cosmetic" issue.

VipZ

18th February 2012, 12:28

Would it be possible to add support for WMA Lossless now as it seems ffmpeg support is much better with recent updates?

nevcairiel

18th February 2012, 12:54

Would it be possible to add support for WMA Lossless now as it seems ffmpeg support is much better with recent updates?

The decoder is still highly experimental, so no.
ffmpeg itself disables it unless i specifically ask it to enable experimental codecs.

VipZ

18th February 2012, 15:23

The decoder is still highly experimental, so no.
ffmpeg itself disables it unless i specifically ask it to enable experimental codecs.

ok thanks

nevcairiel

18th February 2012, 16:01

Here is a new test build:

http://files.1f0.de/lavf/LAVFilters-0.46-42-g46ff9fb.zip

As a quick summary, since 0.46 this is new:

- DXVA2 native, of course. Quite a bunch of issues fixed since the last test build
- Performance enhancements across the board (mostly for 8-bit content)
- Tweaked QuickSync settings
- Fraps multi-threading

Especially the Fraps multi-threading could also use a bit of testing to check that nothing breaks. I'm confident that it'll work ok, but my testing is somewhat limited.
Of course, DXVA2 native also likes being tested, but so far it looks pretty good.

I'm looking into releasing tomorrow, if nothing big comes up, so i can start working on new features without blocking release.

dukey

18th February 2012, 17:03

tested the dxva2 mode with my custom EVR presenter, works fine. Only comment is, could dxva be automatically selected upon install ? Or whatever is best for the end user.

nevcairiel

18th February 2012, 17:06

Who am i to judge whats best for the user? :)

dukey

18th February 2012, 17:09

Well good point, but if its available it would make sense to select it instead of software decoding by default :p

NikosD

18th February 2012, 18:08

Really good and fast DXVA native implementation

From my first preliminary test, looks like it is optimized for high bitrate clips.

Only one WMV3 clip with artifacts in both copy-back and native mode, on signature system

Download it here (https://rapidshare.com/files/3457679129/halo2_wmp9_WMV3_audio0x162.wmv)

nevcairiel

18th February 2012, 18:59

Only one WMV3 clip with artifacts in both copy-back and native mode, on signature system

Download it here (https://rapidshare.com/files/3457679129/halo2_wmp9_WMV3_audio0x162.wmv)

I couldn't find any hardware decoder that properly decoded this. ffmpegs software decoder also cannot.
Thats a kind of special file that was encoded with a beta version of the WMV encoder, which is not 100% compliant with WMV9/VC-1 specs.

CruNcher

18th February 2012, 19:28

Microsofts first ever released WMV9 demo streams (the kelsy streams) also show this issue with any decoder only Microsofts own Decoder isn't affected though it seems what ever causes these strange blocking for every other 3rd party decoder was never used later on again, It only shows itself in high motion every scene that suffers from this is high motion though mostly the scenes are short except for a stream that appeared on mplayers sample server that is even older then the kelsy streams (and i absolutely dont remember this one being a official Microsoft Release back then) their you even see it much longer in a high motion scene (Video_Smoothing.wmv) :).

nevcairiel

18th February 2012, 19:52

Obviously Microsoft used their own beta encoder to encode the first demo streams. :p
The fact remains that its not compatible with the WMV9/VC-1 specs

aufkrawall

18th February 2012, 20:07

No problem with multithreaded FRAPS decoding (how can I be certain that it's really MT?).
At least there is no noticeable difference to previous builds, ST was already fast enough.
Of course there's still the "issue" that FRAPS YV12 videos don't look right, neither with madVR as renderer compared to EVR *sigh*.

The problem when decoding x264 RGB with Avisynth seemed to be related to VirtualDub.
If I feed x264 with the same script like VD, decoding works flawlessly.

fairchild

18th February 2012, 20:45

I just watched Friday the 13th Blu-ray using the new test file and DXVA2 Native + EVR CP and playback was flawless. During the credits I seeked back using the MPC-HC D3D Fullscreen seek bar and it wasn't as smooth as when using software decoding, but I think this is standard with all DXVA2 decoding since the GPU has to catch up or something of the sort?

So now that this is implemented, is this one step closer to having native DXVA2 GPU decoding + MadVR in the future or is that just never gonna happen? I know DXVA2 copyback works with MadVR but it's decoding on my ATI is not as efficient as native DXVA2 decoding. (52 fps with DXVA2 copyback vs 147 fps with DXVA2 native on the crowdrun_1080p50 test file)

nevcairiel

18th February 2012, 21:07

During the credits I seeked back using the MPC-HC D3D Fullscreen seek bar and it wasn't as smooth as when using software decoding, but I think this is standard with all DXVA2 decoding since the GPU has to catch up or something of the sort?
On most PCs, software decoding is significantly faster then hardware decoding, which also accelerates seeks.

So now that this is implemented, is this one step closer to having native DXVA2 GPU decoding + MadVR in the future or is that just never gonna happen?
You have to ask madshi about that.
Note that copy back doesn't have to be that slow, should complain to ATI/AMD more. The 7000 series seem to have improved on that front.