Replacing stream input when using segment time option

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

Replacing stream input when using segment time option

jamesfowkes
Hello all,

We have an application using ffmpeg to record an RTSP stream. We split this
stream into timestamped segments using the following options:

ffmpeg -f segment -segment_time 60 -strftime 1 "+%Y-%m-%d_%H-%M-%S.mp4"

We now have a requirement to replace recordings made using this stream with
a placeholder blank video under certain conditions (for privacy reasons).
This needs to be recorded using the same segment time options so that later
post- processing can treat the files the same and not have to know which is
"real" video and which is placeholder. The switchover does not have to be
seamless, it's OK to stop one ffmpeg process and start another.

I'm comfortable with ffmpeg basics, but this is a bit beyond my knowledge.
I'm not sure of the best way to do things.

Is the easiest way to have one instance of ffmpeg acting as a streaming
server for the placeholder video (using -stream_loop maybe?) and then
switch to recording from this stream when required? Or am I overthinking
this?

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: Replacing stream input when using segment time option

jamesfowkes
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.

If I add the "-re" and "-vsync  0" options:

ffmpeg -re -vsync 0 -loop 1 -i frame.png -reset_timestamps 1 -vcodec libx264
-f segment -segment_time 60 -strftime 1 +%Y-%m-%d_%H-%M-%S.mp4

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.

Is there a way to get an exact 1x encoding speed in this case?




--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
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: Replacing stream input when using segment time option

Moritz Barsnick
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
[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: Replacing stream input when using segment time option

jamesfowkes
> 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 <[hidden email]> 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
> [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".