Hey Carl, That command took the following time:
real 3m19.316s user 3m14.730s sys 0m1.830s I'm curious about your thoughts on this. With -codec copy, the decoder should not be involved, so it shouldn't be a bottleneck. I'm wondering if the extra file I/O is the culprit here? Either in writing more logs or not buffering enough content in RAM to write out to disk in larger bursts. Ronak > On Jun 20, 2018, at 12:12 PM, Carl Eugen Hoyos <[email protected]> wrote: > > 2018-06-20 16:51 GMT+02:00, Ronak <[email protected]>: > >> Ffmpeg -I "${FILE}.mp4" -codec copy -f dash -single_file_name >> "${FILE}_1sec.m4s" -min_seg_duration 975238.095238095 -hls_playlist 1 >> "${FILE}_1sec.mpd" >> >> Here's an abbreviated dump of the logs for a 52:15:29.84 hour audio file. >> You can find the full log here: >> https://drive.google.com/open?id=13GyppqvUJRYQNG9XhJ0feDATjvL1FvFf >> <https://drive.google.com/open?id=13GyppqvUJRYQNG9XhJ0feDATjvL1FvFf> >> >> To note, this file took over 1 day to fragment, which is totally not >> acceptable for our SLAs. > > Understandably. > Please also test the following: > $ ffmpeg -i bk_argo_001199_44_64.mp4 -f null - > > Carl Eugen > _______________________________________________ > ffmpeg-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
