LAV Filters - DirectShow Media Splitter and Decoders

[VipZ]

I use MPC x64 with internal sub renderer.

Did some more testing with your builds as well to eliminate mine as a possible issue. Its down to x64, in x86 it doesn't crash.

[nevcairiel]

Ah, there we go. I see why its crashing.
Apparently not many people use x64. :D

[VipZ]

Ah, there we go. I see why its crashing.

Cool :)

Dont worry, I will continue to use x64 and find any bugs that may exist in it :D

[nevcairiel]

And its fixed.

[VipZ]

Awesome, thanks.

BTW, aren't you meant to be on holiday ;)

[nevcairiel]

It was raining too much, so we got back earlier. Driving on a boat over the baltic sea isn't much fun if its raining all day.

[VipZ]

I can imagine that not being fun.

[STaRGaZeR]

One thing puzzles me, though. You don't configure any language, but you still expect the "default" stream to show up? And the forced stream? How is it supposed to select the proper forced stream, in case there is more then one?
Without a language preference, it really is only guesswork which stream is right. Sure, it can go with the "default" stream, or the first "forced" stream, but unless you configure languages, it'll never be 100%.

Anyway, i won't be doing small adjustments to the logic now, i rather schedule a full logic rewrite for one of the future versions.

Since you're talking about flags, I assume you mean MKV. When watching something, the normal way is without subs. If the file has forced or default tracks it's because the guy who muxed it (in this case myself) wanted them to show up on purpose. By not configuring any language I "trust" the file, as I assume the muxer to know what he's doing. This has always worked for me. Also, configuring a language isn't an option either because I can have 2 or even 3 preferred languages, all present on the same file, which one to pick? I don't always want to see the same one, nor I want to see it all the time. So by default, no subtitles, and if the file I'm watching has flags, obey them because they are there for a reason. Then manually switching if needed/wanted, or more advanced logic if the user has special needs. It seems Haali thought the same when he designed his stuff :p

If there is more than one forced stream, then that file was muxed incorrectly in my book, as you can't force 2 or 3 subtitles at once. Of course you have to guess in this case, but since they are forced streams you have to select one, the first is the best candidate if there are no languages set. Now, if there are no forced or default streams, I realize that the muxer wanted to have subs there, but disabled by default. In the end, there is no other way to do it.

As you wish, will be waiting for it so I can finally say goodbye to good ol' Haali.

Now to another "issue". Is it normal for swscale to convert to RGB32 this (http://img402.imageshack.us/img402/9533/lavvrgb32.png) bad? When I was messing with ffdshow I came up with the same thing, but assumed it was because of the point scaling used there. However in LAV Video you use SWS_BICUBIC... this (http://img263.imageshack.us/img263/3103/ffdshowrgb32.png) is ffdshow's RGB32HQ for comparison.

[nevcairiel]

"forced" in my book indicated subtitles that should always be shown to understand the movie, like alien languages. Those subtitles can of course be present in multiple languages, and on Blu-ray typically are - so when i convert the Blu-ray to an MKV, i might have two or more tracks with the "forced" flag, perfectly valid IMHO.

Regarding RGB32, i think swscale has a "special" converter for YV12 to RGB32 that does some cheap scaling.
Do you happen to have a short sample movie with such a red-to-black contrast that shows the problem clearly, so i can run some tests?

Edit:
NVM, found a good sample.

[nevcairiel]

Here its two images of a red-on-black, the default swscale 4:2:0->RGB conversion, and a better one with a bunch of different flags. Apparently swscale is capable, its just hidden behind loads of flags, who knows why.

"Bad"
http://files.1f0.de/bad.png

"Better"
http://files.1f0.de/better.png

This is a 300% zoom.
I did not test how much more performance this needs, but i'll test and if its significant, add a checkbox for that, i guess.

Here is a build:
http://files.1f0.de/lavf/LAVFilters-0.32-rc3.zip

[sneaker_ger]

If there is more than one forced stream, then that file was muxed incorrectly in my book, as you can't force 2 or 3 subtitles at once. Of course you have to guess in this case, but since they are forced streams you have to select one, the first is the best candidate if there are no languages set. Now, if there are no forced or default streams, I realize that the muxer wanted to have subs there, but disabled by default. In the end, there is no other way to do it.
"forced" in my book indicated subtitles that should always be shown to understand the movie, like alien languages. Those subtitles can of course be present in multiple languages, and on Blu-ray typically are - so when i convert the Blu-ray to an MKV, i might have two or more tracks with the "forced" flag, perfectly valid IMHO.

nevcairiel is correct, the Matroska spec explicitly allows multiple forced tracks and says that the user preference shall be selected in such a case.

Something along the lines of post #4667 would be a big improvement over the current situation. Then you can just disable subtitles for dubs you understand and activate for those you don't.

[STaRGaZeR]

Regarding RGB32, i think swscale has a "special" converter for YV12 to RGB32 that does some cheap scaling.

Not as smooth as ffdshow's but a lot better (http://img268.imageshack.us/img268/4848/lav2e.png), I can't tell the difference without looking at 10 cm of the screen. CPU utilization is significantly higher, from 25-30% to 35-45% playing ~35mbps H.264 Blu-ray on a 4.5GHz 2500K. Have you run any tests comparing bilinear, bicubic, lanczos, etc.?

"forced" in my book indicated subtitles that should always be shown to understand the movie, like alien languages. Those subtitles can of course be present in multiple languages, and on Blu-ray typically are - so when i convert the Blu-ray to an MKV, i might have two or more tracks with the "forced" flag, perfectly valid IMHO.

It is of course valid, but what happens when you're going to play the file and the splitter doesn't know what language (between English and native for example) you want to hear this particular time? What happens if I don't want to see the subs, even if I don't understand what they're saying? Since both are forced at least one of them must be played, so I'm screwed. The forced flag is a dangerous one, I would only use it for the video track (just in case it wasn't obvious :D).

nevcairiel is correct, the Matroska spec explicitly allows multiple forced tracks and says that the user preference shall be selected in such a case.

Something along the lines of post #4667 would be a big improvement over the current situation. Then you can just disable subtitles for dubs you understand and activate for those you don't.

Yes, that's why I said in my book. But the spec doesn't tell you what to do when there is no such preference, and when there is no default flag. Also the whole paragraph is filled with "should", not "must". So basically if there are 2 or more forced tracks you can do whatever you want as long as you pick at least one, as the spec doesn't force anything on you.

There's one MUST in the forced flag description, but you are free to do whatever you want with the default flag. And here comes the problem, everyone wants to do different things with it :p

And yes, that would be great. More control is always a good thing.

Track Flags

Default flag

The "default track" flag is a hint for the playback application and SHOULD always be changeable by the user. If the user wants to see or hear a track of a certain kind (audio, video, subtitles) and she hasn't chosen a specific track then the player SHOULD use the first track of that kind whose "default track" flag is set to "1". If no such track is found then the first track of this kind SHOULD be chosen.

Only one track of a kind MAY have its "default track" flag set in a segment. If a track entry does not contain the "default track" flag element then its default value "1" is to be used.

Forced flag

The "forced" flag tells the playback application that it MUST display/play this track or another track of the same kind that also has its "forced" flag set. When there are multiple "forced" tracks, the player should decide on the language of the forced flag or use the default flag if no track matches the use languages. Another track of the same kind without the "forced" flag may be use simultaneously with the "forced" track (like DVD subtitles for example).

Taken from here (http://matroska.org/technical/specs/notes.html).

[sneaker_ger]

Yes, that's why I said in my book. But the spec doesn't tell you what to do when there is no such preference, and when there is no default flag. Also the whole paragraph is filled with "should", not "must". So basically if there are 2 or more forced tracks you can do whatever you want as long as you pick at least one, as the spec doesn't force anything on you.

There's one MUST in the forced flag description, but you are free to do whatever you want with the default flag. And here comes the problem, everyone wants to do different things with it :p.

Yes, the spec is too vague about all this. I'm hesitant to actually use the forced flag, since I fear it might be interpreted like some dvd style user operation prohibition. I rather include the "forced" in the subtitle name (so a system not only allowing to choose by languages and default/forced flag but also a simple regex would be even more welcome. Sadly, more power comes with additional complexity. I guess that's why Haali not only allows pairs but also "simple" selections, so that not all intuitive configuration abilities are lost.)

It would've been nice to have the ability to define certain pairs in Matroska. (Like English: English Dub, English forced subs; English (hearing impaired): English Dub, English full subs; etc.) But we have to work with what the spec gave us.

[nevcairiel]

Have you run any tests comparing bilinear, bicubic, lanczos, etc.?

I can't detect any visual difference between bilinear or bicubic, and bilinear is around 20% faster.

However, even on my 2600k, on 1080p its only fast enough for around 45fps, so 50p or 60p content fails.

Is ffdshows HQ RGB converter multi-threaded, or just generally faster?
I can probably implement multi-threaded conversion at some point.

In general, i really recommend to let the renderer and the GPU do the RGB conversion, its so much faster, and can use much more advanced interpolation algorithms on the shaders.

[madshi]

I can't detect any visual difference between bilinear or bicubic, and bilinear is around 20% faster.
The difference between bilinear and bicubic is rather small, when talking about chroma upsampling. Furthermore, since chroma upsampling is always exactly 2x, you could even use a very simple hard wired logic like e.g. a 25/75% average of neighboring pixels. Might allow further speed optimizations (e.g. shifts instead of multiplications etc) with practically identical quality.

[nevcairiel]

I really don't feel like hacking up swscale or roling my own logic just for those few people that really want RGB output. :p

[madshi]

Yeah, agreed. Just mentioned that because you were talking about implementing multi threaded conversion. So I thought you were planning to write custom conversion code or something.

[nevcairiel]

I'll just do a "frame threading" kind of thing, allowing multiple images to be processed at the same time, but still with the same conversion in swscale. If it can do 45fps single-threaded, i can theoreticially get it to do 90fps with two threads. :p
But its nothing i plan on doing for the first release.

[madshi]

Ah ok, makes sense.

BTW, have you thought about implementing DXVA_ExtendedFormat in your video decoder's output media type? Would be quite useful.

[nevcairiel]

Its somewhere on my list of things to do.

[madshi]

Its somewhere on my list of things to do.
Ok, that's fine. For your reference:

primaries:
// DXVA_ExtendedFormat values:
// 2: BT.709
// 3: BT.470 System M
// 4: BT.601 (PAL, SECAM)
// 5: SMPTE 170M
// 6: SMPTE 240M
// 7: BT.601 (PAL, SECAM)
// 8: SMPTE C

// MPEG2, VC-1 and h264 bitstream values:
// 1: [DXVA: 2] 0.640 0.330, 0.300 0.600, 0.150 0.060, D65, BT.709, sRGB
// 4: [DXVA: 3] 0.670 0.330, 0.210 0.710, 0.140 0.080, C, BT.470 System M
// 5: [DXVA: 4] 0.640 0.330, 0.290 0.600, 0.150 0.060, D65, BT.601 (PAL, SECAM)
// 6: [DXVA: 8] 0.630 0.340, 0.310 0.595, 0.155 0.070, D65, BT.601 (NTSC), SMPTE C, SMPTE 170M
// 7: [DXVA: 6] 0.630 0.340, 0.310 0.595, 0.155 0.070, D65 SMPTE 240M
// 8: [DXVA: -] 0.681 0.319, 0.243 0.692, 0.145 0.049, C, Generic film (colour filters using Illuminant C)

decoding matrix:
// DXVA_ExtendedFormat values:
// 1: BT.709
// 2: BT.601
// 3: SMPTE 240M
// 7: YCgCo

// MPEG2, VC-1 and h264 bitstream values:
// 0: [DXVA: -] Y = G, Cb = B, Cr = R
// 1: [DXVA: 1] kr 0.2126, kb 0.0722, BT.709
// 4: [DXVA: -] kr 0.3000, kb 0.1100, United States National Television System Committee 1953 Recommendation for transmission standards for colour television, United States Federal Communications Commission Title 47 Code of Federal Regulations (2004) 73.682 (a) (20)
// 5: [DXVA: 2] kr 0.2990, kb 0.1140, BT.601 (PAL, SECAM)
// 6: [DXVA: 2] kr 0.2990, kb 0.1140, BT.601 (NTSC)
// 7: [DXVA: 3] kr 0.2120, kb 0.0870, SMPTE 240M
// 8: [DXVA: 7] YCgCo

transfer function:
// DXVA_ExtendedFormat values:
// 1: Linear
// 2: True 1.8 gamma
// 3: True 2.0 gamma
// 4: True 2.2 gamma, BT.470 System M
// 5: 0.45, 0.0990, BT.709, BT.601
// 6: 0.45, 0.1115, SMPTE 240M
// 7: 1/2.4, 0.0550, sRGB, scRGB(12)
// 8: True 2.8 gamma, BT.1700 (PAL, SECAM), BT.470 System B, G (PAL) -> change to BT.601
// 9: Logarithmic transfer characteristics (100:1 range)
// 10: Logarithmis transfer characteristics (100*sqrt(10):1 range)
// 11: xvYCC, IEC 61966
// 30: BT1361 extended colour gamut system
// 31: True 2.6 gamma, DCI

// MPEG2, VC-1 and h264 bitstream values:
// 1: [DXVA: 5] 0.45, 0.0990, BT.709
// 4: [DXVA: 4] True 2.2 gamma, BT.470 System M
// 5: [DXVA: 8] True 2.8 gamma, BT.1700 (PAL, SECAM), BT.470 System B, G (PAL)
// 6: [DXVA: 5] 0.45, 0.0990, BT.601
// 7: [DXVA: 6] 0.45, 0.1115, SMPTE 240M
// 8: [DXVA: 1] Linear
// 9: [DXVA: 9] Logarithmic transfer characteristic (100:1 range)
// 10: [DXVA: 10] Logarithmic transfer characteristic (100*sqrt(10):1 range)
// 11: [DXVA: 11] xvYCC, IEC 61966
// 12: [DXVA: 30] BT.1361 extended colour gamut system
h264 is specifying the largest list of possible values. MPEG2 and VC-1 only use a subset of the h264 supported values. But since there's no overlap anywhere, I think we can safely use the full h264 range of values for all h264, MPEG2 and VC-1. At least that's what I'm doing in madVR. Of course for formats other than h264, MPEG2 and VC-1 you'll need to find your own map of video bitstream index -> DXVA_ExtendedFormat index.

I've also extended the list of DXVA_ExtendedFormat values by those added by MediaFoundation, and those added by the (work in progress) Open Media Format. Shouldn't harm to use the full list of those values.

[Sebastiii]

Hi Nevcairiel,

I think it already been ask, it is possible to set output audio PIN (LAVAudio ofc) to not float ? humm sorry for my word !!! i hope you know what i try to explain :)
Is it possible to do this easily ?
I asking because i would like to Try MP Audio Renderer (Reclock Fork) for Mediaportal.
Thanks :)

[nevcairiel]

I think it already been ask, it is possible to set output audio PIN (LAVAudio ofc) to not float

Not yet.
http://code.google.com/p/lavfilters/issues/detail?id=10

You can compile your own version, and in LAVAudio.h set "REQUEST_FLOAT" to 0.

[Sebastiii]

Thanks Nevcairiel :) Will try when go to home :)

[fastplayer]

The difference between bilinear and bicubic is rather small, when talking about chroma upsampling. Furthermore, since chroma upsampling is always exactly 2x, you could even use a very simple hard wired logic like e.g. a 25/75% average of neighboring pixels. Might allow further speed optimizations (e.g. shifts instead of multiplications etc) with practically identical quality.
FYI, that's the method ffdshow is using (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=2646).

[nevcairiel]

If i feel one day like doing alot of assembler, i might as well create a more efficient custom scaler. swscales problem is that it supports scaling everything into everything, and that makes it slow. It has a "special" converter for YV12->RGB which is quite fast, but why that one is so absolutely horrible in quality, i cannot say.
Anyhow, for the first version of LAV Video, this will have to suffice. Yes, its too slow for 50/60p content, but shrug. Me personally, i will always let the renderer do the conversion. If you desperately need RGB32 conversion on 60p content, there is always ffdshow in the meantime.

[roytam1]

New nightly: http://roy.orz.hm/lavf-w32-nightlies/lavf-my110816_2-1b350b81.7z

[Thunderbolt8]

what do I need to do to get LAV video to play? I installed it, set it to prefer in mpc-hc, disabled ffdshow/coreavc and the mpc internal renderers, but theres no picture at all, aside that window with 'mpc-hc could not render some pins to the graph...'

[STaRGaZeR]

I can't detect any visual difference between bilinear or bicubic, and bilinear is around 20% faster.

However, even on my 2600k, on 1080p its only fast enough for around 45fps, so 50p or 60p content fails.

Is ffdshows HQ RGB converter multi-threaded, or just generally faster?
I can probably implement multi-threaded conversion at some point.

I can't see a difference either, plus it's quite a bit faster. Also screw my previous LAV screenshot, it was done with ffdshow in the middle. This (http://img844.imageshack.us/img844/5878/lavbilinear.png) is how it looks now, against ffdshow (http://img263.imageshack.us/img263/3103/ffdshowrgb32.png). The same in my book. Have you tried without SWS_ACCURATE_RND? Because I found this in swscale:

// reuse chroma for 2 pixels RGB/BGR unless user wants full chroma interpolation
811 if (flags & SWS_FULL_CHR_H_INT &&
812 dstFormat != PIX_FMT_RGBA &&
813 dstFormat != PIX_FMT_ARGB &&
814 dstFormat != PIX_FMT_BGRA &&
815 dstFormat != PIX_FMT_ABGR &&
816 dstFormat != PIX_FMT_RGB24 &&
817 dstFormat != PIX_FMT_BGR24) {
818 av_log(c, AV_LOG_ERROR,
819 "full chroma interpolation for destination format '%s' not yet implemented\n",
820 sws_format_name(dstFormat));
821 flags &= ~SWS_FULL_CHR_H_INT;
822 c->flags = flags;
823 }
824 if (isAnyRGB(dstFormat) && !(flags&SWS_FULL_CHR_H_INT)) c->chrDstHSubSample=1;

So maybe the bad quality is caused by missing SWS_FULL_CHR_H_INT only.

All these really need a bit of documentation...

SWS_FULL_CHR_H_INT
SWS_FULL_CHR_H_INP
SWS_DIRECT_BGR
SWS_ACCURATE_RND
SWS_BITEXACT

ffdshow's is both faster and multithreaded. Close to free with this CPU, even with 1080p60 content: 35-39%, against 33-37% YV12 output.

Also the idea of calling swscale for each frame in parallel is nice.

[nevcairiel]

Both SWS_FULL_CHR_H_INT and SWS_ACCURATE_RND are needed for it to look good. I started with SWS_FULL_CHR_H_INT at first, because it looked promising from the code, and it did improve it somewhat, but not nearly to the final result we have now.

Like i said, if i ever feel like hacking on YUV->RGB assembly code one day, its certainly a possibility to get something similar to ffdshows converter implemented. But its something for another day (and something that i personally wouldn't use, which gives it a somewhat lower priority)

The LAVPixFmtConverter class is however pretty straight forward, and it shouldn't be too much trouble to implement a new converter, if someone would want to do that. ;)
Another option would of course be to check how the YV12 -> RGB "special" converter in swscale works, and why it is doing such a crappy job. (it hides in libswscale/x86/yuv2rgb_template.c - yuv420_rgb32, looks like point scaling)

[Mercury_22]

Is there a way to make LAVSplitter override the default audio track (in a mkv file) and select, by default, the "better" audio (for the same language) e.g. select AC3 5.1 eng over AAC stereo (default) eng ?

[nevcairiel]

No, default is stronger then codec features.
This may be possible in the future when i implement the new selection magic.

[SamuriHL]

Nev, I posted a new thread on J River's forum. Getting a crash in LAVVideo.ax when trying to play MKV's. As I was typing this I decided to try it in MPC-HC with the same setup. Same crash. So I don't know what's happening there. madVR, LAV Splitter, LAV Audio, LAV Video. Blu-ray rip to MKV...all of them that I've tried recently. Let me know if you need me to do anything. Here's the line it's crashing on:


> LAVVideo.ax!CBaseOutputPin::CBaseOutputPin(const wchar_t * pObjectName, CBaseFilter * pFilter, CCritSec * pLock, HRESULT * phr, const wchar_t * pName) Line 2465 + 0x23 bytes C++

Seems bad. :)

[nevcairiel]

Thats not the line its crashing on, thats just the line it claims its crashing on.
It sometimes gets confused when crashing inside ffmpeg functions.

[SamuriHL]

Ok. I attached the debugger to it in hopes of providing you some useful info. Clearly I was mistaken. Any thoughts on what might be causing this crash? It happens on both my laptop and my desktop. I can't use LAV Video at all right now. It's been like that for me for a while now and I just now got around to trying to figure it out. If I switch to another video decoder it works fine.

[nevcairiel]

I get no crashes at all.
Default configuration?

Try my build
http://files.1f0.de/lavf/LAVFilters-0.32-rc3.zip

Someone else reported some crashes earlier, and it was caused by not having a updated ffmpeg in their build, or a broken build environment.

[SamuriHL]

Your build works. UGH. Do I even want to know why my builds are causing fatal crashes? sigh.

[nevcairiel]

Just install a clean MSYS, that solved it the last time.

Thats the one i'm using for building:
http://xhmikosr.1f0.de/tools/MSYS_MinGW_GCC_461_x86-x64_Full.7z

[SamuriHL]

I was still using 4.5.2 if that makes any difference. Also I have the VS 2010 SP1 security update that was just released installed. Wonder if that's related at all. I'll try your MSYS and see what happens. Thanks!

[Thunderbolt8]

I get no crashes at all.
Default configuration?

Try my build
http://files.1f0.de/lavf/LAVFilters-0.32-rc3.zip

Someone else reported some crashes earlier, and it was caused by not having a updated ffmpeg in their build, or a broken build environment.that one works for me as well (at least for AVC), the other nightly build didnt.

is interlaced VC-1 not supported yet by LAV Video? dont seem to get a picture.

[nevcairiel]

No, interlaced VC-1 does not work (and it'll be quite a while until it does)

[Thunderbolt8]

are there PQ wise any advantages to use LAV Video over CoreAVC or mpeg2 Dscaler mod?

[SamuriHL]

Nev, I think I see what happened. It's been a while since I built clean and you changed the names of the output dll's. I've updated the install builder script to deal with that, as well. I'll go attach a new version to the issue tracker.

EDIT: Unfortunately that didn't fix the crash. :( Even using your MSYS version my build crashes. Anyone want to bet that the VS 2010 security update is causing this problem? SIGH! Thank you, MS....thanks a lot.

[nevcairiel]

Anyone want to bet that the VS 2010 security update is causing this problem? SIGH! Thank you, MS....thanks a lot.
Highly unlikely, i dont even use those parts of the MFC that the patch updated.

[SamuriHL]

Highly unlikely, i dont even use those parts of the MFC that the patch updated.

SIGH. Well, I'm reapplying VS2010 SP1 now anyway. I guess the next step would be to dump the local rep on my hard drive and pull clean. Maybe something got corrupted. I'd like to get this resolved, though, as it's frustrating and I really like using LAV Video as my decoder of choice. (VC-1 interlaced not-withstanding, of course).

[CruNcher]

are there PQ wise any advantages to use LAV Video over CoreAVC or mpeg2 Dscaler mod?

Jep Deinterlacing is correct for Mpeg-2 Studio 4:2:2 in combination with Lav Splitter before only Lav Splitter + Mainconcept did it right in 1 EBU case 1080 50i with Nvidias Pixel Adaptive Deinterlacer via VMR9 ffdshow and dscaler both fail (though it's crazy hard noticeable visually in motion you see slight gray ghosting around edges very faint though it makes motion unfluid colors also seem to shift in certain motion scenes from objects) also the output of ffdshow (libavcodec,libmpeg2) differs from dscaler in this test case different field selection, in the end you get 3 different results :D from which all show the above issue only Mainconcept didn't and now Lav Video also as it looks like the Mainconcept result.

Certainly non of these issues with Lav Splitter->Lav Video->VMR9 on Nvidia (Motion absolute fluid like with Mainconcepts Decoder non of the strange ghosting especially visible @ moving edges in front of red,blue chroma backgrounds ) :)

VS CoreAVC their shouldn't be or it is flawed vs dscaler not sure didn't looked @ PQ yet (though the difference should be marginal in the area of idct differences) only this 1 specific Deinterlace issue ;)

[SamuriHL]

ARGH! I failed to copy them to my MC16 dir so yes, it was crashing on the old dll's still. I can't win today. My build with your new MSYS is working fine, Nev. Sorry for the idiot confusion. All is well in SamuriHL land today. Really. cough cough. :D

[SamuriHL]

http://www.mediafire.com/file/7opwuy9xqc89dt9/LAVFilters-0.32-RC3.exe

The latest WORKING :rolleyes: installer. Sorry about the issues for anyone that used my previous installers. Thanks, Nev, for helping me sort that nonsense out. A warning to others...Nev has changed the name of the output dll's to include a -lav in the name. If you have old ones kicking around, you'll wanna remove them and replace them with the new dll's.

P.S. I will be avoiding that issue from now on as I use this neat little script after I do a build:



@ECHO OFF

@SET ISCC="c:\Program Files (x86)\Inno Setup 5\ISCC.exe"

cd /d c:\dev\projects\LAVFSplitter

@echo [Building distribution]
@%ISCC% LAVFilters_SamuriHL.iss
xcopy LAVFilters-*.exe c:\users\samuri\downloads\video /Y
del LAVFilters-*.exe

ECHO ___________________________________
ECHO *****Updating distribution dir*****
ECHO -----------------------------------

set DEST="c:\users\samuri\downloads\video\LAVFilters"

del %DEST%\*.dll
del %DEST%\*.ax
xcopy bin_Win32\*.dll %DEST% /Y
xcopy bin_Win32\*.ax %DEST% /Y
xcopy README.txt %DEST% /Y
xcopy COPYING %DEST% /Y
xcopy CHANGELOG.txt %DEST% /Y

ECHO ____________________________________
ECHO *****Updating MC16 private copy*****
ECHO ------------------------------------

set DEST="C:\Users\Samuri\AppData\Roaming\J River\Media Center 16\Plugins\lav"

del %DEST%\*.dll
del %DEST%\*.ax
xcopy bin_Win32\*.dll %DEST% /Y
xcopy bin_Win32\*.ax %DEST% /Y
xcopy README.txt %DEST% /Y
xcopy COPYING %DEST% /Y
xcopy CHANGELOG.txt %DEST% /Y

PAUSE


:D

[Thunderbolt8]

Jep Deinterlacing is correct for Mpeg-2 Studio 4:2:2 in combination with Lav Splitter before only Lav Splitter + Mainconcept did it right in 1 EBU case 1080 50i with Nvidias Pixel Adaptive Deinterlacer via VMR9 ffdshow and dscaler both fail (though it's crazy hard noticeable visually in motion you see slight gray ghosting around edges very faint though it makes motion unfluid colors also seem to shift in certain motion scenes from objects) also the output of ffdshow (libavcodec,libmpeg2) differs from dscaler in this test case different field selection, in the end you get 3 different results :D from which all show the above issue only Mainconcept didn't and now Lav Video also as it looks like the Mainconcept result.

Certainly non of these issues with Lav Splitter->Lav Video->VMR9 on Nvidia (Motion absolute fluid like with Mainconcepts Decoder non of the strange ghosting especially visible @ moving edges in front of red,blue chroma backgrounds ) :)

VS CoreAVC their shouldn't be or it is flawed vs dscaler not sure didn't looked @ PQ yet (though the difference should be marginal in the area of idct differences) only this 1 specific Deinterlace issue ;)dscaler deinterlacing looked always a bit strange and broken to me, didnt provide good results. so I have always used either yadif or the ffmpeg deinterlacer

[STaRGaZeR]

Both SWS_FULL_CHR_H_INT and SWS_ACCURATE_RND are needed for it to look good. I started with SWS_FULL_CHR_H_INT at first, because it looked promising from the code, and it did improve it somewhat, but not nearly to the final result we have now.

Like i said, if i ever feel like hacking on YUV->RGB assembly code one day, its certainly a possibility to get something similar to ffdshows converter implemented. But its something for another day (and something that i personally wouldn't use, which gives it a somewhat lower priority)

The LAVPixFmtConverter class is however pretty straight forward, and it shouldn't be too much trouble to implement a new converter, if someone would want to do that. ;)
Another option would of course be to check how the YV12 -> RGB "special" converter in swscale works, and why it is doing such a crappy job. (it hides in libswscale/x86/yuv2rgb_template.c - yuv420_rgb32, looks like point scaling)

Indeed, SWS_ACCURATE_RND is what disables the so called optimized path. Unfortunately is all in assembly, and I don't understand it. ffdshow's is also written with intrinsics, more of the same. It should be fairly easy to port it to LAV (or take ideas from it) if you don't want to write a new one from scratch. It's all in ffdshow_converters.cpp