LAV Filters - DirectShow Media Splitter and Decoders

[ramenchef]

I'm having a weird issue. I currently use Haali for mkvs just for ordered chapters. For everything else, LAV splitter is being used. When playing back an ogm file, LAV splitter refuses to automatically load the subtitles. The subtitles show up under the splitter source, but it defaults to no subtitles every time. Subtitle selection mode is set to default with eng,jpn as the options. I am using MPC-HC + xy-vsfilter. I have tried moving directvobsub above and below LAV Splitter in the external filters setting in MPC-HC, but it doesn't help. This is on LAV Filter 5.1.3(?) and 5.2.
http://i.imgur.com/27d1b.png

[nevcairiel]

Your file has wrong language tags.
You can either put "English" in the language tag, or "eng", but a combination of "English[eng]" will not be recognized properly.

[Dogway]

Originally Posted by CoRoNe

there's absolutely no reason to mess with the merit settings or external filters in MPC-HC.

So if I have LAV Video, FFDshow and XviD, who chooses what to decode?
or another scenario, LAV Audio, FFDShow Audio, and MPEG Layer 3 Decoder? (That assuming I don't have more codecs installed, which is highly unlikely as they get installed with programs like PowerDVD, iZotope, TechSmith, etc)


My AVS is simple, because I'm testing:

setmtmode(3,2)
MPEG2Source("source.d2v", cpu=0)
Trim(34165, 42102)

EDIT: To demonstrate that your workflow doesn't work, I deleted all the external filters, and this is what I get:

If you're curious, mp4 (avc+aac), mov (asp+pcm)

[Reino]

Originally Posted by nevcairiel

Now if you use madVR or even VMR-9 on a Fraps YUV420 file, it would switch to NV12/YV12 output.

That's true, but since the decoder's output is RGB, that would mean 2 colorspace conversions; YV12-->RGB-->YV12.
Your splitter correctly detects these files as either FPS1(yuvj420p), or FPS1(bgr24), so wouldn't it be possible to determine the colorspace before connecting to the video decoder? If the splitter detects FPS1(yuvj420p), tell the video decoder not to do any colorspace conversion.
And I don't know what FFDShow's PC.709-->Rec601 conversion is based on, but since ffmpeg can do PC.709-->Rec601 conversions now (-pix_fmt yuv420p -vf colormatrix=bt709:bt601), is it possible to integrate it into LAV Filters? LAV Filters is based on ffmpeg, right?
And btw, I'm not so sure if most people use Fraps's RGB recording mode. It's quite a bit more demanding compared to the YV12 mode and when you do a proper PC.709-->Rec601 conversion, I doubt you would see any (major) differences. A survey (on the Fraps forum) would be interesting.

Originally Posted by Dogway

So if I have LAV Video, FFDshow and XviD, who chooses what to decode?

I thought you were trying to play an Avisynth script in MPC-HC. Don't change the subject please.
Your script appears to be YV12, so installing a YV12 video decoder is all you need.
Such a script would play fine here with the AVI/WAV File Source and FFDShow's Raw Video Decoder.
Again: except for FFDShow's Raw Video Decoder, there's absolutely no reason to mess with the merit settings or external filters in MPC-HC, if you want to play Avisynth scripts, or any other media file for that matter. At least I have never had to mess with them for any scenario whatsoever.

[nevcairiel]

Originally Posted by CoRoNe

That's true, but since the decoder's output is RGB, that would mean 2 colorspace conversions; YV12-->RGB-->YV12.

Wah?
The decoder outputs YV12 for such files, LAV tries to switch the renderer to NV12 or YV12 mode, and if the renderer accepts that, no conversion is performed at all. If the renderer refuses, it sticks with its current format, which for Fraps defaults to RGB. So either you have YV12 -> RGB for EVR, or you have just plain YV12 -> YV12 for any sane renderer.

LAV doesn't even have the ability to do any double-conversions.

Originally Posted by CoRoNe

Your splitter correctly detects these files as either FPS1(yuvj420p), or FPS1(bgr24), so wouldn't it be possible to determine the colorspace before connecting to the video decoder? If the splitter detects FPS1(yuvj420p), tell the video decoder not to do any colorspace conversion.

Most video renderers completely fail at fullrange YV12 input, which is why it was prefered to simply use RGB, because when LAV converts to RGB, it properly takes the range and the matrix into account (the "j" in yuvj420p indicates its jpeg-range, aka full-range)

If the Fraps decoder in ffmpeg also manages to tell LAV that the YV12 it outputs is in some specific matrix (709 or 601), it will properly take this into account and create perfect RGB.
If Fraps encoded YV12 is always in the same matrix, i can also hardcode that value somewhere.

I have no plans to add code to change the YUV color matrix. Its not something a decoder should be doing.

[Reino]

Originally Posted by nevcairiel

The decoder outputs YV12 for such files, LAV tries to switch the renderer to NV12 or YV12 mode, and if the renderer accepts that, no conversion is performed at all.

LAV in Avisynth through DirectShowSource() shows the output to be RGB24, and although I can confirm that VMR-9 puts out NV12, I thought 2 colorspace conversions would take place. But that's good to hear.

Originally Posted by nevcairiel

Most video renderers completely fail at fullrange YV12 input...

I guess that doesn't include VMR-9 then, because with VMR-9 it's still PC.709. With EVR it becomes Rec709 indeed.

Originally Posted by nevcairiel

If Fraps encoded YV12 is always in the same matrix, i can also hardcode that value somewhere.

Originally Posted by PhrostByte

...so I sent an email to FRAPS' author about 6 months ago. He just now finally got back to me with this:

Dear Cory,

Thanks for your message and I apologize for the very long delay in getting back to you.
In YUV mode Fraps will use 709 coefficients and generate the full range 0-255 (i.e. it's not clamped between 16-235).

Regards,
Rod Maher

It seems one of FRAPS or libav or me is doing something wrong.

FPS1(yuvj420p) is always PC.709. ffmpeg by default also treats it that way. I don't think there's metadata, or any file property that indicates it's using the Rec.709 luma coefficients.

[nevcairiel]

Originally Posted by CoRoNe

I guess that doesn't include VMR-9 then, because with VMR-9 it's still PC.709. With EVR it becomes Rec709 indeed.

Both renderers have no clue how to identify PC range YUV content. Microsoft specifys a way to put that information into the mediatype, however besides madVR i know of nothing that reads that information.

Because its the more common format, basically all renderers assume YV12 is limited-range.

[Dogway]

Originally Posted by CoRoNe

Don't change the subject please.
(...)there's absolutely no reason to mess with the merit settings or external filters in MPC-HC

Then please, don't create confusion by telling me to don't deal with external filter settings when the OP recommends a tutorial where the usage of external filter settings is promoted.

I managed to reproduce the filter chain on graphedit. It works:
"AVI/WAV File Source"->"FFDShow Video Decoder"->"Video Renderer"
It creates the filter chain automatically when I drop the avs in the program, but I still can't play it in mpc-hc for some reason (whatever my external filters configuration is).

[vad74]

nevcairiel
Can new LAV Filters 0.52 work with QuickSync in fullscreen mode?

[Reino]

Haha, I never knew about these guides. Notice nevcairiel also states: Those guides are in no way "official", and I do not guarantee the accuracy of these guides, but they should get you started.
I'll say it again; there's absolutely no reason to mess with the merit settings or external filters in MPC-HC to play any audio or video file.
If I'm using it, it's only to block specific filters for testing purposes.

If it successfully creates a DirectShow graph in GraphEdit (it's better to use GraphStudioNext btw), but fails in MPC-HC, have you tried to use a regular MPC-HC version(*) instead of the "modded austere light version" you're using, or selecting another renderer than madVR?

Note that if you change "Raw Video" to "YV12" in the Codecs-section of FFDShow's Video Decoder config and you're using another video decoder than FFDShow (MPC-HC's internal decoders, or LAV Video Decoder for instance), it will then always connect to that video decoder's output. For a MKV[H.264+AC3] file for instance, that would mean:

LAV Splitter Source --> LAV Video Decoder --> FFDShow Video Decoder --> Video Renderer
                    \-> LAV Audio Decoder --> Audio Renderer

...which is of course completely unnecessary.
If you use FFDShow's Raw Video Decoder (by changing its merit to 00400000) instead, you won't have this problem.

Originally Posted by nevcairiel

Sounds like he updated to some broken version of that directory index script. I let him know.

(*) Looks like he did it again and although I'm using the Firefox plugin NoScript, all Javascript is allowed for that site.
Kinda weird he doesn't check if his own website is functioning properly.

[madshi]

I'm sure this question was answered before, but I didn't found anything useful in a quick search, so:

With an NVidia card, is there any advantage to using DXVA over CUDA or the other way round? I understand that with EVR/VMR, DXVA gets along with less copying around, but other than that?

Thanks!

[nevcairiel]

Originally Posted by madshi

With an NVidia card, is there any advantage to using DXVA over CUDA or the other way round? I understand that with EVR/VMR, DXVA gets along with less copying around, but other than that?

"Native" DXVA has the advantage of never leaving the GPU, which leaves you with like 0% cpu usage, but you know the limitations that includes, so there is that.
Its really only an advantage if you are very focused on battery life, or you have a very slow CPU, like the ION platforms.

Copy-Back DXVA is pretty similar to the CUDA mode, both operate on the same concept really.

CUDA Pro:
- NVIDIA driver does the bitstream parsing and sends the data to the GPU exactly in the way it expects it (may avoid problems here and there, i know of no cases where this matters)
- Support for MPEG4-ASP
- Built-in DI possibility before software post-processing
- Works without a D3D device (can be used in exclusive mode)
- Partial acceleration of VC-1 on older GPUs

CUDA Con:
- No support for WMV3
- Puts the GPU into maximum performance mode (something in the CUDA API causes this)

Think thats about all. None of these points are very strong imho, unless you want the DI.

[Dogway]

-Yes I'm already using GraphStudioNext, for instance yesterday I updated to v.5.0.0.1 because I had the comctl32.dll error.

-Yes, I'm already using the regular "modded austere light version" of MPC-HC. :P

I appreciate your help, but please, make yourself clear.

Originally Posted by CoRoNe

"there's absolutely no reason to mess with the merit settings"
"by changing its merit to 00400000"

Do you want me to change merit or not?
Besides there is no "FFDShow's Raw Video Decoder", maybe you mean "FFDShow's Raw Video Filter"?

OK, now look. I changed "FFDShow's Raw Video Filter" merit to 00400000, and set RAW video to YV12 (Thanks to your shortcut trick). I disabled "FFDShow Video Decoder" RAW Video. I enabled VMR9 renderer.
AVS doesn't play, and playing an mp4(avc+aac), ffdshow audio gets preference over LAV Audio.
Now loading avs into GraphStudioNext even doesn't work: "Can't Open File". XD
BUT if I manually build the graph, it works:
"AVI/WAV File Source"->"FFDShow RAW Video Filter"->"Video Renderer"

[cyberbeing]

When opening AVS files via VFW, your graph should be "AVI/WAV File Source"->"Video Renderer" only with no additional filters.

[Dogway]

Originally Posted by cyberbeing

When opening AVS files via VFW, your graph should be "AVI/WAV File Source"->"Video Renderer" only with no additional filters.

When I connect the avs to the video renderer, the RAW filter node gets automatically created and connected between the nodes.

[Pat357]

Nev,

I'm testing with the latest build from git (41ce391).
I use a 16 bit colordepth .PNG file (48 bits/pixel) with MPC-HC & Madvr.
Lavspliiter reports : PNG , RGB48be, 512x512

If I enable all formats in Lavvideo, I get indeed a 25fps "movie", but Madvr reports RGB32 (8bit) instead of RGB48 ??
Only if I disable RGB32/RGB24, I get a nice 25fps Y416 video.

With a 16-bit gray png :
Lavsplitter : png, gray16be
Madvr : NV12 8bit 4:2:0 (!)

Is this a Madvr issue or what do you think ?
Maybe I'm just testing something that hasn't been finished yet, if, sorry for my impatience ....

[nevcairiel]

Right now all high-bitdepth RGB gets internally converted to 8-bit RGB, because there is no native support for 16-bit RGB yet.

So yes, patience, find it.

[cyberbeing]

Originally Posted by Dogway

When I connect the avs to the video renderer, the RAW filter node gets automatically created and connected between the nodes.

If you add ConvertToRGB32() or ConvertToRGB24() to the end of your script, it should connect directly to "Video Renderer".

For other colorspaces, an intermediary filter like Microsoft's AVI Decompressor, Microsoft's Color Space Converter, or FFDShow RAW is needed. To enable YV12 support in AVI Decompressor, you can install DivX.

madVR on the other hand is special, and will accept direct YV12, YUY2, YV16, YV24, RGB24, and RGB32 Avisynth connections via "AVI/WAV File Source" without any intermediary conversion filters.

[clsid]

Originally Posted by Dogway

So if I have LAV Video, FFDshow and XviD, who chooses what to decode?

Things are very simple:
* ffdshow has a very high merit. This means that if a format is enabled in ffdshow settings, ffdshow will get used.
* LAV decoders have a merit that is a little bit higher than most other decoders. So if a format is enabled in LAV (and not in ffdshow), then LAV will be used.
* If a format is disabled in both ffdshow and LAV, then another decoder will get used if you have any others installed.
* With regard to splitters, it is possible to configure a specific splitter for each file extension using similar Registry tweaks as I have posted before for .avs. An easy way to configure this as a novice user is to use Codec Tweak Tool

A good way to test if .avs input works is to first test the most simple script:

version()

"AVI/WAV File Source" may give problems with audio. This is one of the reasons why Haali added Avisynth input support to his splitter.

For YV12 conversion, the Xvid VFW codec can be used. That is better than using ffdshow RAW, because it won't have any unwanted side-effects on normal video playback.

[Dogway]

Originally Posted by cyberbeing

If you add ConvertToRGB32() or ConvertToRGB24() to the end of your script, it should connect directly to "Video Renderer".

Yes it does, interestingly enough when I add the converttorgb line dropping the avs automatically loads the Convert Color Space node, it isn't necessary, so I can manually delete it and connect directly to video renderer.

MPC never worked, I will try with the latest lite portable version, but I fear it's more a codec and merits thing than anything else.

EDIT:
if LAV decoders merit are a bit higher than other, then why FFDshow Audio still gets preference to decode AAC than LAV Audio?

On relation to avs playback, if I load the avs on MPC-HC it gets stuck on opening, then I have to close the program, and go to processes and finish the process.

I right know thought that the Haali reg I created before (by now I have Haali already uninstalled) was giving me problems on splitter requirements, so I deleted it as well. But MPC still gets stuck.