repeat a frame

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

repeat a frame

Mark Filipak (ffmpeg)
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Paul B Mahol
On Tue, Mar 2, 2021 at 5:50 PM Mark Filipak (ffmpeg) <[hidden email]>
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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
On 2021-03-02 11:53, Paul B Mahol wrote:

> On Tue, Mar 2, 2021 at 5:50 PM Mark Filipak (ffmpeg) <[hidden email]>
> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Carl Eugen Hoyos-2
In reply to this post by Mark Filipak (ffmpeg)
Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg)
<[hidden email]>:
>
> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

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)
> <[hidden email]>:
>>
>> 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/(720000 ticks/s)...

...so, for a 24fps CFR INPUT to a 24fps CFR OUTPUT for example,

ffmpeg -i INPUT -vf settb=expr=1/720000,setpts=N*30000...setpts=N/24/TB,fps=24 OUTPUT

sets a high resolution TB in the pipeline. With 'settb=expr=1/720000,setpts=N*30000' 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Carl Eugen Hoyos-2
Am Di., 2. März 2021 um 20:51 Uhr schrieb Mark Filipak (ffmpeg)
<[hidden email]>:

>
> On 2021-03-02 13:31, Carl Eugen Hoyos wrote:
> > Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg)
> > <[hidden email]>:
> >>
> >> 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/(720000 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/720000,setpts=N*30000...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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
On 2021-03-02 15:18, Carl Eugen Hoyos wrote:

> Am Di., 2. März 2021 um 20:51 Uhr schrieb Mark Filipak (ffmpeg)
> <[hidden email]>:
>>
>> On 2021-03-02 13:31, Carl Eugen Hoyos wrote:
>>> Am Di., 2. März 2021 um 17:50 Uhr schrieb Mark Filipak (ffmpeg)
>>> <[hidden email]>:
>>>>
>>>> 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/(720000 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Jim DeLaHunt-2
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/30000.…


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/360000, or 1/24, or 1001/24000.


Best regards,
       —Jim DeLaHunt


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
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/30000.…
>
>
> 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/360000, 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Moritz Barsnick
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
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/720000,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/(720000 ticks/s), for a 24.976fps output,
deltaPTS = (1001/24000 frames/s)/(1/(720000 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 720000? TB = 1/(720000 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Jim DeLaHunt-2
On 2021-03-03 14:57, Mark Filipak (ffmpeg) wrote:
> With TB = 1/(720000 ticks/s), for a 24.976fps output,
> deltaPTS = (1001/24000 frames/s)/(1/(720000 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
On 2021-03-04 01:05, Jim DeLaHunt wrote:

> On 2021-03-03 14:57, Mark Filipak (ffmpeg) wrote:
>> With TB = 1/(720000 ticks/s), for a 24.976fps output,
>> deltaPTS = (1001/24000 frames/s)/(1/(720000 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/(90000 ticks/s) = 11.[1..] µs/tick is the
time_base for mpeg2video.

What I'm using is TB = 1/(720000 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 '720000' 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. 720000 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/(720000 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, 189 days, 49 minutes, 43 seconds). Such an improbable
running time is a consequence of PTS being an int64. it has no bearing on temporal resolution. The
temporal resolution is 1.3[8..] µs/tick (or, for 23.976fps CFR, deltaPTS = 30030).

> Most of your films will likely be shorter than that.

Do you agree with my figures? Do you see the difference between time extents and time resolution?
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Moritz Barsnick
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 '720000' 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 720000, that's correct.

> That includes AVRational. 720000 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/720000
is probably stored as { 1, 720000 }, but could also be { 2, 1400000 }
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/(720000 ticks/s)
> = 1.3[8..] µs/tick, a PTS of +9223372036854775800 indicates a
> 307138595965860 maximum frame number.

Huh? At 720000 ticks/seconds, and PTS being number of ticks, you can
create timestamps spanning
(2^63 - 1) / 720000 seconds
which is
~12810238940076 seconds
which is
~400000 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Michael Koch
In reply to this post by Mark Filipak (ffmpeg)
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/720000,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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Peter White
In reply to this post by Mark Filipak (ffmpeg)
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
In reply to this post by Michael Koch
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/720000,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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
In reply to this post by Peter White
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: repeat a frame

Mark Filipak (ffmpeg)
In reply to this post by Moritz Barsnick
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 '720000' 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 720000, that's correct.
>
>> That includes AVRational. 720000 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/720000
> is probably stored as { 1, 720000 }, but could also be { 2, 1400000 }
> 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/(720000 ticks/s)
>> = 1.3[8..] µs/tick, a PTS of +9223372036854775800 indicates a
>> 307138595965860 maximum frame number.
>
> Huh? At 720000 ticks/seconds, and PTS being number of ticks, you can
> create timestamps spanning
> (2^63 - 1) / 720000 seconds
> which is
> ~12810238940076 seconds
> which is
> ~400000 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12