LAV Filters - DirectShow Media Splitter and Decoders

[michkrol]

Here's Quicktime 7 x86 player that uses the same resource like LAV x64:
(IMG)
But LAV x86 uses twice more CPU usage ~65% :confused:

I've checked some files in ProRes format in ffplay and the difference between 32 and 64 bit is there, so you might want to bring it to ffmpeg's developers' attention as it's always better to get things patched upstream.

That said this format is not really popular (and not intended) for actual playback, but as intermediate used in video editing. Personally I don't see a problem as long as it plays in real-time without a problem and would rather see developers investing time in common formats' support and new features.

[nevcairiel]

Like I explained before, and I just checked to confirm, all the optimizations for ProRes are only available in 64-bit. Most likely because their complexity is too high, and they need more registers then 32-bit can offer, so it was written only for 64-bit.
This is a common trend as codecs get more and more complex, and their optimized functions need more then the 7 gp registers or 8 SIMD registers that 32-bit mode is limited to (in contrast to 15 gp and 16 SIMD in 64-bit). For example, many of the VP9 SIMD improvements commited to FFmepg over the last weeks are also only 64-bit for the same reason - they need more registers.

Just accept it as it is. Or use 64-bit.

[jkauff]

Just accept it as it is. Or use 64-bit.
The only problem with going 64-bit is you have to leave madVR behind. That's the only reason I'm still 32-bit.

[turbojet]

Can anyone confirm whether they get audible clicks and pops in this sample (http://www.aotplaza.com/Files/HTPC/Samples/DTS-HD%20MA%20Pops%20-%20Sample.mkv) when using dtsdecoderdll please? It's 7.1 DTS-HD MA and I get clicks and pops all over the place when using v1.1.0.8 or v1.1.0.9 of the dll with LAV Audio 0.60.1 (no matter whether I have mixing enabled or not). Works fine using the in-built DTS decoder. The most obvious glitch is dead centre at 00:02.

Apologies for the large file size.

Sounds fine here with 1.1.0.9. TMT not installed.

[cyberbeing]

All versions of LAV Splitter seem to hang MPC-HC if you have a MKV with a chapter specified with a start timecode beyond the end of the file, and you have more than one file in your playlist.

When using Haali splitter, MPC-HC only fails to automatically proceed to the next file in the playlist, but doesn't hang.

[nevcairiel]

LAV doesn't use chapters for playback (unless you're talking about ordered chapters), so there must be a MPC-HC thing involved.

[bugmen0t]

Hi,

Is this statement still supposed to stand true with recent versions?
It seems some change made between 0.58.2 and 0.59 changed this behavior.
Up to 0.58.2, the splitter works as described above, but starting with 0.59, the first subtitle track in an .mkv file gets selected even if none of them are flagged as default nor forced, and there are no preferred languages specified. Subtitle Selection Mode is set to Default.
I am wondering is this change intentional.
For me the subtitle track is initially selected correctly but switches to the first one a few seconds later.

[nevcairiel]

Thats a player then, LAV doesn't change anything ever by itself after the initial selection.

[Plutotype]

Hi Nev,
Does MPC-HC store now also all LAVfilters ( splitter, video, audio ) settings in its own .ini file?
Thanks

[nevcairiel]

I develop LAV Filters, not MPC-HC.
Its certainly possible for a player to completely control the configuration of LAV, i build it that way, but if it stores it completely in its own config, ask the developers that built it!

[DragonQ]

Sounds fine here with 1.1.0.9. TMT not installed.
Hmm how strange. It happens for me in both MPC-HC and MediaPortal on two different machines. Did you test using LAV Splitter & LAV Video too?

[Plutotype]

I develop LAV Filters, not MPC-HC.
Its certainly possible for a player to completely control the configuration of LAV, i build it that way, but if it stores it completely in its own config, ask the developers that built it!

Tested couple of settings from all three inbuilt filters, MPC-HC stores the settings from LAV components as well. Its a nice feature for all unexperienced users - you can pre-configure the MPC-HC inclusive LAV filters and share the mpc-hc.ini file with them.

[nevcairiel]

Can anyone confirm whether they get audible clicks and pops in this sample (http://www.aotplaza.com/Files/HTPC/Samples/DTS-HD%20MA%20Pops%20-%20Sample.mkv) when using dtsdecoderdll please? It's 7.1 DTS-HD MA and I get clicks and pops all over the place when using v1.1.0.8 or v1.1.0.9 of the dll with LAV Audio 0.60.1 (no matter whether I have mixing enabled or not). Works fine using the in-built DTS decoder. The most obvious glitch is dead centre at 00:02.


It looks like there is one HD frame missing (one audio frame only has the core frame), and the decoder gets confused by that and fails to decode this one frame, so 10ms of audio are missing.
I checked my mkv version of this movie (directly copied from BD with MakeMKV), and its fine. So something must've gone wrong somewhere. :)

Of course the avcodec decoder doesn't notice such a missing HD frame, since it can't decode them!

[cyberbeing]

LAV doesn't use chapters for playback (unless you're talking about ordered chapters), so there must be a MPC-HC thing involved.

Just normal chapters.

It probably is the fault of MPC-based chapter/playlist handling, as the same issue also occurs with MPC-BE when using LAV Splitter, but not with it's internal MKV Splitter.

The question remains as to why only LAV Splitter seems to trigger a deadlock when MPC most likely attempts to load/read/seekto that last bogus chapter. I did notice that the LAV Splitter Tray icon will seek beyond the valid timeline (i.e. 00:31/00:30 with 00:31 chapter) when such a chapter is selected and the video is paused, while the Haali Splitter Tray Icon by comparison seeks to the last valid timecode (i.e. 00:30/00:30 with 00:31 chapter), instead of the invalid timecode in the chapter file. Could be unrelated, but strange none the less.

[nevcairiel]

When LAV tries to seek a MKV to after its duration, it'll probably seek to the last frame in the file and then immediately return EndOfStream, which would cause the player to enter pause state.
Seems all to be working as designed from that description.

The reason it allows such seeks is for growing files, it may actually have chapter information for the whole file, but at the time of playback start only a part was downloaded already, so the duration is wrong.
No reason not to allow the chapter jump, in case more data was downloaded now. It'll fail gracefully and just cause an EOF event if it doesn't have such data.

[DragonQ]

It looks like there is one HD frame missing (one audio frame only has the core frame), and the decoder gets confused by that and fails to decode this one frame, so 10ms of audio are missing.
I checked my mkv version of this movie (directly copied from BD with MakeMKV), and its fine. So something must've gone wrong somewhere. :)

Of course the avcodec decoder doesn't notice such a missing HD frame, since it can't decode them!
Only one frame in the whole sample? I get clicks and pops all through the film and a few times even in that sample.

I do have other rips that have 7.1 DTS-HD MA tracks though and they're all fine. I guess for now I'll just use the core DTS until I can be bothered to rerip it.

[nevcairiel]

Probably for all the places where it happens.

[P.J]

Like I explained before, and I just checked to confirm, all the optimizations for ProRes are only available in 64-bit. Most likely because their complexity is too high, and they need more registers then 32-bit can offer, so it was written only for 64-bit.
This is a common trend as codecs get more and more complex, and their optimized functions need more then the 7 gp registers or 8 SIMD registers that 32-bit mode is limited to (in contrast to 15 gp and 16 SIMD in 64-bit). For example, many of the VP9 SIMD improvements commited to FFmepg over the last weeks are also only 64-bit for the same reason - they need more registers.

Just accept it as it is. Or use 64-bit.

First lemme thank you very much for reply :thanks:

Yes, you're right but I just wonder why Quicktime can play ProRes with less CPU usage while it's working in 32bit mode :confused:

[turbojet]

Hmm how strange. It happens for me in both MPC-HC and MediaPortal on two different machines. Did you test using LAV Splitter & LAV Video too?

Yes but I didn't have normalization on and the background noise was drowning out the problem. After turning on normalization I can hear 4 pops with dtsdecoderdll. There's something wrong at 0:03 for dts core decoders too here.

[SUPERBIF]

A quick question:

Are there any disadvantages by updating LAV filters? Can the picture quality change?

[wanezhiling]

Why you ask this?
LAV filters decrease image quality on your system?

[LigH]

There will never be a guarantee that all decoders will work bug-free at any time. But in general, it will be very improbable that a low-quality feature will ever be implemented. Decoding will usually be rather "exact", and displaying the result will be a matter of the following renderer, after LAV filters did their job.

[ryrynz]

Just following previous posts with more direct responses to Superbif's questions.


Are there any disadvantages by updating LAV filters?

Generally none, any regressions are taken care of by Nevcairiel in short order, I would always upgrade to the latest version.


Can the picture quality change?


If everything is as it should be, there should never be any regressions in picture quality, things can sometimes improve though.

[SUPERBIF]

Just following previous posts with more direct responses to Superbif's questions.



Generally none, any regressions are taken care of by Nevcairiel in short order, I would always upgrade to the latest version.



If everything is as it should be, there should never be any regressions in picture quality, things can sometimes improve though.

Thanks for the quick answers:)
Regarding the picture quality I updated, and thought the picture was not as sharp as v. 49 something, but it's just my eyes I'm sure now, so thanks for confirming.

[Stereodude]

Should DXVA2 native and copy back behave differently on the same file MPEG-2 video stream on a HD 7790 with the 13.12 Catalyst drivers? Software decoding and DXVA2 copy back behave the same way reporting a 33.37ms movie frame interval and IVTC works (within madVR). DXVA2 native reports back a 16.68ms movie frame interval and IVTC doesn't work (within madVR).

I can only guess that the output from LAV to the downstream video chain is not the same. This is the integrated LAV version in MPC-HC 1.71.

[Sparktank]

Can anyone confirm whether they get audible clicks and pops in this sample (http://www.aotplaza.com/Files/HTPC/Samples/DTS-HD%20MA%20Pops%20-%20Sample.mkv) when using dtsdecoderdll please? It's 7.1 DTS-HD MA and I get clicks and pops all over the place when using v1.1.0.8 or v1.1.0.9 of the dll with LAV Audio 0.60.1 (no matter whether I have mixing enabled or not). Works fine using the in-built DTS decoder. The most obvious glitch is dead centre at 00:02.

Using: 1.1.0.1.
I hear a popping noise at the said time when the scene switches to the guard.

There are other noises here and there, but it's always random. I replayed the clip and the noises weren't in the same spot except for the pop at the scene change with the guard.

I noticed you used the "Jan 8" build for MKVtoolnix 6.7.0 (x64).
I've noticed that not all remuxes using the x64 build are 100% clean but that's for further investigation to be brought up in the MKVtoolnix thread (with reproductive evidence).

If you try remuxing from the source again using the x86 build (or maybe a pre-build of x64), it will remux cleanly (or stick with whatever MakeMKV creates).
If you try to remux the damaged file, you'll only remux the damages.

But yes, I've experiences weird noise defects using ArcSoft/LAV but it seems limited to only x64 remuxes.

[huhn]

Should DXVA2 native and copy back behave differently on the same file MPEG-2 video stream on a HD 7790 with the 13.12 Catalyst drivers? Software decoding and DXVA2 copy back behave the same way reporting a 33.37ms movie frame interval and IVTC works (within madVR). DXVA2 native reports back a 16.68ms movie frame interval and IVTC doesn't work (within madVR).

I can only guess that the output from LAV to the downstream video chain is not the same. This is the integrated LAV version in MPC-HC 1.71.

you can't use madvr ivtc with dxva native. ivtc runs on the cpu and need the decoded frames, but with dxva native they are already on the gpu and not copy back so madvr uses your gpu deinterlacer.

[madshi]

you can't use madvr ivtc with dxva native. ivtc runs on the cpu and need the decoded frames, but with dxva native they are already on the gpu and not copy back so madvr uses your gpu deinterlacer.
That is correct. The madVR IVTC algoritm currently doesn't support native DXVA2 decoding, unfortunately. Not LAV's fault.

[Stereodude]

you can't use madvr ivtc with dxva native. ivtc runs on the cpu and need the decoded frames, but with dxva native they are already on the gpu and not copy back so madvr uses your gpu deinterlacer.I see...

Thanks for the explanation.

[jkauff]

That is correct. The madVR IVTC algoritm currently doesn't support native DXVA2 decoding, unfortunately. Not LAV's fault.
Yet another good reason to use LAV software decoding, if possible.

[andyvt]

Yet another good reason to use LAV software decoding, if possible.

Or a method that copies the surface back to system memory.

[huhn]

Yet another good reason to use LAV software decoding, if possible.

but dxva copy back works fine too. it's not like you can't use dxva.

[Stereodude]

but dxva copy back works fine too. it's not like you can't use dxva.Well, it seems like copy back takes longer so you have less rendering time for madVR's scaling/processing and then can get dropped frames. Or at least that was my quick observation last night when testing.

[sgraves66]

i have a minor issue that, to date, i haven't been able to solve. i'm building a custom graph with lav filters (0.60.1), madvr (0.86.11) and, when applicable, xy-VSFilter. the first time i start any video after a reboot, and only after a reboot, there's a tremendous amount of lag, stuttering, and audio is out-of-sync. my application fails to respond while this settles, so whatever is happening is also blocking the main ui thread. it takes 30 seconds or so to flesh-out. pausing playback, and waiting a few seconds seems to help.

after this, as long as i don't reboot, the problem never surfaces again, even after restarting the application. i'm inclined to think it's a file sharing issue as i've run out of viable options from the application side. i was curious to know if anyone else has experienced this. i suspected it could also be an issue with xy-VSFilter, but same results with or without the filter added. attached is the graph.

http://i41.tinypic.com/2n99k53.png

[clsid]

Monitor system activity with ProcessMonitor utility. Maybe some other program (like a virus scanner) is also accessing the file.

[sgraves66]

Monitor system activity with ProcessMonitor utility. Maybe some other program (like a virus scanner) is also accessing the file.

Thanks for the suggestion. It's been an issue for 2 years now on all of my htpc's and I never bothered to revisit until today. It's definitly not a madVR or LAV bug, just annoying. My gut tells me it's a drive pooling issue that coincides with initial smb connect and not related to something local to the box or app. Virus/malware scanners have been ruled-out. I really just wanted to see if this may be a known or reported issue.

I used to pre-read portions of files prior to playback to allow time for sleeping drives to spin-up. Prevented some unexpected crashes. May add this back in to see if it helps. I had forgotten about this and, for some odd reason, your comment brought it back.

[DragonQ]

Using: 1.1.0.1.
I hear a popping noise at the said time when the scene switches to the guard.

There are other noises here and there, but it's always random. I replayed the clip and the noises weren't in the same spot except for the pop at the scene change with the guard.

I noticed you used the "Jan 8" build for MKVtoolnix 6.7.0 (x64).
I've noticed that not all remuxes using the x64 build are 100% clean but that's for further investigation to be brought up in the MKVtoolnix thread (with reproductive evidence).

If you try remuxing from the source again using the x86 build (or maybe a pre-build of x64), it will remux cleanly (or stick with whatever MakeMKV creates).
If you try to remux the damaged file, you'll only remux the damages.

But yes, I've experiences weird noise defects using ArcSoft/LAV but it seems limited to only x64 remuxes.

Thanks for the investigation. I don't think the MKVToolnix issue is related; the original MKV I made was using a much older version and that also has the clicks & pops. It's only because I had to make a cut that the sample uses the most recent version of MKVToolnix.

Funnily enough, I'm not using MKVToolnix much at the moment because the BBC apparently changed their encoder settings slightly in late 2013 (on satellite at least) and now recordings of their HD channels don't mux correctly using either ffmpeg or MKVToolnix (possibly to do with "packed B frames" but I don't even know what that is). Mosu will hopefully look into this in a couple of weeks. For now, Haali's MKV muxer works fine.

[Deihmos]

I have a video with 3 audio tracks and I have lav set to default to eng but it stiil goes to French when using lav audio decoder. The french audio is marked default and forced.

If I use ffdshow as the audio decoder it correctly selects eng audio.

Anyone know this is happening?

[Soukyuu]

I would suspect it's because of the forced flag, which basically means "whatever the settings, play this one". ffdshow probably didn't respect the flag, that's all.

[Deihmos]

I would suspect it's because of the forced flag, which basically means "whatever the settings, play this one". ffdshow probably didn't respect the flag, that's all.

I did some testing an removed the force flag and even the default flag and it still played the french audio. All audio streams are DTS and are the same quality.

I also set Lav to prefer Spanish and it selected that track then it changed right back to the first track. Couple videos it selected the commentary track. All these work fine when using ffdshow as the audio decoder.

[nevcairiel]

LAV Audio does not influence the stream selection at all. It does not have a single line of code to influence anything, it just decodes whatever the splitter offers.

If the splitter does not select the track like it should based on its configuration, then in general it is your player which overrides its choice. Many players are trying to be too smart for their own good these days. LAVs stream selection still works perfectly.

[cyberbeing]

LAV Video 0.55+ software decoding is showing fullframe corruption during a small segment of an old circa 2010 8-bit video encoded with x264 r1677.

ffmpeg ffplay 2014-01-23 git-e6d1c66 also shows this corruption, and reports the following error "Invalid mix of idr and non-idr slices", so it would seem a ffmpeg update you did after LAV Video 0.54.1 which broke this.


ffmpeg ffplay 2012-11-25 git-26c531c = no corruption or error message

ffmpeg ffplay 2012-12-26 git-ceee440 = corruption

libav avplay 2014-01-23 v10_alpha2-41-gcff480e = no corruption or error message

From the above, it would seem this regression only occurred in FFMPEG but not Libav.

[nevcairiel]

Since you already determined its a FFmpeg issue, how about reporting it there? :)
Might be this issue, though: https://trac.ffmpeg.org/ticket/3131

[cyberbeing]

Thanks for pointing out that ticket. It does seems like the same issue, especially considering the ffmpeg git-7973a075 commit mentioned was on 2012-12-16. Unfortunately, the video I saw this problem with isn't particularly suitable for posting publicly. Guess I'll just need to wait for ffmpeg to address this.

[filler56789]

Might be this issue, though: https://trac.ffmpeg.org/ticket/3131

PERHAPS that's actually a multiplexing issue :confused:

I demuxed the sample file with mp4creator and remuxed it with L-Smash --- and now, no corrupted frames anymore :)

[cyberbeing]

I can confirm this. If I demux the raw h264 from my own mp4 sample which has this problem and mux it into a mkv with mkvmerge the corruption goes away.

mp4 = corruption
mp4 -> mkv = corruption
mp4 -> demuxed raw h264 -> mkv = no corruption
mp4 -> mkv -> demuxed raw h264 -> mkv = no corruption

ffmpeg must not be handling strange mp4 h264 data properly or something.

Also interestingly with the original problem mp4:

LAV Video + LAV Splitter = Corruption
LAV Video + Haali Splitter = Corruption
LAV Video + MPC-BE MP4 Splitter = Corruption
LAV Video + Intel Media Codecs MP4 Splitter = No Corruption

So while this may actually be a container issue, it seems it probably needs to be fixed in ffmpeg at both the splitter and decoder stage for maximum compatibility.

[Deihmos]

LAV Audio does not influence the stream selection at all. It does not have a single line of code to influence anything, it just decodes whatever the splitter offers.

If the splitter does not select the track like it should based on its configuration, then in general it is your player which overrides its choice. Many players are trying to be too smart for their own good these days. LAVs stream selection still works perfectly.

Oh I see I didn't know that. I am using windows media center. If I use ffdshow the stream selection works perfect. I guess I'll just use that instead for audio.

Sent from my HTC One using Tapatalk

[mcnauge]

Hello,

First, thanks for the great product!

My question/issue is that I checked with graphstudio to ensure I had everything setup correctly, and the DVD mkv movies are passing through lav audio and lav video. However, the blue-ray mkv movies are going through lav audio only...the video is going through Microsoft DTV-DVD Video Decorder.

Is this correct? I can se the DVDs are hardware accelerated when I click on the properties of LAV Video Decoder so I can only assume that the Microsoft decoder is software only.

Thanks,
Erik

[nevcairiel]

GraphStudio always uses the Windows' preferred filters, and unless you used one of those tools to override this, the Microsoft decoder is always the preferred H.264 decoder.
More important would be what happens in your player, tbh.

MPC-HC for example overrides this.

[mcnauge]

Thanks,

Is there a way to determine whether lav filters is the active decoder? for example, if I play a movie in MediaBrowser Theater or VLC or whatever, can I open something that shows it is actually using lav...and more importantly that's its using my NVIDIA CUVID hardware acceleration? (I checked the system tray icons and they don't show up at all, with various players and movies)

Thanks again,
Erik