LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Seeking in MKVs without a index works, but its just extremely slow the first time. Wait for a few seconds, and it will finish seeking. A second seek is then fast.
This is not going to change much, since you can't arbitrarily seek in a MKV without manually building up a seeking index first.

I can probably speed those seeks up by increasing the index steps from 10mb to something else, though. 10mb was choosen in a time when video was still much lower bitrate.

[wanezhiling]

LAV splitter outputs "H264" FourCC for all MPEG-TS/AVI AVC1 files? (http://i1.tietuku.com/6ewauludd.png)

Is this intentional? :)

[nevcairiel]

MPEG-TS is always H264, AVI can be both H264 or AVC1. It automatically detects the right mode.

So yes, its intentional. It helps to reduce CPU usage, if you want to output AVC1 from MPEG-TS, you need to convert it, which uses CPU.

[wanezhiling]

Thanks, That explains why some commercial solutions like MainConcept do same thing.

[Niyawa]

Hey nev, I have one question which searching never found me an answer.

There is a specific encode, this one (http://bakabt.me/details.php?id=141941), which after episode 51 always stutter. Apparently it's related to LAV not being able to handle WMV9 correctly (this is what I get no matter where I go) so I'd like your input on the issue. What really happens and why the video/audio stutters when those files are played? I always believed it was an isolated encode issue.

[filler56789]

Hey nev, I have one question which searching never found me an answer.

There is a specific encode, this one (http://bakabt.me/details.php?id=141941), which after episode 51 always stutter. Apparently it's related to LAV not being able to handle WMV9 correctly (this is what I get no matter where I go) so I'd like your input on the issue. What really happens and why the video/audio stutters when those files are played? I always believed it was an isolated encode issue.

That's an interesting problem, and apparently it's related to the audio part :confused: If I open one of the "problematic" MKVs in Graphstudio, yes, stuttering happens, BUT if I remove the audio from the graph, then there is no stuttering, and when the audio is re-added to the graph, the playback remains "stutter-free" :confused:

[nevcairiel]

filler56789 is right, its the audio stream which is the problem. The video is handled perfectly.
Whoever decided to go with WMAv2 audio is just a bad person! :)

Anyhow, the audio is muxed weirdly, plus that wma doesnt really belong in MKV.

In my tests it looks like that when you use LAV Audio, you'll get a much better result. wma is disabled by default in LAV Audio, but if you turn it on and let it take over, you get mostly smooth playback of these files. With the MS decoder, its stuttering like mad.

[Dstruct]

Hints
- When running on Windows XP, its recommended to turn the "Use HQ DXVA processing" setting off, its not fully supported on XP and might cause image corruption.

Is this still true? If so, this option should be greyed out/disabled on XP systems (so users can't enable it)!

MPC-HC 1.7.1 with internal LAV

[Raylan Givens]

I used it for testing occasionally, i may switch to it for the next release, not decided yet. 0.59.1 is built with VS2012 U4.

Nice, mate... For the sake of consistency, it would be great to give us the the next update built with MSVC2013; like MPC-HC. I heard there are useful improvements, but I've no idea in what field and if it's relevant to LAV. Nevertheless, I don't think it's gonna hurt.

[clsid]

Don't expect any (performance) improvements. Most changes in MSVC2013 are in the development environment. Also, most performance critical parts of LAV Filters are either in FFmpeg, which is compiled with GCC, or are written in intrinsics. So there is not much that can be improved by MSVC.

@nev
Those anime videos play smoothly with Haali splitter. Perhaps you can imitate how Haali is handling the WMA audio?

[filler56789]

@nev
Those anime videos play smoothly with Haali splitter.
Well-spotted, those encodes are "very-old" already, and were created when there was no such thing as LAV Splitter :)
Perhaps you can imitate how Haali is handling the WMA audio?

FWIW --- those MKVs are handled fine by Mplayer (and by VLC too, according to the page linked in Niyawa's post).

[wanezhiling]

http://url.cn/V2XQwI
No picture, openjpeg library seems fine.

[nevcairiel]

Test with ffmpeg, and report it there if it also happens. Its their bug.

[annovif]

Hi Nevcairiel , i use with great satisfaction your Lav audio-splitter that are incredible. I don't use Lav video because i prefer Coreavc. The fact is that in my lcos projector it has much more sharpness . Yesterday i tried Lav video and changed from Random dithering in Ordered dithering and i've seen that the sharpness situation was much better, but Coreavc has another time more sharpness. Can you add a voice "no dithering" like coreavc? I think that the difference that i see are there. If you have another idea......

Thank you very much and congratulations for your wonderful work, Fabio

[sneaker_ger]

Hi Nevcairiel , i use with great satisfaction your Lav audio-splitter that are incredible. I don't use Lav video because i prefer Coreavc. The fact is that in my lcos projector it has much more sharpness . Yesterday i tried Lav video and changed from Random dithering in Ordered dithering and i've seen that the sharpness situation was much better, but Coreavc has another time more sharpness. Can you add a voice "no dithering" like coreavc? I think that the difference that i see are there. If you have another idea......
There is no quality difference between CoreAVC and LAV decoding. Both decode according to the H.264 standard and their output is bit-identical. You can test it with proper testing methods (your eyes aren't). Dithering is only used when a conversion has to happen because the renderer does not accept the direct decoder output (decoding 10 Bit H.264 but renderer only accepts 8 Bit) - this is not the case for 99% of content. In these cases you definitely don't want to turn dither off, it can lead to artifacts.

[Anima123]

nevcairiel, I have some video encoded as double-framerate, probably due to the using a kind of double-framerate deinterlacer before encoding. These files get me into trouble since I am using a 2010 laptop which is quite not fast enough for it.

I wonder if you can add an option to output 1/2 decimated frames from LAV video decoder, so that I can play it with nowadays old hardwares.

[sneaker_ger]

You can't just not decode every other frame because common codecs use inter-frame techniques to increase the compression, i.e. a frame needs data from the decoded preceding frame. Some frames can be dropped under certain conditions but it will probably not be practical enough no implement anything like that.

Are you using software or hardware decoding? Try switching between them.

[Anima123]

I prefer software decoding as nav suggested. It's not the decoding power not enough, it's that my gpu cannot handle framerate like that. It should be nice to trigger that option only if 1/2 decimated framerate is close to standard framerate.

[sneaker_ger]

Putting aside your feature request your problem sounds very strange for a 2010 laptop. What kind of GPU does it have? Input and output resolutions? Renderer? Framerate? Is it trying to deinterlace (try forcing deinterlacing off in LAV Video)?

[Anima123]

It's a laptop for office use, with a crappy nV 3100 card. The LED resolution is 1440x900, with madVR, no deinterlace, and the source is 720p, the framerate is 59.940.

[DragonQ]

Make sure Windows Power Options are set correctly, i.e. video is set for max performance and frame rate isn't reduced to 40p or anything like that.

[mindbomb]

i have a question about pgs subs with forced captions in matroska.
enable automatic forced subs is on by default, right? so the forced parts always get played, regardless of whether the sub track has the default flag?

[nevcairiel]

There is a specific encode, this one (http://bakabt.me/details.php?id=141941), which after episode 51 always stutter. Apparently it's related to LAV not being able to handle WMV9 correctly (this is what I get no matter where I go) so I'd like your input on the issue. What really happens and why the video/audio stutters when those files are played? I always believed it was an isolated encode issue.


@nev
Those anime videos play smoothly with Haali splitter. Perhaps you can imitate how Haali is handling the WMA audio?

I found the reason for that, and it should be fixed in the next version.

[clsid]

Thanks

[sneaker_ger]

Their muxing might be considered b0rked in general if they don't have a standard duration elements for the audio tracks despite grouping frames unless I'm missing something here.

[nevcairiel]

The real issue was ffmpegs magic to try to compute timestamps for the audio was rather broken, so instead of simply having an occasional frame without a timestamp, you would get rather broken timestamps...

[sneaker_ger]

Well, the timestamps are broken as I see it. The muxing went wrong. That doesn't mean players can't be clever and correct that on-the-fly, of course. Because of the jitter in most mkv files something like that has to be done anyways. (But you know that better than me...)

[annovif]

ok sneaker_ger, thank you for your explanation, but I think if I could enable or disable dithering, after I could choose the situation that I like the most.

Thank you, Fabio

[Soukyuu]

I downloaded the file and will check it when i get a chance. First tests show that it mis-identifies the second track as adx as well, which results it in discarding it because it thinks its invalid (since its not valid adx)
Not sure when I'll get to it, hopefully on the weekend.nevcariel, I reported this to the FFMPEG devs and they fixed the demuxing of ac3 out of .sfd files now. Just tried the latest git and it works fine, i'm getting both the m1v, the adx and the ac3 out of the sfd as it's supposed to.

I noticed some more strange behavior when playing those .sfd files with the latest stable mpc-hc: the adx audio seems to be playing fine, however if I try to seek the file, the audio disappears. The video plays fine until the next seek, then it just hangs at that position. Pressing stop -> play hangs as well. I'm not sure if it's an MPC-HC related but or a LAV bug though.

[nevcairiel]

nevcariel, I reported this to the FFMPEG devs and they fixed the demuxing of ac3 out of .sfd files now. Just tried the latest git and it works fine, i'm getting both the m1v, the adx and the ac3 out of the sfd as it's supposed to.

I noticed some more strange behavior when playing those .sfd files with the latest stable mpc-hc: the adx audio seems to be playing fine, however if I try to seek the file, the audio disappears. The video plays fine until the next seek, then it just hangs at that position. Pressing stop -> play hangs as well. I'm not sure if it's an MPC-HC related but or a LAV bug though.

I saw the fix, I'll update soon.

I tested seeking in the sample you provided, and while the audio does indeed vanish on seek, the video seems to work properly here. But I'll test again after I've updated to the latest version with the AC3 fix, and see if something changed, and try to find out where the audio goes.
Not sure the format was designed for seeking in mind. AFAIK, its some game format? They don't usually seek.

[Soukyuu]

The format is actually just mpeg1/2 (depending on the version) video that allows muxing CRI's ADPCM (adx) as audio, from what I gathered. I don't know if they did any modifications apart form that. There is some info about the format here (http://forum.xentax.com/viewtopic.php?f=10&t=3084), though I don't know how correct it is. If it doesn't support seeking, that's fine, however why would play -> stop -> play not work? MPC-HC seeking to file start instead of reopening?

[wanezhiling]

Hi nev would LAV splitter add Strongene FourCCs (HM6.2/9.1/10.0/11.0/12.0)? So that we do not need their special "FLVSplitter.ax" anymore. :)

[JEEB]

wanezhiling, have some reasons for not hacking in support for these FLV mappings:

They are hacks on top of Adobe's container, completely unofficial. If Adobe ever considers using these IDs they will collide.
As far as I remember, those contain multiple ways of derping HEVC when muxing/demuxing.
At least three of them seem to note a HM version that is not compatible with the final specification.

There are more or less officially settled ways of muxing HEVC into containers. By supporting a 100% unofficial hack, or well -- multiple of them, you are letting people use it and think it is alright. It is not. Now, give me one good reason why people should add support to these hacks.

If Adobe ever makes an official mapping for HEVC, feel free to have it implemented over at libavformat, of course.

[hubblec4]

hi nev

is this right that LAV filters not support this ChapterElement?

<ChapterProcessData format="ascii">GotoAndPlay(452202188);</ChapterProcessData>

and when not is it possible to implement this?

[Niyawa]

The real issue was ffmpegs magic to try to compute timestamps for the audio was rather broken, so instead of simply having an occasional frame without a timestamp, you would get rather broken timestamps...
Thanks for the replies everyone. Now I get a better idea that I should definetively avoid old encodes. Anyway, thank you very much for the fix, it was kinda irritating when people said that it worked perfectly in VLC but not in LAV, now I can get that back to 'em.

[iSunrise]

@nevcairiel:
Can you add RTMP-support to the splitter filter? I am asking, since ffmpeg seems to already have good support for it (they even introduced seeking support recently) and LAV also supports RTP and RTSP already.

[fluffy01]

I have a 38mpbs h.264 AVC 1080i 10-bit 4:2:2 video, that when I play it using LAV Video, the picture stutters like crazy and I get loads of frame drops. According to madVR, the decoder queue just wont fill up, and it stays at 0-1 all the time.

I have tried different combinations of renderers and splitters, and no matter what I try, as long as I am using LAV Video, it is stuttering like crazy. CPU usage is only around 45%, so I can't figure out why it is doing it.

I even tried remuxing the video, just to make sure, that it wasn't due to a bad mux, but it didn't help.

If I use ffdshow as decoder, there is no problem at all, and the video is fluid. Still using LAV Splitter, LAV Audio and madVR, and no problems at all.

So my best guess is that there is some kind of bug in LAV Video, causing this problem.

I can cut you a sample and put it on my FTP-server, if you need a sample.

[Guest]

Tell us about your source material (what is it and where did it come from) and, yes, post a small unprocessed source sample.

[fluffy01]

It's from a sat feed of a sports entertainment show.

I will cut you a sample shortly, if you want, and PM you login details to my FTP server.

[Guest]

It's from a sat feed of a sports entertainment show. Where did you get it?

I will cut you a sample shortly, if you want, and PM you login details to my FTP server. Post the link here. Please don't send me a PM about it.

[fluffy01]

Where did you get it?
I got it from the satellite dish. I think it was a test broadcast, as they usually don't broadcast in that format.
Post the link here. Please don't send me a PM about it.
I am not posting login credentials to my personal FTP publicly. My FTP would get swamped.

And I mostly intended for Nev to get a login since he is the main dev and the person most likely to be able to debug and fix any issues.

[nevcairiel]

You can send me the link, I'll look at it when i have some time.

[fluffy01]

You can send me the link, I'll look at it when i have some time.
Done.

If it helps, the first sample I made didn't have the problem, so apparently it is not all 10 bit 4:2:2 AVC that are suffering.

[nevcairiel]

If it helps, the first sample I made didn't have the problem, so apparently it is not all 10 bit 4:2:2 AVC that are suffering.

I got the file, and it seems to be running (mostly) smoothly here.
Are you sure the video isn't overloading something in your hardware?

4:2:2 10-bit has a rather high memory bandwidth requirement.
What does madVR say as format? If everything is ideal, it should be "h264, 10 bit, 4:2:2 -> P210, 10 bit, 4:2:2"

I can imagine that ffdshow for example does not deliver native 10-bit content and instead converts to 8-bit, which would result in lower memory bandwidth and possibly avoid the problem. You could check by comparing this line between LAV and ffdshow.
You can als try to disable 4:2:2 10-bit formats in LAV and see if it improves.

For the record, i can kinda reproduce the issue if i play it on my Intel iGPU. Its not as extreme as you describe, but its not perfect smooth either. On my NVIDIA it seems to run fine.

[fluffy01]

According to madVR, both LAV and ffdshow delivered the video in P210 format. Also in ffdshow's info box, it said that it was outputting P210.

My GFX card is a Geforce GTX 670, so it should be plenty powerful.
Also, I can software decode and play 4K videos without any issues, so I don't think there should be bandwidth issues either.

But maybe it's just some issue on my PC and it's not affecting anybody else.

But I can't test it on my other computers, as they are not powerful enough to decode the video.

[nevcairiel]

I think it might just be your CPU hitting its limit.
I tried to benchmark the clip, and it doesn't go above 20% CPU usage here. Some interlaced clips sadly have this issue that the current ffmpeg decoder cannot multi-thread properly, so it ends up using 2 threads at max - so in a benchmark i can barely get 35 fps out of it on my system, which for a 29.97 fps clip is not really all that much headroom.

I can try to talk to the ffmpeg developers if something can be improved here, though.

[fluffy01]

My CPU is a Intel Ivy Bridge quad core i5-3450, and it runs at about 45% avg. load on both LAV and ffdshow when playing that clip.

One thing I have noticed, is that when I start playing the clip, all madVR buffers are full, and then the decoder queue drains to 0-1 over about 15 secs, after which the stuttering begins.

I have a CPU queue at 12 atm, and if I increase that, then it takes longer before the stuttering begins, but it does stutter after the queue is emptied.

I just tested. With a CPU queue of 12 and a GPU queue of 8 and 4 frames presented in advance, I get around 450 dropped frames for that 1 minute sample, and 0 dropped frames from the start until the queue runs out.

[nevcairiel]

Yeah the CPU is just slightly too slow, I guess. I have a i7-4770k, and like i said it can barely get 35 fps out of it, so your CPU staying just below 30 seems likely.
ffdshows version of ffmpeg is about 1.5 years old, so maybe a bug was fixed in the meantime that made it a few percents slower (checking everything works properly sadly also makes stuff slightly slower sometimes), but its impossible to say what the difference really is.

Like i said, I'll talk to the ffmpeg developers to check if they can improve the multi-threading capability, so that the file can actually make use of all your CPU cores, and not just run at 1.8 cores... :)

[fluffy01]

Ok. I just find it counter intuitive that the CPU is too slow, when it is only running at 45% usage.

[nevcairiel]

Well, like i said, it doesn't multi-thread well, so in this case on a quadcore that means one core is at 100% load, and one core is only at about 80% (and 2 are idle), giving a grand total of 45%.
The way this interlaced sample is encoded doesn't let it multi-thread better right now, and it can't use more cores, but this is something that can hopefully be improved.