LAV Filters - DirectShow Media Splitter and Decoders

[iSunrise]

@nevcairiel:
Is there a specific reason why audio tracks like DTS-HD MA don't show the bitrate (in kbps) in the splitter info? Is that info not exposed through the new dcadec properties? Is that because LAV would need to calculate an average?

Also, it seems from the commits that foo86 finally added high-resolution DTS-HD support:


- Add support for 192 kHz XLL audio.
- Fix parsing 16-bit 192 kHz XLL audio.

[sneaker_ger]

@nevcairiel:
Is there a specific reason why audio tracks like DTS-HD MA don't show the bitrate (in kbps) in the splitter info? Is that info not exposed through the new dcadec properties? Is that because LAV would need to calculate an average?
You would need to parse the complete file to get that information because lossless DTS-HD MA is variable bitrate.

[iSunrise]

You would need to parse the complete file to get that information because lossless DTS-HD MA is variable bitrate.
Ok, thought something like that is necessary. Well, you can't have all can you.

[nevcairiel]

Also, it seems from the commits that foo86 finally added high-resolution DTS-HD support:

The version included in latest nightly LAV should already play 192kHz just fine. Don't worry, I'm keeping well on top of dcadec changes!

[willyarm]

I've just bought a GTX 960, it works great for HEVC in my Windows 7 64bit machine, but in my Windows 8.1 32bit PC the video freezes up whenever I resize the window or go full screen. I've tried DVBViewer (and I have to 'rebuild graph' to get video back) and MPC-HC (and I have to press stop and play to get video back).

Any ideas?

[tobindac]

I heard there might be issues with native vs loopback GPU decoding. If I have no issues with native should I keep using it? Shouldn't it be faster?

[willyarm]

Furthur to my previous post... I have just installed Windows 8.1 64 bit (Dual Boot) on the same PC as I had Windows 8.1 32 bit, and everything works perfectly, when I switch back to 32 bit the problem comes back. I have tried various versions of LAV including the latest nightly build, I have an LG UHD TV, its running at 3840x2160 (4:2:0, 8 bit). I have configured MPC-HC to not use its internal filters. I have set LAV to use copy-back, both 32 and 64 bit play in H/W just fine, its just resizing under 32 bit thats an issue. Is there any info I can get that might help debug this issue?

[huhn]

maybe to little ram?

but why are you even using the 32 bit version?

[James Freeman]

Where can one see the changelog for each nightly build?

[nevcairiel]

Where can one see the changelog for each nightly build?

There is no formal changelog for nightlies. You can however just check the repository, ie. https://github.com/Nevcairiel/LAVFilters/commits/master

[mzso]

There's this file I have a trouble with. The video freezes for seconds if I seek to a specific spot. It happens when I jump to 00:04.422 or using the jump to subtitle feature of potplayer, it happens with mpc too with internal LAV, AVSplitter is also affected. It looks like Haali and Potplayers internal splitter is immune to this issue.
https://drive.google.com/open?id=0ByfdfPvnoDuzOGF5RXR6N3I1bHc&authuser=0

[LigH]

Without downloading it, I would guess that remultiplexing and rebuilding a clean container (open in MKVmergeGUI and save as a copy) may fix it. If not, then there may be a stream error which should be reported while trying to remultiplex.

[mzso]

Without downloading it, I would guess that remultiplexing and rebuilding a clean container (open in MKVmergeGUI and save as a copy) may fix it. If not, then there may be a stream error which should be reported while trying to remultiplex.

As that's a sample it's already remuxed, with mkvmerge. But I also re-remuxed it with ffmpeg when I made it (a while ago). With FFmpeg file the issue wasn't present.
Just tried it again. The outcome is the same and neither gives an error or a warning.
(It's 30MB-s, not quite overwhelming to download)

[nevcairiel]

The video just doesn't have a whole lot of keyframes, it has a video Cue at 2.377 and one at 12.387, but a bunch of subtitle Cues in between.
Ideally it should use the video Cue and start demuxing from that, not sure why it doesn't. I think it seeks to a subtitle Cue point instead, which is of course hardly ideal.

Edit:
Fixed

[mzso]

Edit:
Fixed
Great!

[ryrynz]

Ideally it should use the video Cue and start demuxing from that, not sure why it doesn't. I think it seeks to a subtitle Cue point instead, which is of course hardly ideal.


I gotta ask, was this added to ffmpeg recently because of this issue? or was it something that LAV just wasn't taking advantage of and has been in ffmpeg for a while?

[nevcairiel]

I am not sure what you are asking.

Some time ago, the only Cue points in MKVs used to be for video keyframes, so the naive seeking approach was simple: Seek to the closests Cue point, demux from there.
Recently, mkvtoolnix (and ffmpeg as well) started to write Cue points for subtitles. Trying to use those for seeking is of course not that great, since they don't necessarily have a video keyframe - so they don't help.

Now, the demuxer will always prefer video Cues for seeking.

Unrelated to this fix, a change was submitted to LAV recently which also makes use of those subtitle Cues to load subtitles on a seek which started before the seek point, but should still be displayed.

[ryrynz]

Was just wondering if the ability to seek via subtitle cue points was something ffmpeg already had and was just now added to LAV.
It's just the build notes give the impression LAV's fork of ffmpeg is a little behind, but I wasn't sure if that was actually the case or not.

[nevcairiel]

ffmpeg doesn't make any use of subtitle Cues when demuxing, as far as I know. To be honest, ffmpegs built-in mkv demuxer has a rather bad seeking function as is.
It writes them when muxing though.

[Luv]

Zoomplayer 10,LAV 0.64,madVR v0.87.19

Not relevant.

[Luv]

Not relevant.Sorry.

[Luv]

Fixed everything by clicking on "Auto-configure"...:D
Smashing,smashing work,Nevcairiel.Thank you.

[Nerva]

I have the same problem with my 7.1 setup. When playing 5.1 audio I get the side's sound on the back speakers.
I work it around using MPC-HC audio switcher custom channel mapping. I select 6 channel's and then map the back speakers to the side speaker.

But yes, I would prefer that LAV Audio had it correctly, so I could disable MPC-HC's audio switcher.

Bat

Apparently it has been fixed in the nightlies -- does anyone know when the fix is going to find its way into a K-Lite Codec Pack build?

[hello_hello]

I have a problem with MKVs and MPC-HC that seems to be caused by the LAV splitter. MPC-HC is currently using "LAV 0.63.0.52-git" as it's "internal" filters.

When the x264 encoder is writing it's output to an MKV, I often open the MKV to preview the output while the encoding still progresses. This has worked fine in the past, but since MPC-HC 1.7.7 the MKVs will often open without the ability to navigate. So far I can fix the problem by either switching to the Haali splitter or by deleting the MPC-HC "LAVFilters" folder and replacing it with the same folder from MPC-HC 1.7.6, which would then mean it's using LAV 0.62.0.0.
I assume therefore it's a splitter problem and not a MPC-HC problem.

Here's a sample MKV. I posted it in the MPC-HC forum a while back but the link hasn't expired yet.
http://ge.tt/7lVDr642/v/0?c (about 29MB).
MPC-HC will open the sample and allow me to navigate when using Haali or LAV 0.62.0.0 but it won't let me navigate when "LAV 0.63.0.52-git" is used. The same applies to the flavour of LAV used by MPC-HC 1.7.7, which is LAV 0.63.0.18

Thanks.

[Pat357]

I have a problem with MKVs and MPC-HC that seems to be caused by the LAV splitter. MPC-HC is currently using "LAV 0.63.0.52-git" as it's "internal" filters.

When the x264 encoder is writing it's output to an MKV, I often open the MKV to preview the output while the encoding still progresses. This has worked fine in the past, but since MPC-HC 1.7.7 the MKVs will often open without the ability to navigate. So far I can fix the problem by either switching to the Haali splitter or by deleting the MPC-HC "LAVFilters" folder and replacing it with the same folder from MPC-HC 1.7.6, which would then mean it's using LAV 0.62.0.0.
I assume therefore it's a splitter problem and not a MPC-HC problem.

Here's a sample MKV. I posted it in the MPC-HC forum a while back but the link hasn't expired yet.
http://ge.tt/7lVDr642/v/0?c (about 29MB).
MPC-HC will open the sample and allow me to navigate when using Haali or LAV 0.62.0.0 but it won't let me navigate when "LAV 0.63.0.52-git" is used. The same applies to the flavour of LAV used by MPC-HC 1.7.7, which is LAV 0.63.0.18

Thanks.

It's just a badly or incomplete muxed video.
After properly remuxing (Mkvmerge), Lav will support seeking.

[hello_hello]

It's just a badly or incomplete muxed video.
After properly remuxing (Mkvmerge), Lav will support seeking.

Yes, but that's not the problem as such. I can seek using the file I linked to with LAV 0.62.0.0 (or even Haali) but I can't seek using the file I linked to with LAV 0.63.0.18.

I've been opening MKVs as they're written by the x264 encoder for a long time without an issue. Sometime around LAV 0.63.0.0 something must have changed. Now LAV won't always create an index (or whatever it needs to do) in order to allow seeking. Sometimes it does, sometimes not.
I can literally open an MKV as it's being written by the x264 encoder and not be able to seek. I close MPC-HC and open it again and I can, then next time maybe I can't etc, but only recently. It's never been a problem before. I actually had a little trouble creating a sample that consistently won't allow me to seek any time it's opened with LAV 0.63.0.18, but the sample I linked to won't.

Thanks.

[Pat357]

Yes, but that's not the problem as such. I can seek using the file I linked to with LAV 0.62.0.0 (or even Haali) but I can't seek using the file I linked to with LAV 0.63.0.18.

I've been opening MKVs as they're written by the x264 encoder for a long time without an issue. Sometime around LAV 0.63.0.0 something must have changed. Now LAV won't always create an index (or whatever it needs to do) in order to allow seeking. Sometimes it does, sometimes not.
I can literally open an MKV as it's being written by the x264 encoder and not be able to seek. I close MPC-HC and open it again and I can, then next time maybe I can't etc, but only recently. It's never been a problem before. I actually had a little trouble creating a sample that consistently won't allow me to seek any time it's opened with LAV 0.63.0.18, but the sample I linked to won't.

Thanks.
I see.
I 'd recommend you to try the latest LAV, but I'm relative sure this will not work either. -:)
What you ask, seek support in badly muxed MKV's, is the about same as asking to support seeking in RAW H264 files, what is currently not supported.
Sure it's possible because other players or other splitters can do it.

I don't know why the older LAV 062 supported seeking in that file and how it's possible that later LAV versions can't any more, it's indeed a bit strange ..
I think the author (Nev) has other task on his "to-do-list" with higher priorities than seeking in RAW H264 files.
Note : FFMpeg's player FFPlay has some support to seek in such files and because LAV is based on FFMpeg, one might assume that LAV would also support this, but it's not.
Maybe that's why earlier LAV versions managed to do it: like a kind of "not-intentional" supported feature that was later on dropped to allow other improvements for playback of normal (=properly muxed) media files -:)
Does this make sense to you or not ?

[andybkma]

Hi madshi, I need to report that 87.19 has a playback bug. When any video starts (any format), it is frozen for a split second then plays quick catchup (plays fast for a another split second) then will start to play normally. I went from 87.17 to 87.19 and 87.17 didn't have this problem so this is something new that was introduced in the last two versions. Thank you :-)

[nevcairiel]

I think you got slightly confused about some things.

[andybkma]

I think you got slightly confused about some things.

Indeed I did :-) I go report that in the proper thread right away hehe

[qtwebkit]

Hi，Nev!
Could you please transfer all your lav codes to github?

[Kurtnoise]

https://github.com/Nevcairiel/LAVFilters

[qtwebkit]

https://github.com/Nevcairiel/LAVFilters

But ffmpeg, libburay and qsdecoder are not included.

[nevcairiel]

The code stays where it is.

[hello_hello]

What you ask, seek support in badly muxed MKV's, is the about same as asking to support seeking in RAW H264 files, what is currently not supported.
Sure it's possible because other players or other splitters can do it.

Maybe, but it's not like I'm expecting a new feature that's not been implemented previously. I'm just pointing out something no longer works as it did.

I don't know why the older LAV 062 supported seeking in that file and how it's possible that later LAV versions can't any more, it's indeed a bit strange ..
I think the author (Nev) has other task on his "to-do-list" with higher priorities than seeking in RAW H264 files.
Note : FFMpeg's player FFPlay has some support to seek in such files and because LAV is based on FFMpeg, one might assume that LAV would also support this, but it's not.

MPC-BE seeks when opening the file I linked to (internal filters). I've never has an issue getting it to seek after opening MKVs as the x264 encoder is writing them.
VLC has never been able to seek in such files.

I'll confess I was encoding today and it took three goes for LAV 0.62.0.0 to open the MKV so I could navigate, but once it did, it's opened it fine each time since. Version 0.62.0.0 has otherwise been pretty reliable in that respect.

Maybe that's why earlier LAV versions managed to do it: like a kind of "not-intentional" supported feature that was later on dropped to allow other improvements for playback of normal (=properly muxed) media files -
Does this make sense to you or not ?

Yes and no.
Here's what happens when you open a similar file with MPC-BE (my limited understanding is the inability to navigate is due to a lack of an index and the player/splitter needs to create one).
MPC-BE opens the file showing no duration initially and you can't navigate. As it's creating an index (or whatever it is it's doing) it shows you the progress.

Like this:
http://s29.postimg.org/qysjdbznb/image.jpg (http://postimage.org/)

When it's done, it displays the correct duration, allows you to navigate, and even gets all previewie. :)

Like this:
http://s11.postimg.org/v4hjph98z/image.jpg (http://postimage.org/)

I assume MPC-HC used to do exactly the same thing. I say "assume" because it didn't show you the progress while indexing as MPC-BE does, but it'd usually be faster to show the correct duration and allow you to navigate.
Since around LAV 0.63.0.0 it's been very inconsistent, only opening files (as they're being written) with the ability to navigate around a fifth of the time at best, but the file I linked to is one where it'll never let you navigate. I was hoping someone might want to work out why given LAV 0.62.0.0 does.

I guess I'll need to keep a second player installed using a different splitter by default with which I can open MKVs as they're being written to preview the encoding, although I'd rather just use the one player for everything if possible.

[sneaker_ger]

Try the newest nightly.

I also wish LAV would at least do some dumb seeking in files without an index (e.g. H.264 and H.265 ES), I'd rather have dumb seeking than no seeking - it would be good enough to take a few glimpses at a new encode. But this has been discussed on here before without any result. Nev must have his reasons for not implementing it.

[hello_hello]

Try the newest nightly.

I also wish LAV would at least do some dumb seeking in files without an index (e.g. H.264 and H.265 ES), I'd rather have dumb seeking than no seeking - it would be good enough to take a few glimpses at a new encode. But this has been discussed on here before without any result. Nev must have his reasons for not implementing it.

That's why I get the x264 encoder to write directly to MKV. I've always been able to seek that way in the past.

Anyway, after all that..... I just tried 0.64 and it appears to be okay. I didn't want to start installing stuff right this minute so I downloaded the 0.64 zip file, replaced everything in the MPC-HC\LAVFilters folder and it looks like things are back to normal in respect to MKVs. The file I liked to earlier can now be navigated and the MKV file the x264 encoder is currently writing has opened with navigation each time so far. I guess I complained too late. :)
I'll report back if anything changes.

Thanks.

[hello_hello]

Okay, I spoke too soon. I thought I'd copied all the files, but I missed one. As it turns out though, that helped me find the problem, or part of it.

When libbluray.dll is in the MPC-HC\LAVFilters folder and I open the MKV I linked to, MPC-HC won't navigate. If I delete libbluray.dll, it will. So libbluray.dll is somehow the culprit there. I haven't got time to test MKVs as they're being written at the moment, but it looks like libbluray.dll is at least partly to blame there, but it's late, I'm tired, and I've got to work tomorrow. I'll experiment some more tomorrow night. At least that's a start in the right direction.

[sneaker_ger]

Why don't you install the nightly like I told you to? You are wasting everyone's time by not testing the newest version.

About the libbluray.dll thing: I assume when you deleted it from MPC-HC\LAVFilters the splitter could not load anymore and MPC-HC switched from its internal to the one you have installed in your system which happens to be 0.62 or whatever you have still installed. Delete the both the internal and the system LAVFilters folders and do a clean install of the nightly build.

[nevcairiel]

If you delete libbluray.dll, then LAV will fail to load entirely and not be used at all anymore.

[sneaker_ger]

I mean if he still has it in the system's LAV Filters folder (c:\program files (x86)\LAV Filters\...). MPC-HC will not be able to load the internal version from MPC-HC\LAVFilters if he deletes the libbluray.dll there but of course should still be able to load the system version if that one still has the dll.

[hello_hello]

Why don't you install the nightly like I told you to? You are wasting everyone's time by not testing the newest version.

Because I don't have LAV installed at all (it's just being used by MPC-HC as it's internal filters), it was late at night, the PC was in the middle of running some encodes, and I didn't want to start installing new software that might mess things up until I've got time to spend sorting it out. So I tried the zip file of version 0.64 and used it to replaced the files MPC-HC is using instead.

That, and because there's no indication as to why the latest nightly should be a magic bullet, and because if I install it and it does work differently installed than when MPC-HC is using it as it's internal filters, how do I know it'll continue to work the same way when it is? Although I guess that'd probably be worth finding out.

I'm wondering why I even bothered posting a sample. I thought maybe someone running a later LAV version or has it installed might test it, but I've posted about a problem I thought would be worth looking into and so far received enough negativity to be close to losing interest and just using something else. Especially as I've already tried going through this process in the MPC-HC thread without getting anywhere.

If you delete libbluray.dll, then LAV will fail to load entirely and not be used at all anymore.

Yes, you're correct. I didn't realise it at the time (it was three in the morning and I was pretty tired), but with libbluray.dll gone from the MPC-HC\LAVFilters folder MPC-HC is using the Haali splitter along with the LAV video decoder and that combination works as it should.

I'll try some more testing later on. I have a clean Windows (XP) install on another drive. Once the latest encoding has finished I'll boot from it, install LAV and see what happens from there. Mightn't be until tomorrow now...... :)

Thanks.

[qtwebkit]

Its difficult for us Chinese users to sync with those codes due to the block of GFW.
Moving to github would make it much more handy, I would appreciate if you would consider it.

[sneaker_ger]

That, and because there's no indication as to why the latest nightly should be a magic bullet, and because if I install it and it does work differently installed than when MPC-HC is using it as it's internal filters, how do I know it'll continue to work the same way when it is? Although I guess that'd probably be worth finding out.

I'm wondering why I even bothered posting a sample. I thought maybe someone running a later LAV version or has it installed might test it, but I've posted about a problem I thought would be worth looking into and so far received enough negativity to be close to losing interest and just using something else. Especially as I've already tried going through this process in the MPC-HC thread without getting anywhere.
I wasn't suggesting the nightly just because it's newer but because Nev did a commit the day before yesterday that fixes your sample. Your report was not in vain - he sometimes just silently fixes things reported without giving direct feedback in here.

[hello_hello]

I wasn't suggesting the nightly just because it's newer but because Nev did a commit the day before yesterday that fixes your sample. Your report was not in vain - he sometimes just silently fixes things reported without giving direct feedback in here.

Sorry. Had I known that I wouldn't have wasted time with 0.64, but nobody mentioned it.

I haven't quite got to the "ready to reboot" stage yet as I haven't had much spare time today, the PC's still encoding, and it's late so it looks like I'll have to try the nightly tomorrow (there's no zip for the nightlies I could find).

If it's fixed though, many thinks to Nev in advance!

I'll report back tomorrow once I've installed the nightly.

[sneaker_ger]

You should be able to unpack the installer using innounp (http://innounp.sourceforge.net/). Then you can simply replace MPC-HC's internal version with the nightly by copying the files into the MPC-HC\LAVFilters folder without the installer messing with your system.

[DigitalLF]

i got a little wish that would help me out alot and proberly others to.

"mix settings depending on output"

I would love to see a setting that would allow me to always downmix to 2.0 on my DAC and on my home cinema there should be no downmix.

I have to change my default output unit in ReClock everytime i go from "home cinema" to "headphones" and if i would be able to simplify it a bit like "mix settings depending on output" it would be great!!

other then that i just want to say GREAT work with LAV Filters :)

[Thunderbolt8]

getting MPC-HC crash when closing it down, but otherwise everything seems to be working fine here (Windows 8.1, GTX760M, GeForce 347.88)

Problem signature:
Problem Event Name: BEX64
Application Name: mpc-hc64.exe
Application Version: 1.7.8.152
Application Timestamp: 5526f937
Fault Module Name: StackHash_1e37
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: PCH_AB
Exception Code: c0000005
Exception Data: 0000000000000008
OS Version: 6.3.9600.2.0.0.256.4
Locale ID: 1031
Additional Information 1: 1e37
Additional Information 2: 1e373e69fff075aed81f57003e66ce10
Additional Information 3: 9f0e
Additional Information 4: 9f0e095f32a88249d7a2b7eca4e322ea

[sneaker_ger]

Are you using madVR 64? Known issue (http://forum.doom9.org/showpost.php?p=1717318&postcount=28846), probably not related to LAV.

[ryrynz]

are you using madvr 64? known issue (http://forum.doom9.org/showpost.php?p=1717318&postcount=28846), probably not related to lav.

MadVR 64?