头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: 【置頂】 LAV Filters 【0.54.1-git-r2468(237f0dd)】

2012-11-29 23:22

如果我說過要修改RGB輸入時的輸出邏輯
然後我沒修改
這當然是我的問題

如果我說過要修改RGB輸入時的輸出邏輯
然後我沒修改
我做錯啥了?

您現在就像個幼稚園的小朋友一樣,阿姨和你說來來給你糖吃,然後您在那兒大叫為什麼不給我蛋糕不是說了要給我蛋糕的麼

輸入10bit的YUV(輸入時這東西不叫P010叫yuv420p10,同樣輸入16bit yuv444叫做yuv444p16不叫Y416,請自己查區別)會修改輸出邏輯,因為它是YUV,和RGB有什麼關係?就算是RGB輸入,按您說的輸出還是RGB,這裡還是沒有錯誤,只是用不用dither的問題,和輸出邏輯又有啥關係?就我個人而言把RGB輸入轉成yuv再輸出,到時候交給渲染器dither回RGB才是搞笑的邏輯,要實現也應該是直接實現16bit RGB到8bit RGB的dither代碼才對…

LAVF內的pix_fmt轉換只要可能(有完成自己的轉換代碼的話),根本就不走FFmpeg,都是解碼輸出之後LAVF自己的pix fmt converter來做。FFmpeg那個sws是人用的麼…

前面已經說了,LAVF內部的pix_fmt轉換輸入RGB時只能接受8bit,更高的bit depth根本就沒有寫,如果需要請向nev提需求把它完成,不是修改輸出邏輯就能解決的
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

yangzhezhen
帖子: 20
注册时间: 2012-03-07 10:49

Re: LAV Filters【23/05/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-05-24 23:41

有个问题。

只选择DXVA2(native)硬解,第2硬解为无的情况。且只有SD实现DXVA2解码。
根据分辨率选择是否激活特定分辨率HW模式实现反而有点麻烦了。

比如说实现480P native硬解 720P以上软解。
按照逻辑就是,勾上 native,第2硬解选择 无。分辨率那边只勾上SD。
但就目前的情况,无法直接实现。要绕道。。
第2硬解不能直接选择无,否则在native这边无法实现只有SD硬解。

要选择可以运行的模式的(根据你电脑装备的显卡而定),把分辨率选项激活然后才可调整。。。
如,我的情况,因为是N卡,选择到CUID下面,调整右边的分辨率选项,只勾上SD。然后调整回NONE。完成。
实现只有SD硬解。HD以上软解。但操作繁琐了。

头像
Billy Herrington
帖子: 83
注册时间: 2013-01-09 9:54

Re: LAV Filters【24/05/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-05-25 2:47

Seems fixed in the updated version 0.57-2.

fch1993
帖子: 213
注册时间: 2012-06-12 11:56

Re: LAV Filters【24/05/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-05-25 19:56

MADVR最新版支持DXVA 2 native 我在播放30i视频的时候,LAV在我开启DXVA 2 native之后并没有走DXVA 2 native解码输入MADVR,之后madvr做deint,而是LAV使用CUVID做deint后输入MADVR。
24p的时候又调用DXVA 2 native了,好奇怪。
不懂这个是什么机制。按理说DXVA2不会说失败啊。

头像
hλlframe
帖子: 1
注册时间: 2013-04-14 13:36

Re: LAV Filters【23/06/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-06-29 20:19

解压版的对比原版少了个 LAVFilters.Dependencies.manifest 文件,貌似是0.58新加的
LAV Filters now includes a manifest file to control DLL loading

mingwang
帖子: 6
注册时间: 2013-07-21 14:43

Re: LAV Filters【06/07/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-07-21 14:47

06_taro阁下,为什么LAV官方没有采用你的输出color space优先顺序呢?

头像
Billy Herrington
帖子: 83
注册时间: 2013-01-09 9:54

Re: LAV Filters【06/07/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-07-21 20:18

NV12 is widely supported by video renderers, and is preferred for many hardware post-processers which are usually used in branded renderers, e.g. VMR, EVR, etc.. RGB32 is also widely used, but normally not for post-processing, so many renderer still need to convert RGB32 to NV12 internally, and convert it back after processing. Even madVR's DXVA2 functions (deint, resize) use the same method.

NV12 needs 12-bit data per one pixel on average while RGB32 needs 32-bit ( even P010 does not uses that many. I didn't review the spec, but it is likely that P010 uses padded 16-bit for luma, and 8-bit for chroma, thus totally 24-bit ), so RGB32 graph chain is sometimes unendurablely slow for legacy hardwares with some dshow filters (even if they are heavily optimized for memory copy or share).

If one is not keen on video quality ( actually the visual difference between properly dithered RGB32 and NV12 is usually not noticeable ), one should always use NV12 instead of RGB32 if P010 is not available.

mingwang
帖子: 6
注册时间: 2013-07-21 14:43

Re: LAV Filters【06/07/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-07-22 9:13

Billy Herrington 写了:NV12 is widely supported by video renderers, and is preferred for many hardware post-processers which are usually used in branded renderers, e.g. VMR, EVR, etc.. RGB32 is also widely used, but normally not for post-processing, so many renderer still need to convert RGB32 to NV12 internally, and convert it back after processing. Even madVR's DXVA2 functions (deint, resize) use the same method.

NV12 needs 12-bit data per one pixel on average while RGB32 needs 32-bit ( even P010 does not uses that many. I didn't review the spec, but it is likely that P010 uses padded 16-bit for luma, and 8-bit for chroma, thus totally 24-bit ), so RGB32 graph chain is sometimes unendurablely slow for legacy hardwares with some dshow filters (even if they are heavily optimized for memory copy or share).

If one is not keen on video quality ( actually the visual difference between properly dithered RGB32 and NV12 is usually not noticeable ), one should always use NV12 instead of RGB32 if P010 is not available.
英语不行,用谷歌直译了一下。
既然看不出什么明显的区别,而且NV12还能后处理,那我就更不明白为什么要更改输入优先顺序了。

头像
Billy Herrington
帖子: 83
注册时间: 2013-01-09 9:54

Re: LAV Filters【06/07/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-07-22 19:18

Someone claims they can tell the difference between RGB32 and NV12, and believes in one's eyes with which RGB32 gives a better illusion than NV12. And one is "keen on video quality". So here it goes.

Anyway, it is easy to disable RGB32 output in you settings and you won't bother any more as there are too few RGB videos in reality, then in most cases nothing regarding colorspace order will be different from official one. But if you'd like to make official build to this original->rgb32->nv12 order for both 10-bit and 8-bit, I don't think it is possible without tweaking between different sources.

leaies
帖子: 7
注册时间: 2013-06-28 12:24

Re: LAV Filters【06/07/13 支持DXVA2(native)->其他HW->SW的轮询】

2013-07-24 16:26

mingwang 写了:
Billy Herrington 写了:NV12 is widely supported by video renderers, and is preferred for many hardware post-processers which are usually used in branded renderers, e.g. VMR, EVR, etc.. RGB32 is also widely used, but normally not for post-processing, so many renderer still need to convert RGB32 to NV12 internally, and convert it back after processing. Even madVR's DXVA2 functions (deint, resize) use the same method.

NV12 needs 12-bit data per one pixel on average while RGB32 needs 32-bit ( even P010 does not uses that many. I didn't review the spec, but it is likely that P010 uses padded 16-bit for luma, and 8-bit for chroma, thus totally 24-bit ), so RGB32 graph chain is sometimes unendurablely slow for legacy hardwares with some dshow filters (even if they are heavily optimized for memory copy or share).

If one is not keen on video quality ( actually the visual difference between properly dithered RGB32 and NV12 is usually not noticeable ), one should always use NV12 instead of RGB32 if P010 is not available.
英语不行,用谷歌直译了一下。
既然看不出什么明显的区别,而且NV12还能后处理,那我就更不明白为什么要更改输入优先顺序了。
额...你搞错他的意思了吧?-.-;;
简单大意来说在肉眼【直接观看】的前题底下,高色域和低色域不会有如此大的差距、甚至显示器本身也不一定能表现出那差异(尽管很多都会标榜自己高清什么的)。既然看不出那么多的差异那为了追求更多的速度,我们理当要去选择低画质、低色域、低分辨率...。(这同时也会是LAV Filters的本质)但反过来说假如你今天目的并不是为了【直接观看】例如后制、转档、截图、挂滤镜、自HIGH、享受高清等,那我们应该就要选择高画质、高分辨率这些以确保在后期运算时可以得到更精确的结果...也就是一般俗称的更好的画面。至于后制那自然都可以后制主要就看你软件的支持如何,不支持NV12的也有...说不定还更多点?

回到 “解码 播放 字幕 / Decoder playback and subtitles”