Re: [FFmpeg-user] problem with fast seeking and splitting
> On 5/1/2022 10:27 PM, Alexander Solonsky via ffmpeg-user wrote: >> I'm trying to split an input file into 2 second chunks, transcode and >> assemble using a concat muxer. > I hate to question the question, but what's the purpose of this process? > Generally speaking, you're better off transcoding in a single pass. If that > process is too slow, can you use hardware to accelerate the process? Cutting > into 2-second chunks to recode seems like a poor approach. > If you really want to recode chunks, which may have their own issues when > concatenated together, decode the entire stream and select chunks from the > uncompressed data. Hi Carl, the original idea was to split accelerate video encoding by splitting on scene changes or much larger chunks than 2 seconds to make it more efficient, for sure. 2 seconds were selected to isolate the problem and make the debugging easier and faster. VP9 and AV1 encoders are not thread efficient yet and splitting to several independent encoding processes speeds up things significantly. Or the lambda encoding also requires accurate splitting and concatenation. And none of that seems to be working. Decoding into intermediate uncompressed is not an option because of complications and additional cost (think about 4K movie in 10 bits). And why would we do that? - when we have input stream with all offsets, frame types, pts times etc. And neither seeking (I couldn't actually find a compressed file for which the fast seek would work more or less accurately) nor concatenation seems to be working properly. And yet there is https://trac.ffmpeg.org/wiki/Seeking with quotes "-ss is now also "frame-accurate" even when used as an input option", "The input will be parsed using keyframes, which is very fast", "-ss as an input option is now both fast and accurate" @Paul B Mahol Thanks, Alexander // ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". -- Best regards, Alexander Solonsky ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] problem with fast seeking and splitting
On 5/1/2022 10:27 PM, Alexander Solonsky via ffmpeg-user wrote: I'm trying to split an input file into 2 second chunks, transcode and assemble using a concat muxer. I hate to question the question, but what's the purpose of this process? Generally speaking, you're better off transcoding in a single pass. If that process is too slow, can you use hardware to accelerate the process? Cutting into 2-second chunks to recode seems like a poor approach. If you really want to recode chunks, which may have their own issues when concatenated together, decode the entire stream and select chunks from the uncompressed data. Later, z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] problem with fast seeking and splitting
On 02-05-2022 10:18, Paul B Mahol wrote: On Mon, May 2, 2022 at 9:54 AM Alexander Solonsky < alexander.solon...@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@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 -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 -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? HLS demuxer is a totally different beast than ffmpeg, it operates from an audio/video stream (from hlssink2) and it generates keyframes when desired e.g. when the stream needs cutting it generates a keyframe for that purpose from which the cut can be made. ffmpeg works with the encoded audio/video container that has fixed keyframes, if you want the same behaviour you will need to work with uncompressed audio/video. greetings Ferdi Scholten ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] problem with fast seeking and splitting
On Mon, May 2, 2022 at 9:54 AM Alexander Solonsky < alexander.solon...@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@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 -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 -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@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> To unsubscribe, visit link above, or email >> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". >> > > -- > Best regards, > Alexander Solonsky > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] problem with fast seeking and splitting
Monday, May 2, 2022, 2:21:17 PM, you wrote: > On Mon, May 2, 2022 at 7:27 AM Alexander Solonsky via ffmpeg-user > 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 -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 -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@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-user >> To unsubscribe, visit link above, or email >> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". -- Best regards, Alexander Solonsky ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] problem with fast seeking and splitting
On Mon, May 2, 2022 at 7:27 AM Alexander Solonsky via ffmpeg-user < ffmpeg-user@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 -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 -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. > > Thanks, > Alexander > // > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] problem with fast seeking and splitting
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 -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 -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? Thanks, Alexander // ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
