[FFmpeg-user] Replacing stream input when using segment time option

[James Fowkes]

> That means you want your segments to not be finished too early? Is that
> really a requirement?

Essentially yes - this is to generate placeholder videos that would
otherwise be coming from an IP camera.
The timestamped videos are used in later post-processing and if the videos
are not generated at 60-second intervals, the timestamps on the files don't
match the cumulative elapsed time of the videos.
I was hoping to basically keep all the post-processing the same regardless
of the video source, which means keeping the segments at 60-second
intervals.

> Why did you add the vsync option? What did it change (without "-re")?

I was trying some suggestions from this reddit thread
<https://www.reddit.com/r/ffmpeg/comments/a8l78y/limit_ffmpeg_capture_speed_to_realtime_1x/>.
It didn't seem to change much anything, but I'm basically shooting in the
dark here.

> I don't see why this should not hit 1.0x, except for slight variations.

It's mainly the first video that's off. The processing starts about about
0.3x and pretty quickly gets to 0.95x and then keeps increasing to about
0.98x over the rest of the first segment. Leaving it running for ages, it
does increase to 0.99x, so maybe it would get to 1.0x eventually.

>You could try the "realtime" filter instead of "-re". It defaults to
> 1.0x and might hit more precisely.

There's no particular difference in the speed (using realtime=speed=1.0),
but it did emit this line:

[Parsed_realtime_0 @ 0x55a8a7675c40] time discontinuity detected: -1994741
us, resetting

during processing of the first segment. That time (just under 2s) is
roughly the time that is "lost" during the slow processing of the first
segment.

I increased the multiplier to realtime=speed=1.1, just to make any
differences easier to see. I then get a lot more of those discontinuity
messages. But there is no discernable difference in the output - the first
file has the same issue of taking slightly longer to process than desired.

On Fri, 16 Oct 2020 at 10:21, Moritz Barsnick <barsnick at gmx.net> wrote:

> Hi James,
>
> On Fri, Oct 16, 2020 at 03:11:36 -0500, jamesfowkes wrote:
> > Further to this, I've managed to get a still frame to record into
> timestamped
> > segments using:
> >
> > ffmpeg -loop 1 -i frame.png -reset_timestamps 1 -vcodec libx264 -f
> segment
> > -segment_time 60 -strftime 1 +%Y-%m-%d_%H-%M-%S.mp4
> >
> > But while the segments are 60 seconds of wallclock time long, they are
> > record much faster than that, taking (on my laptop) about 30 seconds to
> > actually record, meaning I have ~120 seconds of video every 60 seconds of
> > elapsed wallclock time.
>
> That means you want your segments to not be finished too early? Is that
> really a requirement?
>
> > If I add the "-re" and "-vsync  0" options:
>
> Why did you add the vsync option? What did it change (without "-re")?
>
> > The speed is just slightly lower than 1x (around 0.98x), resulting in
> very
> > slightly truncated files. This is no so much of an issue, but again
> would be
> > good to solve.
>
> I don't see why this should not hit 1.0x, except for slight variations.
> You could try the "realtime" filter instead of "-re". It defaults to
> 1.0x and might hit more precisely. If not, you can manipulate it with
> its "speed" parameter, e.g. "-vf realtime=speed=1.01".
>
> Cheers,
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".