LAV Filters - DirectShow Media Splitter and Decoders

[Mixer73]

Hey Nev

Been testing JRMC as I seem to be too much of a noob to get the performance I want out of PotP or MPC-HC :P

I got the following on the second file:

Problem signature:
Problem Event Name: APPCRASH
Application Name: Media Center 16.exe
Application Version: 16.0.181.0
Application Timestamp: 4e9de255
Fault Module Name: LAVSplitter.ax
Fault Module Version: 0.37.0.0
Fault Module Timestamp: 4e8d4447
Exception Code: c0000005
Exception Offset: 000094bb
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3081
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


Was playing an MPEG2 in DVR-MS format... Using Red October HQ.

Using Nvidia 280.26 on Win7 64bit.

I also had 0.43 crash my media center yesterday playing a h264/mkv file but it crashed so bad I couldn't get a crash report out of it. Had to RDP in and kill ehshell.

[CruNcher]

LAV Filters 0.44

LAV Splitter
- Fixed a seeking regression in the mkv demuxer introduced in 0.43
- Fixed a bug that caused stream descriptions to vanish after the file finished playing
- Improved playback of WMVA video with commercial decoders
- Added support for the new OpenType MIME type produced by mkvtoolnix > 5.2.0

LAV Audio
- Fixed LATM AAC playback with some source filters

LAV Video
- Added Intel QuickSync hardware decoder
- Added support for YADIF with hardware decoding
- Added support for Dirac decoding
- Added support for DNxHD decoding
- Added support for v210/v410 output
- Improved dynamic reconnection with post-processing filters
- Fixed a seeking related corruption issue with MPEG4-ASP


Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.44.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.44.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.44-x64.zip)

Intel QuickSync Decoder
The decoder is based on Eric Gur's decoder which is also used in ffdshow.
In theory, it should work with all Intel GPUs since Penryn, however i can only guarantee for Sandy Bridge based GPUs. Note, however, that it only works if the GPU is active, which means you need a monitor connected, or "fake" it.
Its limited to Windows Vista/7, it does NOT work on Windows XP.

For Multi-GPU setups, you can read this:
http://forum.doom9.org/showthread.php?p=1532786#post1532786

For general questions about QuickSync decoding, you can also refer to this thread:
http://forum.doom9.org/showthread.php?t=162442

If it doesn't work for you, the only things i can recommend checking is that the GPU is active and the drivers are up2date.
I do not have many experience with weird setups, i have monitors connected to my Intel GPU, and thus no experience with "fake" setups or Laptops with switchable graphics. You're free to ask, of course, but i cannot help you. :)

For everyone building their own version:
This build is using v0.22 of Erics decoder, which is r18 in his repository.

Known Issues:
- v210 output to madVR does not work properly. I think thats a madVR bug, but i cannot be sure until madshi gets back to me.

The overall behavior for .WMV .ASF in general seems much better (though i found already some files witch strangely don't seek with Lav splitter/Lav Video but do with Microsofts ASF Reader), i wouldn't say its only for WMVA :)

[ajp_anton]

It seems that when using QS on any video (h264 or mpeg2, don't have vc1) in mkv or mpg with any splitter and any renderer gives a chaotic frame order. GPU is HD3000 (only).

[easyfab]

It seems that when using QS on any video (h264 or mpeg2, don't have vc1) in mkv or mpg with any splitter and any renderer gives a chaotic frame order. GPU is HD3000 (only).

I don't think the GPU is that important because QS is a separate hardware transcoder. For example in encoding tasks with QS, you have almost the same speed with a i5 2300 and a i7 2600

[CruNcher]

@ajp_anton
be sure to have the latest driver installed currently 15.22.50.2509 (32bit )15.22.50.64.2509 (64bit) using a old driver (the main hardware library gets updated with the driver libmfxhw/32/64-i1.dll) with a newer MSDK build can result in strange decoding behavior. It's comparable to Nvidias nvcuvid.dll/nvcuvenc.dll just in 1 lib

[vivan]

Actually 2559 are newer (15.22.52.64.2559)... Even their tool suggest it (http://2.firepic.org/2/images/2012-01/08/dltvo1mnli6j.png). But it seems that Intel removed them, since all links are dead.
Anyway, same problem with 2559. Downgraded to 2509 - works fine.

[CruNcher]

Actually 2559 are newer (15.22.52.64.2559)... Even their tool suggest it (http://2.firepic.org/2/images/2012-01/08/dltvo1mnli6j.png). But it seems that Intel removed them, since all links are dead.
Anyway, same problem with 2559. Downgraded to 2509 - works fine.

indeed http://webcache.googleusercontent.com/search?q=cache:FW2q-fo2vqYJ:downloadcenter.intel.com/Detail_Desc.aspx%3FDwnldID%3D20676 i had no real issues with 2559 strange that they backuped to 2509

[Paladin77]

Hi Nev!

I am having issues playing some realmedia files. If I use madVR renderer I get weird diagonal and side green lines. If I revert to EVR I get corruption and sound dropouts. Sample: http://megaupload.com/?d=IQZI23J6

Using latest LAV,madVR, MPC. both lower end system (in sig) and other rig (5650 ATI card).

Thank you so much for you work!

EDIT. Ok initial troubleshooting shows its splitter related. Activating MPC source alleviated the issue. Will test further!

[DragonQ]

Hi Nev, could you expand on this fix please?:

LAV Audio
- Fixed LATM AAC playback with some source filters

Does it address the issue in MediaPortal where audio on channels with LATM AAC would sometimes just disappear (possibly on changes from/to 2.0/5.1) or not work at all?

[nevcairiel]

Does it address the issue in MediaPortal where audio on channels with LATM AAC would sometimes just disappear (possibly on changes from/to 2.0/5.1) or not work at all?

Possibly, go test it? :p
I don't use Media Portal, so it might as well have been another error, but an error of that kind was fixed.

[Reino]

I'd like to report a little bug. Initially reported as a MPC-HC bug by someone else, but it looks like to be a Lav Splitter bug instead.
http://sourceforge.net/apps/trac/mpc-hc/ticket/1933

[Paladin77]

Hi Nev!

I am having issues playing some realmedia files. If I use madVR renderer I get weird diagonal and side green lines. If I revert to EVR I get corruption and sound dropouts. Sample: http://megaupload.com/?d=IQZI23J6

Using latest LAV,madVR, MPC. both lower end system (in sig) and other rig (5650 ATI card).

Thank you so much for you work!

EDIT. Ok initial troubleshooting shows its splitter related. Activating MPC source alleviated the issue. Will test further!
ok It seems LAV splitter doesn't like that specific file. Tried another file and it works well. EVR corrupts and sound drops while madVR I get a nasty diagonal green line.

[nevcairiel]

I'd like to report a little bug. Initially reported as a MPC-HC bug by someone else, but it looks like to be a Lav Splitter bug instead.
http://sourceforge.net/apps/trac/mpc-hc/ticket/1933

Was a LAV Audio bug, but fixed

ok It seems LAV splitter doesn't like that specific file. Tried another file and it works well. EVR corrupts and sound drops while madVR I get a nasty diagonal green line.

Fixed with madVR, didn't encounter issues with EVR

[AmshTemp]

The installer doesn't check for x64 before installing IntelQuickSyncDecoder.dll.


Source: bin_x64\IntelQuickSyncDecoder.dll; DestDir: {app}\x64; Flags: ignoreversion restartreplace uninsrestartdelete skipifsourcedoesntexist; Components: lavvideo32

Should have been:

Source: bin_x64\IntelQuickSyncDecoder.dll; DestDir: {app}\x64; Flags: ignoreversion restartreplace uninsrestartdelete skipifsourcedoesntexist; Components: lavvideo64

[Reino]

Was a LAV Audio bug, but fixedLav Audio has nothing to do with this. It's all about the splitter. It hangs/crashes with 0.44.

[nevcairiel]

Lav Audio has nothing to do with this. It's all about the splitter. It hangs/crashes with 0.44.

Plays just perfectly.
There was a bug that caused it to never output any audio when lav audio was used, which i fixed.
That was also the original bug report.

[Reino]

You're right, I take it back. Normally I only use MPC-HC, but after having tested the wav-file in Zoom Player and with MONOGRAM GraphStudio, where it plays perfectly fine, I have to conclude that MPC-HC is indeed the culprit, like the guy said. :o

[nevcairiel]

But, it works fine in MPC-HC for me. :)

[DragonQ]

Possibly, go test it? :p
I don't use Media Portal, so it might as well have been another error, but an error of that kind was fixed.
OK well I've selected LAV Filters for my LATM AAC decoder in MediaPortal but I don't know when I'll get to test it - I only watch/record Freeview HD channels (which use LATM AAC audio) when my DVB-S2 decoder is in use!

I'll let you know if I get any more problems though.

[STaRGaZeR]

nev, when seking in this VC-1 file using QS the image freezes. It doesn't hang the player, but it doesn't recover either.

http://www.multiupload.com/2403BDXAFT

[ajp_anton]

I don't think the GPU is that important because QS is a separate hardware transcoder. For example in encoding tasks with QS, you have almost the same speed with a i5 2300 and a i7 2600It was the shortest way of saying I don't have a pre-Sandy Bridge CPU, and no additional GPU connected.

Anyway, updated drivers and it works now. Didn't think it would make a difference since ffdshow used to work before.

[egur]

It seems that when using QS on any video (h264 or mpeg2, don't have vc1) in mkv or mpg with any splitter and any renderer gives a chaotic frame order. GPU is HD3000 (only).

I've seen this before.
Do you have Lucid Virtu installed and and playing using the 64 bit version?
If so, then it's a lucid Virtu bug. Somehow it's mixing the frame order. 32 bit was fine (on 64 bit OS).

[CruNcher]

@nev
ftp://132.185.142.44/video/maybefinal/diracpromo-tr1500.ts plays way to slow (8 FPS) compared to VLC

also can you please add wma lossless to lav audios selection (WMAL) option so that it wont try to playback streams with it and fallback to wmaudio decoder accordingly http://roundup.libav.org/issue421 putting wmaudio decoder above lav audio works too but it's not the correct way of handling it :)

[Pat357]

I've reinstalled filters and it works now.

It's quite funny- DNxHD encoder is multithreaded, but decoder not. ProRes is opposite :)
Where are the ProRes and DNxHD codecs available ?

Here is something strange:
I've made AVI Prores file and it works fine except when it's loaded to some software directly it gets decoded in one thread.
When I load same AVI through avisynth (directshow source) than it works fine- all cores are working and speed is good.
Why?
Are you running an MT version from Avisynth ?
I have this often with lossless codecs, where the VfW codec is multithreaded, but the Dshow (Libav, FFmpeg) version is not.
Also the VfW is often more optimized then the Dshow version. (UTVideo, Lagarith,...)
Because you're using directshowsource, you 're basically using the Dshow version, so the speed difference is not clear to me;
the avisynth way should not be noticeble faster unless using MT version....
Can we also have dithering as an option?
I think ditthering is not dependent from the codec, you probably have already dithering if you're using Lav-video.

[nevcairiel]

Intra-only codecs are usually very easy to multi-thread in decoding, because every frame is "stand-alone" and doesn't have to wait for the previous reference frames to be decoded.
Multi-threaded decoding was just recently added to ffmpegs UtVideo decoder. Adding the same for DNxHD would probably be rather easy, someone just has to do it.

[egur]

QS decoder rev20 is committed.
Changes are:
Added MT copy. A mild performance gain. Added flag to disable it
Fixed bad seeking in VC1 (nev's report). On every seek in every codec, the entire session is destroyed. Works smoothly.
Added flag to report a corrupted frame (what MSDK reports).
Cosmetics.

FYI, I'm not building a version myself ATM, I want to address 2 other issues.
One of them is VC1 decoder sends the same buffer over and over with different time stamps which breaks my code.

[kolak]

Where are the ProRes and DNxHD codecs available ?


Are you running an MT version from Avisynth ?
I have this often with lossless codecs, where the VfW codec is multithreaded, but the Dshow (Libav, FFmpeg) version is not.
Also the VfW is often more optimized then the Dshow version. (UTVideo, Lagarith,...)
Because you're using directshowsource, you 're basically using the Dshow version, so the speed difference is not clear to me;
the avisynth way should not be noticeble faster unless using MT version....

I think ditthering is not dependent from the codec, you probably have already dithering if you're using Lav-video.

LAV decoder supports ProRes and DNxHD.

Problem is opposite what you described.

I wrap ProRes into AVI and when it's loaded to some application- eg Premiere it works slow.
If I load it through avisynth (directshowsource) using fake AVI (virtual file system for avisynth) than it's fine- all cores are used. Not sure why it's happening.

[STaRGaZeR]

QS decoder rev19 is committed.
Changes are:
Added MT copy. A mild performance gain. Added flag to disable it
Fixed bad seeking in VC1 (nev's report). On every seek in every codec, the entire session is destroyed. Works smoothly.
Added flag to report a corrupted frame (what MSDK reports).
Cosmetics.

FYI, I'm not building a version myself ATM, I want to address 2 other issues.
One of them is VC1 decoder sends the same buffer over and over with different time stamps which breaks my code.

Looks like you forgot to commit some new files to the repository :p. Will test it as soon as you upload these.

[egur]

Looks like you forgot to commit some new files to the repository :p. Will test it as soon as you upload these.

Working too hard lately...
Rev 20 has the files

[Cyber-Mav]

i dont get hardware acceleration on xvid standard definition files. gpu = gtx560 ti.

[Superb]

i dont get hardware acceleration on xvid standard definition files. gpu = gtx560 ti.LAV Video doesn't support CUVID accelaration of MPEG-4 ASP files AFAIK.

[Asmodian]

i dont get hardware acceleration on xvid standard definition files. gpu = gtx560 ti.

This isn't a major issue as your CPU can handle SD Xvid quite well I assume?

[STaRGaZeR]

Working too hard lately...
Rev 20 has the files

That VC-1 file works with this revision :)

However I had to disable the VS option "Treat compiler warnings as errors" because there are warnings that weren't there before.

[Pat357]

LAV decoder supports ProRes and DNxHD..
I should have asked about the encoders :D Where are these available ?

[Midzuki]

^ ffmpeg can encode to both DNXHD and ProRes

( or at least the command-line "ffmpeg -codecs" says so :-P ).

[blexley]

Can anybody get LAV audio working with crystalplayer as LAV video is working. ?

[skingery]

Running Lav splitter, audio and video and MPD-HC. I just tried the new .44 version and when I enable hardware decoding with QuickSync I get nothing but stuttering. Doesn't matter if I use EVR CP or MADVR. I have an i3.
Any ideas? Could it be the version of MPC-HC?

[kolak]

I should have asked about the encoders :D Where are these available ?

ffmpeg, ffmbc, Carbon Coder, Telestream Episode (if we talk about PC)

[egur]

That VC-1 file works with this revision :)

However I had to disable the VS option "Treat compiler warnings as errors" because there are warnings that weren't there before.

Yes, forgot to turn off static analysis on the standalone project. Fixed with rev21.

[Cyber-Mav]

yes my cpu can handle xvid playback fine, i just thought i would test it to see if it works. i though the lavcuvid had mpeg4-asp hardware decode working.

could be my graphics driver, im using 275.33. may need to update not sure.

[STaRGaZeR]

When the input is 4:2:2 (any bitdepth) and all 4:2:2 formats are unticked in the settings, LAV Video prefers downsampling to 4:2:0 instead of upsampling to 4:4:4 or RGB. I see the logic in this, but wouldn't it be better not to destroy any color information?

[nevcairiel]

I suppose that can be argued, i don't care either way, easy enough change to prefer RGB.

[STaRGaZeR]

It'd be nice not to destroy any info, definitely.

[madshi]

I'd suggest to use YCbCr 4:4:4 then, if checked and supported by the renderer. Otherwise I'm not sure if I would vote for RGB. RGB has the problem that most video renderers passthrough RGB untouched, ignoring their own "levels" option. So for most video renderers LAV Video Decoder would have to be configured to use either video or PC levels RGB output, depending on whether the display/TV/projector needs PC or video levels. I don't find it intuitive that the user has to setup a video decoder filter to satisfy a monitor's specific needs, especially not with native YCbCr content. So I think RGB output should only be chosen if the content is native RGB, or if no YCbCr connection is available at all. Just my 2 cents, of course. In the end it's not really important to me.

[nevcairiel]

Nothing really supports 4:4:4 (AYUV), EVR claims to accept it, but on most hardware its using software emulation which is incredibly slow, which is why i'm reluctant to prefer it. In the end, if you turn off 4:2:2, its your own damn fault. :)
Sadly, i cannot make this dependent on the renderer, because i need to expose the media type before the renderer connects, and at least EVR is too stupid to allow me to switch pixel format after connection.

[STaRGaZeR]

So I think RGB output should only be chosen if the content is native RGB, or if no YCbCr connection is available at all.

So you prefer 4:2:0 YUV over RGB coming from a 4:2:2 or 4:4:4 source? ;)

[nevcairiel]

4:4:4 will always use RGB over downsampling chroma, fwiw.

The whole list of which format is preferred for what decoding format, see the table here:
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=decoder/LAVVideo/LAVPixFmtConverter.cpp;h=e671f18a7c877295e532972d3dd7502977522a3d;hb=HEAD#l58

[dann23]

now that there is support for hardware decoding using intel and nvidia gpu, can we hope for something similar for ati?

[madshi]

So you prefer 4:2:0 YUV over RGB coming from a 4:2:2 or 4:4:4 source? ;)
You were talking about 4:2:2, not 4:4:4. Of course castrating 4:4:4 to 4:2:0 is even more painful than downconverting 4:2:2 to 4:2:0. I don't really think there's an ideal solution if the renderer neither supports 4:2:2 nor 4:4:4 YCbCr. Using YCbCr 4:2:0 has its pros and cons in this situation, so does RGB. Personally, for 4:2:2 content I'd still prefer YCbCr 4:2:0 over RGB, due to the RGB levels problem. Not sure what I'd prefer with YCbCr 4:4:4 content, though. Anyway, the real problem is that most video renderers don't treat RGB input correctly, IMHO. Passing it through untouched isn't a good idea, I believe. If LAV Video Decoder could simply output RGB without having to worry whether the user gets correct levels then choosing RGB output would be an easy choice for LAV Video Decoder with 4:2:2 YCbCr content, if the renderer doesn't support 4:2:2. But well, you know, we had this discussion before. You like video renderers to passthrough RGB untouched, I think it's a bad solution. We couldn't agree last time, so probably we won't this time, either... :D

Edit: Btw, did you ever check whether the RGB level autodetection works in the newer madVR builds? I believe it should be pretty much perfect now. I dare you to make it fail (without resorting to clearly broken setups like configuring ffdshow to output PC levels while letting an avisynth script convert to video levels at the same time).

[STaRGaZeR]

4:4:4 will always use RGB over downsampling chroma, fwiw.

The whole list of which format is preferred for what decoding format, see the table here:
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=decoder/LAVVideo/LAVPixFmtConverter.cpp;h=e671f18a7c877295e532972d3dd7502977522a3d;hb=HEAD#l58

Yep, that's why I was curious as of why did you put NV12 and YV12 over AYUV and RGB in case of 4:2:2.

You were talking about 4:2:2, not 4:4:4.

Yes, but you said "if no YCbCr connection is available at all". Hence the question. The situation is the same thou. You'd be destroying information. And when you use one of these formats, it's because you have information to keep.

Personally, for 4:2:2 content I'd still prefer YCbCr 4:2:0 over RGB, due to the RGB levels problem. Not sure what I'd prefer with YCbCr 4:4:4 content, though. Anyway, the real problem is that most video renderers don't treat RGB input correctly, IMHO. Passing it through untouched isn't a good idea, I believe. If LAV Video Decoder could simply output RGB without having to worry whether the user gets correct levels then choosing RGB output would be an easy choice for LAV Video Decoder with 4:2:2 YCbCr content, if the renderer doesn't support 4:2:2. But well, you know, we had this discussion before. You like video renderers to passthrough RGB untouched, I think it's a bad solution. We couldn't agree last time, so probably we won't this time, either... :D

Edit: Btw, did you ever check whether the RGB level autodetection works in the newer madVR builds? I believe it should be pretty much perfect now. I dare you to make it fail (without resorting to clearly broken setups like configuring ffdshow to output PC levels while letting an avisynth script convert to video levels at the same time).

Maaan, not again. I don't want renderers to do XXX or YYY, I asked for a simple option so we can do XXX and YYY, nothing more, nothing less. You refused so now I'm using EVR CP with some custom code that does everything I ever wanted madVR to do while consuming less power and producing less heat. Might consider going back if you offer the same thou ;)