segment_atclocktime problem

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

segment_atclocktime problem

Tom Worster
I'm using ffmpeg to connect to an icecast server and save its AAC audio
stream to m4a files each 5 minutes long.

Occasionally, about 1 in 15 or 20 files, the name of the file has
timestamp one second after the desired atclocktime, like

name-20201115T144500Z.m4a
name-20201115T145000Z.m4a
name-20201115T145500Z.m4a
name-20201115T150000Z.m4a
name-20201115T150501Z.m4a

I do not have this issue with MP3 shoutcast/icecast streams.

What can I do to prevent this and get ffmpeg to write files with the
atclocktime? instead of what I assume is the actual time when the file
is written.

ffmpeg \
-i http://icecast.ser.ver/mount \
-c copy \
-f segment \
-segment_format_options movflags=+faststart \
-segment_time 300 \
-segment_atclocktime 1 \
-break_non_keyframes 1 \
-strftime 1 \
name-%G%m%dT%H%M%SZ.m4a

When working with an MP3 stream the command has segment_format_options
write_xing=0 and mp3 output file extension.

Tom
_______________________________________________
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: segment_atclocktime problem

Carl Zwanzig
On 11/15/2020 9:41 AM, Tom Worster wrote:
>
> What can I do to prevent this and get ffmpeg to write files with the
> atclocktime? instead of what I assume is the actual time when the file is
> written.

Depending on the actual implementation, you might not be able to- it's
common to write into a temp file and at the trigger time close & rename,
which takes some time; that rename could happen after a seconds boundary
depending on system load. Someone would need to look at the code to really know.

You may be better off with a cron job that looks for "01" files and renames
them; run every segment_time but a few seconds delayed; something like
"rename 01.m4a 00.m4a *.m4a".

(probably not relevant here, but it's always good to post the full command
output)

Later,

z!

_______________________________________________
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: segment_atclocktime problem

Tom Worster
On 11/16/2020 1:03:41 AM, "Carl Zwanzig" <[hidden email]> wrote:

>On 11/15/2020 9:41 AM, Tom Worster wrote:
>>
>>What can I do to prevent this and get ffmpeg to write files with the atclocktime? instead of what I assume is the actual time when the file is written.
>
>Depending on the actual implementation, you might not be able to- it's common to write into a temp file and at the trigger time close & rename, which takes some time; that rename could happen after a seconds boundary depending on system load. Someone would need to look at the code to really know.
That makes sense. movflags=+faststart may be contributing significantly
to the delay in completing each file. The MP3 streams don't have that so
maybe that explains why they don't have a 01 problem.


>  You may be better off with a cron job that looks for "01" files and renames them; run every segment_time but a few seconds delayed; something like "rename 01.m4a 00.m4a *.m4a".
Yes. I put that into the script I already had for moving moving the
files from ec2 to s3.

Thanks, z!

Tom

_______________________________________________
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".