LAV Filters - DirectShow Media Splitter and Decoders

[XadoX]

Thx for the fast feedback. At first tests the stuttering seems to be gone. I have to do some more testing to be realy sure.

The stuttering ist gone, thx for the quick bugfix.

[CruNcher]

OpenVideoDecode is stupid. It's not any easier than DXVA, it requires the use of OpenCL, for which AMD offers no Direct3D9 interop at the moment, it doesn't support deinterlacing and it's strictly AMD, only. NVidia's CUDA Decoding solution is much better, it's much easier to use than DXVA, it offers CUDA access with Direct3D9 interop and it does support deinterlacing. Furthermore, NVidia is very fast at GPU -> System RAM copy, while AMD is very slow with that. NVidia's solution: All good. AMD's solution: All bad. Sorry, but that's the honest truth.

I remember times where this was the exact opposite its heavy how fast Nvidia overrun ATI in Digital Video (though it took some years and theirfore ATI hit them in 3D/Power performance) especially realizing early on how much better its is to make their APIs available not only to NDA subscribers and really open their whole DSP portfolio and creating a huge ecosystem where everyone is involved from big isv partner to home coder and end user fixing bugs early on, though still ATI/AMD have some nice additional stuff inside their driver currently that Nvidia doesn't have yet like the realtime deshaking (ATI/AMD where first with that) :)
AMD was really to late to this Open ecosystem idea with exclusive NDA stuff and resheduling realeases over and over (to be exact 2 years to late) also this gave Intel time to catch up which also buildup a big High Quality ecosystem like Nvidia did early on :)

Though ATI/AMD where always straight on implementing stuff directly from their Labs into their Drivers like the Realtime Deshaking,adaptive sharpening and so on :)

[mkanet]

I don't use mpc-hc. To be honest I didn't even know there was a problem's using other players. Sagetv player does exactly what graphstudio does.. except it inserts EVR as video tenderer. What is DEP by the way?

PS: As an additional performance enhancement, I changed default colorspace to yv12 instead of yuy2. Im still trying to make my mind up yo use ivtc=when flag detected or ALWAYS. "Always" has better results for ivtc but seems to adversely affect true Video based material.


Just a quick question : how did you adjust this settings ?
MPC-HC crashes when trying to access the Dscaler Mpeg decoder settings (well known problem, reason is DEP) and if I change the settings in Graphstudio, they don't seem to retain.
Have you find a way to exclude your player from DEP ?

[Thunderbolt8]

could you please try if this VC-1 video plays? doesnt for me (was only a first try though). its from the latest BBC blu-ray: http://www.mediafire.com/?vhxgz1qwxmc2u6b

edit: nvm it does, its ffdshow raw video which creates trouble.

[mbordas]

what's the difference or affect of choosing mpeg-2 under lav video "codecs for hardware decoding" versus under the formats tab? I only ask cause I finally got dscaler5 to more or less work with mpc-hc for 24fps on soft telecined dvds, and figured I probably want to disable one or both of these?

[sneaker_ger]

If you don't select mpeg-2 under the formats tab, LAV Video will never accept mpeg-2, neither for software nor hardware decoding. If you turn off mpeg-2 in "codecs for hardware decoding" LAV Video will decode mpeg-2 in software mode.

[mbordas]

thx. on further inspection, it doesn't seem to matter - mpc uses the dscaler decoder, probably because the merit is higher.

funny thing is, dscaler seems to have been around for years. Wonder why its ivtc capabilities never made it into ffmpeg?

[Pat357]

I don't use mpc-hc. To be honest I didn't even know there was a problem's using other players. Sagetv player does exactly what graphstudio does.. except it inserts EVR as video tenderer. What is DEP by the way?

DEP = Data Execution Prevention
It's a Windows security thing ; most modern processors also have it on HW level.
See http://windows.microsoft.com/en-US/windows-vista/Data-Execution-Prevention-frequently-asked-questions#

I still can't use the Dscaler decoder IVTC because of this...
Some players don't require DEP, for example with Zoomplayer I can access the Dsaler dec properties, but they don't retain on my system. Even not after changing the Dscaler setting directly in the registry.
I'm out of ideas how to use it in MPC-HC. :(:( Unless a MPC-HC version with DEP requirements disabled comes along, I'm pretty sure it's plain *impossible* to use the Dscaler decoder. :(

[dead_screem]

thx. on further inspection, it doesn't seem to matter - mpc uses the dscaler decoder, probably because the merit is higher.

funny thing is, dscaler seems to have been around for years. Wonder why its ivtc capabilities never made it into ffmpeg?

maybe because it doesn't reliably detect soft pulldown. it's only officially supported on 1080i. whether it works on other formats is a crapshoot (576i dvb doesn't seem to work, 480i dvd does. not sure about others...)


I'm out of ideas how to use it in MPC-HC. :(:( Unless a MPC-HC version with DEP requirements disabled comes along, I'm pretty sure it's plain *impossible* to use the Dscaler decoder. :(have you tried disabling DEP in your system BIOS? (that is, if your system has the option...)

[Pat357]

thx. on further inspection, it doesn't seem to matter - mpc uses the dscaler decoder, probably because the merit is higher.
Nice ! I trying to get it working with MPC too, but till now, no success.
I mean the decoder loads in the graph and can decode MPEG-2, but the IVTC is not enabled. I can't enable it because accessing the properties always crashes MPC.
What OS are you running ? I've W7 Professional x64 SP1.

[FlashGordon]

Pat, try accessing the filter properties for Dscaler IVTC using Graph Studio (http://blog.monogram.sk/janos/download/dl-graphstudio.php)

[mbordas]

maybe because it doesn't reliably detect soft pulldown. it's only officially supported on 1080i. whether it works on other formats is a crapshoot (576i dvb doesn't seem to work, 480i dvd does. not sure about others...)


ha. you're right, I forgot to test it on some hard telecined files and it's no good. It just sets everything to 23.976. Oh well, it was worth the try...

[mkanet]

It looks like Dscaler's IVT mod can correctly handle popular American standard HDTV and DVD file formats:

480i/1080i film 1080i video

It can even handle 720p HDTV; however, for some odd reason YUY2 needs to be selected for the colorspace instead of YV12; otherwise, "white dot" unwanted artifacts appears in the video. Also, if "Enable Always" for IVTC is selected, it seems to cause video based playback to play at 23.976. So, use only if flag detected is best if playing back video based content too.

ha. you're right, I forgot to test it on some hard telecined files and it's no good. It just sets everything to 23.976. Oh well, it was worth the try...

[Paladin77]

Noob Question ladies and Gentlemen. How to force lav splitter to ALWAYS load subtitles using mpc-hc internal renderer, becuase sometimes sub groups forget to flag the subtitle track as default which will always be loaded by lav as part of the settings. However when I looked for the always load option it wasn't there.

[golagoda]

Noob Question ladies and Gentlemen. How to force lav splitter to ALWAYS load subtitles using mpc-hc internal renderer, becuase sometimes sub groups forget to flag the subtitle track as default which will always be loaded by lav as part of the settings. However when I looked for the always load option it wasn't there.

Setting your lav splitter settings to something like this should work, assuming we're talking about english subtitles. I put und there incase anything isn't set and is detected as undetermined.

http://i.imgur.com/s63Y5.png

Works fine for me at least.

[ryrynz]

Nevcairiel, Potplayer has a seamless playback feature which appears to replace Lav Splitter with the Seamless Parser when enabled.
Does this mean that this features ability to read ahead is something that can be implemented into the splitter?
It's quite nice having the next file play instantly without waiting for Avisynth to load it's script.

[nevcairiel]

Does this mean that this features ability to read ahead is something that can be implemented into the splitter?

No, it does not. A source filter can only open one file, it cannot open another one "ahead", it something the player has to implement.

[DragonQ]

OK, I've just tested this by comparing to my PC monitor upstairs. The TV when receiving 16-235 has washed out colours but when receiving 0-255, it has black crush. I wonder if it's to do with the TV's brightness and contract settings? I'm sure I calibrated according to Lagom's LCD test website but maybe it needs adjusting.

I think I figured it out. When sending 0-255, the information is definitely there in the image. I think the reason for the black crush is just the poor quality of the TV - if I play with the contrast and brightness settings I can significantly reduce the crush but it also raises the black level to be more grey. I've currently set it kind of in the middle as a compromise between deep blacks and shadow detail. Hopefully will have a chance to play with it more later, but I know for sure that using 16-235 levels is just a washed out mess.

[Paladin77]

Setting your lav splitter settings to something like this should work, assuming we're talking about english subtitles. I put und there incase anything isn't set and is detected as undetermined.

http://i.imgur.com/s63Y5.png

Works fine for me at least.


Brilliant thanks! I already put English and that always displayed subs flagged as English. I just needed a way for non flagged subs and putting und did the trick. Many thanks golagoda.

Awesome work Nev.

[nevcairiel]

Here is a recent test build.

x86: http://files.1f0.de/lavf/LAVFilters-0.42-20-g34e6d90.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.42-20-g34e6d90-x64.zip

There isn't really anything note-worthy to test, however there were alot of ffmpeg updates, including a new audio decoding API, and i need to make sure everything still works.

So if you can, run this version, and see if anything breaks that worked before. :)

Thanks!

[sneaker_ger]

Error 404

[nevcairiel]

Error 404

My fault, fixed the links. :p

[dead_screem]

Some ISDB-T TS files have their 1seg sub program auto selected instead of the main program, started happening some time after 0.42, first happens in previous test build 0.42.10.
http://www.megaupload.com/?d=QBRH6F6I

Its about time we had proper program switching added, and also to do away with automatically selecting the "best" program and just default to the first program.

[Mangix]

useless post...

[mindbomb]

what is the state of ffmpeg and interlaced vc-1?

[golagoda]

what is the state of ffmpeg and interlaced vc-1?

The one perfect word to describe it is 'horrendous' :p

It is getting a lot better though, I have a VC-1i file here I've been testing against ffmpeg (that I update and build daily from the git) using ffplay and mplayer2 for a few weeks since there's been a lot of commits for the vc1 decoder.

It's basically just laggy/jumpy (but with low CPU usage) and gives a lot of obviously incorrect playback, ffplay still spits out errors saying VC-1i playback isn't finished yet too.

[Pat357]

Pat, try accessing the filter properties for Dscaler IVTC using Graph Studio (http://blog.monogram.sk/janos/download/dl-graphstudio.php)

That works, but the settings don't retain in MPC-HC.

[Skinleech]

This issue with Dscaler, MPC & DEP has cropped up in a few places.

Work arounds I've seen are:

Using Zoomplayer to configure Dscaler.

Using MPC-HC builds around 1.3.1249 to change settings.

Post 16508 on the below thread gives you a batch file to toggle DEP on/off with MPC:

http://forum.doom9.org/showthread.php?t=123537&page=826

[VideophileII]

Hi nevcairiel,

I am the developer of Videophile II and have found that graph-building in my application fails when I have LAV Filters installed. Specifically, the SampleGrabber filter doesn't seem to play nicely with LAV Filters. Is this something that you are aware of and, more importantly, can it easily be resolved?

Regards...

[Reino]

Last time you fixed me a Vorbis Media Type bug...I found some more, that your LAV Video/Audio Decoder can handle, but where the splitter and FFDShow have a tough relationship:

Atrac3 Audio
- Atrac3 in WAV sample (http://samples.mplayerhq.hu/A-codecs/ATRAC3/mc_sich_at3_105.wav): LAV Splitter connects to FFDShow no problem.
- Atrac3 in RM sample (http://samples.mplayerhq.hu/real/AC-atrc/mc_sich_ra8_105.rm): connecting to FFDShow fails.

Cook Audio
- Cook in RM (obviously) sample (http://samples.mplayerhq.hu/real/AC-cook/mc_sich_ra8_44.rm): connecting to FFDShow fails.

Real Video 2
- RV20+Cook (RM) sample (http://samples.mplayerhq.hu/real/VC-RV20/Dolby7.5fps1.rm): FFDShow can handle RV20 (as well as Cook), but connecting LAV Splitter to FFDShow fails (Cook, same story).
(with Real Video 3 and 4 though LAV Splitter connects to FFDShow no problem)

Real Video 1
- RV10+AC3 (RM) sample (http://samples.mplayerhq.hu/real/VC-RV10/thankyou.rm): I can't tell at the moment, because LAV Splitter + FFDShow crashes immediately on RV10 and I don't know which one's the cause.
LAV Splitter + LAV Video Decoder works fine of course ;), but surprisingly MPC-HC's internal RM Splitter + FFDShow works fine too.

All tested with 0.42-20-g34e6d90, but the same applies to 0.42 as well.

[nevcairiel]

RealMedia stuff is not meant to connect to anything but LAV Audio/Video.
RM uses some rather weird special format of codec extradata, and re-constructing that is a tedious task i would rather avoid - use LAV Audio/Video. :p

[CruNcher]

Hi nevcairiel,

I am the developer of Videophile II and have found that graph-building in my application fails when I have LAV Filters installed. Specifically, the SampleGrabber filter doesn't seem to play nicely with LAV Filters. Is this something that you are aware of and, more importantly, can it easily be resolved?

Regards...

Nice application Edwin :) though i have still hope that someone implements mediainfo directly as a windows explorer shell extension (with colum details list integration) :)

[VideophileII]

Nice application Edwin :)

Thanks. But where did you get Edwin from?

[ryrynz]

If I take the first three letters from Edwards and the last two letters from Colin I get Edwin. :p

[VideophileII]

If I take the first three letters from Edwards and the last two letters from Colin I get Edwin. :p

Of course. Obvious, really. Silly me...:p

[CruNcher]

Thanks. But where did you get Edwin from?

If I take the first three letters from Edwards and the last two letters from Colin I get Edwin. :p

Oops sorry Colin, yeah i guess somehow that happened ;)

[VideophileII]

Oops sorry Colin, yeah i guess somehow that happened ;)

No problem. ;)

[sneaker_ger]

What method does LAV Splitter use to determine the source fps it reports to e.g. madVR (I mean the framerate used for refresh rate switching)? It seems to report the bitstream timings, which IMHO does not make sense, because for the actual playback only the mkv timecodes are used. (Talking about h264 in mkv)

[madshi]

Well, you could consider an MKV file in which the timecodes contradict the bitstream as being "broken". In theory you could have an MKV file with 3 different bitstreams: (1) video bitstream fps (2) MKV header fps (3) actual timecodes. I've seen such files. Which fps information should LAV Splitter forward to madVR then? Just add VFR to the mix and the mess is complete...

[nevcairiel]

What method does LAV Splitter use to determine the source fps it reports to e.g. madVR (I mean the framerate used for refresh rate switching)? It seems to report the bitstream timings, which IMHO does not make sense, because for the actual playback only the mkv timecodes are used. (Talking about h264 in mkv)

In my experience, trusting the MKV header information is even worse (it commonly has 60 fps for interlaced 60i content, which is just not correct). The only reliable thing would be to decode some frames and see what we get, but thats really alot more effort then worth (and VFR still blows that ouf of the water)

IHMO, the encoders are usually more sane then the MKV muxers. ;)

[THX-UltraII]

Hi Nevcairiel, I just send you a PM

[sneaker_ger]

In my experience, trusting the MKV header information is even worse (it commonly has 60 fps for interlaced 60i content, which is just not correct). The only reliable thing would be to decode some frames and see what we get, but thats really alot more effort then worth (and VFR still blows that ouf of the water)

IHMO, the encoders are usually more sane then the MKV muxers. ;)

Well, you could consider an MKV file in which the timecodes contradict the bitstream as being "broken". In theory you could have an MKV file with 3 different bitstreams: (1) video bitstream fps (2) MKV header fps (3) actual timecodes. I've seen such files. Which fps information should LAV Splitter forward to madVR then? Just add VFR to the mix and the mess is complete...

Since no one actually uses (1) for playback, I'd rule that one out. Decision between (2) and (3) is not that easy, because header could say 23.976, because the file is mostly 23.976, even though it may begin at 29.97.

My point is: (1) is never used, so it should be either (2) or (3). Since (2) is not always present it might be easiest to just always use (3).

Ideally, bitstream and container would agree, but currently it is easy to change the e.g. framerate in mkvtoolnix, but it does not change the bitstream information. (Though Mosu said he has plans to also change the bitstreams infos eventually.)

[madshi]

Timecodes might jitter a lot, depending on how the file was muxed. You can only get reliable FPS information from (3) by parsing large parts of the file. IMHO that doesn't really make sense for a splitter. Loading MKV files would be very slow that way.

[sneaker_ger]

Shouldn't the first few timecodes be sufficient? I can't see the bitstream information being more reliable.

[nevcairiel]

MKV timecodes typically only have a very rough precision, which means for 23.976 they jitter between 41ms and 42ms, so to 100% measure the difference between 23.976 and 24.000 you need to decode around 30-40 frames, which is just not practical. For H264 specifically, you also need to actually *decode* the frames, otherwise you will have a really hard time to re-order the timecodes from PTS to DTS.
Anyway, i had some issues with MKV header information before, so i'm sticking with bitstream now.

[sneaker_ger]

MKV timecodes typically only have a very rough precision, which means for 23.976 they jitter between 41ms and 42ms, so to get the difference between 23.976 and 24.000 you need to decode around 30-40 frames, which is just not practical.

Oh, that is too much already? For mkvmerge they already differ on the sixth frame, but I guess it depends on the muxer.

Anyway, i had some issues with MKV header information before, so i'm sticking with bitstream now.

With the respective header being optional, we couldn't rely on that only anyways.

[nevcairiel]

Oh, that is too much already? For mkvmerge they already differ on the sixth frame, but I guess it depends on the muxer.

"Differ", maybe, but to really be sure, you need to decode enough so that when you average them the precision is high enough to ensure you don't get it wrong. 20 was not enough in the past, and caused it to detect 23.976 as 24.000 quite frequently, so it was increased to 40, until i turned that logic off (because it also doesn't work properly with telecine flags and some interlaced codings)

Millisecond precision is sadly a default of the MKV spec, and even though it can be increased by the muxer, it appears not many do so.

[madshi]

Oh, that is too much already? For mkvmerge they already differ on the sixth frame, but I guess it depends on the muxer.
The timecodes are also not necessarily continuous. They might jump up and down, due to the I, P and B frame logic. Looking at timecodes and figuring out the correct FPS from them isn't a trivial task, not if you want it to be *reliable* for most MKV files out there. FWIW, I've a similar logic in eac3to and although it works fine most of the time, it sometimes (often enough to not rely on it) misdetects the timestamps FPS.

[sneaker_ger]

I see. I guess the bottom line is: it would be possible, but overly complicates while being relevant in just a few cases.

Do you have such detection for all video formats? The only other advantage with using the mkv info would be that it that the detection could work regardless of the video codec.

[nevcairiel]

Do you have such detection for all video formats? The only other advantage with using the mkv info would be that it that the detection could work regardless of the video codec.

Its really up to ffmpeg, when a format does not provide its own timings, it'll try to measure it by reading some frames. I only tweaked the logic some to fit my needs.