LAV Filters - DirectShow Media Splitter and Decoders

[Pat357]

On gt5** I wasn't able to go beyond middle power state so far when watching video. I probably need to plug in heavy fft3dgpu denoiser in my playback chain to do that :P

FFT3DGPU isn't be needed for that : play a VC-1 1080i60 movie in DXVA-CB or with CUVID and madVR as renderer : MadVR will do the deinterlacing for DXVA-CB. Further enable Lanczos with the anti-ringing....

[RealSnoopyDog]

Thanks, fixed.

Quote:
Originally Posted by RealSnoopyDog View Post
Is it possible to add the output configuration "Mono" to the audio downmixer?

I'll add it for the next version.

I had some time to look at the sources and saw that current version is already capable of downmixing to Mono. When i manually write the value "4" (AV_CH_LAYOUT_MONO=AV_CH_FRONT_CENTER) to "MixingLayout" in the Registry then it's downmixing to Mono ;) And i saw that you added the option to the configuration dialog - thank you!

[ajp_anton]

Don't know about AMD but Intel's processors don't consume maximum power they can when decoding video. They run at half clock maximum and this doesn't consumes more power. Plus they have their own quicksync stuff, plus I doubt it consumes less power than DXVA CB, the actual chip on the GPU does exactly the same job.
My quesion is not "why use dxva" but "why use native dxva"That's why I used the word "desperately", because it uses ever so slightly less power to not copy the frames back and forth.

[cyberbeing]

It appears that threading doesn't always properly activate in the 0.51.3-15 and 0.51.3-18 test builds when benchmarking with Avisynth 2.6 DirectShowSource & AVSMeter 1.21.

CPU usage reported by Windows Task Manager goes strange too. Sometimes it reports 0-1% for an entire run and other times 25% CPU usage when this issue occurs, even though benched fps is identical (125fps min | 300fps max | 200fps avg). And then at random it will start acting normally again with 100% CPU usage (250fps min | 1000fps max | 525fps avg). Official 0.51.3 release seems to be unaffected.

The script contained nothing but directshow source with a 1280x720 10-bit h.264 video, so there is a YV12 conversion performed by LAV Video. The splitter was Haali Media Splitter:

directshowsource("test.mkv", fps=24/1.001, audio=false, pixel_type="YV12")

[nevcairiel]

Thats not really possible, it has nothing that would make it randomly fallback to single threading for some reason, unless your splitter behaves unpredictable and sometimes doesn't provide a proper media type (which is the only reason it would even disable multithreading)
How would it even produce ~200 fps average on 1% cpu? :D

Note that -15 was still buggy, and you should not use it for anything.

Somehow i think your testing tool is faulty, these results don't make much sense.

[cyberbeing]

It could very well be a bug in AVSMeter (http://forum.doom9.org/showthread.php?t=165528), I just found it strange as well. I do have "Use custom media type" (CCV1) and auto-load VSFilter enabled in Haali if that matters. It's not VSFilter related though, since it happens even when it's unregistered.

Edit: It appears the performance reported by the bugged runs identically matches the min/avg fps of LAV Video with 2 threads, which makes it even more strange.

Edit2: I reproduced the same problem with avs2pipemod 0.4.1 (-benchmark), so it seems it's not a AVSMeter exclusive issue. Rather it would seem to suggest that the new LAV Video threading may have compatibility issues with DirectShowSource in general. The Avisynth 2.6 build I'm using is xhmikosr's.

Edit3: The CPU is definitely more active than the 1-5% Usage which Task Manager shows. RealTemp shows a ~40% load which explains why the results nearly match LAV Video with 2 threads. It also seems to have a tendency to always occur right after I reboot for whatever reason, even if it randomly starting working normally before the reboot (Win7 x64, i5-3570K).

[nevcairiel]

I see no reason for any slow downs. The nature of the change is quite simple, there is really only 3 outcomes: It works, it deadlocks, or it works and causes video corruption. A deadlock was what happend with the -15 build, and is fixed since, and i've yet to find a codec inside avcodec that corrupted. I just don't see how it can really slow down there.

How often does the problem occur? Can it easily be reproduced by just trying a few times?
If its easy enough to re-produce to form a conclusion, does it happen with LAV as splitter?

Anyhow, the advantage on already multithreaded codecs is nearly zero, so i might as well turn it off for those (it just uses more RAM when running with those)
Speaking of RAM, looking at AVSMeter running, either it or AviSynth itself seem to leak massive amounts of memory, it uses significantly more then say MPC-HC just playing that file, and is constantly increasing.

[Soukyuu]

I am not sure whether to post this here or on the madVR thread, but I found some weird behavior when playing back a certain scene (https://dl.dropbox.com/u/19330332/test.mp4) of a h264 file (114Mb, rightclick->save as...).

Following setup:

- MPC-HC 1.6.2.4902
- Haali Media Splitter
- LAV Audio+Video Decoder 0.51.3
- madVR v0.82.5/EVR custom pres

Following problem:

From 0:14 to 0:22 in the above clip, madVR stutters horribly, EVR much less but still noticeable.
Once I block LAV Video Decoder and use MPC-HC internal one, the clip plays back smoothly with either renderer.

It doesn't matter if I only encode this scene, or the whole cutscene, it always stutters at the same frames.
There is no noticeable increase in CPU usage (well below 20% on each of the 4 cores), while GPU usage actually drops.

The source material (MJPEG recorded from the game with msi afterburner) plays smoothly with LAV, so it must be a h264 specific problem.
I encoded the clip with x264 rev2200, no special settings (--crf 24 --b-adapt 2 --qpmax 51 --me umh) using MeGUI.

I hope there is no legal issue with uploading this scene as an example, as it's not the whole cutscene and the footage was not obtained illegally.

[Keiyakusha]

check if you use dxva cuvid or quicksync. it maybe hardware related problem. specific part of the video may be more complex and your hardware maybe not good enough to handle that part of the video. modern nvidia cards with vp4-vp5 engine for example can eat any h264 video, but not the older ones
EDIT: Maximum bit rate : 100 Mbps omg, who ever created this he need to rethink his encoding approach. if you DO use hardware decoding it may be hardware problem as I expected because this high bitrate exactly at the time you saying and looking at the picture its pretty obvious why such bitrate is there. Bit for hardware decoders this may be too much.
EDIT2: this is not good (http://i.imgur.com/aeZBA.png). mpc-hc uses software decoder when you switch probably.

[nevcairiel]

I am not sure whether to post this here or on the madVR thread, but I found some weird behavior when playing back a certain scene (https://dl.dropbox.com/u/19330332/test.mp4) of a h264 file (114Mb, rightclick->save as...).

I cannot detect any problems with that file, seems to decode just fine here.
May be caused by the extremely high bitrate in that section. On my system at least it works fine with both software and hardware decoding, but i have pretty good and recent hardware which can deal with high-bitrate clips like this.

[Keiyakusha]

I was playing more with this video, my hardware decoders does statter on it. Software LAV seems to be fine if not to count few runs when I got error in avcodec-lav-54.dll (Microsoft C++ runtime "application requested to terminate it in unusual way")
EDIT: actually i tested only DXVA before, other hardware versions doesn't stutter for me. however note that the video itself contains some duplicate frames that may look like stuttering and frame drops.

[nevcairiel]

I got error in avcodec-lav-54.dll (Microsoft C++ runtime "application requested to terminate it in unusual way")

Thats a bug in the latest test builds which i'm still trying to find, not sure how it can happen yet. I have turned off part of the new multi-threading handling until i can find it (i planned ahead and made it controllable with a switch :p)

[edwrap]

just a quick question about one of your recent commits, nev
Always try fallback reconnect instead of giving up completely.

does this mean playback will more reliably resume after a system standby? it usually doesn't on my laptop, though I'm not sure if that's because of my wifi/router, mpc-hc, or lav specifically

[Pat357]

Speaking of RAM, looking at AVSMeter running, either it or AviSynth itself seem to leak massive amounts of memory, it uses significantly more then say MPC-HC just playing that file, and is constantly increasing.

It's probably buffering more and more frames.
That's when the setting
"SetMemoryMax(xx)" xx = max RAM allowed [MB]"
comes handy.

Now that I think about it : AVSMeter also creates a buffer...:D

[Pat357]

just a quick question about one of your recent commits, nev


does this mean playback will more reliably resume after a system standby? it usually doesn't on my laptop, though I'm not sure if that's because of my wifi/router, mpc-hc, or lav specifically
Do you maybe connect wireless to another system where your movies are stored ?
Put a decent wire between or try with MPC and LAV installed on the other PC, at least in case if it's a PC.
This should exclude your Wifi from this problem.

[cyberbeing]

How often does the problem occur?
Almost always. It's rare to see normal results.

Can it easily be reproduced by just trying a few times?
Yes.

If its easy enough to re-produce to form a conclusion, does it happen with LAV as splitter?
Yes.

Speaking of RAM, looking at AVSMeter running, either it or AviSynth itself seem to leak massive amounts of memory, it uses significantly more then say MPC-HC just playing that file, and is constantly increasing.
Probably just Avisynth. If you add an extremely low value like SetMemoryMax(4) or SetMemoryMax(16) to the beginning of the script, it will cap out at roughly MPC-HC memory use +XXMB, where XX is the value you set.

[NanoBot]

Hi nevcairiel, hi everybody !

Since I just saw some postings concerning buffering, I would like to suggest a new feature.

A few days ago, I got my first notebook, which is equipped with a 630M based Optimus graphics solution, 300mBit/s WLAN and 1GBit LAN. After installing MPC-HC, LAV-Filters and MadVR, I am able to playback all my media files like I am used to on my desktop PC, if they are located on the local hard drive of the notebook. Nevertheless, it was the first time I tried to playback media files which are located on network drives, and this is giving me heavy trouble, especially on media files with high average and peak bitrates. When I am trying to playback such files via WLAN, which connects with full 300mbit/s, depending on the bitrate the video stalls within 10s - 60s, while the audio playback continues. But even when using the 1GBit LAN, which in fact is running at full speed, the playback of high bitrate files show the same symptoms earlier or later.

My best guess is, that from time to time the network latency is to big, which causes a buffer underrun. And since I am using LAV splitter, I think that this buffer is located within LAV splitter, and if my assumption is correct, has to be increased here. That's also the reason why I am posting my suggestion here and not in the MPC-HC thread.

To have a comparision with other media player applications, I gave the well known VLC player a shot, and it does not have such problems, if I am increasing the SMB buffer size like described here:

http://www.ehow.com/how_8454118_change-buffer-vlc.html

If my conclusions about the reason for the playback problems are correct, I would like to suggest to add the following feature to the splitter part of LAV filters:

Whenever the user opens a new media file, the splitter checks if the file is located on a network drive or not. This could be done by interpreting UNC pathnames as network drive and/or a list of drive letters, which should also be treated as network drive. If and only if a network drive is identified, the buffer should be increased to a user defined value, e.g. the user can determine a given numbers of mS, which should be ( roughly ) prebuffered, before the playback starts. Of course the playback has to be paused, the prebuffer to be flushed and rebuild, and the playback resumed whenever the user navigates whithin the media file.

C.U. NanoBot

[nevcairiel]

does this mean playback will more reliably resume after a system standby? it usually doesn't on my laptop, though I'm not sure if that's because of my wifi/router, mpc-hc, or lav specifically

It has nothing to do with that. In fact, i don't think the decoders or the splitter cares what happens to them, they don't use any special resources (unless you're talking DXVA here), its most likely the renderer giving up. On the other hand, why would you standby in the middle of playback? :d

[nevcairiel]

Almost always. It's rare to see normal results.


I tried to reproduce the problem with AviSynth and AVSMeter, but it always looks just fine :(
Anyhow i found some other issues which i couldn't really explain yet, and i deactivated it again for the time being until i have some more time to properly debug this.

Back to working on my subtitle interface and dvd video support..

[cyberbeing]

Did you try immediately after rebooting Win7? If it randomly starts outputting normal results, it seems to continue doing so consistently for awhile. What triggers this change is unknown.

It appears that LAV Video is creating 6 threads, but each thread is limited to 7% CPU usage each on my 4-core 3570K (totaling ~42% usage). It also seems like if I disable HPET in my BIOS, the bugged runs are faster and limited to 8% CPU each for just under 50% CPU usage. Thread timing or synchronization bug? I wonder if this could be an Ivy Bridge errata or something.

The only reason I somewhat care or even noticed this, is because I use regularly use DirectShowSource to benchmark experimental xy-VSFilter optimizations, and document results in order to catch regressions.

[ryrynz]

Back to working on my subtitle interface and dvd video support..

:) *Hangs up DND sign*.

[dukey]

What are you doing with subs nev ?

[Groucho2004]

Now that I think about it : AVSMeter also creates a buffer...:D
:confused::confused:
What buffer?

[Keiyakusha]

:confused::confused:
What buffer?
It usually starts displaying something only after some number of processed frames, like 30-60 frames. This is not due to buffer? Oo

[Groucho2004]

It usually starts displaying something only after some number of processed frames, like 30-60 frames. This is not due to buffer? Oo
No, it just has to read a certain number of frames at the beginning in order to display meaningful values.

[Soukyuu]

EDIT: Maximum bit rate : 100 Mbps omg, who ever created this he need to rethink his encoding approach. if you DO use hardware decoding it may be hardware problem as I expected because this high bitrate exactly at the time you saying and looking at the picture its pretty obvious why such bitrate is there. Bit for hardware decoders this may be too much.
EDIT2: this is not good (http://i.imgur.com/aeZBA.png). mpc-hc uses software decoder when you switch probably.Uhm. The encoder was me XD
The setting I used are in my post, I guess the crf just makes it jump to that insane bitrate trying to preserve the quality. The file is not meant for sharing, so as long as I get the best quality playable, I'm fine with the space it uses.

I am a newbie when it comes to encoding though, I guess I should somehow limit the bitrate additionally to specifying the crf?

I cannot detect any problems with that file, seems to decode just fine here.
May be caused by the extremely high bitrate in that section. On my system at least it works fine with both software and hardware decoding, but i have pretty good and recent hardware which can deal with high-bitrate clips like this.
I have a Phenom II X4@3.4GHz an a nVidia 260GTX. What I don't understand is, if it's my hardware being too weak for this bitrate, why is the usage not spiking to 100% when it stutters?

The same file playing fine with same settings when LAV is off is what makes me think it must have something to do with LAV...

edit: after further testing, it looks like this:
no hardware acceleration - no stuttering - ~70% cpu peak usage
nVidia CUVID - stuttering - ~26% GPU load, 72% Video engine load according to GPU-Z
DXVA2 (copyback) - stuttering - ~26% GPU load, 100% Video engine load
DXVA2 (native) - no stuttering - ~26% GPU load, 0% Video engine load

So it seems nVidia's decoder screws up, same for the copyback version of DXVA2 (whatever that means)

edit2: added load numbers

[nevcairiel]

Its not so much that the GPU screws up, the 260GTX just has one of the oldest hardware decoders, which is slower then for example the one in my card. 100mbit H.264 is a pretty high bandwidth, so its completely possible that it just doesn't support that much.

PS:
I think DXVA2 Native didnt work in your setup and it used software decoding instead, otherwise there would be more then 0% load.

[Soukyuu]

So for some reason, my post was blank, I guess maintenance ate it.

I tested the video with vdpau on linux and it's the same over there. What I still don't understand is why it is stuttering if video engine load is not maxed out when using CUVID.

My only guess is there might be a bandwidth issue uploading the frames to the card, my mainboard is kinda gimpy.

Anyway, thanks for helping me to clear it up, I guess I won't be using hardware acceleration since the CPU is doing a better job on this.

[st-fixer]

Hi. Im trying to use LAVSplitter.ax without registration in system, through LoadLibrary(); / GetProcAddress(); functions, but its working only if I put all libraries into the program folder (with exe). If I put it into subfolder (with LAVSplitter.ax), I've got error - file ****.dll not found.
occurs with:
avcodec-lav-54.dll
avfilter-lav-3.dll
avformat-lav-54.dll
avresample-lav-0.dll
avutil-lav-51.dll
libbluray.dll
swscale-lav-2.dll

same situation with LAVAudio.ax and LAVVideo.ax. all dlls should be in folder with program, even if mail files (*.ax) are in subfolder.

Please, fix it.
Sorry my English,
Tnx.

[SamuriHL]

Nothing to fix AFAIK. It works fine with other players who load it dynamically.

[Snowknight26]

Isn't that a security feature of the DLL search order?

http://support.microsoft.com/kb/2264107

[nevcairiel]

Correct there is nothing to fix. You should read the documentation of LoadLibraryEx, it has a flag to control that.

[st-fixer]

Many thanks, problem solved.

[piccirilli]

Same problem here. LAV video decoder will connect, but not the LAV audio. This maybe the reason for the stuttering. Has anyone else had success using these filters to play Sony's AVCHD videos?

I have some trouble playing AVCHD .m2ts from a Sony 1080i cam, i.e. freezing, stuttering or not playing at all.

The same works perfectly with other decoders.

Before uploading huge files, has anybody tested LAV with those kind of files?

Mediainfo report:

General
ID : 0 (0x0)
Complete name : E:\avchd\03-06-2012\20120603090917.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 24.1 MiB
Duration : 11s 935ms
Overall bit rate mode : Variable
Overall bit rate : 16.9 Mbps
Maximum Overall bit rate : 18.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=13
Codec ID : 27
Duration : 11s 880ms
Bit rate mode : Variable
Bit rate : 15.8 Mbps
Maximum bit rate : 16.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.305
Stream size : 22.4 MiB (93%)

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 11s 968ms
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -80ms
Stream size : 655 KiB (3%)

Text
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 11s 375ms
Delay relative to video : -80ms

[Focalom]

Hey

Sorry for asking about something completely different.

I have been setting up my system the last week, but have a problem I can't figure out. I have a 720p plasma screen which accept 1080p24 signals (1080p23). My computer have a core2duo e8500 at stock 3,16ghz and an amd radeon hd 7770 graphic card.

Today i run the latest MPC-HC + the LAV package (splitter, audio and video decoder) and madvr render. I can run every file I throw at it without any frame drops, all the queues in madvr are full. The audio is bitstreaming to the receiver.

To the problem: When playing my bluray movies 1080p24 (rips), and the resolution and framerate in win7 is set to 1080p23 the audio is out of sync. But when I set it to 720p59 the video and audio is in sync. But I guess I must set the framerate to (23.976), and therefore the resolution must be set to 1080p, to get the film run smoothly. I get the same result with both madvr and EVR cust pres.

Any idea how to fix this? I'm sorry if this have been answered many times, but I can't find a solution :-(

[nevcairiel]

Some people asked about Opus decoding, so here it is.

x86: http://files.1f0.de/lavf/LAVFilters-0.51.3-28-gbacb7df.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.51.3-28-gbacb7df-x64.zip

This version uses the libopus reference decoder for decoding of opus audio streams. LAV Splitter can read .opus files and LAV Audio can decode the streams.

Please let me know if it doesn't work as expected. Initial tests seemed to play just fine.

[Sebastiii]

:) nice work :P

[SeeMoreDigital]

Opus audio decoding is working fine for me, with Windows Media Player and Media Player Classic :D

It's just crazy how well Opus sounds at low bit-rates...


Many thank Nev

[Gser]

What about Opus at higher bit rates? Could it be a good alternative for lc-aac?

[SeeMoreDigital]

What about Opus at higher bit rates? Could it be a good alternative for lc-aac?If you start an Opus audio discussion topic within the forums "Audio Encoding" section, anyone who's interested in Opus can talk about it there ;)

[Reino]

With all due respect for Doom9, but for a discussion on Opus I would really suggest Hydrogenaudio's Opus codec thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580).

[Tacio]

I'm a little bit wondering my system behavior. I have notebook equipped by core i5-2410 + NVIDIA GT520M and use mpc-hc, lav filters + pure EVR renderer.
When I use choose Intel QuickSync as a decoder, GPU-Z shows that only HD3000 GPU loaded, but when I choose NVIDIA CUVID both HD3000 GPU and GT520M Video Engine loaded. Same behavior if I choose dxva. Is it normal? Because I believed that in second case only GT520M Video Engine has to be loaded...

[kopija]

Greetings,
I am wondering whether "Normalize matrix" feature works when bitstreaming audio? Or do I have to enable mixing too?

What I am trying to do is basically get rid of sudden jumps in volume for late night viewing.

I use MPC HC, LAV audio and bitstream to my 5.1 receiver.

What would be the correct configuration to achieve this?

Thanks!

[nevcairiel]

LAV Audio has absolutely no influence on the volume if you're bitstreaming. You need to find a similar option on your Receiver for this.

[kopija]

LAV Audio has absolutely no influence on the volume if you're bitstreaming. You need to find a similar option on your Receiver for this.
I found it already, its called "Night mode" and does absolutely nothing.
Could you please instruct me how to setup LAV Audio to prevent sudden increases of volume on the receiver side?

[ryrynz]

Just buy a better receiver.

[balkerman]

Also called Dynamic range compression.

Posted using Android

[iSeries]

Just buy a better receiver.

Hmmm how the other half live.

I believe Reclock has a DRC feature.

[jmonier]

I believe Reclock has a DRC feature.

I don't believe it does but it wouldn't work with bitstreaming anyway. Bitstreaming passes the TrueHD/DTS-HD bitstream through to the receiver without decoding it so any processing of this sort would have to be done after it is decoded in the receiver.

[strumf666]

And we are back to this:
Just buy a better receiver.