V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mxalbert1996  ›  全部回复第 4 页 / 共 83 页
回复总数  1646
1  2  3  4  5  6  7  8  9  10 ... 83  
@jqtmviyu 我是在告诉你如何更好地问问题。你自己再读一遍你的主楼,你根本就没有提到对任何除了播放本地音乐以外的功能的需求。
我觉得既然你对一些功能有需求,就应该在主楼说清楚,这样能节省双方的时间。
241 天前
回复了 Jaime668 创建的主题 YouTube 油管 TV 版本
没有,Fire TV 版 YouTube 可以正常看 4K
@billccn 那可能三星回音壁比较特殊,我用过的 Sony 和 JBL 的都是显示 TrueHD 的。但显示 Atmos 也有可能是降级到了 DD+,所以也不见得是直通成功了。
7.1 的话应该是 Dolby TrueHD 吧,显示为 Atmos 可能是因为电视不支持直通 TrueHD 降级了。
盒子的话国内品牌的不太了解,国外品牌的话目前同时支持 Dolby Vision 和 Dolby TrueHD/DTS-HD MA 音频直通的应该只有 Shield TV 2019 年款和 Fire TV Cube 第 3 代。直通功能本身都一样的不存在什么最好。
另外很重要的一点就是 Kodi 的兼容性。Kodi 对这两款的兼容性都是没问题的,但如果你想买国内品牌的建议你提前查一下 Kodi 的兼容性怎样。
293 天前
回复了 Kinnikuman 创建的主题 程序员 为什么播放杜比视界会发绿发紫?
@ysc3839
你知道我说的当然不是这种情况。我也说了,如果真的侵权我不信 Dolby 会放任他们不管。
而且实现算法侵权这个其实是说不通的,就好比游戏机的模拟器不侵权一样。
294 天前
回复了 Kinnikuman 创建的主题 程序员 为什么播放杜比视界会发绿发紫?
另外我对播放器支持 DV 需要授权持怀疑态度。ffmpeg 已经通过试错和逆向实现了 DV 的专有格式的解码,mpv 、IINA 和 Kodi 等等开源免费的播放器也都支持播放 DV ,我不信他们付了授权费,也不信 Dolby 会放任他们不管。
294 天前
回复了 Kinnikuman 创建的主题 程序员 为什么播放杜比视界会发绿发紫?
@SkywalkerJi
按我的理解,楼主并不是想问「为什么有些播放器不支持播放 DV 」,而是想问「为什么不支持 DV 的播放器播放 DV 会发绿发紫」。后者只和技术有关。
294 天前
回复了 Kinnikuman 创建的主题 程序员 为什么播放杜比视界会发绿发紫?
哦不对,原因应该是因为这些播放器没有正确解码 DV 。DV 由 10bit 的 Basic Layer 和 Enhanced Layer 组成,正确解码时会把这两层组合成 12bit 的视频流,但不支持 DV 的解码器会只解码 BL ,结果就是偏色。
294 天前
回复了 Kinnikuman 创建的主题 程序员 为什么播放杜比视界会发绿发紫?
很可能是因为这些播放器没有和像素信息一起发送 DV 的 per-frame metadata 。
299 天前
回复了 Kinnikuman 创建的主题 程序员 关于杜比视界授权与映射问题
电视判断是不是 DV 是根据和视频信号一起通过 HDMI 传输的 metadata 。
「应用支持」展开以后有开发者邮箱
313 天前
回复了 zuotun 创建的主题 Linux 关于字体安装
如果你用的是 mpv ,你可以直接用 --sub-fonts-dir 指定用于字幕的字体目录,不用安装。
不可能。日本办卡已经严到了智障的程度,我用过的几家里,povo 的 eSIM 连每次换机都要重新上传身份证件等人工认证,LINEMO 直接不给没永居的外国人办 eSIM 。
316 天前
回复了 MegatronKing 创建的主题 程序员 应用想上架 Setapp,被无情拒绝
很正常的商业决定啊,你上架了 setapp 那他们得给你钱吧,订阅价格不变所以每个订阅的利润就减少了,如果他们认为加了你这个应用不能吸引到足够的新用户来增加利润,那拒绝你不是很正常么。
@ShadowPower
我相信任何一个阅读理解不是 0 分的人都能从你之前的回复看出你是在提出「 Google 应该学习国产 ROM 的自启动权限管理」,然后你现在又来说「这倒不是默认开启或者默认关闭的问题。目前的情况是,想要的人早已用上了,而不想要的人可以永远不用。它并不是一项需要“新增”的功能。」,我就不太能理解你到底想说什么。
另外你也不用装理中客,很显然你不是(当然我也不是)。
@ShadowPower
你所谓的改动好像不止一个呀。

> 把原本由 APP 显示通知内容,改为由系统服务负责显示。
没问题呀,我不反对。

> 杀掉应用,并切断所有唤醒途径的话,大多数时间里,这款应用后台的资源占用就像没安装它一样。而这时候,你又能通过系统服务来查看来自这个应用的推送。这难道不是更好吗?
如果这个功能默认开启,那我坚决反对。如果默认关闭,那我并不反对,只是在因为有 FCM 加上 Android 越来越严的后台活动限制下已经相当好的国外应用环境下能有多大效果,又有多少用户会真正去用,都是疑问。

你不同意没关系,你也不用写长篇大论来说服我,我在国外用 Pixel 用得好得很,对我来说(可能也是对大部分用户来说)不用操心哪个应用需要后台哪个应用不需要才是更重要的。
@ShadowPower
「不需要应用启动」是没错的,应用并不需要在后台运行。如果你把它理解成是系统不会启动应用,其实也没差太多,因为只有 FirebaseMessagingService 被短暂地启动,最近的 Android 版本都会在短时间内杀死应用,应用并没有机会完全启动。
关于通知是由谁显示的,我已经在下面更正了。
强制停止应用并且禁止自启动当然不好,因为这是以牺牲应用功能为代价的。如果你不同意这一点的话,那我觉得我们也不用继续讨论了。
我研究了一下, @Musong 说的没错,FCM 确实是由应用里的 FirebaseMessagingService 接收 broadcast 来显示通知,但楼主的论据和结论都是错误的。首先「自启动权限」是国产系统特供的吧,AOSP 和 Pixel 里都没有这个东西。然后后台可以使用限制模式,不需要保活。结论,国际上 Android 不费电不费内存并不是误解。
@Musong @ShadowPower
我在 Pixel 上实测电池用量设为受限并且从最近应用划掉以后仍然能正常收到通知。
1  2  3  4  5  6  7  8  9  10 ... 83  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1048 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 19:27 · PVG 03:27 · LAX 11:27 · JFK 14:27
Developed with CodeLauncher
♥ Do have faith in what you're doing.