Re: [FFmpeg-user] repeat a frame
On 2021-03-02 13:31, Carl Eugen Hoyos wrote: Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg) : I've searched the docs one-by-one. I seek a simpler way to repeat a frame. Increase the frame rate, either with the fps filter or the ffmpeg option "-r". They differ in their greediness and verbosity on the status line. Thanks, Carl Eugen. I seek a simple way to repeat a specific frame, not a way to increase fps. Specifically, I need to repeat frame #3 in each group of 4 frames: 0 1 2 3 in, 0 1 2 3 3 out. I need it because 'shuffleframes' can't insert frames. To reiterate: This works: split[1][2],[1]setpts=(N+floor(N/4))/FR/TB[3],[2]select=eq(mod(n\,4)\,3),setpts=(N*5+4)/FR/TB[4],[3][4]interleave I seek a simpler way. Is there a simpler way? Thanks! ___ 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] repeat a frame
On 2021-03-04 09:26, Moritz Barsnick wrote:
On Thu, Mar 04, 2021 at 03:57:38 -0500, Mark Filipak (ffmpeg) wrote:
Well, per rational.h, 'num' & 'den' are both integers.
Now, I don't know how '72' is stored. Is it stored as an int64?
They are defined as "int", which can be platform dependant. ffmpeg
assumes/guarantees ints to be at least 32 bits.
I don't know, but I do know that it can't be stored as an 8-bit
integer or a 16-bit integer or anything else that has 8-bit or 16-bit
resolution.
If you mean the number 72, that's correct.
That includes AVRational. 72 can't be stored as
AVRational. AVRational just doesn't have enough resolution.
Huh? You didn't even wait for the answer to how it is stored. And you
even asked whether it was 64 bits. This would work just fine with 64
bits.
It's a rational number of two integers with at least 32 bits...
Ah! An 'int' is a signed, 32-bit integer (aka int32_t). Okay. Good to know.
Thanks.
... 1/72
is probably stored as { 1, 72 }, but could also be { 2, 140 }
for example, unless they get reduced automatically (I'm too lazy to
check).
So, TB is stored as an AVRational: 'num', 'den', each signed, 32-bit integers. Okay. Good to know.
Thanks.
No problem then. I think that just about clears everything up. You see, I'm not a 'C' programmer and
it appears that just what an int *is* varies. I guess that's why the 'C' world has standardized on
calling the datatype "int32_t", eh?
I'm sure you know that the running time produced by 'PTS's depends on frame
rate *and* time_base. For example, for 23.976fps and TB = 1/(72 ticks/s)
= 1.3[8..] µs/tick, a PTS of +9223372036854775800 indicates a
307138595965860 maximum frame number.
Huh? At 72 ticks/seconds, and PTS being number of ticks, you can
create timestamps spanning
(2^63 - 1) / 72 seconds
which is
~12810238940076 seconds
which is
~40 years.
Where am I going wrong?
A maximum frame number, N, of 307138595965860 frames at 24/1.001 frames/s yields a running time of
12810238940076.0775 seconds. So we're in agreement I think.
Oh! I see. I wrote this: "That frame number is reached by a 426581383 second video (= 13 years, 189
days, 49 minutes, 43 seconds)." I apparently divided maximum running time by deltaPTS (30030). Why
did I do that? Well, that was at 4AM. I was getting pretty punchy. Sorry.
Do you agree with my figures? Do you see the difference between time
extents and time resolution?
I don't agree with your figures.
I swear: That is the last mistake I will ever make (for all time). :-)
--
In U.S. History: The House Un-American Activities Committee was a committee of the House of
Representatives that engaged in un-American activities.
___
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] repeat a frame
On 2021-03-04 11:02, Peter White wrote: On 03.03.21 23:57, Mark Filipak (ffmpeg) wrote: On 2021-03-03 11:30, Mark Filipak (ffmpeg) wrote: I've tried transcoding a 2:21:19 movie via this script: SET codecs=-codec:v libx265 -x265-params crf=16:qcomp=1.00 -codec:a copy -codec:s copy -dn FWIW I could not help but notice that you effectivly degrade crf to constant quantizer. Might as well use: -x265-params qp=16 See https://x265.readthedocs.io/en/master/cli.html#cmdoption-qcomp Peter Thanks, Peter! What these directives actually mean is a bit hazy to me. Is there a functional relationship between 'crf' and 'qcomp'? Perhaps qp = crf/qcomp? What would the units be? 'crf' would be frames/s I suppose. The others: ? ...something to do with quantizing and compressing, but I don't have much of a clue regarding what is quantized, how it is quantized and what is compressed. Basically, I understand processes via the input and output units. Without units, I don't know what a process does. It just becomes tossed word-salad. ___ 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] repeat a frame
On 2021-03-04 09:36, Michael Koch wrote: Am 03.03.2021 um 23:57 schrieb Mark Filipak (ffmpeg): I've tried transcoding a 2:21:19 movie via this script: SET prep23=settb=expr=1/72,setpts=N*30030 SET cfr23=setpts=N*1001/24000/TB,fps=24000/1001 SET codecs=-codec:v libx265 -x265-params crf=16:qcomp=1.00 -codec:a copy -codec:s copy -dn ffmpeg -i i:\BDMV\STREAM\00303.m2ts -vf %prep23%,%cfr23% %codecs% test.mkv Isn't the first setpts filter useless, because it's overwritten by the second setpts filter? Not useless. The 'TB' set by 'prep23' produces 'PTS's based on it -- 'PTS' is a function of 'TB' & 'N'. If the 'TB' in that function doesn't have enough resolution to produce valid 'PTS's throughout the video, if it gets truncated in some internal step, then for those 'PTS's toward the end of the video, frames will have bogus 'PTS's and will be dropped. On the other hand, if all is well within the filter pipeline and 'TB' is not truncated in some internal step, then, Yes, the test seems superfluous. My command line determines which of those is the case. If the output, 'test.mkv', wound up shortened (due to dropped frames), then I could conclude that calculations that included 'TB' got truncated in some internal step. Essentially, what I did was indirectly test the resolution of 'TB'. ___ 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] repeat a frame
On 03.03.21 23:57, Mark Filipak (ffmpeg) wrote: On 2021-03-03 11:30, Mark Filipak (ffmpeg) wrote: I've tried transcoding a 2:21:19 movie via this script: SET codecs=-codec:v libx265 -x265-params crf=16:qcomp=1.00 -codec:a copy -codec:s copy -dn FWIW I could not help but notice that you effectivly degrade crf to constant quantizer. Might as well use: -x265-params qp=16 See https://x265.readthedocs.io/en/master/cli.html#cmdoption-qcomp Peter ___ 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] repeat a frame
Am 03.03.2021 um 23:57 schrieb Mark Filipak (ffmpeg): I've tried transcoding a 2:21:19 movie via this script: SET prep23=settb=expr=1/72,setpts=N*30030 SET cfr23=setpts=N*1001/24000/TB,fps=24000/1001 SET codecs=-codec:v libx265 -x265-params crf=16:qcomp=1.00 -codec:a copy -codec:s copy -dn ffmpeg -i i:\BDMV\STREAM\00303.m2ts -vf %prep23%,%cfr23% %codecs% test.mkv Isn't the first setpts filter useless, because it's overwritten by the second setpts filter? Michael ___ 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] repeat a frame
On Thu, Mar 04, 2021 at 03:57:38 -0500, Mark Filipak (ffmpeg) wrote:
> Well, per rational.h, 'num' & 'den' are both integers.
>
> Now, I don't know how '72' is stored. Is it stored as an int64?
They are defined as "int", which can be platform dependant. ffmpeg
assumes/guarantees ints to be at least 32 bits.
> I don't know, but I do know that it can't be stored as an 8-bit
> integer or a 16-bit integer or anything else that has 8-bit or 16-bit
> resolution.
If you mean the number 72, that's correct.
> That includes AVRational. 72 can't be stored as
> AVRational. AVRational just doesn't have enough resolution.
Huh? You didn't even wait for the answer to how it is stored. And you
even asked whether it was 64 bits. This would work just fine with 64
bits.
It's a rational number of two integers with at least 32 bits. 1/72
is probably stored as { 1, 72 }, but could also be { 2, 140 }
for example, unless they get reduced automatically (I'm too lazy to
check).
> I'm sure you know that the running time produced by 'PTS's depends on frame
> rate *and* time_base. For example, for 23.976fps and TB = 1/(72 ticks/s)
> = 1.3[8..] µs/tick, a PTS of +9223372036854775800 indicates a
> 307138595965860 maximum frame number.
Huh? At 72 ticks/seconds, and PTS being number of ticks, you can
create timestamps spanning
(2^63 - 1) / 72 seconds
which is
~12810238940076 seconds
which is
~40 years.
> Do you agree with my figures? Do you see the difference between time
> extents and time resolution?
I don't agree with your figures.
Moritz
___
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] repeat a frame
On 2021-03-04 01:05, Jim DeLaHunt wrote: On 2021-03-03 14:57, Mark Filipak (ffmpeg) wrote: With TB = 1/(72 ticks/s), for a 24.976fps output, deltaPTS = (1001/24000 frames/s)/(1/(72 ticks/s)) = 30030 ticks/frame If working time_base (from the AVRational) has an effective resolution of int32 (i.e. ±2147483647 ticks), then frames past 0:49:42 will be dropped. I see what you are getting at, but you are using the wrong terminology for this software product, so your statements sound garbled. Remember that, in FFmpeg, the time_base is the time difference between frames, in seconds... I can't agree. I think you refer to (PTS ticks)x(TB s/tick). I think that time_base (TB) is the tick rate of the STC (system time clock, 27 MHz for mpeg2video) divided by a divider (300 for mpeg2video). For example, 1/(9 ticks/s) = 11.[1..] µs/tick is the time_base for mpeg2video. What I'm using is TB = 1/(72 ticks/s) = 1.3[8..] µs/tick (which has 8x higher resolution than mpeg2video). ... It is an attribute of the stream, so its value does not change regardless of the length of the stream (unless something changes the time_base, creating a second stream derived from the first). Time_base is type AVRational, which is a rational number, not an integer, not a float. Hmmm... You are implying that time_base is not being converted to a float, eh? AVRational mathematics, eh? Strange, but I guess it's not impossible (or unreasonable). Instead of "working time_base", i think you mean "time offset". This is the number of seconds since the zero time. FFmpeg can get a lot done without calculating the time offset. By "working time_base" I mean the time_base used in the filter pipeline (as opposed to the decoder or encoder time_base). I gave it a name because it otherwise has no name to differentiate it. Time offset = time_base * Presentation Timestamp (PTS). Thus, PTS = time offset / time_base. FFmpeg uses PTS values, related to the constant time_base, a lot. If working time_base has an effective resolution of uint32 (i.e. 4294967295 ticks), then frames past 1:39:26 will be dropped > When it comes to integers, "resolution" is not the right term to use. "Maximum value" and "minimum value" are the most comment. "range" or "capacity" might also be used. The number of bits in the integer is the "size". No, I mean resolution, temporal resolution in this case. A 1.3[8..] µs/tick time_base has 8 times the resolution of a 11.[1..] µs/tick time_base. The thing that's attractive about a 1.3[8..] µs/tick time_base is that it produces exact integer 'PTS's for 23.976fps, 24fps, 25fps, 29.970fps, 30fps, 47.952fps, 48fps, 50fps, 59.940fps, 60fps, 100fps, 119.880fps, and 120fps. Lower resolution 'time_base's do not produce exact integers for such a broad range of frame rates. The AVRational value is stored as an integer numerator and an integer denominator. The ranges of those integers are sufficient to store 1 and 72,000. Beyond that, for this discussion it doesn't matter what their maximum values are. Well, per rational.h, 'num' & 'den' are both integers. Now, I don't know how '72' is stored. Is it stored as an int64? I don't know, but I do know that it can't be stored as an 8-bit integer or a 16-bit integer or anything else that has 8-bit or 16-bit resolution. That includes AVRational. 72 can't be stored as AVRational. AVRational just doesn't have enough resolution. Please prove me wrong! I hope you can, because in the proving you will expose what really happens when ffmpeg computes 'PTS's, and that's something I very much want to know. I think that the successful transcode of a 2:21:19 video confirms that the working time_base is sufficient. I suspect it's a float but of course I don't know that and I don't know its resolution. As we have discussed, PTS is stored as an int64_t, a signed integer with a size of 64 bits. The maximum value of an int64_t is (2^63)-1, about 9 billion billion (9.2 * 10^18). FFmpeg may reserve a few of the maximum and minimum values to indicate special conditions, but 9 billion billion will do. Again, my issue is with the resolution of TB, not the extent (range) of either TB or PTS. The time offset is calculated from an int64_t * (integer / integer). FFmpeg code can choose to store the result exactly as a rational number (assuming a numerator with a high enough maximum value), or approximately as an integer or a high-precision float, as the circumstances demand. With a time_base of 1/720,000 secs, a near-maximum PTS of 9 billion billion indicates a near-maximum time offset of a little over 396,000 years. I'm sure you know that the running time produced by 'PTS's depends on frame rate *and* time_base. For example, for 23.976fps and TB = 1/(72 ticks/s) = 1.3[8..] µs/tick, a PTS of +9223372036854775800 indicates a 307138595965860 maximum frame number. That frame number is reached by a 426581383 second video (= 13 years,
Re: [FFmpeg-user] repeat a frame
On 2021-03-03 14:57, Mark Filipak (ffmpeg) wrote: With TB = 1/(72 ticks/s), for a 24.976fps output, deltaPTS = (1001/24000 frames/s)/(1/(72 ticks/s)) = 30030 ticks/frame If working time_base (from the AVRational) has an effective resolution of int32 (i.e. ±2147483647 ticks), then frames past 0:49:42 will be dropped. I see what you are getting at, but you are using the wrong terminology for this software product, so your statements sound garbled. Remember that, in FFmpeg, the time_base is the time difference between frames, in seconds. It is an attribute of the stream, so its value does not change regardless of the length of the stream (unless something changes the time_base, creating a second stream derived from the first). Time_base is type AVRational, which is a rational number, not an integer, not a float. Instead of "working time_base", i think you mean "time offset". This is the number of seconds since the zero time. FFmpeg can get a lot done without calculating the time offset. Time offset = time_base * Presentation Timestamp (PTS). Thus, PTS = time offset / time_base. FFmpeg uses PTS values, related to the constant time_base, a lot. If working time_base has an effective resolution of uint32 (i.e. 4294967295 ticks), then frames past 1:39:26 will be dropped. When it comes to integers, "resolution" is not the right term to use. "Maximum value" and "minimum value" are the most comment. "range" or "capacity" might also be used. The number of bits in the integer is the "size". The AVRational value is stored as an integer numerator and an integer denominator. The ranges of those integers are sufficient to store 1 and 72,000. Beyond that, for this discussion it doesn't matter what their maximum values are. I think that the successful transcode of a 2:21:19 video confirms that the working time_base is sufficient. I suspect it's a float but of course I don't know that and I don't know its resolution. As we have discussed, PTS is stored as an int64_t, a signed integer with a size of 64 bits. The maximum value of an int64_t is (2^63)-1, about 9 billion billion (9.2 * 10^18). FFmpeg may reserve a few of the maximum and minimum values to indicate special conditions, but 9 billion billion will do. The time offset is calculated from an int64_t * (integer / integer). FFmpeg code can choose to store the result exactly as a rational number (assuming a numerator with a high enough maximum value), or approximately as an integer or a high-precision float, as the circumstances demand. With a time_base of 1/720,000 secs, a near-maximum PTS of 9 billion billion indicates a near-maximum time offset of a little over 396,000 years. Most of your films will likely be shorter than that. Best regards, —Jim DeLaHunt ___ 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] repeat a frame
On 2021-03-03 11:30, Mark Filipak (ffmpeg) wrote: On 2021-03-03 05:58, Moritz Barsnick wrote: On Tue, Mar 02, 2021 at 17:32:42 -0500, Mark Filipak (ffmpeg) wrote: Thank you, Jim. To the best of my knowledge, rational is not a 'C' datatype. No, but it is an ffmpeg data type, AVRational, as defined in libavutil/rational.h, along with functions to operate on this type. I need to know the dimension (or 'C' datatype) of TB as it is used in PTC calculations. Do you really need to know? Do you really need to ask? I've tried transcoding a 2:21:19 movie via this script: SET prep23=settb=expr=1/72,setpts=N*30030 SET cfr23=setpts=N*1001/24000/TB,fps=24000/1001 SET codecs=-codec:v libx265 -x265-params crf=16:qcomp=1.00 -codec:a copy -codec:s copy -dn ffmpeg -i i:\BDMV\STREAM\00303.m2ts -vf %prep23%,%cfr23% %codecs% test.mkv pause exit I succeeded. So, the working filter pipeline time_base -- whatever it is -- must have higher resolution than 32 bits. Why? With TB = 1/(72 ticks/s), for a 24.976fps output, deltaPTS = (1001/24000 frames/s)/(1/(72 ticks/s)) = 30030 ticks/frame If working time_base (from the AVRational) has an effective resolution of int32 (i.e. +/-2147483647 ticks), then frames past 0:49:42 will be dropped. If working time_base has an effective resolution of uint32 (i.e. 4294967295 ticks), then frames past 1:39:26 will be dropped. I think that the successful transcode of a 2:21:19 video confirms that the working time_base is sufficient. I suspect it's a float but of course I don't know that and I don't know its resolution. Why 72? TB = 1/(72 ticks/s) guarantees that 'PTS's will be exact integers for a wide variety of source and intermediate frame rates. Of course the MKV output resolution is 1 milliseconds, but I'm essentially setting the pipeline's resolution to 1.3[8..] microseconds. You know, I've transcoded a great number of movies and many wind up VFR. I think that's bogus, resulting from loss of pipeline resolution. Has anyone actually encountered a professionally mastered source video that is VFR. I haven't. ___ 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] repeat a frame
On 2021-03-03 05:58, Moritz Barsnick wrote: On Tue, Mar 02, 2021 at 17:32:42 -0500, Mark Filipak (ffmpeg) wrote: Thank you, Jim. To the best of my knowledge, rational is not a 'C' datatype. No, but it is an ffmpeg data type, AVRational, as defined in libavutil/rational.h, along with functions to operate on this type. I need to know the dimension (or 'C' datatype) of TB as it is used in PTC calculations. Do you really need to know? Do you really need to ask? ___ 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] repeat a frame
On Tue, Mar 02, 2021 at 17:32:42 -0500, Mark Filipak (ffmpeg) wrote: > Thank you, Jim. To the best of my knowledge, rational is not a 'C' datatype. No, but it is an ffmpeg data type, AVRational, as defined in libavutil/rational.h, along with functions to operate on this type. > I need to know the dimension (or 'C' datatype) of TB as it is used in PTC > calculations. Do you really need to know? Cheers, Moritz ___ 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] repeat a frame
On 2021-03-02 16:34, Jim DeLaHunt wrote: On 2021-03-02 13:13, Mark Filipak (ffmpeg) wrote: On 2021-03-02 15:18, Carl Eugen Hoyos wrote: …timebase is not 64bit, I believe this was already mentioned. No, it has not been mentioned. Mark, I can point to three times it has been mentioned, in the last month, in threads which you initiated. 1. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/051961.html On 2021-02-14 17:28, Paul B Mahol wrote: You need TB aka timebase too. TB is rational. PTS is 64bit integer. 2. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/052097.html On 2021-02-22 21:01, Jim DeLaHunt wrote: The Presentation Time Stamp (PTS) value which FFmpeg associates with video frames and audio data is a 64-bit integer. There is an associated time base attribute for each video or audio stream, which gives the number of seconds between successive values of PTS. This time base might be thought of as the resolution of PTS. Thus if you have two PTS values pts1 and pts2, then the difference in seconds between them is (pts2-pts1)*time_base. The time base can be represented as a rational number, e.g. 1001/3.… 3. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/052161.html On 2021-02-26 17:32, Jim DeLaHunt wrote: As I told you back on 23. February, ffmpeg uses a timebase that is a rational number, and is an attribute of the video stream, and can take various values. The timebase could be 1/36, or 1/24, or 1001/24000. Thank you, Jim. To the best of my knowledge, rational is not a 'C' datatype. I need to know the dimension (or 'C' datatype) of TB as it is used in PTC calculations. ___ 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] repeat a frame
On 2021-03-02 13:13, Mark Filipak (ffmpeg) wrote: On 2021-03-02 15:18, Carl Eugen Hoyos wrote: …timebase is not 64bit, I believe this was already mentioned. No, it has not been mentioned. Mark, I can point to three times it has been mentioned, in the last month, in threads which you initiated. 1. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/051961.html On 2021-02-14 17:28, Paul B Mahol wrote: You need TB aka timebase too. TB is rational. PTS is 64bit integer. 2. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/052097.html On 2021-02-22 21:01, Jim DeLaHunt wrote: The Presentation Time Stamp (PTS) value which FFmpeg associates with video frames and audio data is a 64-bit integer. There is an associated time base attribute for each video or audio stream, which gives the number of seconds between successive values of PTS. This time base might be thought of as the resolution of PTS. Thus if you have two PTS values pts1 and pts2, then the difference in seconds between them is (pts2-pts1)*time_base. The time base can be represented as a rational number, e.g. 1001/3.… 3. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/052161.html On 2021-02-26 17:32, Jim DeLaHunt wrote: As I told you back on 23. February, ffmpeg uses a timebase that is a rational number, and is an attribute of the video stream, and can take various values. The timebase could be 1/36, or 1/24, or 1001/24000. Best regards, —Jim DeLaHunt ___ 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] repeat a frame
On 2021-03-02 15:18, Carl Eugen Hoyos wrote: Am Di., 2. März 2021 um 20:51 Uhr schrieb Mark Filipak (ffmpeg) : On 2021-03-02 13:31, Carl Eugen Hoyos wrote: Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg) : I've searched the docs one-by-one. I seek a simpler way to repeat a frame. Increase the frame rate, either with the fps filter or the ffmpeg option "-r". They differ in their greediness and verbosity on the status line. Thank you, Carl Eugen, I have noted that reality. Since I've assumed that AVFrame *is* the format of the frames in the filter pipeline (and therefore int64_t), and based on an assumption that TB is also 64 bits, I've adopted TB = 1/(72 ticks/s)... timebase is not 64bit, I believe this was already mentioned. No, it has not been mentioned. What is the struct name of frames in the filter pipeline? What is the name of the struct that includes time base? ___ 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] repeat a frame
Am Di., 2. März 2021 um 20:51 Uhr schrieb Mark Filipak (ffmpeg) : > > On 2021-03-02 13:31, Carl Eugen Hoyos wrote: > > Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg) > > : > >> > >> I've searched the docs one-by-one. I seek a simpler way to repeat a frame. > > > > Increase the frame rate, either with the fps filter or the ffmpeg option > > "-r". > > They differ in their greediness and verbosity on the status line. > > Thank you, Carl Eugen, I have noted that reality. > > Since I've assumed that AVFrame *is* the format of the frames in the filter > pipeline (and therefore int64_t), and based on an assumption that TB is > also 64 bits, I've adopted TB = 1/(72 ticks/s)... timebase is not 64bit, I believe this was already mentioned. > ...so, for a 24fps CFR INPUT to a 24fps CFR OUTPUT for example, If your input is cfr and you want cfr output, there should be no reason to mess with timestamps. > ffmpeg -i INPUT -vf > settb=expr=1/72,setpts=N*3...setpts=N/24/TB,fps=24 OUTPUT In addition to above, note that setpts is rarely a good idea as it is supposed to break A/V sync. Using the filter several times does not improve the situation. Perhaps you should go back several (dozen) steps: You have already explained that you have little interest in becoming a C programmer (which is 100% reasonable), you therefore should not be interested in the internal representations of FFmpeg (no, you cannot improve them: The people who have written this code most likely understand analog video as good as you but they are light years ahead of you concerning digital video). It is possible you have found other bugs in FFmpeg (many exist and you have already found two or three). If you want us to improve the project, simply post the command line you tested including the complete, uncut console output and explain what you don't like in the output file. (You would have avoided a lot of flames lately...) The fact that you cannot force a timebase when writing to Matroska is not a bug that you have to report. Carl Eugen ___ 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] repeat a frame
On 2021-03-02 13:31, Carl Eugen Hoyos wrote: Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg) : I've searched the docs one-by-one. I seek a simpler way to repeat a frame. Increase the frame rate, either with the fps filter or the ffmpeg option "-r". They differ in their greediness and verbosity on the status line. Thank you, Carl Eugen, I have noted that reality. Since I've assumed that AVFrame *is* the format of the frames in the filter pipeline (and therefore int64_t), and based on an assumption that TB is also 64 bits, I've adopted TB = 1/(72 ticks/s)... ...so, for a 24fps CFR INPUT to a 24fps CFR OUTPUT for example, ffmpeg -i INPUT -vf settb=expr=1/72,setpts=N*3...setpts=N/24/TB,fps=24 OUTPUT sets a high resolution TB in the pipeline. With 'settb=expr=1/72,setpts=N*3' to prep the pipeline, and 'setpts=N/24/TB,fps=24' to terminate the pipeline, I've been doing temporally-perfect manipulations of frames and fields that don't produce VFR in the encoder. ___ 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] repeat a frame
Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg) : > > I've searched the docs one-by-one. I seek a simpler way to repeat a frame. Increase the frame rate, either with the fps filter or the ffmpeg option "-r". They differ in their greediness and verbosity on the status line. Carl Eugen ___ 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] repeat a frame
On 2021-03-02 11:53, Paul B Mahol wrote: On Tue, Mar 2, 2021 at 5:50 PM Mark Filipak (ffmpeg) wrote: I've searched the docs one-by-one. I seek a simpler way to repeat a frame. This: split[1][2],[1]setpts=(N+floor(N/4))/FR/TB[3],[2]select=eq(mod(n\,4)\,3),setpts=(N*5+4)/FR/TB[4],[3][4]interleave works, but perhaps there's an easier way that I'm just not seeing. What timestamps repeated frame should have? Hey Paul. Thanks. 'PTS's don't matter. I can manipulate 'TB' & 'PTS's as needed ...The stream is CFR. If 'shuffleframes' could insert frames, for example shuffleframes=0 1 2 3 +3 I'd do that, but 'shuffleframes' doesn't have a '+' operator. I do have a method that works (above). I'm just wondering whether there's a simpler way. Thanks! ___ 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] repeat a frame
On Tue, Mar 2, 2021 at 5:50 PM Mark Filipak (ffmpeg) wrote: > I've searched the docs one-by-one. I seek a simpler way to repeat a frame. > > This: > > > split[1][2],[1]setpts=(N+floor(N/4))/FR/TB[3],[2]select=eq(mod(n\,4)\,3),setpts=(N*5+4)/FR/TB[4],[3][4]interleave > > works, but perhaps there's an easier way that I'm just not seeing. > What timestamps repeated frame should have? > > Suggestions are welcome. Thanks! > > - Mark. > ___ > 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] repeat a frame
I've searched the docs one-by-one. I seek a simpler way to repeat a frame. This: split[1][2],[1]setpts=(N+floor(N/4))/FR/TB[3],[2]select=eq(mod(n\,4)\,3),setpts=(N*5+4)/FR/TB[4],[3][4]interleave works, but perhaps there's an easier way that I'm just not seeing. Suggestions are welcome. Thanks! - Mark. ___ 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".
