python - ffmpeg stdin 管道搜索

Question

我正在尝试编写一些从标准输入读取的代码，然后通过搜索修剪视频。
这就是我到目前为止得到的:

def trim():
            in_use=io.BytesIO()
            process = sp.Popen(shlex.split('ffmpeg -i pipe: -ss 00:00:01.0 -t 00:00:01.4 -c:v libx264 -strict -2 output.mp4'), stdin=sp.PIPE, bufsize=10**8)
            # Pipewriter function
            pipewriter(in_use,process)
            process.wait()

pipewriter 函数看起来像这样:

def pipewriter():
        video.seek(0)
        for chunk in iter(partial(video.read,1024),b''):
            process.stdin.write(chunk)
        process.stdin.flush()
        process.stdin.close()

in_use io.BytesIO 对象中的文件是有效的视频，这不是问题所在。
输出文件也会正确生成和修剪，因此该功能可以正常工作。
我的问题是，由于寻找和修剪 pipewriter 功能确实将整个视频写入管道。但是 ffmpeg 进程在 -t 00:00:01.4 秒后停止，因此用标准输入编写的视频的其余部分导致管道错误
有人没有尝试就得到一个干净的解决方案，除了。
我还必须尽可能准确地修剪视频。当前的解决方案确实对我有用。
错误 :

   process.stdin.flush()
BrokenPipeError: [Errno 32] Broken pipe

Answer 1

Does somebody got a clean solution for that without try except.

没有人有从根本上更好的解决方案，因为这就是管道闭包的反向传播被设计为在 Unix 中工作的方式。

前向传播是通过程序从关闭的输入管道中读取、查看 EOF、结束并关闭其输出管道(如果有)而发生的。

反向传播是通过程序写入关闭的管道并(默认情况下)接收到杀死它的 SIGPIPE 来发生的，从而导致任何打开的输入管道被关闭。程序可以选择忽略 SIGPIPE，而是处理 Python 用于 raise an Error in its place 的 EPIPE 退出代码本身。 .

所有 API 都在顶层，例如 subprocess.communicate ，只需在引擎盖下处理这个事实。最好的做法是停止与 Python 和 Unix 对抗，而只需使用 try-catch (可选地在辅助函数中整理)顺其自然。
然而，如果你真的想要一个没有 try-catch 的外观更干净的版本，你可以调用一些不好的做法，例如禁用 Python 的默认信号处理程序:

import signal
signal.signal(signal.SIGPIPE, signal.SIG_DFL);

这将导致 Python 进程立即被无声地杀死，这就是管道中大多数程序停止的方式，例如 find在 find / | head -n 1