|
|
樓主 |
發表於 2011-9-5 11:27:08
|
顯示全部樓層
更新至LAV Filters 0.34
這次的更新算是蠻重要的,所以再來介紹一下~
重點是LAV Video Decoder改進不少~
速度快了不少,使用Hi10P的影片測試便知~
還是要稱讚一下LAV系列解碼器的作者nevcairiel實在太厲害啦^^
LAV Video
- New optimized pixel format converters (faster and more accurate)
- New YUV->RGB converter
- Support for PNG video
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.
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. |
|
[複製連結]
狗仔卡
發表於 2011-8-19 14:21:00
