Re: [FFmpeg-user] Decimal times to frame numbers
Gyan Doshi (12021-08-21): > A nit, but MP4 is inherently VFR-ready - that's what the (mandatory) stts > box is for. > > It is for some opaque reason that the muxer defaults to CFR, possibly to do > with some limitation or bug in the early days. Good to know. I will still argue that MP4 is a crappy format designed with more concern for pleasing big investors than with concern for good design. For careful examination of the output, NUT would be the most reliable. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Decimal times to frame numbers
On 2021-08-21 03:05 pm, Nicolas George wrote: - By adding -r on your output and by using a format like MP4 that only supports constant frame rate, you are forcing ffmpeg to duplicate or A nit, but MP4 is inherently VFR-ready - that's what the (mandatory) stts box is for. It is for some opaque reason that the muxer defaults to CFR, possibly to do with some limitation or bug in the early days. Regards, Gyan ___ 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] Decimal times to frame numbers
amindfv--- via ffmpeg-user (12021-08-20): > I then tested the output of running commands like this, only changing the > value for $STARTTIME : > > export STARTTIME=0.33 ; ffmpeg -r 24 -i color-frames.mp4 -r 24 -ss > $STARTTIME "test-$STARTTIME.mp4" There are several flaws in problem report: - You did not post the full output. We need the full output to spot some usual missteps. - You do not need export since you are using the variable directly. - By adding -r on your input, your force ffmpeg to re-synthesize the timestamps. This is wrong in general. In this particular case, it changes the precision of the timestamps: your input file has a 1/12288 time base, with -r 24 it becomes 1/24. - By adding -r on your output and by using a format like MP4 that only supports constant frame rate, you are forcing ffmpeg to duplicate or drop frames to a certain rate. If you want to examine the output carefully, either use a format that supports arbitrary timestamps or do not use a format at all and write to individual images with "-vsync passthrough". It is possible you have unearthed an off-by-one bug somewhere. But in general, the logic should be: - The timestamps you write are rounded to the nearest integer multiple of the time base. - The frames you get in the filter line are exactly the interval you requested. That means if the time base is more precise than the frame rate you can get frames with half the duration. What happens after the filter chain, on the other hand, is subject to more complex heuristics. I strongly suggest you try to work as much as possible only with filters. > On Wed, Aug 18, 2021 at 09:26:03PM -0600, amindfv--- via ffmpeg-user wrote: Top-posting is forbidden on this mailing-list. Do not do it again if you want help. Look it up if you do not know what it means. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Decimal times to frame numbers
To test this, I've just created a fixed-frame-rate video at 24 fps: |---R|G|---B| (1/3) seconds (8 frames) solid Red, followed by (1/24) seconds (1 frame) solid Green, followed by (1/3) seconds (8 frames) solid Blue. Per the FFmpeg Mailing List FAQ, I've uploaded the sample file to https://0x0.st/-yD3.mp4 I then tested the output of running commands like this, only changing the value for $STARTTIME : export STARTTIME=0.33 ; ffmpeg -r 24 -i color-frames.mp4 -r 24 -ss $STARTTIME "test-$STARTTIME.mp4" (Side note: I originally put the -ss value before the input specifier, but the times were very inaccurate: some clips dropped no frames - i.e. I saw 8 frames of red in some cases! Other times too many frames appeared to be dropped. If I'm reading the man page entry for -ss correctly, this seems like a bug.) Below are values for $STARTTIME, with the color of the first frame of the output: 0.3: Red 0.30: Red 0.31: Red 0.311: Red 0.312: Red 0.31249: Red 0.31249: Red 0.3125: Green < This is halfway between the start time of the last Red frame (7/24) and the start time of the first Green one (1/3). Calculation: ((7/24) + (((1/3)-(7/24))/2)) == (5/16). Note this output file starts with 2(!) green frames even though the input only contains 1. 0.3125001: Green (still 2 frames of Green) 0.312501: Green (still 2 frames) 0.31251: Green (still 2 frames) 0.31250001: Green (still 2 frames) 0.3125001: Green (still 2 frames) 0.312501: Green (back to only 1 frame of Green) 0.31251: Green 0.313: Green 0.315: Green 0.317: Green 0.32: Green 0.33: Green 0.333: Green < This is where the source video turns from Red to Green (1/3 == 0.333...) 0.334: Green 0.334: Green 0.34: Green 0.35: Green 0.36: Blue 0.37: Blue 0.374: Blue 0.374: Blue 0.375: Blue < This is where the source video turns from Green to Blue 0.3750: Blue 0.3751: Blue 0.4: Blue 0.41: Blue 0.416: Blue 0.41: Blue 0.417: Blue In summary, I'm more confused than when I started. It seems (though I haven't tried hairier time values, e.g. with frame rate 23.976) that seeking may compute the closest start frame - i.e. simply round. But then the output seems to be working in some other way: what's the distinction between time 0.312501 (1 frame of Green) and 0.3125001 (2 frames of Green)? I don't know. Any help here is much appreciated. Thanks! Tom On Wed, Aug 18, 2021 at 09:26:03PM -0600, amindfv--- via ffmpeg-user wrote: > How are frame numbers converted to and from decimal numbers of seconds in > ffmpeg and related tools? > > For example, given a file foo.mp4 at 24fps, when I run a command like: > > ffmpeg -i foo.mp4 -t 0.72 bar.mp4 > > 0.72 is a time between frame 18 (0.70833... seconds) and frame 19 (0.75 > seconds). > > In my tests, it seems that the number of seconds is rounded down, i.e. any > value less than 0.75 is equivalent to the earlier frame. > > Is this always true? Is this the best way to think about the decimal > seconds<->frame number conversion? Is there any difference (e.g. in audio > track duration) between saying 0.71 or 0.73 in the above? > > Thanks, > Tom > > ___ > 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".
Re: [FFmpeg-user] Decimal times to frame numbers
I must reinforce Carl's interpretation here. To define the problem more formally, timestamps are a necessary and perfectly reasonable approach to timing video playback in a variable frame rate environment. They're not a particularly good way of looking up specific images in a sequence in a fixed frame rate environment. There's a lot of ambiguity in that a range of times refer to any one image, and applications working in a fixed frame rate environment (which means absolutely all of film and television production) have to make some sort of hopefully-sensible estimated conversion, which can and has caused real world problems. Issues arise particularly when bringing variable frame rate material into a fixed frame rate environment, which may be as simple as video shot on cellphones, which often don't maintain a very consistent frame rate even when asked to. The reason it feels like there isn't any very obvious and guaranteed-correct way to convert frame counts to timestamps and vice versa is that... there isn't any guaranteed-correct way to do that. That doesn't mean it shouldn't be done. People involved with the ffmpeg project in the past have made some odd statements about timecode, though; I don't think most of the people involved in the project have much experience of real world film and TV production, so I wouldn't hold your breath for a fix. P ___ 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] Decimal times to frame numbers
I hate to disagree with you, but On 8/19/2021 5:56 AM, Nicolas George wrote: No, it is the other way around: you should not be thinking about frame numbers, you should be thinking about timestamps. Not necessarily Timestamps are an inherent property of the frame, they will be preserved or converted by filters and storage. Frame numbers are not. Frame numbers are not an internal property of a frame itself, but I'm sure you know that in production and editing environments*, nobody cares about a timestamp, they care that this frame is 3 seconds and 5 frames from that one, that the clip is 32 seconds and 13 frames long, or that a transition takes 19 frames. Frame numbers are ordinal from an arbitrary point. And it's not relevant that they be "preserved by filters" because the don't exist in that context anyway- kind of like saying that 20 story building doesn't have a 13th floor; it surely does, even if it's labeled "14". *which tend to be fixed rate, not variable It's also quite a lot easier and more clear and precise to specify a point as 00:00:00.13 (the thirteenth frame interpreted at the current frame rate) than as 0.43377... (at 29.97); it will always be the 13th frame of the second and can't mean anything else. So, yes, frame numbers are meaningful and commonly used. If ffmpeg only accepts decimal seconds, so be it, but that complicates matters for a fair few users and they're not likely to change to decimals for their daily work. 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] Decimal times to frame numbers
amindfv--- via ffmpeg-user (12021-08-18): > Is this the best way to think about the decimal seconds<->frame number > conversion? No, it is the other way around: you should not be thinking about frame numbers, you should be thinking about timestamps. Timestamps are an inherent property of the frame, they will be preserved or converted by filters and storage. Frame numbers are not. If you have an issue with timestamps, please be more specific about it, there is no doubt it can be solved. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] Decimal times to frame numbers
How are frame numbers converted to and from decimal numbers of seconds in ffmpeg and related tools? For example, given a file foo.mp4 at 24fps, when I run a command like: ffmpeg -i foo.mp4 -t 0.72 bar.mp4 0.72 is a time between frame 18 (0.70833... seconds) and frame 19 (0.75 seconds). In my tests, it seems that the number of seconds is rounded down, i.e. any value less than 0.75 is equivalent to the earlier frame. Is this always true? Is this the best way to think about the decimal seconds<->frame number conversion? Is there any difference (e.g. in audio track duration) between saying 0.71 or 0.73 in the above? Thanks, Tom ___ 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".
