[FFmpeg-user] problem with fast seeking and splitting

[Paul B Mahol]

On Mon, May 2, 2022 at 9:54 AM Alexander Solonsky <
alexander.solonsky at castlabs.com> wrote:

> 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.
>

Where is claimed that fast seek is accurate? The FFmpeg source code tells
different.

It may be that when seeking it picks the closes key frame to target PTS
instead to closest one from past side in timeline.

Hard to guess when I do not know precise location of keyframes of your
input.

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
>