CocoKuromies (2024/11/12 23:20)
jiehuan, 豪德wwww 插个眼 坐等一波

jiehuan (2024/11/12 18:51)
CocoKuromies, 这就是https的问题了，我手上没有黑莓设备暂时无法测试，如果之后测试塞班全系列能支持特定的https的话，就会有适配的

CocoKuromies (2024/11/12 17:47)
黑莓9720实测不能用 wifi环境下无论是搜索还是输入bv号皆显示「应用程序Kilikili已尝试访问220.231.16.67 但它不包含签名 它可能不是来自可信任的源 您是否允许该操作？」 选择「是」后便没了下文 没有任何反应 版本为V0.2正式版（24.11.02） 问问有没有解决方法T T 或者lz是否愿意开发一个适配黑莓的版本呢（jad+alx+cod）

[已删除] (2024/11/11 01:38)
关于服务器端转码方案，貌似有两种技术路线：一种是彻底的流式播放，一种是“类hls”播放。
因为JSR135 MMAPI在诺基亚N97mini和索爱M1i上的测试中，貌似只有等整个mp4视频通通下载到内存里之后才能播放，所以提出两个方案（3gp我没测试，或许3gp可以边从服务器读取边播放，那就相当于下面的第一种方案）
第一种适用于支持流媒体的手机，可以用rtsp实时推流，或者生成rmvb这样的流媒体文件让手机播
第二种适用于不支持流媒体的手机。
现象：如果一整个mp4文件扔给手机，需要很长时间下载，下载完后才能播放（在WiFi信号较好条件下，N97mini和M1i下载一个10MB的6分钟视频大概需要等待10多秒。如果是长视频的话，恐怕有些人就等不及了吧）。
应对方法：把原视频文件像hls点播中ts文件那样切成小段（这样就能在短时间内下好视频切片并迅速播放）（当然这些古董手机不支持ts，所以可以用mp4/3gp来代替，故称“类hls”），然后把一个类似于m3u8的，记载了原视频各时间区间对应的切片视频文件的，诡异的文本文件，扔给手机。但mp4和ts有区别，连续播放mp4的时候，中间会有卡顿和破音，影响观感。
JSR135的拖动进度条方法将会被覆写：当拖动到某一个区间内，手机向服务器请求那个区间对应的切片视频文件。
综上对比：
流式播放
优点：简单 优雅
缺点：需要服务器一直运作 带宽要求高 某些设备可能不支持
“类hls”式播放
优点：支持设备广泛
缺点：难 切片之间有卡顿破音 服务器上会产生一堆小文件（干掉这些文件的好方法是把他们存内存里，但是又需要较大的内存）
不过真实情况更像是我想太多了。能实现基本功能，不管等多久只要能放出来就行，能支持最大众的v3v5就好

[已删除] (2024/11/11 01:03)
......我的想法是，如果资金确实困难的话，为了能在应用内播放视频，可以在S60平台上开发原生视频播放器（同时还可以实时渲染弹幕），而对于S40等不那么智能的平台再去使用服务器端转码，以节省服务器成本。
但是开发原生视频播放器所耗人力物力也很大。计算机科学常常存在时间换空间/空间换时间的操作，而开发S60原生播放器则是拿脑力去换成本。py平台基本可以枪毙了，自带的几个多媒体库基本都是废的，只能上C++，然后就得和塞班系统API、塞班特有的诡异命名方法和塞班特有的诡异的异常处理机制搏斗了。
或者退而求其次，我们只把新版ffmpeg移植到S60平台（且之前确实有人这么干过），让用户自己去转码，但是依然不那么方便。

[已删除] (2024/11/11 00:52)
搞出TLS的大佬也做过一个叫JTube的软件，让J2ME设备可以看YouTube，其中一种播放方法是跳转到某个毛子网站：
https://video.2yxa.mobi/mov.php?id=【此处填入id】&poisk=you&lang=en
这个网站能够转码，但是下载视频需要等待，转码需要等待，虽然能看，但是确实考验耐心。
虽说之前我也试图用python flask+ffmpeg写一个类似的网页转码网站（symbiantranscoder.pythonanywhere.com）但是最终因为玩不懂多线程，无法处理转码进度而烂尾。（另外提一嘴，pythonanywhere.com的服务器可以白嫖，虽然需要懂python web）
JTube另外两种播放方法分别是
1.使用JSR135内置的MMAPI播放ytb原视频（对于我们来说，理论上也可以实时渲染弹幕），但是很多设备也是因为编码问题放不出来
2.用platformRequest跳转到浏览器播放ytb原视频（这样可以把视频下载下来，放到自己的播放器里面去播放）

[已删除] (2024/11/03 22:35)
Fast32, 说明白了就有解决方案了，即服务器端转码