- 主题:写了一个小python程序
在Linux上把播放器不支持的视频文件实时转码成ts流，再用fuse替换原文件，支持seek和预览
纯python仅依赖ffmpeg命令行
--
FROM 155.64.23.*
看你发言，以为你是个水货，原来这么厉害。
【 在 xiaoju 的大作中提到: 】
:
: 在Linux上把播放器不支持的视频文件实时转码成ts流，再用fuse替换原文件，支持seek和预览
:
: 纯python仅依赖ffmpeg命令行
: --
:
发自「今日水木 on Mi Note 3」
--
FROM 106.121.3.*
~~~上次未发表的内容~~~
~~~上次未发表的内容~~~
想法不错
【 在 xiaoju () 的大作中提到: 】
: 在Linux上把播放器不支持的视频文件实时转码成ts流，再用fuse替换原文件，支持seek和预览
:
: 纯python仅依赖ffmpeg命令行
--
FROM 124.78.220.*
海客谈瀛洲，烟涛微茫信难求。 越人语天姥，云霓明灭或可睹。
说错就说错吧，没有必要再专门下ffmpeg和vlc来试验。
感觉为FUSE而FUSE。
1. 啥视频ffmpeg能放，vlc放不了？
2. 为啥不ffmpeg推rtsp, vlc收rtsp
3. 为啥不ffmpeg转码到ts文件，与此同时vlc放？就像a.out print到文件，同时用tail来看。再次强调可能说错，与mp4, mkv等不传完没法看不同，ts相对格式简单，可以从头开始放。我记得在web服务器端看log, vlc播mp4时要"seek"到文件尾去下。通过smb共享，也是支持文件seek的。
4. FUSE我知道没用过，看了xiaoju的帖子后学习了下，写了个贴：
https://zhuanlan.zhihu.com/p/145384311
请问你是ffmpeg发到rtp之类，python里写了个server收吗？
--
修改:billybear04 FROM 106.121.142.*
FROM 106.121.142.*
理论上说所有编码一定有适合的播放器，但不一定你喜欢的播放器一定支持所有编码，转码是最简单手段
我是直接转了mpegts，有的播放格式需要完整文件才行，ts是传输格式，可直接播放也可通过管道或者网络流播放
有点挑战的部分是显示总长和seek，因为不等待整个文件转换完成，你是不知道最终ts流有多大的，也无法知道精确的比特率，这个地方需要点想象力和trick
【 在 billybear04 的大作中提到: 】
: 海客谈瀛洲，烟涛微茫信难求。 越人语天姥，云霓明灭或可睹。
: 说错就说错吧，没有必要再专门下ffmpeg和vlc来试验。
: 感觉为FUSE而FUSE。
: ...................
--
FROM 155.64.23.*
具体实现了哪些格式转ts？
【 在 xiaoju () 的大作中提到: 】
: 在Linux上把播放器不支持的视频文件实时转码成ts流，再用fuse替换原文件，支持seek和预览
:
: 纯python仅依赖ffmpeg命令行
--
FROM 223.104.11.*
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: 有点挑战的部分是显示总长和seek，因为不等待整个文件转换完成，你是不知道最终ts流有多大的，也无法知道精确的比特率，这个地方需要点想象力和trick
这个我不知道。tail不能读到文件尾，失败后就不再读。mkfifo出来的，好像读完后会阻塞
那个loggedfs倒是比strace专用啊，例如可以知道某个程序open了哪些文件，不过strace: -e trace=syscall_set
--trace=syscall_set
Trace only the specified set of system calls.
--
修改:billybear04 FROM 106.121.142.*
FROM 106.121.142.*
ffmpeg支持的格式都可以，受限于机器最大的实时算力
【 在 poikilotherm 的大作中提到: 】
: 具体实现了哪些格式转ts？
: --
: 发自xsmth (iOS版)
--
FROM 27.91.71.*
看了下你写的zhihu有一点不同意：“放在user space更灵活，但效率会低点”
用户态并不比内核态效率低，而且得益于高层系统服务，大部分时候效率会更高。微内核用户态服务的唯一缺陷是，当你的机器只有一个逻辑核却需要处理网络或者GUI任务的时候，会有比较严重的context切换损失。
【 在 billybear04 的大作中提到: 】
:
: 这个我不知道。tail不能读到文件尾，失败后就不再读。mkfifo出来的，好像读完后会阻塞
: 那个loggedfs倒是比strace专用啊，例如可以知道某个程序open了哪些文件，不过strace: -e trace=syscall_set
: ...................
--
FROM 27.91.71.*
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: 看了下你写的zhihu有一点不同意：“放在user space更灵活，但效率会低点”
: 用户态并不比内核态效率低，而且得益于高层系统服务，大部分时候效率会更高。微内核用户态服务的唯一缺陷是，当你的机器只有一个逻辑核却需要处理网络或者GUI任务的时候，会有比较严重的context切换损失。
首先，谢谢捧场。:-) 其次，你说是就是吧，open-iscsi，wiki上没有列出(用了fuse)，但是前者似乎涉及到了fusectl。如果效率不低，为啥不放在外面？ext4等呢？我感觉是那些本来就慢的，例如gmailfs，这点损失无所谓。再说，在kernel里写socket程序，好像可以创建kernel thread，但不是调用socket, connect，还得再学，如果系统管理员肯让你干，你也敢干的话
--
修改:billybear04 FROM 106.121.143.*
FROM 106.121.143.*