V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Licsber  ›  全部回复第 13 页 / 共 36 页
回复总数  702
1 ... 9  10  11  12  13  14  15  16  17  18 ... 36  
@Jooooooooo #2 非常认同您的看法!以我这个零零后的切身体会来看
但现在中小学生面临的压力已不比我当年
家里有孩子的家长,哪个不希望自己的小孩人中龙凤
现实是靠仅仅学习课本教材、义务教育知识,不加点自己的勤奋 /开窍(可能这个形容有点过)
估计考上普通高中都成问题,又怎么谈高考见分晓呢?
@pcbl #1 @vvxu27 #5 @mikewang #6 @angrylid #7 @dangyuluo #8 @chenyu8674 #9
已补充心路历程 在附言中 为之前的不理性、缺乏耐心道歉
2021-12-16 21:33:25 +08:00
回复了 Licsber 创建的主题 宽带症候群 个人收藏、归档视频 有比 HEVC 更好的编码方式吗?
@ynyounuo #13 谢谢 感觉还是我对 HEVC 的期望太高了
现在决定还是保留原始文件 + HEVC 二压用来快捷预览和网络分享
期待未来有创时代的技术可以解决画质细节和压缩率之间的 trade off

@mxT52CRuqR6o5 #14 只能期待过几年 av1 普及( HEVC 可是等了十年
2021-12-16 18:28:37 +08:00
回复了 Licsber 创建的主题 宽带症候群 个人收藏、归档视频 有比 HEVC 更好的编码方式吗?
@mxT52CRuqR6o5 #7 大厂自研的 av1 就没一个公开的 估计现阶段也拉垮
嗯 感觉各种字幕组在这方面经验很多 一些番剧都是压的很不错的

@amirobotics #8 白嫖 od 对我没啥用 不在本地的数据我都会加密 这就丧失了随时预览的能力

@Rheinmetal #9 还没到这种量级 虽然这是最好的归档方案了

@qq316107934 #10 哈哈 H.267 估计有生之年了 265 都花了十年 到那个时候硬盘应该不值几个钱了

@wy315700 #11 嗯 每次编码都会引入损失 想的是这个损失近可能小 只要收益超过付出成本就 ok
2021-12-16 17:38:39 +08:00
回复了 Licsber 创建的主题 宽带症候群 个人收藏、归档视频 有比 HEVC 更好的编码方式吗?
@mxT52CRuqR6o5 #4 感觉 av1 真的就是战未来了 完全没办法拿上来比
我这测试下来 上面的 HEVC 参数对于一些略有噪点的视频(比如老番)完全看不出来区别
但是对于真人皮肤细节就不太行 使用原始码率都会带一点涂抹感觉
要是现实视频也能有 waifu2x 这样的模型就好了 自动锐化补充高频细节
2021-12-16 17:33:04 +08:00
回复了 Licsber 创建的主题 宽带症候群 个人收藏、归档视频 有比 HEVC 更好的编码方式吗?
@msg7086 #3 也看到了文章说 储存原始视频是最好的 因为总有更好的编码方案
一路等下去哪里是个尽头呢(🐶
2021-12-16 16:18:40 +08:00
回复了 Licsber 创建的主题 宽带症候群 个人收藏、归档视频 有比 HEVC 更好的编码方式吗?
@cpstar #1 确实可以
但是还想要把各种奇怪格式都转成 mp4 比如 rmvb 、mkv
还有一些 QuickTime player 预览会卡顿的 mp4 都想要重新编码一下
@AoEiuV020 #7 我没设账单预警 跑了完整一个月收到账单才看到 已经联系客服退款了
@zyxk #32 群晖还不支持么 在 macOS 下威联通已经可以按需同步了 和 onedrive 几乎相似的使用体验
威联通 QSync 最新版( 5.0 以上)也支持
体验了半年 目前没出过什么大岔子
2021-09-25 10:17:05 +08:00
回复了 xlsepiphone 创建的主题 程序员 求帮忙斟酌推荐一下好用的开源对象存储方案
1. 单机部署还是集群部署?
2. 数据重要么 总容量大么 需要纠删码( EC )额外保证数据安全性么?
3. 数据总文件数多么 需要 SeaweedFS 合并的特性么?
2021-08-27 22:31:03 +08:00
回复了 tu8ge 创建的主题 程序员 请问如何做到每个用户一个独立的 raid1?
为什么会有这种奇怪的需求 你们机房都是可以让几百个用户随意进出的么
如果不行 那么需要将数据“打包带走”的时候 有一个专员准备俩空硬盘不就 ok ?
@abcbuzhiming #13 嗯 我一开始怀疑是千兆设备和百兆设备不能一起插交换机上 然后单独测试每个设备还是没用
就是上层那根网线莫名其妙给协商百兆 千兆速率无法协商 我拆墙看了 是一根带屏蔽和支撑的六类线
理论上这样的线短距离万兆都没有问题的 出问题的时候我换了好几个设备都没办法和它协商千兆
但是没问题的时候 任何设备插上去都可以有效协商 只能说是它的 bug 了 目前没找到修复方法
确实 验证下来 只要存在百兆设备 那么千兆设备就不能改成强制 1000M 全双工 不然根本无法通信
估计存在一种可以让千兆设备同时支持千兆和百兆通信的机制吧 没搜到这样的名词 期待有人能解释一下
@ThirdFlame #11 客户端手工改强制千兆取消协商的后果就是上不了网 我也很奇怪 但是千兆设备之间仍然可以通信
上不了网这个现象就像是强制千兆之后百兆设备无法和千兆设备通信一样 理论上大家都是发给的交换机 由它转发
但是据观察是不是存在一种机制 哪怕二层协商了千兆速率 在千兆设备和百兆设备通信时
是由千兆设备而不是交换机控制最终通信的速率 就是说 千兆设备只知道和交换机连接是千兆 然后以千兆速率发包
交换机转发过去却是以它和所有设备的握手速率给固定端口 /广播给所有端口 这就必然导致写满交换机缓存
然后这样一种机制使得千兆设备能发现这样的问题 进而降为百兆?
我也不太明白为什么强制千兆之后 和百兆设备就断连了 连 DHCP 信号都接不到
@felixcode #5 查了查没有关于这方面太多的叙述 意思就是实际上取决于上层么
比如 tcp 会按照自己的状态加速或者减速 哪怕用千兆速率发包
tcp 也会识别到丢包率极高(都被底层丢了)从而慢慢降低到底层极限(百兆速率)?
@jim9606 #3 协商速率仅限于两个物理接口之间 这点我已验证 提问的起因就是这个场景
我网络环境本来是千兆 最近不知道上层网关出了啥问题 总是周期性协商成百兆

指本地交换机之间千兆设备测速仍然是千兆 但是出口带宽成了百兆级别 排除了交换机、网线各种因素
直到直接将上层那根网线插到客户端才发现只会协商百兆 因此疑惑 按理说二层是没有什么类似四层的控制的
并且查到 网口协商只跟一层有关 也不存在什么特殊的数据帧 /特殊的电信号啥的可以重新开始协商过程
想要重新协商就只能触发接口事件 比如 ifdown ifup 之类的或者物理接口插拔

于是就很奇怪 遇到的现象是好好的千兆上网 突然断网十秒左右 之后一切正常 但上层的入口已经成了百兆
并且问题无法自主复现 上层直连的也不知道是一个路由还是三层交换 /二层交换 无法去排查它的问题
我这里都检查过了六类线没任何问题 墙上的接口我也重新接了线 傻瓜交换机也换了俩
@ThirdFlame #1 滑动窗口是指的 TCP 的滑动窗口协议么
疑惑的是 同交换机下存在千兆和百兆设备之后 千兆设备之间仍然是千兆
通信的两端出现百兆设备那就会是百兆 交换机在其中做了什么呢
2021-05-25 17:07:22 +08:00
回复了 Licsber 创建的主题 问与答 如何迅速统计一批 Word 文档的总页数?
@ihipop #18 嗯 一样要在 macOS 上引入新的工具链 我在看虚拟打印机方法了 试试魔改开源的 PDF Writer


@renmu123 #19 在我的测试文档下 二进制 doc 文件打开类似信息都没找到

@play78 #20 语言不限制 常见语言基本都可以快速调起来 demo 就是很难找相关的

@danbai #21 付费库就算了 可见这确实是个需求 不知道为什么没人开源

@miao1007 #22 pandoc 可以把一页转化为一行么 还是第一次见这样的框架
2021-05-24 18:06:42 +08:00
回复了 Licsber 创建的主题 问与答 如何迅速统计一批 Word 文档的总页数?
@renmu123 #16 这个思路有点怪 我试了试 没看出来什么规律 只看到有些东西在不断重复
rels/PK drs/downrev.xmlPK 类似的文本
2021-05-24 16:47:54 +08:00
回复了 Licsber 创建的主题 问与答 如何迅速统计一批 Word 文档的总页数?
@qqjt #13 嗯 也看到了 libreoffice 的一些方法 觉得还是我一开始的想法方便 自己造一个虚拟打印机的轮子

@qqjt #14 可以一试 但万一有人是很老的电脑就玩完了
1 ... 9  10  11  12  13  14  15  16  17  18 ... 36  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1418 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 17:04 · PVG 01:04 · LAX 09:04 · JFK 12:04
Developed with CodeLauncher
♥ Do have faith in what you're doing.