View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
zerowalker
17th November 2011, 02:35
Lagarith Playback doesnīt work properly, there is black screen and a big delay, then audio will start but it stays black.
ruinevil
17th November 2011, 04:45
Lagarith Playback doesnīt work properly, there is black screen and a big delay, then audio will start but it stays black.
http://samples.mplayerhq.hu/V-codecs/lagarith/
File takes a second to load, and then goes to end.
Lagarith is a bad lossless codec though. ffmpeg probably doesn't implement it correctly.
edit: http://forum.doom9.org/showthread.php?t=86148&page=7 , I guess it does, sorta.
nevcairiel
17th November 2011, 07:51
Because otherwise it seems kind of useless to include VC-1 decoding at all, since it messes up the filter preferences.
Thats why VC-1 decoding is off by default.
Lagarith Playback doesnīt work properly, there is black screen and a big delay, then audio will start but it stays black.
Thats why Lagarith is also off by default.
There have been a few patches for Lagarith the last week or so, which are not yet in LAV Video, and might improve the situation.
However, the speed issue remains, its right now neither SIMD'ed nor multi-threaded. (As i understand, its a intra-only codec, so multi-threading should work pretty easily?)
zerowalker
17th November 2011, 11:04
Thats why VC-1 decoding is off by default.
Thats why Lagarith is also off by default.
There have been a few patches for Lagarith the last week or so, which are not yet in LAV Video, and might improve the situation.
However, the speed issue remains, its right now neither SIMD'ed nor multi-threaded. (As i understand, its a intra-only codec, so multi-threading should work pretty easily?)
Okay, well letīs hope for the best than;D!
CruNcher
17th November 2011, 16:34
Hmm where are the problems with Lagarith i have some recordings from the last version and they so far all work decoding is not as performant as the vfw decoder but @ least watchable, maybe it's more a problem with older streams ?
El Topo
17th November 2011, 17:12
Hi Nev,
first: thanks for your work!
Any progress on supporting Intel Graphics HW Acceleration?
nevcairiel
17th November 2011, 17:15
Any progress on supporting Intel Graphics HW Acceleration?
That feature has been moved further into the future, alot of other things to do - and honestly, such Intel CPUs that support full hardware decoding are fast enough to decode anything you throw at it anyway - without even breaking a sweat.
iSeries
17th November 2011, 17:28
Hi,
I posted this issue in the MadVR thread however Madshi concluded that this is not a MadVR issue but possibly a splitter issue.
The problem I'm having is playback of blu ray via the index.bdmv or the mpls file. Playback is very choppy, with MadVR reporting 100's of dropped frames within minutes. Madshi has concluded that it's a timestamp issue, and that MadVR is receving frames with duplicate timestamps.
The odd thing is though, if I play the m2ts file directly then playback is perfectly smooth.
Would be grateful if someone can help pinpoint where the problem might be?
EDIT: I just tried playback using MPC-HC's internal splitter and playback of index.bdmv and mpls files is absolutely fine, using LAV splitter and I get the issue above.
nevcairiel
17th November 2011, 18:08
Here is a test build, with fresh ffmpeg:
http://files.1f0.de/lavf/LAVFilters-0.39-37-g56a1605.zip
Nothing noteworthy in there, just to make sure no regressions appeared - and one build before i start working on stuff that won't be ready for a while.
nevcairiel
17th November 2011, 18:13
The problem I'm having is playback of blu ray via the index.bdmv or the mpls file. Playback is very choppy, with MadVR reporting 100's of dropped frames within minutes. Madshi has concluded that it's a timestamp issue, and that MadVR is receving frames with duplicate timestamps.
The odd thing is though, if I play the m2ts file directly then playback is perfectly smooth.
Is that from the disc, or a rip? Possibly remuxed?
Maybe your remuxing tool did a poor job? :)
I've only ever played BD discs, and i really have no huge interest in testing all BD ripping software out there.
In any case, try with this version:
http://files.1f0.de/lavf/LAVFilters-0.39-37-g56a1605-debug.zip
Its a special debug version that should leave log files on your desktop. Note that it empties the log everytime its run again, so play it once and save the log somewhere.
Both LAV Splitter and LAV Video logs could be of interest. (If you're not using LAV Video, please try for the sake of getting a log)
iSeries
17th November 2011, 18:18
Hi,
Thanks - I just tried to register the splitter from the debug build and I got an error saying "The module "LAVSplitter.ax failed to load"?
I had used EasyBD to mux them - I've emailed their support about it but they are adamant that it is not an EasyBD issue. Indeed, all muxes made with EasyBD have played in my three standalone players perfectly.
nevcairiel
17th November 2011, 18:23
Thanks - I just tried to register the splitter from the debug build and I got an error saying "The module "LAVSplitter.ax failed to load"?
Ah, my bad, use this instead:
http://files.1f0.de/lavf/LAVFilters-0.39-37-g56a1605-debug2.zip
iSeries
17th November 2011, 18:33
Thanks Nev, here are the logs:
http://www.mediafire.com/?aue6muh3dba97t3
http://www.mediafire.com/?yssyx1p2ckvzkvb
nevcairiel
17th November 2011, 18:54
Thanks Nev, here are the logs:
In the LAV Splitter options, uncheck "Try to fix broken HD-PVR recordings" and see if that then breaks the m2ts playback?
That seems to be the only big difference between m2ts playback or Blu-ray playback.
VipZ
17th November 2011, 20:21
Nev, I read that you are looking to support DVD decoding and possibly putting the subs directly on the image. Hope this is part of the work you talking about that's wont be available for awhile :)
I assume LAV Video would need to deinterlace the video 1st for this, or not needed?
nevcairiel
17th November 2011, 20:22
I assume LAV Video would need to deinterlace the video 1st for this, or not needed?
Actually, i'm not sure. Since the subtitles don't move, i think it might be OK'ish.
For the future, i'm exploring ideas to send them to the renderer for painting onto the image after all its processing.
VipZ
17th November 2011, 20:29
Actually, i'm not sure. Since the subtitles don't move, i think it might be OK'ish.
For the future, i'm exploring ideas to send them to the renderer for painting onto the image after all its processing.
Yep, when I 1st thought about it I assumed it would be required, but as you say, they don't move so it may work. Also would doing such a thing mess the interlaced flags on the video stream?
I do prefer the rendering of subs to the renderer myself.
joe42
17th November 2011, 21:17
Without looking at the file, i guess its interlaced, and thus not supported.
Edit:
After looking at the file, i'm sure its interlaced.
Use the MS decoder. ;)
I found that madVR's video decoder works well if you include the Intel decoder DLL. It seems that madVR is smart enough to use the libav decoder for non-interlaced VC-1, and to automatically use the Intel decoder for interlaced VC-1.
I guess that is an advantage to the way madVR integrates its decoder? Or is it possible for LAV video decoder to do something similar?
nevcairiel
17th November 2011, 21:18
I found that madVR's video decoder works well if you include the Intel decoder DLL. It seems that madVR is smart enough to use the libav decoder for non-interlaced VC-1, and to automatically use the Intel decoder for interlaced VC-1.
I guess that is an advantage to the way madVR integrates its decoder? Or is it possible for LAV video decoder to do something similar?
I don't understand why you don't just simply use the Microsoft decoder? Its faster and decodes every VC-1 stream available.
jmonier
17th November 2011, 21:29
I don't understand why you don't just simply use the Microsoft decoder? Its faster and decodes every VC-1 stream available.
My experience with the Microsoft decoder is that it uses a lot more CPU time for VC-1 interlaced than non-interlaced. Since it's apparently not multi-threaded, that means that one processor can get close to the practical limit.
One VC-1 interlaced file that I have won't run smoothly on anything less than than an i7-960 using the Microsoft decoder.
nevcairiel
17th November 2011, 21:32
My experience with the Microsoft decoder is that it uses a lot more CPU time for VC-1 interlaced than non-interlaced. Since it's apparently not multi-threaded, that means that one processor can get close to the practical limit.
One VC-1 interlaced file that I have won't run smoothly on anything less than than an i7-960 using the Microsoft decoder.
The libav or Intel decoders aren't any better.
libav is not multi-threaded, and of course fails on interlaced completely. The Intel decoder seems generally to be pretty slow.
iSeries
17th November 2011, 21:45
In the LAV Splitter options, uncheck "Try to fix broken HD-PVR recordings" and see if that then breaks the m2ts playback?
That seems to be the only big difference between m2ts playback or Blu-ray playback.
Hi Nev,
I'm out at the moment but will do as soon as I'm home. So if I uncheck that and m2ts playback then also becomes bad does that mean a muxing issue?
nevcairiel
17th November 2011, 21:46
So if I uncheck that and m2ts playback then also becomes bad does that mean a muxing issue?
Yes, but it also means i can fix it.
It would probably help if you can cut a small sample off the m2ts and upload it to mediafire or similar (~20mb would be good). Use something like DGSplit, not a special mpegts splitter.
iSeries
17th November 2011, 21:51
Yes, but it also means i can fix it.
Hmmm the EasyBD guys were adamant to the point of dismissive that this is not an EasyBD muxing issue. Although if it was wouldn't playback also be choppy in a standalone player?
Glad that you can fix it though - although a bit annoyed that the software that I've paid for is at fault. Looks like I'll be going back to tsMuxer ;)
Will certainly provide a small sample for you.
joe42
17th November 2011, 21:54
I don't understand why you don't just simply use the Microsoft decoder? Its faster and decodes every VC-1 stream available.
I guess I like to minimize the number of external filters in my list. I don't have a good reason I can explain for my preference. But madVR appears to do what I wanted, so why do you think I should use the Microsoft decoder? Is it better than madVR's combo of libav for VC-1(p) and Intel for VC-1(i)?
And just to verify, by "Microsoft decoder", do you mean "WMVideo Decoder DMO"?
nevcairiel
17th November 2011, 21:55
I guess I like to minimize the number of external filters in my list. I don't have a good reason I can explain for my preference. But madVR appears to do what I wanted, so why do you think I should use the Microsoft decoder? Is it better than madVR's combo of libav for VC-1(p) and Intel for VC-1(i)?
And just to verify, by "Microsoft decoder", do you mean "WMVideo Decoder DMO"?
Thats the right filter, and yes, the MS decoder is better then those two.
nevcairiel
17th November 2011, 21:57
Will certainly provide a small sample for you.
Cut the sample off the start of the file, and if you can, also upload the Blu-ray metadata with it, the two bdmv files, the playlists and clipinfo files, so that i can directly see the difference.
iSeries
17th November 2011, 22:04
Cut the sample off the start of the file, and if you can, also upload the Blu-ray metadata with it, the two bdmv files, the playlists and clipinfo files, so that i can directly see the difference.
Ok no problem with the bdmv files etc, although how do I provide the metadata?
Thanks again!
nevcairiel
17th November 2011, 22:06
Ok no problem - how do I provide the metadata?
Thanks again.
Just zip up following files/directorys:
BDMV\index.bdmv
BDMV\MovieObject.bdmv
BDMV\PLAYLIST
BDMV\CLIPINF
Add to that some 20mb of sample from the m2ts, and it should be good.
Matching_Mole
17th November 2011, 22:16
Thats the right filter, and yes, the MS decoder is better then those two.
For VC-1 encoded blu-ray I use Arcsoft one because it is multithreaded and works perfectly on interlaced VC-1 file, so it is far better than these ones. Its (big) issue is it do not recognize other aspect ratio that the blu-ray one. But personally I don't care because I don't have other VC-1 file that the Blu-ray ones and so I'm happy with it.
I know that "reverse engineering" to use ASVC1Vid.dll is far too big but use it in LAV Video Filter as LAV Audio Filter do with dtsdecoderdll.dll would be the better situation possible... We can just hope that someday libav VC-1 decoder will be "finished".
jmonier
17th November 2011, 23:04
The libav or Intel decoders aren't any better.
libav is not multi-threaded, and of course fails on interlaced completely. The Intel decoder seems generally to be pretty slow.
The same file (that I mentioned earlier) shows balanced usage across four processors with the Intel decoder. The Microsoft decoder has considerably higher usage on one processor than the Intel thus the Intel allows the use of a considerably slower CPU than the Microsoft. So, at least for the worst case, the Intel is effectively considerably faster.
nevcairiel
17th November 2011, 23:11
You cannot really trust Windows per-core display, due to its scheduling the load will show up spread over cores rather randomly - even if you use one thread at 100%, it won't just fill up one core in task manager or any other tools for that matter.
The only thing you can really trust is the total CPU usage. When benchmarking the WMVideo decoder, i at least get around 25% usage on my 8 logical cores, so it does seem to use at least 2 cores for something.
Too bad you cannot benchmark madVR that way.
In reality, i just use my NVIDIA card to decode VC-1 anyway. :)
jmonier
18th November 2011, 01:18
You cannot really trust Windows per-core display, due to its scheduling the load will show up spread over cores rather randomly - even if you use one thread at 100%, it won't just fill up one core in task manager or any other tools for that matter.
Can you point me to a source that discusses this? My experience is the opposite. With the WMVideo decoder I can pretty well predict when I'm going to get problems by looking at the one core that shows more usage than the others. If it gets up to 70-80% I will see problems somewhere during the playing of the file. And when this happens, the total CPU usage is 25% or less on a cpu without hyperthreading and half that on one with hyperthreading.
It's very dependent on content. If I'm marginal, then the problems will show up only at a few places in the file, but it will be the same places every time.
So, based on experience that goes back several years on a number of different computers, I stand by my statement that the Intel decoder is better than Microsoft, at least with worst case material.
In reality, i just use my NVIDIA card to decode VC-1 anyway. :)
I agree that that would be the best as long as the "silent stream" bug is not a problem. As we've discussed before, it's unacceptable for me.
nevcairiel
18th November 2011, 07:51
Can you point me to a source that discusses this?
I'm sorry, but my brain is not wikipedia, its not archived with citations and source links for every piece of information.
My comment also only applies to Win7. Its pretty easy to test - wip up some tool that just runs an infinite loop. Its not multi-threaded, yet the task manager will show multiple cores with load instead of one being maxed out.
iSeries
18th November 2011, 09:28
Just zip up following files/directorys:
BDMV\index.bdmv
BDMV\MovieObject.bdmv
BDMV\PLAYLIST
BDMV\CLIPINF
Add to that some 20mb of sample from the m2ts, and it should be good.
Good morning Nev,
The sample you requested is here: http://www.mediafire.com/?8s14nh0pq1o1m92
And you were right, unticking "Try to fix broken HD-PVR recordings" does break m2ts playback and is as glitchy as playing the index.bdmv. I should add though that every mux with EasyBD has so far played perfectly in my standalones, and also the m2ts files have been played perfectly by my WDTV.
Many thanks again for your help!
nevcairiel
18th November 2011, 09:33
Good morning Nev,
The sample you requested is here: http://www.mediafire.com/?8s14nh0pq1o1m92
And you were right, unticking "Try to fix broken HD-PVR recordings" does break m2ts playback and is as glitchy as playing the index.bdmv. I should add though that every mux with EasyBD has so far played perfectly in my standalones, and also the m2ts files have been played perfectly by my WDTV.
Many thanks again for your help!
Thanks for that. The good news is, the problem is what i thought it was and i can fix it. The bad news is - if that problem did not occur on the original disc before the ripping, your ripping software did mess it up.
I guess its not too much to worry about, not many things actually try to use the information they messed up, since its not really required.
Check back with the next version, should be released on the weekend sometime, i think.
iSeries
18th November 2011, 09:48
Ok great - could you let me know exactly what / where the issues with the mux are so I can go to the developers of EasyBD with this information please? As so far they have dismissed me by saying it definitely isn't an issue with their software.
I have remuxed an EasyBD-muxed movie with tsMuxer, and guess what? Plays perfectly. I guess the saying 'you get what you pay for' isn't true at all sometimes!
Will remuxing the movies I have already muxed with EasyBD with tsMuxer solve these issues for me?
nevcairiel
18th November 2011, 10:22
Ok great - could you let me know exactly what / where the issues with the mux are so I can go to the developers of EasyBD with this information please?
It would appear the H264 sei_cpb_removal_delay & sei_dpb_output_delay no longer match the timestamps, causing ffmpeg to order the timestamps wrong. It may as well be a bug in ffmpeg for all i know - the other files that option was supposed to fix were broken far more obviously.
golagoda
18th November 2011, 10:25
I'm sorry, but my brain is not wikipedia, its not archived with citations and source links for every piece of information.
My comment also only applies to Win7. Its pretty easy to test - wip up some tool that just runs an infinite loop. Its not multi-threaded, yet the task manager will show multiple cores with load instead of one being maxed out.
If anyone wants to try this out just plug in something like
#include <iostream>
int main ()
{
loop:
int a = 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 * 99999999999999999999999999999999999999999999999999999999999999999999999999999999999;
goto loop;
}
into your favourite C++ compiler and see if it maxes out your CPU, if not just increase numbers to test it, here on this linux machine it only gets done on one core so I guess Microsoft managed to do something properly if it works as it says it will.
nevcairiel
18th November 2011, 10:37
Those numbers will already overflow the integer you're using. Anyway, its a endless loop and should max out one core 100%, however on Windows it won't show up as that - on a quadcore it will show 25% CPU usage, but the task manager won't show one core at 100%.
Edit:
http://images.gammatester.com/pics/ad5a21d0c447efda54a2185b996ed4e1.png
Thats running a endless loop once. If i run it 4 times, all cores are maxxed out properly.
While the first core shows more usage then the others, its not even close to 100%
I tried to dig up some documentation on the windows scheduler, but its really not all that publicly documented.
fastplayer
18th November 2011, 11:14
I tried to dig up some documentation on the windows scheduler, but its really not all that publicly documented.
Knock yourself out: http://download.sysinternals.com/Files/WindowsInternals-Ch05.pdf
Relevant chapters: Multiprocessor Systems, Multiprocessor Thread-Scheduling Algorithms (pages 434-444)
El Topo
18th November 2011, 13:30
That feature has been moved further into the future, alot of other things to do - and honestly, such Intel CPUs that support full hardware decoding are fast enough to decode anything you throw at it anyway - without even breaking a sweat.
At least not true for my up-to-date Sandy Bridge Celeron G530 (supports full hardware decoding). Here is what I get while trying to play a 1080p24 mkv file, using lav video + lav audio decoders:
http://s3.kkloud.com/gett/static/scaled/9hK1V7A-0.dkghyykgduslwhfr.jpg
nevcairiel
18th November 2011, 13:40
At least not true for my up-to-date Sandy Bridge Celeron G530 (supports full hardware decoding).
I suppose there will always be those people that mistakenly buy a Celeron instead of a CPU. Luckily, Microsoft even ships DXVA codecs that just work for those folk.
Xaurus
18th November 2011, 13:42
I suppose there will always be those people that mistakenly buy a Celeron instead of a CPU.
Thanks for making my day at work slightly funnier. :D
nevcairiel
18th November 2011, 13:45
Thanks for making my day at work slightly funnier.
But its true, those chips are artificially cut down in size, and really don't have any power anymore. But of course they appeal to people because you get them for $50 or something.
If i were to build a HTPC right now, i wouldn't go below the i3-2100, maybe even a bit up for some reserves.
Hardware decoding is all and well, but if it doesn't work for some reason, i would always want a system that can produce enough performance to run everything in software.
El Topo
18th November 2011, 13:45
... but making me cry! ;)
Xaurus
18th November 2011, 13:47
If i were to build a HTPC right now, i wouldn't go below the i3-2100, maybe even a bit up for some reserves.
It doesn't feel like my 2120T has much reserves, but it's awesome for a 35W chip. Best choice I ever made computer-wise.
nevcairiel
18th November 2011, 13:50
It doesn't feel like my 2120T has much reserves, but it's awesome for a 35W chip. Best choice I ever made computer-wise.
Well, the T series are down-clocked for less-power, aren't they?
The i3-2100 seems to be even faster then yours, but of course uses more power (65W)
I can't wait for Yvy Bridge, my HTPC is up for a rebuild. :)
fastplayer
18th November 2011, 13:54
At least not true for my up-to-date Sandy Bridge Celeron G530 (supports full hardware decoding).
According to Intel (http://ark.intel.com/products/53414), Clear Video HD Technology is disabled.
DragonQ
18th November 2011, 13:59
At least not true for my up-to-date Sandy Bridge Celeron G530 (supports full hardware decoding). Here is what I get while trying to play a 1080p24 mkv file, using lav video + lav audio decoders:
http://s3.kkloud.com/gett/static/scaled/9hK1V7A-0.dkghyykgduslwhfr.jpg
Well that clearly isn't using hardware decoding, is it? MPC-HC will say "DXVA" at the bottom if it's using hardware decoding. You can also press CTRL-J to see what rendering device and decoder are being used. LAV works with nVidia's CUDA but it doesn't work with Intel's equivalent, does it?
Personally I'm going Celeron G530 + nVidia GT430 for my HTPC. Using LAV CUVID the video card can handle all the difficult stuff with ease and the CPU is plenty for other things like DivX/Xvid. It can even handle MadVR.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.