V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ungrown  ›  全部回复第 52 页 / 共 90 页
回复总数  1794
1 ... 48  49  50  51  52  53  54  55  56  57 ... 90  
2020-08-27 11:58:45 +08:00
回复了 Aoerz 创建的主题 Apple 大家伙,看一下这个电池使用正常吗?
你屏幕开着掉电再快都不奇怪,液晶屏是耗电大户,其他啥都比不过
2020-08-27 11:58:10 +08:00
回复了 Aoerz 创建的主题 Apple 大家伙,看一下这个电池使用正常吗?
@littlewing 视频类软件的播放界面在前台,你还指望会系统自动息屏吗
2020-08-27 11:56:52 +08:00
回复了 EdmondYoung 创建的主题 生活 怎样才能不做一颗韭菜,觉得活着好难没有意义
拟态
2020-08-27 11:50:58 +08:00
回复了 keyfunc 创建的主题 宽带症候群 现阶段千兆网口的 wifi6 路由器有什么意义吗?
首先信号衰减非常快的
其次 WiFi 是半双工信道
实际情况单向一半的速度都跑不到
2020-08-27 09:20:44 +08:00
回复了 RtIHZ 创建的主题 奇思妙想 可能是一种“获得对自己长的好不好看的客观评价”的方法
要命了,“美”是个纯主观域的概念,那真的是一丁点客观域的杂志都不夹带的

这咋整?
2020-08-27 09:18:56 +08:00
回复了 Mindjet 创建的主题 奇思妙想 多语言编程的设想:将变量名与自然语言解耦
总觉得你这文不对题,想了想,这不是与自然语言解耦,而是和特定的自然语言(英文)解耦,或者就直观点叫做省却为变量命名找单词的过程

Python 支持 Unicode 变量名,写 Python 完全可以直接用。中文编程阻碍重重不是语言本身的问题,是输入法在从中作梗:英文变量直接敲字母就能补全,中文还得切换输入法至少打出一个汉字才行,这能忍?

其实也有折衷思路,变量以汉语拼音首字母组合开头,后接中文文本,ide 里面直接根据声母敲键盘就能自动补全了。

但还是不如全英文敲起来便捷。
2020-08-27 09:07:46 +08:00
回复了 oatw 创建的主题 职场话题 讲真的,受不了开放式办公
耳机 x
耳罩 √
任何参数调整都是在速度、体积、画质三者之间取舍,而这三者从来不可兼顾,最终也是按需选取一个并不平衡的“平衡点”。
默认参数正是那个三者正中间、最平衡、但反而不一定符合某些需求和场景的点,但默认参数的结果也自然成为整个参数空间函数输出值域的一个基准点,手动调参后在速度、体积、画质上呈现出来的变动都将以默认参数为中点辐射开来。
而 hevc 和 avc 的区别是系统性的而非局部的,它们默认参数的导致的结果本身就是是两个相距甚远的平衡点,它们进行调参后各自辐射开来的值域空间也将各自独立,也许会有部分相交,但不相交的部分才是大头。
最直观的,再怎么调参也不会缩小速度上的差别,再怎么调参也不会让 hevc 在小色块上的涂抹感降低到 avc 的水平。这就是系统差异。

至于逐帧逐像素对比这件事,如果你非要将理论验证和技术迭代过程中所采用的实验方法与评判标准,来强行替代日常使用中人们所依赖的视觉感官体验和重整体轻细节的取舍策略,并且还恬不知耻地指望别人在看到你这些脱离应用场景、偏离讨论重点、单纯否定却无法给出替代方案且毫无建设性的发言后,居然不会将之看作捣乱、挑衅、思维干扰和思想攻击,那你要么摘下道貌岸然的面具放声嘶吼,要么把面具戴好默不作声维持住这好不容易经营起来的伪装。

综上,结论有没有意义我不知道,讨论其意义本身才是意义,数据是实打实的价值,有表可查是莫大的幸福。至于悟,我悟不悟我不知道,也没人能自己说自己悟的这没法证伪,你在猪鼻子插葱,装悟,这倒是能切实体会出来。
@imn1 #73 用的哪种格式?兼容 kodi 吗?
@EasyProgramming #70 你点我 ID 进主题找呗,反正帖子原样保留。
@imn1 #66 懂的懂的,就是想勾引你嘛,“来玩嘛~换换口味嘛~”
@imn1 #63 我现有的收藏,电视剧算它 50 季每季 12 集共 600 集就算它折合 200 部电影吧,再加上真的电影大约 300 部,一共 500 部长片。假设每部长片原盘 50G,一共 25T,如果用 4T 硬盘需要 7 个,6T 硬盘需要 5 个。
我现在能把这些收藏塞进半个 2T 的移动硬盘。
分享给别人的时候,硬盘对拷每部按秒计,走互联网比如奶牛快传按分钟计,这样的便捷性和便携性说不羡慕是假的。
@imn1 #63 如果是分辨率不超过 FHD 帧率不超过 60 的 8bit HEVC,问题不大。
哪怕两三年前的主流移动端芯片内置解码器基本都支持,现在的更不用说,客厅端更更不用说,低端产品都内置了基本的 hevc 硬解码,而桌面端就不存在这个问题了。
@ungrown #61 删就删呗,一个小众论坛还整文字狱各种杂七杂八的规矩,大不了我新建个小号呗。
@mikeven #59 没记错的 x265 是目前最好的 hevc 编码器?
我倒也没觉得有什么反常识,厂商再怎么吹牛一般也只承诺节省 20%~30%左右码率,夸张点的也无非是说“最多”可以节省一半。
低码率优势明显符合我的实验数据和结论的,低码率对应高 crf,你看表格里面高 crf 时是不是 hevc 优势很大嘛
@darer #26
@minami #7
我组合尝试了 ctu 和 sao 的参数

单纯禁用 sao 会丢失涂抹细节,码率和不禁用一样,但是画质变得稍微更差了

```python
In [29]: c.config_hevc(crf=19)
In [30]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error "o-0\2.mkv"
[h264 @ 000001fd7594f180] Increasing reorder buffer to 1
Out[30]: {'0': 0.226}

In [47]: c.config_hevc(crf=19,no_sao=1)
In [48]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:no-sao=1 "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:no-sao=1 "o-0\2.mkv"
[h264 @ 0000017a35d7f140] Increasing reorder buffer to 1
Out[48]: {'0': 0.222}
```

单纯调整 ctu 、cu 、tu 码率有略微上升,速度速度进一步降低,但是截图对比又看不出有保留更多细节,似乎和没调这些参数之前一样

```python
In [43]: c.config_hevc(crf=19,ctu=32,max_tu_size=4,min_cu_size=8)
In [44]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8 "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8 "o-0\2.mkv"
[h264 @ 0000022faaa9f1c0] Increasing reorder buffer to 1
Out[44]: {'0': 0.282}
```

然后我把这俩参数一起用,既调小块又禁用 sao,输出画质好像比默认参数时保留了更多的细节,好像有所改善,但又不明显,我也不知道是不是心理作用

```python
In [45]: c.config_hevc(crf=19,ctu=32,max_tu_size=4,min_cu_size=8,no_sao=1)
In [46]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8:no-sao=1 "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8:no-sao=1 "o-0\2.mkv"
[h264 @ 000001e7e3eaf1c0] Increasing reorder buffer to 1
Out[46]: {'0': 0.274}
```
@Dukewill #55 啊不,家里电影电视剧都是二压成不超过 720p 的 hevc 了,电影 crf=25,电视剧视情况 22~28 (有些年代久远的低分辨率文件得用 22 压不然全糊了),观感很好,体积很小(动作场景不多的电影压到 500M 以下,大点的基本在 800M 左右)
@minami #7 调了 ctu 、cu 、tu 的参数后,hevc 本身就已经很慢的速度又慢了几倍,2333
1 ... 48  49  50  51  52  53  54  55  56  57 ... 90  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5006 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 38ms · UTC 09:21 · PVG 17:21 · LAX 02:21 · JFK 05:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.