[FFmpeg-user] problem with fast seeking and splitting

[Alexander Solonsky]

Monday, May 2, 2022, 2:21:17 PM, you wrote:

> On Mon, May 2, 2022 at 7:27 AM Alexander Solonsky via ffmpeg-user <ffmpeg-user at ffmpeg.org> wrote:

>> Dear Experts,

>> I'm trying to split an input file into 2 second chunks, transcode and assemble using a concat muxer. And experiencing two problems:
>> major one:
>> 1) when using ffmpeg -ss 00:00:08 -t 2 -i <input_file> -c:v libx264 ....  instead of seeking to second 8, ffmpeg seeks somewhere to second 15 or so.  The first segments are correct, and then it start to go haywire.
>> Using accurate seek ffmpeg  -i <input_file> -ss 00:00:08 -t 2 -c:v libx264 ....  resolves the problem. But it is completely unusuble if you want to split the whole file.
>> Minor one:
>> 2) when concatenating the resulting files - there happens a noticeable break between the chunks. For both audio and video and is equal to 2 additional frame durations (e.g. prev chunk ends at 1.981333 and the next chunk (after concat) while it should start at 2.023000 actually starts at 2.095744 for 24 fps video, and for audio prev chunk ends at 1.927256 and starts at 2.023220 while it should start at 1.950476).

>> adding all additional flags like copyts, copytb, enctimebase, vsync doesn't change anything. And it's really curious when using the hls demuxer - it splits the file accurately and fast, without these breaks.

>> Can you please help me fix those two problems or suggest to understand which command like I could use to reproduce splitting behavior from the HLS demuxer?

> It can not be fixed. You can not seek and start decoding without key frames.
Hi Paul,
 
I cannot say that I fully understood your comment. In my input file key frames are 0  and then 250 then 431. FFMpeg seeks ok to frame 48, frame 96, frame 144,  frame 192, frame 240. Then when I am asking to seek to frame 288 and FFMpeg seeks to frame 538. Sane behavior in my understanding would be to locate the closest key frame happening before the requested frame and decode frames from there. And it is claimed that the fast seek should be accurate. And for this case I can't make sense of what is happening.
and there is the second issue with the gap....
 
>  
>> Thanks,
>> Alexander
>> //////////////

>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user

>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".

-- 
Best regards,
Alexander Solonsky