View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
nevcairiel
3rd September 2011, 19:24
I currently have no concrete plans to support raw video input, but maybe one day..
Midzuki
3rd September 2011, 19:37
On a side note, LAV Splitter doesn't parse the 'test_audacity.wav' file in this zip (http://stfcc.org/misc/lavfilters_wav_samples.zip).
Q.: Should LAV Splitter start supporting b0rked .WAV files? :rolleyes:
A.: Of course it shouldn't ;)
nevcairiel
3rd September 2011, 19:38
That .wav file actually worked for me. Its only missing some information in the media type, so it requires LAV Audio and doesn't connect directly to the renderer.
Of course, i'm using a development version, maybe something changed in ffmpeg that wasnt in the last release.
STaRGaZeR
4th September 2011, 01:50
nev, MPEG-4 ASP (DivX 5 and Xvid at least) in matroska causes video corruption when seeking. The problem is in the splitter, MPC's and Haali are fine. Is this a known issue or do you need a sample?
Also seeking is quite a bit slower than both of them with matroska in general, if the video has long GOPs. As if LAVS was waiting till the next keyframe or something.
nevcairiel
4th September 2011, 06:59
Somehow those two symptoms don't match. If its waiting for the next key-frame, how can there be corruption? :D
I know that Matroska seeking is a bit slow on oddly muxed files, right now it'll always seek to the nearest Cue point and take it from there, which can take quite some time. Luckily most people mux their MKVs sanely with enough Cue points for smoother seeking.
I do have plans and ideas how to improve that. To avoid corruption, it does have to find a key-frame to start with, though.
Anyhow, i can't seem to find a Xvid in MKV, all i have are in .avi, so a sample which directly shows the corruption would be good.
I'll then look at it when i work on the seeking issues, which should be relatively soon. (After the next release)
betaking
4th September 2011, 07:15
Somehow those two symptoms don't match. If its waiting for the next key-frame, how can there be corruption? :D
I know that Matroska seeking is a bit slow on oddly muxed files, right now it'll always seek to the nearest Cue point and take it from there, which can take quite some time. Luckily most people mux their MKVs sanely with enough Cue points for smoother seeking.
I do have plans and ideas how to improve that. To avoid corruption, it does have to find a key-frame to start with, though.
Anyhow, i can't seem to find a Xvid in MKV, all i have are in .avi, so a sample which directly shows the corruption would be good.
I'll then look at it when i work on the seeking issues, which should be relatively soon. (After the next release)
I have one files about Xvid in MKV!but is very big!:rolleyes:
and lavfilters can not use lavvideo to decoder this mpeg file!
Format : MPEG-PS
File size : 63.1 MiB
Duration : 4mn 13s
Overall bit rate : 2 086 Kbps
Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 1
Format settings, BVOP : Yes
Format settings, Matrix : Default
Duration : 4mn 13s
Bit rate : 1 789 Kbps
Maximum bit rate : 1 800 Kbps
Width : 352 pixels
Height : 240 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.706
Stream size : 54.1 MiB (86%)
Audio
ID : 192 (0xC0)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Duration : 4mn 13s
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -67ms
Stream size : 7.74 MiB (12%)
nevcairiel
4th September 2011, 07:39
Media Info is really not helpful. Either post the media type (maybe its as simple as that), or a sample of the file.
betaking
4th September 2011, 07:55
Media Info is really not helpful. Either post the media type (maybe its as simple as that), or a sample of the file.
OK! sample download here!
http://hotfile.com/dl/128806918/a301be7/THEME_PK.mpg.html
Carpo
4th September 2011, 08:15
I know that Matroska seeking is a bit slow on oddly muxed files, right now it'll always seek to the nearest Cue point and take it from there, which can take quite some time. Luckily most people mux their MKVs sanely with enough Cue points for smoother seeking.
In mkvmerge you have the options for cue points as, default, only for I frames, for all frames, and none - which would you suggest people use? Normally I just leave it on default
nevcairiel
4th September 2011, 09:19
I dunno what default does, but i guess it might be fine. Its mostly pretty old files or files not muxed with mkvmerge that have those issues.
It also depends on your encode how big GOPs are / how often a key frame is inserted.
Less key-frames may give you slightly smaller files, but of course without key-frames you cannot seek.
nevcairiel
4th September 2011, 09:21
OK! sample download here!
http://hotfile.com/dl/128806918/a301be7/THEME_PK.mpg.html
That file plays just fine with LAV Video, with both LAV Splitter and the MPC-HC MPEG Splitter.
Maybe something that was fixed in the latest version, try again with the next release.
VipZ
4th September 2011, 10:51
Nev, do you have any plans to do a status page for LAV Video showing input format and colour conversions etc in use?
betaking
4th September 2011, 11:19
That file plays just fine with LAV Video, with both LAV Splitter and the MPC-HC MPEG Splitter.
Maybe something that was fixed in the latest version, try again with the next release.
i Enabled mpeg1 decoder on lavvideo,but mpc-hc still use MPEG VIDEO DECODER by System embedded!:confused:
BloodySword
4th September 2011, 13:15
Only I-Frames is good because some dumb splitters or decoders may cause the named "corruption".
I try to not use mkv at all, because I don't like its design.
kerimcem
4th September 2011, 13:19
mkv and flv thumbnails not open show :( added lav codec ?
great codec thanks..
STaRGaZeR
4th September 2011, 14:37
Somehow those two symptoms don't match. If its waiting for the next key-frame, how can there be corruption? :D
I know that Matroska seeking is a bit slow on oddly muxed files, right now it'll always seek to the nearest Cue point and take it from there, which can take quite some time. Luckily most people mux their MKVs sanely with enough Cue points for smoother seeking.
I do have plans and ideas how to improve that. To avoid corruption, it does have to find a key-frame to start with, though.
Anyhow, i can't seem to find a Xvid in MKV, all i have are in .avi, so a sample which directly shows the corruption would be good.
I'll then look at it when i work on the seeking issues, which should be relatively soon. (After the next release)
With ASP, you have corruption and fast seeking.
With everything else (that's why I said in general, but it's H.264 mainly), you have no corruption and slow seeking if the GOPs are long. Maybe it's always slow, but only noticeable with long GOPs, I can't know that. x264 with most presets will produce files with up to 250 frames between keyframes. That's more than 10 seconds of 23.976 video, so go figure.
It should be possible to do it better, since other splitters provide both faster seeking and no corruption.
ASP in MKV sample here: http://www.mediafire.com/?2rwv3ua3138sz78
nevcairiel
4th September 2011, 14:41
With a fast software decoder (and a fast CPU), 250 frames shouldn't be a big issue. On my system, decoding 250 frames takes about 1 second, and thats the worst case, but i do see longer seeking delays on some files, so i know that something else is going wrong, and i already have some ideas what, and i do plan to look into that soon.
With a hardware decoder, those 250 frames can take a few seconds to decode though (they typically top out around 70-80 fps on 1080p), so a higher delay is certainly possible.
Thanks for the sample, the problem is easily reproducible, that should make fixing much easier.
Stephen R. Savage
4th September 2011, 16:03
nevcairiel: Is there a reason LAV Video won't connect to DVDs? It doesn't seem to be related to CSS, as I can't get it to load for decrypted discs either.
nevcairiel
4th September 2011, 16:11
nevcairiel: Is there a reason LAV Video won't connect to DVDs? It doesn't seem to be related to CSS, as I can't get it to load for decrypted discs either.
Supporting DVDs requires some special magic in the video decoder, which i just didn't put any priority on.
SamuriHL
4th September 2011, 16:24
Supporting DVDs requires some special magic in the video decoder, which i just didn't put any priority on.
If it was supported does that mean we could render it with madVR?
nevcairiel
4th September 2011, 16:55
If it was supported does that mean we could render it with madVR?
no idea, probably not.
STaRGaZeR
4th September 2011, 20:45
With a fast software decoder (and a fast CPU), 250 frames shouldn't be a big issue. On my system, decoding 250 frames takes about 1 second, and thats the worst case, but i do see longer seeking delays on some files, so i know that something else is going wrong, and i already have some ideas what, and i do plan to look into that soon.
With a hardware decoder, those 250 frames can take a few seconds to decode though (they typically top out around 70-80 fps on 1080p), so a higher delay is certainly possible.
Thanks for the sample, the problem is easily reproducible, that should make fixing much easier.
The problem is that it doesn't seem to be playback speed related. For example, imagine a file with keyframes at frames 1000 and 1250. Before the seek I was in frame 500. If I seek to frame 1100, it seeks instantly to frame 1100 and audio plays from there. But the screen freezes with frame 500 until, at normal playback speed, frame 1250 is reached. Then video is resumed. This can perfectly be 5+ seconds of screen freeze while audio is playing in the back. With other splitters you can clearly see that previous frames are decoded very fast until you reach frame 1100 as you say, or that they seek instantly to it, with LAVS it seems that it just waits until the keyframe is reached, then resumes playback. Pure speculation right here, but that is what it looks like.
nevcairiel
4th September 2011, 20:49
LAV Filters 0.34
LAV Splitter
- Improve playback of VC-1 in EVO
- Support for SSA subtitles in AVI
- Support for H264 in VFW mode in MKV
LAV Video
- New optimized pixel format converters (faster and more accurate)
- New YUV->RGB converter
- Support for PNG video
Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.34.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.34.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.34-x64.zip)
I finished implementing the YUV -> RGB converter and all important YUV -> YUV converters. There are quite some significant speed ups in this version, especially if you're dealing with dithering (10bit content, 8bit output).
RGB
The new RGB converter is also working nicely, using bilinear interpolation and high-precision RGB conversion.
It supports the BT.601, BT.709 and SMPTE 240M transfer matrices, and properly handles both TV and PC range input and output. I did not add options to configure the input format (levels/matrix), because i do hope that files are properly encoded. I wouldn't want to switch that setting around on every file i play, now would i.
Quality
In theory, its mathematically slightly more accurate then ffdshows HQ RGB option. In reality, i couldn't detect any difference between the two. Note that LAV Video uses the proper chroma siting for H264/MPEG2, while ffdshow seems to assume the "old" chroma siting used by MPEG1/H263. This is a very minor difference, and like i said, i didn't see the difference.
Performance
The converter itself is really fast, and in addition its also multi-threaded. I did get performance numbers slightly above ffdshows values out of it, and any modern system should be able to use it fluidly.
Features
In addition to all the "usual" features, it supports native 9/10-bit input, without any notable degredation. It can output TV or PC range, or an untouched range (as the YUV was). I decided to set the default to PC range, because thats how most other filters and renderers work. It'll also let the renderer know which range is used, however only madVR understands this hint as of now.
Now, why would you use RGB instead of native YUV output?
The thing is that alot of renderes by default have a pretty bad chroma upsampling. I'm talking about EVR/VMR here, the "trusted" default renderes on every Windows system. They usually rely on the GPU to actually convert the YUV to RGB, and the quality of that process leaves alot to be desired. So with EVR/VMR, it can give you a quality boost if you actually use RGB. With a modern renderer like madVR, its usually not recommended to use RGB, unless you have a post-processing filter that requires it.
Note that converting interlaced YUV to RGB will stop the deinterlacing process from working!
Anyhow, i hope everything works fine, and i can focus on other things again. All these converters was a nice exercise in assembler/intrinsics, but at some point, you just have enough of those. :)
nevcairiel
4th September 2011, 20:56
The problem is that it doesn't seem to be playback speed related. For example, imagine a file with keyframes at frames 1000 and 1250. Before the seek I was in frame 500. If I seek to frame 1100, it seeks instantly to frame 1100 and audio plays from there. But the screen freezes with frame 500 until, at normal playback speed, frame 1250 is reached. Then video is resumed. This can perfectly be 5+ seconds of screen freeze while audio is playing in the back. With other splitters you can clearly see that previous frames are decoded very fast until you reach frame 1100 as you say, or that they seek instantly to it, with LAVS it seems that it just waits until the keyframe is reached, then resumes playback. Pure speculation right here, but that is what it looks like.
Yeah i've seen that symptom, not 100% sure why its happening, but i have some ideas how to check whats really going on.
I'll focus on that over the next weeks, its been too long on my list.
fastplayer
4th September 2011, 21:19
I'm not sure if this is 100% LAV-related but it brings MPC-HC down to its knees whereas its internal filters work fine.
Here are the steps to reproduce:
1. http://download.microsoft.com/download/e/a/d/eadb9b42-728b-42b0-bfdf-b472fa2a2464/Step_into_Liquid_1080.exe
2. Make sure "Rewind when done playing" is disabled in MPC-HC.
3. Start playback, seek to the near end of the video, wait until playback stops.
4. Now start playback by clicking on the video or pressing Space key.
5. Result: With MPC's internal filters/splitters, playback restarts as expected. Using LAVFilters, MPC-HC freezes 2 out of 3 times.
My setup: madVR 0.74 (windowed mode), LAV 0.33 (default settings), MPC-HC 3694.
Can anyone else reproduce this?
Edit: I narrowed it down to LAVVideo. If it's disabled, restarts are OK.
Just wanted to confirm that this issue is fixed in 0.34.
:thanks:
fairchild
4th September 2011, 22:25
Thanks for the update Nev! I have a quick question which I tried searching for in this thread but didn't find anything on it. Regarding the setting "Use High-Quality Format Conversions", under what scenarios would enabling this option which is disabled by default benefit me?
I'm guessing this setting is more for a scenario where I run solely LAV Video decoder > EVR. As I'm running ffdshow raw video filter to get YADIF deinterlacing + MadVR, then this setting wouldn't do anything for me correct?
Thanks again for an awesome set of filters! :)
STaRGaZeR
4th September 2011, 22:27
Yeah i've seen that symptom, not 100% sure why its happening, but i have some ideas how to check whats really going on.
I'll focus on that over the next weeks, its been too long on my list.
To make things worse, sometimes when it freezes it doesn't recover, a player restart is required. Hope you can nail it down.
BTW, congrats on the new converters, massive work right there. Everything seems to be working just fine, and the YUV->RGB one is even faster than ffdshow's!
pirlouy
5th September 2011, 00:20
@ pirlouy, this is what works over here:
1) dis-able "uncompressed" in the audio decoder
2) en-able "uncompressed" in the audio processor
3) with Graphstudio, or RadLight Filter Manager, set the merit of the audio processor to 0x00800000 or greater
4) reboot, or logoff and logon
5) enjoy :)
Thanks for the help.
Thanks to another computer, I've found the problem: when I double click on "ffdshow audio processor" in MPC external filters, the options window does NOT open...
I've tried to rename the registry for ffdshow, without success. I'll do tests soon in order to fix this...
nevcairiel
5th September 2011, 05:52
Thanks for the update Nev! I have a quick question which I tried searching for in this thread but didn't find anything on it. Regarding the setting "Use High-Quality Format Conversions", under what scenarios would enabling this option which is disabled by default benefit me?
That option really isn't all that useful anymore.
It controls swscale and its scalers, switching them into high-quality mode. But swscale is only used if no hand-optimized converter is found.
So it'll only be used for very rare combinations of formats, which i didn't optimize manually. All of the new converters always use the highest quality, because they are fast as it is. :)
In conclusion, i really cannot say when it'll be beneficial. I might even remove it again, and turn it on by default. It really only was for RGB conversion before, but i wrote my own now ..
Master_T
5th September 2011, 10:06
Both PotPlayer and MPC-HC had been giving me some annoying audio crackling with FFmpeg filters and HD videos on my laptop, I guess because it's not very powerful and it couldn't "keep up", but I switched to LAV filters today and both audio and video are smooth as silk! So, this post is just to thank you for your work, these filters are awesome, and so are the developers... keep it up!
Thunderbolt8
5th September 2011, 10:38
when selecting certain .mpls or .m2ts files in explorer (mostly not the main movie files/playlist, but others as it seems), theres sometimes a long time of wait and cpu load, before I can do anything else. why is that? (got LAV splitter, mediainfo, haali installed)
has it to do with the general readability of the playlist/file, in regards of which audio/video tracks it includes? or maybe with the number of .m2ts files a playlist includes?
blaster00
5th September 2011, 13:56
How to set audio to stereo in LAV audio decoder?
And a render problem with mpc-hc http://forum.doom9.org/showthread.php?p=1523830#post1523830
Superb
5th September 2011, 14:14
How to set audio to stereo in LAV audio decoder?LAV Audio has no mixing capabilities yet.
You can use the Windows mixer or ffdshow (in raw mode) to mix the channels.
And a render problem with mpc-hc http://forum.doom9.org/showthread.php?p=1523830#post1523830Looks like a MPC-HC subtitles rendering bug. Has nothing to do w/ LAV Filters.
CruNcher
5th September 2011, 16:07
@nev
you should keep an eye on this http://forum.doom9.org/showthread.php?p=1523826
it currently crashes a lot with *.ts files it gets via Lav Splitter unfortunately :( (funny is all of those crashy ones work with MPC-HC Internal Splitter though some of them have no audio in the end like the Portuguese Latm samples that also crash it, those with the wrong Audio track ids)
nevcairiel
5th September 2011, 16:08
Its based on ffdshow, i don't expect it to do anything BUT crash. :p
BloodySword
5th September 2011, 17:42
Its based on ffdshow, i don't expect it to do anything BUT crash. :p
He said, that when used with MPC-HC splitters it works.
But that must not be a mistake in you splitter.
Just like the thing with AAC. FFDShow expects init data.
Plutotype
5th September 2011, 18:26
Hi nev,
Have a question to the RGB converter output settings. In which typical scenarios you generally recommend to use 16-235 / 0-255 / untouched?
Thanks
nevcairiel
5th September 2011, 18:51
Hi nev,
Have a question to the RGB converter output settings. In which typical scenarios you generally recommend to use 16-235 / 0-255 / untouched?
Thanks
If you use EVR, you either want 16-235 or 0-255, depends on which level your screen expects. PCs are generally always 0-255, TVs are 16-235, but some TV models also take 0-255. If you don't know, get some black level calibration pattern and test the two modes. Changes should be immediate.
For madVR, you should not use RGB at all, just leave all YUV modes checked, and it should not matter.
If for some arcane reason you do want RGB with madVR, untouched is probably best.
CruNcher
5th September 2011, 18:55
@nev
sorry i was to optimistic there is a major drawback with ffdshow-quicksync it seems to be a direct native Intel API implementation like Nvcuvid not DXVA2 and the overhead is too huuuuuge for a small HD2000 and imho even questionable for general playback purposes @ all :D
http://forum.doom9.org/showthread.php?p=1523906#post1523906
ikarad
5th September 2011, 19:12
LAV Filters 0.34
LAV Splitter
- Improve playback of VC-1 in EVO
- Support for SSA subtitles in AVI
- Support for H264 in VFW mode in MKV
LAV Video
- New optimized pixel format converters (faster and more accurate)
- New YUV->RGB converter
- Support for PNG video
Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.34.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.34.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.34-x64.zip)
Will you include a sub renderer in a next version?
SamuriHL
5th September 2011, 20:11
Will you include a sub renderer in a next version?
LOL. :) That seems unlikely. That's not a small piece of work.
ikarad
5th September 2011, 21:26
LOL. :) That seems unlikely. That's not a small piece of work.
Stephen said that lav filters will replace ffdshow
AssRender.dll is an Avisynth plugin. You can't register it or use it in DirectShow, or anything like that.
As for ffdshow needing a new subtitle renderer, there's nothing stopping you from using the MPC-HC one or DirectVobSub. ffdshow development has halted and it is already planned to be replaced by LAVFilters anyway, so there's no sense in petitioning for feature changes.
http://forum.doom9.org/showpost.php?p=1523723&postcount=13955
SamuriHL
5th September 2011, 21:28
Yea, I read that. I'm not sure I know what that means. LAV Filters have nothing at all to do with ffdshow. If someone wants to work on ffdshow, they can. LAV Filters is its own project.
nevcairiel
5th September 2011, 21:32
I said it before, and i'll say it again - its not the video decoders job to render subtitles. Its a video decoder, not a subtitle renderer.
Besides, you'll get horrible looking subs if you render them on a YUV 4:2:0 frame
mandarinka
5th September 2011, 21:42
Given that there is now a HQ RGB converter (and it accepts 10bit, no less), would it be feasible (as in, not too much work) to add a barebone grab function that would be using this converter?
What I have in mind is something that would dump bmp image of current frame to a predefined directory (or uncompressed png in case that writing a png-structure file is easier than writing a bmp). It would do that either on demand (as ffdshow does when one hits ctrl-alt-g) or for each decoded frame (like when you just enable the grab filter in ffdshow). FFdshow uses the frame's number as a filename for the grabbed image, which is rather useful idea imho.
Luckily, you can already get this to work with ffdshow if you load it after lavvideo with forced rgb output. With this functionality inside lavvideo, it would however allow you to grab images even when passing untouched yuv to madvr, for example. (FFdshow's grab also has some glitches with non-mod4 width video, which is a different thing.)
While it's probably true that (ideally) screenshot-taking should be a responsibility of individual video player programs, there is the same issue as with video renderers, only worse. Many players fail to respect colormatrix of video while converting the screenshot to rgb and what's worse, virtually every player uses lousy chroma upsampling, too. Players I tried use what looked like point-scaling with much worse quality than what a basic gpu's overlay renderer produces... FFdshow's grab was one of the few ways to get around those issues (as it could apply the HQ conversion to the capped images, even when ffdshow itself was outputting yuv).
Here ends a shameless feature suggestion, thanks for reading!
somy
6th September 2011, 13:27
Hi,
Since the YUC/RGB converters are much more optimized in the new version, I'd like to ask whether LAV video decoder is good enough to replace FFDShow?
Thanks!
Com DAC
6th September 2011, 19:34
Thank you for the answer and it makes perfect sense. With this answer I have tried taking the mkv and stripping out the stereo stream and just leaving the 5.1 stream but after doing that I get absolutely no audio with LAV. Could it be because it doesn't start till part way into the file?
On that note does anyone know of a good tool to splice out part of an mkv file without having to re-compress it?
Thank you
SeeMoreDigital
6th September 2011, 20:44
I have a newbie question.
Is it possible to configure the LAV filters to open up video files in VirtualDub?
Midzuki
6th September 2011, 20:52
Is it possible to configure the LAV filters to open up video files in VirtualDub?
Not possible (¿yet?).
mzso
6th September 2011, 20:57
I have a newbie question.
Is it possible to configure the LAV filters to open up video files in VirtualDub?
Ummm. How is that relevant to a splitter or decoder? Just associate the desired filetypes with virtualdub in windows.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.