H264+10bit的片子你们怎么处理的？

金子一马

盒子基本都放不了这种片子，而高质量的片源这种还特别多，我也不知道为什么会那么流行。

我试着自己转成H265 10bit，但是笔记本电脑一集就要压一整天实在受不了了。请问大家都是怎么处理的？

404489039

一般都会有双版本吧？不行就手机投屏

金子一马

404489039 发表于 2019-2-8 22:38
一般都会有双版本吧？不行就手机投屏

老片很多没有

mooerfoes

将就看吧……毕竟我自己压片能力太差，越压越烂，还不如干脆看完了事

typeunknown

压个牺牲画质的h264+8bit凑合看，10bit的留着等以后洗

元肉丸子

用pc解码就好了。
前几年高清动画基本都是这么压制的，因为画面效果好

hamartia

只能跳过

我的动画鉴赏全是在平板上完成的，即使压制得再清楚，在便携设备上解析不了就是抱着金砖挨饿

liwangli1983

只能说现在盒子cpu都是四小核太弱了，要不820这样的软解都没问题。要么htpc，要不加钱上shield tv，tegra x1有风扇有直流电加持（不用降频）的情况下应该问题不大

hac0101

体积的话相比265差了很多，但画质依然是最好的。

  -- 来自 能手机投票的 Stage1官方 Android客户端

112zero

刻盘，放蓝光机看

Mostovoi

安卓盒子装mxplayer，能软解

zmw_831110

Aml logic的4核A53是不够打的，其实8核A53(但主频不能低，比如aml logic的那个8核也不行，主频太低)就可以了，或者有A72级别的大核，比如小米盒子3增强版4个A53加2个A72，不是码率特别变态的H.264 10bit都可以轻松软解。

当然，我现在选择电脑加AFM MADVR连电视机看

17年时候最便宜的盒子解决方案就是小米盒子3增强(当然还有一款超低端的rk3229支持 H.264 10bit硬解，不过因为cpu太差，只能支持720p的UI)，遇见码率变态的，记得给盒子底部加个风扇，买个架子，底部装个12cm机箱扇子就可以了，当时我发过帖子
https://bbs.saraba1st.com/2b/thread-1496801-1-1.html
现在rk3399的盒子也许有便宜点的了吧，支持硬解。

—— 来自 HMD Global Nokia 7 plus, Android 8.1.0上的 S1Next-鹅版 v2.1.2

vxzms

10bit比8bit优势很大，当时HEVC对比AVC优势还不够大，为了画质只能使用AVC-10bit

画质的追求本来就是建立PC上的，而不是盒子、平板这些设备，外挂（特效）字幕在这些设备上的播放也不太方便，想看这种估计只有HTPC可破（或者洗版换片源，千万别二压

alvin051414

vxzms 发表于 2019-2-9 07:51
10bit比8bit优势很大，当时HEVC对比AVC优势还不够大，为了画质只能使用AVC-10bit

画质的追求本来就是建立P ...

10bit 264广泛使用比265定标要早上2年…哪来的优势不大，关公战秦琼么…

被子十三

说起来蓝光原盘的灰阶是多少？也是10bit吗，还是更高？

187san

不知道有没有用草莓派之类转编码的方案，有的话，弄个NAS挂着慢慢转。

liwangli1983

九味小吃 发表于 2019-2-9 07:08
为什么这么流行？因为画质好啊，而且h264 10bit压制普及的时候盒子还没普及呢，人家就不是给什么盒子准备的 ...

并不是画质好，只是有利于压缩算法，可以在画质不变的情况下降低压缩后体积而已，对于动画效果尤其明显，所以只有动画压片这块大规模在用，而且当时也不用考虑啥移动设备的需求

—— 来自 OnePlus ONEPLUS A3000, Android 8.0.0上的 S1Next-鹅版 v2.1.0-play

烈之斩

被子十三 发表于 2019-2-8 20:38
说起来蓝光原盘的灰阶是多少？也是10bit吗，还是更高？

没记错的话只有HDR会有10bit（或者更高？），一般的还是8bit


（非专家）

BallanceHZ

这玩意果子可以硬解

Wuyi无疑

想来做mad的时候最不想看到的就是10bit  不过只有10bit的源有速度的时候，也只能下载下来转了。
有乌龟做的小工具，转的挺快的

ReginaldMorgan

在本地看

password

liwangli1983 发表于 2019-2-9 10:04
并不是画质好，只是有利于压缩算法，可以在画质不变的情况下降低压缩后体积而已，对于动画效果尤其明显， ...

不只是体积缩小 10bit对改善Banding现象有明显效果

响鬼

直接电脑HDMI连过去不是最快？

萼绿华

HTPC大法好，我年前新买了电视，然后照着这贴的配置刚配了一台，现在美滋滋：
https://bbs.saraba1st.com/2b/thread-1786049-1-1.html
上车吧！

vxzms

alvin051414 发表于 2019-2-9 09:06
10bit 264广泛使用比265定标要早上2年…哪来的优势不大，关公战秦琼么… ...

可能是我语文太烂，10bit比8bit效果好所以决定用10bit。在hevc出现后，对比avc没显著优势的情况下大家还是继续使用avc-10bit(13-17年期间不断有实验性的作品)，直到16-17年才开始大幅度转向hevc-10bit。在hevc没出现的那段时间当然都是avc-10bit啊。

lixianfyss

zmw_831110 发表于 2019-2-9 07:16
Aml logic的4核A53是不够打的，其实8核A53(但主频不能低，比如aml logic的那个8核也不行，主频太低)就可以 ...

请问AFM如何处理10bit？现在片源都是10bit，跟直接用madvr差别很大，亮部细节损失惨重。

187san

cybernetics 发表于 2019-2-9 23:29
效果不好，时间成本上不如直接下8bit来的划算

对于我的场景是有意义的。我有个NAS，屯了一些片，也不急着看。要是有嵌入式的设备能够在后台慢慢转到HEVC，盒子放起来不会遇到兼容性问题。我没有时间上的要求。

被子十三

烈之斩 发表于 2019-2-9 10:25
没记错的话只有HDR会有10bit（或者更高？），一般的还是8bit

啊，搜了搜，原来10bit压制的原因是为了减少压制带来的画质损失…一直疑惑如果源视频是8bit的话10bit压制意义何在

— from OnePlus ONEPLUS A6013, Android 9 of S1 Next Goose v2.1.0-play

zmw_831110

lixianfyss 发表于 2019-2-10 12:33
请问AFM如何处理10bit？现在片源都是10bit，跟直接用madvr差别很大，亮部细节损失惨重。 ...

AFM是实时压片插帧,直接压成8bit给你
不过我感觉画质的损失,不去AB的话,根本在意不到
可以AMF+madvr
不过madvr的压力会比较大,因为AFM是放在madvr前面的,所以原本渲染24帧,变成渲染60帧了,设置参数的时候,要记得ctrl+J,观看是否因为性能不够,导致丢帧(drop)或者重复帧(repeat),这2个,会非常影响AFM的效果.
我自己有做一个脚本配置,针对不同的分辨率,采取不同的madvr upscaling.

1. 
   
2. if (srcWidth < 1280) and (srcHeight < 720) and (deintFps < 31)
   
3. "SD"
   
4. 
   
5. else if (srcWidth < 1280) and (srcHeight < 720)
   
6. "SD_60FPS"
   
7. 
   
8. else if ((srcWidth = 1280) or (srcHeight = 720)) and (deintFps < 31)
   
9. "720P"
   
10. 
    
11. else if (srcWidth = 1280) or (srcHeight = 720)
    
12. "720P_60FPS"
    
13. 
    
14. else if ((srcWidth <= 1920) or (srcHeight <= 1080)) and (deintFps < 31)
    
15. "FHD"
    
16. 
    
17. else if ((srcWidth <= 1920) or (srcHeight <= 1080))
    
18. "FHD_60FPS"
    
19. 
    
20. else if (deintFps < 31)
    
21. "QHD"
    
22. 
    
23. else
    
24. "QHD_60FPS"
    

复制代码

所有档位都分"低于31FPS"和"高于31FPS"两种

"SD":横向没有1280或者纵向没有720,涵盖了所有非标清的分辨率
"720P":横向=1280或者纵向=720的,涵盖所有市面上标720P的视频(电影一般是横向1280叫720P,4:3动画横向720叫720P)
"FHD"
"QHD"

cloudliu

1080p x264 10bit 需要2g a72/a73了 我家1.5g a72x4不够

偶滴小乔

上htpc……前几年买了个i3 5005u的无风扇小主机，兼下载机，反正电视机放着卡的就换这机器看

lixianfyss

zmw_831110 发表于 2019-2-11 08:54
AFM是实时压片插帧,直接压成8bit给你
不过我感觉画质的损失,不去AB的话,根本在意不到
可以AMF+madvr

分辨率倒是没啥，madVR只能识别源帧率，我之前想设置插过帧的用低处理但是没法区分。
今天才发现AFM只能接受NV12输入，RGB都不认，LAV也没有识别功能，只好用FFDSHOW处理10bit电影。

zmw_831110

lixianfyss 发表于 2019-2-11 09:34
分辨率倒是没啥，madVR只能识别源帧率，我之前想设置插过帧的用低处理但是没法区分。
今天才发现AFM只能 ...

我那个madvr配置脚本里已经区分了分辨率和帧频了.你仔细看看我给的代码啊.
SD,SD_60FPS这类的,60FPS都有单独区分出来.

zmw_831110

cloudliu 发表于 2019-2-11 09:00
1080p x264 10bit 需要2g a72/a73了 我家1.5g a72x4不够

码率高的1080P H.264 10bit是挺吃主频的
下面是17年,买小米盒子3增强版时候测试的.
A53 1.5G x4+ A72 2.0G x2
大核降频的话,就开始丢帧了,所以,最后我给盒子底部加了风扇,就不降频了.

H.264 10Bit 平均6.6MB/S码率的视频.动态码率应该不低.
反正这玩意,之前S905 S905X S912都是跪
测试视频如下:
Complete name               [CASO&SumiSora][Date_A_Live][DC_BDBOX][BDRip]\[CASO&SumiSora][Date_A_Live][DC_BDBOX][BDRip][01][x264_flac](73F2BD91).mkv
Format                         : Matroska
Format version                 : Version 4 / Version 2
File size                      : 1.30 GiB
Duration                       : 27 min 45 s
Overall bit rate mode          : Variable
Overall bit rate               : 6 697 kb/s
Encoded date                   : UTC 2015-08-12 13:57:00
Writing application            : mkvmerge v8.1.0 ('Psychedelic Postcard') 64bit
Writing library                : libebml v1.3.1 + libmatroska v1.4.2

Video
ID                             : 1
Format                         : AVC
Format/Info                    : Advanced Video Codec
Format profile                 : High 10@L5
Format settings, CABAC         : Yes
Format settings, ReFrames      : 8 frames
Codec ID                       : V_MPEG4/ISO/AVC
Duration                       : 27 min 45 s
Bit rate                       : 5 609 kb/s
Width                          : 1 920 pixels
Height                         : 1 080 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 23.976 (24000/1001) FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 10 bits
Scan type                      : Progressive
Bits/(Pixel*Frame)             : 0.113
Stream size                    : 1.09 GiB (84%)
Writing library                : x264 core 142 r2431+42 c69a006 tMod [10-bit@4:2:0 X86_64]
Encoding settings              : cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=0.60:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=1 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=17.5000 / qcomp=0.60 / qpmin=0:0:0 / qpmax=81:81:81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 / aq-sensitivity=10.00 / aq-factor=1.00:1.00:1.00 / aq2=0 / aq3=0
Language                       : Japanese
Default                        : Yes
Forced                         : No

Audio
ID                             : 2
Format                         : FLAC
Format/Info                    : Free Lossless Audio Codec
Codec ID                       : A_FLAC
Duration                       : 27 min 45 s
Bit rate mode                  : Variable
Bit rate                       : 1 087 kb/s
Channel(s)                     : 2 channels
Channel positions              : Front: L R
Sampling rate                  : 48.0 kHz
Frame rate                     : 11.719 FPS (4096 spf)
Bit depth                      : 24 bits
Detected bit depth             : 20 bits
Stream size                    : 216 MiB (16%)
Writing library                : libFLAC 1.2.1 (UTC 2007-09-17)
Language                       : Japanese
Default                        : Yes
Forced                         : No

一开始,好生猛,火力全开


稍不留神,大核痿了...


摸了一下,盒子顶盖有点热,正好在飘窗上,就把盒子倒过来放


大核又活了


然后在发这个帖子的时候,我切回去看,CPU TEMP挂了,233

烈之斩

被子十三 发表于 2019-2-10 16:03
啊，搜了搜，原来10bit压制的原因是为了减少压制带来的画质损失…一直疑惑如果源视频是8bit的话10bit压制 ...

个人理解是如果目标是纯transparent encoding（就是完全不作处理以还原原始画质为准）的话，10bit去压制8bit的源并不会有多大影响（但是也并不会增大多少体积）；

但是如果用了一些filter尤其是debanding filter的话会对banding有较为明显的改善，在动画中影响比较大。