LAV Filters - DirectShow Media Splitter and Decoders

[aufkrawall]

Is there a chance to see channel downmixing to stereo with v.0.47 or 0.48? :)

Thanks for the new version.

[Alexey1975]

Hi, Nevcairiel !

LAV Video Decoder not always switch to hardware mode (for ex.: when using DVB Viewer with H.264 streams). In this case, the decoder reports that hardware acceleration is "Available", but not "Active".
It happens not quite often, but still...
Maybe 'Pure Hardware Mode' option for LAV Video Decoder will solve it?

Intel P4@4GHz, GTX560Ti

[nevcairiel]

There is always a reason when it decides to switch to software mode, if it wouldn't do it, it would potentially mean that playback would fail.
Its certainly possible there is somewhere a small issue that makes it fail when it wouldn't need to, but then that should be fixed and not some mode added that bypasses the checks.

[Alexey1975]

And yet, I will be grateful to you if I'll be able to decide something... at least in the option "Pure Hardware Mode". ;)
Thank you for great Filters! :)

[CruNcher]

Alexey are you sure the Stream isn't 4:2:2 ? ;) a pure hardware mode wouldn't help in that case as you would only see Garbage

@ Nev

DXVA2 Copy back does really well

https://forum.doom9.org/showpost.php?p=1558039&postcount=754

though Intel got the Kernel pressure nicely under control or is this a bug ?

[dead_screem]

So does the CUDA header update to 4.1 break lav comptibility with CUDA 3.x drivers?

[nevcairiel]

So does the CUDA header update to 4.1 break lav comptibility with CUDA 3.x drivers?

The headers were for 4.0 already before, did it still work for you? :p
In short, not it shouldn't have any impact, unless i start using new functions.

[DragonQ]

Huh? There's a CUDA 4.1? How come on the nVidia site none of the GPUs listed support anything beyond 2.1?

[nevcairiel]

Huh? There's a CUDA 4.1? How come on the nVidia site none of the GPUs listed support anything beyond 2.1?

You misinterpret the specs.
There is GPU Compute capability, which tops out at 2.1 right now, and specifys which features are supported by the GPU.

The CUDA SDK version is just the software version to match, and support only depends on drivers.

[Alexey1975]

Strange issue: using any nVidia GeForce driver since 285.62 and later, cause the problem - image crumbles, tearing into squares, etc. But if I use any earlier driver - there is no problem.
The situation repeating with every new driver release! Any version of LAV Video with CUVID acceleration faces the problem. With CoreAVC Decoder, which uses CUDA too, the same thing!
With decoders that uses DXVA everything OK with any driver...

Can someone experienced and knows how to fix?

[fastplayer]

Typo in decoder/LAVAudio/LAVAudio.rc, line 112:
configura --> configure

[nevcairiel]

Typo in decoder/LAVAudio/LAVAudio.rc, line 112:
configura --> configure

But i like a's. :(

[fastplayer]

Then leave it like that as a treat! :D

[dead_screem]

The headers were for 4.0 already before, did it still work for you? :p
In short, not it shouldn't have any impact, unless i start using new functions.

oh, well thats good to know.

[Razoola]

I have upgraded to 046 and since I have had a couple of system hard lockups when hardware decoder is set to none. No locks if its set to a hardware decoder. This has only started with 046, 045 was fine with decoder set to none.

edit, please ignore this.. I think it was a system issue.

[kolak]

Golden solution for dithering is Floyd-Steinberg+bit of random noise, but ordered+bit of noise will be sufficient in most cases and much faster. Both ordered and random by itself have visible side effects.

[DragonQ]

You misinterpret the specs.
There is GPU Compute capability, which tops out at 2.1 right now, and specifys which features are supported by the GPU.

The CUDA SDK version is just the software version to match, and support only depends on drivers.
I see, thanks.

[Reino]

- Improved Fraps decoding with EVRFor FPS1(yuvj420p) files could you automatically apply TV-levels with VMR-9 Renderless as well as you've done for EVR. The only thing left for both renderers now is BT.709->BT.601 luma conversion and LAV can perfectly decode Fraps files in YV12 mode.
- Multi-threaded decoding for Lagarith- LAGS(rgb24): No problem
- LAGS(yuv420p): No problem
- LAGS(YUY2 / YUV 4:2:2 / yuv422p?) (http://www.mediafire.com/?8l2oabzde53fl8n): Splitter fails. With MPC Avi Source + LAV Decoder the file opens but no image and stays at 0:00. Only MPC Avi Source + LAGS vfw decoder works fine.
- Support for Snow and FFV1SoC_[SNOW+Vorbis].mkv (http://www.mediafire.com/?269b86gmje71r2d): Opens but no image and stays at 0:00. With MPC Matroska Source + LAV Decoder there's no image either, but at least the Vorbis stream is playing.

About FFV1, it all plays fine, but what exactly is "bgr0" for a colorspace? I'm not at all convinced atm FFV1(RGB32) is actually a lossless format. Output is completely different compared to Uncompressed, HFYU, LAGS, MLCY, and MSUD (RGB32).

VP61 issue:
- predator2_vp61.avi (http://samples.mplayerhq.hu/V-codecs/VP6/predator2_vp61.avi) (VP61): No problem
- vid.avi (http://samples.mplayerhq.hu/V-codecs/VP6/vid.avi) (VP61+MP3): Opens but no image and stays at 0:00. With MPC Avi Source + LAV Decoder there's no image either, but at least the MP3 stream is playing.

[cegy]

since 0.46 i have notice a odd bug with decoding. to make sure it wasn't just that 1 build so i tryed the nightly from http://roy.orz.hm/lavf-w32-nightlies/lavf-my120213-b92b5da.7z which still gives me the same problem, it seems it picky on how the .ts has been saved i have uploaded a sample so you can see what the problem could be. video sample (http://www.mediafire.com/?5vqi5qal7f89bh5)

0.46 slow
http://i.imgur.com/emToX.png

0.45 fast (normal it will be over 2x as fast on a bigger sample)
http://i.imgur.com/93BYu.png

[egur]

Version 0.27 beta is out with the following changes:
* Optimized code path to high performance on high bitrate clips.
* FFDShow rev4322

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

[CruNcher]

For FPS1(yuvj420p) files could you automatically apply TV-levels with VMR-9 Renderless as well as you've done for EVR. The only thing left for both renderers now is BT.709->BT.601 luma conversion and LAV can perfectly decode Fraps files in YV12 mode.
- LAGS(rgb24): No problem
- LAGS(yuv420p): No problem
- LAGS(YUY2 / YUV 4:2:2 / yuv422p?) (http://www.mediafire.com/?8l2oabzde53fl8n): Splitter fails. With MPC Avi Source + LAV Decoder the file opens but no image and stays at 0:00. Only MPC Avi Source + LAGS vfw decoder works fine.
SoC_[SNOW+Vorbis].mkv (http://www.mediafire.com/?269b86gmje71r2d): Opens but no image and stays at 0:00. With MPC Matroska Source + LAV Decoder there's no image either, but at least the Vorbis stream is playing.

About FFV1, it all plays fine, but what exactly is "bgr0" for a colorspace? I'm not at all convinced atm FFV1(RGB32) is actually a lossless format. Output is completely different compared to Uncompressed, HFYU, LAGS, MLCY, and MSUD (RGB32).

VP61 issue:
- predator2_vp61.avi (http://samples.mplayerhq.hu/V-codecs/VP6/predator2_vp61.avi) (VP61): No problem
- vid.avi (http://samples.mplayerhq.hu/V-codecs/VP6/vid.avi) (VP61+MP3): Opens but no image and stays at 0:00. With MPC Avi Source + LAV Decoder there's no image either, but at least the MP3 stream is playing.

VP6 Interlaced is not supported by ffmpeg yet

[nevcairiel]

- LAGS(YUY2 / YUV 4:2:2 / yuv422p?) (http://www.mediafire.com/?8l2oabzde53fl8n): Splitter fails. With MPC Avi Source + LAV Decoder the file opens but no image and stays at 0:00. Only MPC Avi Source + LAGS vfw decoder works fine.

YUY2 Lagarith is currently not supported by the decoder, and i guess also causes failure in the splitter for the same reasons.


About FFV1, it all plays fine, but what exactly is "bgr0" for a colorspace?

BGR0 is 32-bit RGB without an alpha channel. It matches RGB32, while BGRA matches ARGB32.

since 0.46 i have notice a odd bug with decoding.
If you're using the Intel QuickSync decoder, then thats a known bug. In any case, you should always mention what decoder you're referring to. (Software, CUVID, QuickSync, DXVA)

[egur]

since 0.46 i have notice a odd bug with decoding. to make sure it wasn't just that 1 build so i tryed the nightly from http://roy.orz.hm/lavf-w32-nightlies/lavf-my120213-b92b5da.7z which still gives me the same problem, it seems it picky on how the .ts has been saved i have uploaded a sample so you can see what the problem could be.
...

In my test clips, 0.46 was faster.
Using the 0.27 QS DLL, I managed to get ~400fps on this clip.

The famous Samsung Oceanic Life clip now runs at 225fps instead of 145. LAV 0.45 ran the same clip at 156fps.
BTW, ffdshow runs the Samsung clip at 270fps.

All benchmarks used LAV splitter as source and were run twice.

[cegy]

In my test clips, 0.46 was faster.
Using the 0.27 QS DLL, I managed to get ~400fps on this clip.

The famous Samsung Oceanic Life clip now runs at 225fps instead of 145. LAV 0.45 ran the same clip at 156fps.
BTW, ffdshow runs the Samsung clip at 270fps.

All benchmarks used LAV splitter as source and were run twice.


this was not with quicksync itself and not to sound funny but that .ts has some decoding issue when using the software decoder am not sure what or even why that is but i would like nevcairiel to look into why this is if you need a good sample just ask but that is sample i posted is very slow at decoding and as you can see in the pics that 0.46 is slower

[nevcairiel]

this was not with quicksync itself and not to sound funny but that .ts has some decoding issue when using the software decoder am not sure what or even why that is but i would like nevcairiel to look into why this is if you need a good sample just ask but that is sample i posted is very slow at decoding and as you can see in the pics that 0.46 is slower

120 fps is very slow? :)

Anyway, i found the issue, need to think how to properly solve it.

[cegy]

uploaded a sample that is ~3m30s long and as you can see in this pic that yes 120 fps is slow say that i've been getting thing a easy ~600fps untill this decoding bug happened. by the way what was the problem nevcairiel? (i'll been using 0.45 untill this problem as been fixed) good .ts sample (http://www.mediafire.com/?87l5a1zgfwzasia)

http://i.imgur.com/3Ny29.png

[Pat357]

Seems that cegy is right : there seems something wrong with the decoding (h264) from this file : in my benchmark I got about the same results.
Strange is that the decoding seems to be limited to 1 thread.:(
I tested with 12 threads and with 1 thread : same result !!
During the benchmark, I had a CPU load between 5-7 % (read from taskmanager), this should to be 50-70% or higher when testing with 12 threads.

Tested on i7-970@3.7/ 6+6 cores.

[cegy]

Seems that cegy is right : there seems something wrong with the decoding (h264) from this file : in my benchmark I got about the same results.
Strange is that the decoding seems to be limited to 1 thread.:(
I tested with 12 threads and with 1 thread : same result !!
During the benchmark, I had a CPU load between 5-7 % (read from taskmanager), this should to be 50-70% or higher when testing with 12 threads.

Tested on i7-970@3.7/ 6+6 cores.

thank you for confirming this :thanks: if you don't mind could you test the good sample and report back what results you get

[Thunderbolt8]

uploaded a sample that is ~3m30s long and as you can see in this pic that yes 120 fps is slow say that i've been getting thing a easy ~600fps untill this decoding bug happened. by the way what was the problem nevcairiel? (i'll been using 0.45 untill this problem as been fixed) good .ts sample (http://www.mediafire.com/?87l5a1zgfwzasia)

http://i.imgur.com/3Ny29.pngfor this file (H.264), on my system I get

~77fps with LAV copy back
~84fps with LAV without copy back
~150fps with coreavc

for a VC-1 .ts sample, I get

~35 fps with WMV DecoderDMO
~51 fpps with LAV copy back

for some reason, LAV copy back works way better with VC-1 than with H.264 for me (meaning theres actually an improvement) -.-
(maybe thats also because VC-1 CPU decoders are not multithreaded)

[nevcairiel]

Hardware decoding isn't necessarily faster then CPU decoding on todays fast CPUs, but it does reduce the CPU load which can save power.

[ryrynz]

Nev, I updated QuickSync to 0.27 and my FPS for LAV 0.46 jumped with my test file to 850FPS from 330FPS. Using LAV 0.45 with QS 0.27 I get 1250 FPS and Eric's build of ffdshow 4322 I get 1550 FPS.

I saw the posts regarding threading and thought I'd look at what my machine was doing, hoping to see why 0.45 is doing better than 0.46, as you can see below it does look like it sets itself up differently with 2 extra QS threads there in the mix.

I hope this helps somewhat in figuring out where this performance regression I'm seeing is coming from, thanks.

LAV 0.45 + QS 0.27
http://i.imgur.com/A60xB.png

LAV 0.46 + QS 0.27
http://i.imgur.com/CyTOD.png

[egur]

FYI, the "check" function (checks QS caps) takes several hundreds ms to complete and may offset benchmarks of short clips. In normal playback it's meaningless, but for benchmarks it might lower the scores...

I don't have a debug environment for LAV decoder so I can't check what's going on exactly.

Update:
The check function reported above is not the cause. It's a misprint caused by not having a pdb file.
Replacing the QS DLL with my another that has an attached pdb file shows that a lot of time (more than 600ms) is spent calling TestMediaType and the initialization of the QS decoder.
There's nothing much to do here except run longer clips (or ignore the first run)...

[nevcairiel]

FYI, the "check" function (checks QS caps) takes several hundreds ms to complete and may offset benchmarks of short clips. In normal playback it's meaningless, but for benchmarks it might lower the scores...

Thats why i recommend to benchmark clips that run longer then just 1-2 seconds.
Also, it would be recommended to not count the first iteration in the benchmark.

[wanezhiling]

http://www.gokuai.com/f/B20m09Ymn989q1n0
A VC-1 file

LAV Splitter Source 0.46 failed to get video parts.
http://i.imgur.com/UXTX2.png

MPC-HC's internal Mpeg Source is ok.
http://i.imgur.com/0CqBY.png

[egur]

I'd like to request the following enhancements from LAV splitter:
1) Seek faster in TS files and provide a stream (after a seek) that will not cause image corruption (like Haali Splitter). Affects QS and libavcodec in H264 and VC1.
2) Fix seeking in WMV files. After a seek, video plays very slowly for a few seconds.

Nev, probably both issues are related to ffmpeg, but maybe you can do something...

[egur]

http://www.gokuai.com/f/B20m09Ymn989q1n0
A VC-1 file

LAV Splitter Source 0.46 failed to get video parts.
http://i.imgur.com/UXTX2.png

MPC-HC's internal Mpeg Source is ok.
http://i.imgur.com/0CqBY.png

Happened to me too. Here's the fix:
Reinstall LAV 0.46 and make sure VC1 is selected.
Probably related to the installer overhaul.
Your clip plays fine (32 bit anyway) with LAV 0.46 (with or w/o QS).

[CruNcher]

@ Egur
i also have a wish seeking would be this experience for anything http://www.mediafire.com/?qr6uh0x689t61xl ;)

It's just to funny to see the GUI can't keep up, though such speeds can only be reached with a very good combination of different things working excellent together ;)
Nev is pretty much aware of the Seek Performance and the Frame Accuracy Problems for *.ts :)

[nevcairiel]

Frame Accurate seeking in TS is way too complicated to even consider doing it. Its a transport format for Broadcasts, it never was designed with seeking in mind. When Blu-ray adopted the format, they added a separate index table to improve seeking (also, Blu-ray has pretty strict standards, like 1 key frame every second)
It can surely be improved a bit at some point, but you always have to keep in mind that its not a seek-friendly format. As always in those cases, 90% can be achieved with 10% of the time, and the last 10% take 90% of the time. :p

[Pat357]

since 0.46 i have notice a odd bug with decoding. to make sure it wasn't just that 1 build so i tryed the nightly from http://roy.orz.hm/lavf-w32-nightlies/lavf-my120213-b92b5da.7z which still gives me the same problem, it seems it picky on how the .ts has been saved i have uploaded a sample so you can see what the problem could be. video sample (http://www.mediafire.com/?5vqi5qal7f89bh5)

0.46 slow
http://i.imgur.com/emToX.png

0.45 fast (normal it will be over 2x as fast on a bigger sample)
http://i.imgur.com/93BYu.png

LAV v0.46 software decoding falls back to single tread decoding, while LAV v0.45 can decode this file multithreaded.
Just try to set the threads in Lav-video (0.46) to 1 : you will get the same result as with xxx threads.

The question is : why lav 0.46 can only use 1 thread, while 0.45 doesn't have this limitation ??
Seems like a regression to me.

Edit : coreavc 3 gets 670 fps on this very same sample. (12 threads)

[CruNcher]

hehe btw nev did you looked further into the Mpeg-2 Bitstream crash with Lav Video DXVA2 (Quicksync Decoder) 720p.mpg that was ?

Btw also Potplayers Decoder has issues decoding it with full VLD its causing also the exception in Intels Driver, so i guess this issue goes deep, it remembers me about the funny crash conditions with jans MPC-HC tester that also caused a exception in intels driver (though he found the issue in his code for it, rather fast) :)

http://img526.imageshack.us/img526/2158/potplayermpeg2bitstream.png

Intels Reference Decoder (accelerated no copy back) and any Quicksync (Lav Video,FFdshow) decoder doesn't crash seems the problem is mainly in DXVA Decoding, though Cyberlink, Arcsoft and Mainconcept DXVA work

Intel Reference (no copy back) = OK
ffdshow-quicksync (copy back) = OK
lav Video Quicksync (copy back) = OK
Cyberlink DXVA (no copy back) = OK
Mainconcept DXVA (no copy back) = OK
Arcsoft DXVA (no copy back) = OK

MPC DXVA (no copy back) = Crash
Lav Video DXVA2 (no copy back) = Crash
Potplayer DXVA (no copy back) = Crash

[nevcairiel]

http://www.gokuai.com/f/B20m09Ymn989q1n0
A VC-1 file

LAV Splitter Source 0.46 failed to get video parts.
http://i.imgur.com/UXTX2.png

MPC-HC's internal Mpeg Source is ok.
http://i.imgur.com/0CqBY.png

That file is broken, it has CRC errors in the PAT/PMT sections.
I did however add a VC-1 probe function that manages to identify a VC-1 stream when those sections are broken, so it should work in the next version.

[wanezhiling]

:thanks:I see.

[nevcairiel]

Nev, I updated QuickSync to 0.27 and my FPS for LAV 0.46 jumped with my test file to 850FPS from 330FPS. Using LAV 0.45 with QS 0.27 I get 1250 FPS and Eric's build of ffdshow 4322 I get 1550 FPS.

Didn't we agree to go testing higher resolution material? :)

I did my own peformance series on 1080p material, anything else will run extremely fast anyhow.

* LAV set to QuickSync decoder, everything else default.
* GraphStudioNext, 5 passes, NULL renderer, first result not used.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* Windows 7 Professional 64 bit, Aero on.
* Intel driver: v2622, no Lucid Virtu
* CPU: i7-2600k (3.4GHz), power management on. HD 3000 (GT2) iGPU.
* DDR3 @1600Mhz
* All Scores are averages

https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

Note that at these speeds any little activity on the PC can alter the scores, so difference of 1-2 FPS are negligible.
I'm happy to report that the speed has increased basically across the board with QS 0.27 (and the changes i did for yet unreleased LAV 0.47)

I'm still a bit confused by that Samsung clip, why does it behave to special and increase so drastically, but oh well!

For the giggles, i'll add a 0.45 + QS0.27 test set.

[egur]

Didn't we agree to go testing higher resolution material? :)

I did my own peformance series on 1080p material, anything else will run extremely fast anyhow.

* LAV set to QuickSync decoder, everything else default.
* GraphStudioNext, 5 passes, NULL renderer, first result not used.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* Windows 7 Professional 64 bit, Aero on.
* Intel driver: v2622, no Lucid Virtu
* CPU: i7-2600k (3.4GHz), power management on. HD 3000 (GT2) iGPU.
* DDR3 @1600Mhz
* All Scores are averages

https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

Note that at these speeds any little activity on the PC can alter the scores, so difference of 1-2 FPS are negligible.
I'm happy to report that the speed has increased basically across the board with QS 0.27 (and the changes i did for yet unreleased LAV 0.47)

I'm still a bit confused by that Samsung clip, why does it behave to special and increase so drastically, but oh well!

For the giggles, i'll add a 0.45 + QS0.27 test set.
Very well, you're results are better than mine, we actually have almost identical systems except mine has slower RAM (1333).

[nevcairiel]

Very well, you're results are better than mine, we actually have almost identical systems except mine has slower RAM (1333).

Maybe its partly the ram, or the HD3000 that i have, or that i test with LAV and not ffdshow, but its no big differences, largest is 3-5% or so.

[Superb]

Maybe its partly the ram, or the HD3000 that i have, or that i test with LAV and not ffdshow, but its no big differences, largest is 3-5% or so.Could you add the latest ffdshow to the table as well?

[nevcairiel]

Could you add the latest ffdshow to the table as well?

I'm working on some improvements to LAV first and will re-benchmark those, after that i could, i guess.

[egur]

Maybe its partly the ram, or the HD3000 that i have, or that i test with LAV and not ffdshow, but its no big differences, largest is 3-5% or so.

I got much worse results when I used LAV 0.46 (w/o updates + QS 0.27).
For the Samsung clip, I got 233fps where in ffdshow I got 273.
RAM speed has a serious effect on performance.
BTW, do you a hard drive or SSD?

Update
On my new HTPC (i7-2600K, DDR3@1600, Win7 64) my result are better but not the same as yours with respect to the Samsung clip (didn't run the whole suite):
LAV 0.46 (QS 0.27) - 255fps
FFDShow 4322 (QS 0.27) - 304fps

Nev, this is strange as is this PC is practically identical yours (but has very slow/old HDD). My HTPC is installed with the bare minimum, even without anti-virus SW.

[nevcairiel]

I got much worse results when I used LAV 0.46 (w/o updates + QS 0.27).
For the Samsung clip, I got 233fps where in ffdshow I got 273.
RAM speed has a serious effect on performance.
BTW, do you a hard drive or SSD?

0.46 also behaved worse for me, but i changed some things now which i called 0.47 in my tests (the bold column)

I optimized even further now, which did give quite a boost again, going to benchmark 0.47 again, and then latest ffdshow build as comparison.

I have a SSD, but i don't have those samples on it.

[nevcairiel]

There, i finished another round of optimizations in LAV, and benchmarked the QuickSync decoder again - as well as ffdshow for comparison.

Here is the link again:
https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

To summarize:
With 0.27 of the QS decoder, and LAV and ffdshow now using the same settings, the upcoming LAV 0.47 and the latest nightly build of ffdshow perform basically the same, with a very minor loss for ffdshow, but nothing worth noting.

Now i can work on other things again. But first, sleep.

PS:
For anyone wondering when 0.47 will be released, i only want to finish one feature, and then i would start preparing a release, so if everything goes well, the end of the week!