Re: [FFmpeg-user] fMP4 generation speed

> On Jul 12, 2018, at 6:21 PM, Ronak Patel > wrote: > > Hey Carl, > > So I dug into this more today and I have root caused what's exactly happening > here. > > The problematic code is this: > https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 >

Re: [FFmpeg-user] fMP4 generation speed

Hey Carl, So I dug into this more today and I have root caused what's exactly happening here. The problematic code is this: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 This is where the

Re: [FFmpeg-user] fMP4 generation speed

> On Jun 27, 2018, at 1:50 AM, Carl Zwanzig wrote: > > On 6/26/2018 9:20 PM, Ronak wrote: >> The temp files are made in the CWD. And they are constantly created and >> destroyed for every single fragment it seems. I looked into the ffmpeg >> code and it looks like every single method in hlsenc

Re: [FFmpeg-user] fMP4 generation speed

On 6/26/2018 9:20 PM, Ronak wrote: The temp files are made in the CWD. And they are constantly created and destroyed for every single fragment it seems. I looked into the ffmpeg code and it looks like every single method in hlsenc and dashenc opens and closes these file handles. I would like to

Re: [FFmpeg-user] fMP4 generation speed

On 27-06-2018 09:50 AM, Ronak wrote: Just to clarify, I'm making a single fMP4 file here; not multiple. Just to confirm. Test with the MP4 muxer and create a fragmented MP4 to check speed. Regards, Gyan ___ ffmpeg-user mailing list

Re: [FFmpeg-user] fMP4 generation speed

> On Jun 25, 2018, at 6:03 PM, Carl Zwanzig wrote: > > On 6/25/2018 2:41 PM, Carl Eugen Hoyos wrote: >> 2018-06-25 15:02 GMT+02:00, Ronak: >>> 1. Apple does not create temp files >> Isn't that generally a disadvantage? > > Why would it be (not creating temp files)? Seems sensible from here. >

Re: [FFmpeg-user] fMP4 generation speed

On 6/25/2018 2:41 PM, Carl Eugen Hoyos wrote: 2018-06-25 15:02 GMT+02:00, Ronak: 1. Apple does not create temp files Isn't that generally a disadvantage? Why would it be (not creating temp files)? Seems sensible from here. A better question is why, it appears, is ffmpeg making temp files

Re: [FFmpeg-user] fMP4 generation speed

On Monday, 25 June 2018, 22:41:42 BST, Carl Eugen Hoyos wrote: >2018-06-25 15:02 GMT+02:00, Ronak : >> 1. Apple does not create temp files >Isn't that generally a disadvantage? In an environment where people may be dealing with very large amounts of data, creating temp files is bad.

Re: [FFmpeg-user] fMP4 generation speed

2018-06-25 15:02 GMT+02:00, Ronak : > 1. Apple does not create temp files Isn't that generally a disadvantage? Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link

Re: [FFmpeg-user] fMP4 generation speed

2018-06-22 21:53 GMT+02:00, Ronak : > > >> On Jun 20, 2018, at 4:48 PM, Carl Eugen Hoyos wrote: >> >> 2018-06-20 18:37 GMT+02:00, Ronak : >> >>> That command took the following time: >>> >>> real3m19.316s >>> user3m14.730s >>> sys 0m1.830s >>> >>> I'm curious about your thoughts

Re: [FFmpeg-user] fMP4 generation speed

> On Jun 23, 2018, at 12:07 AM, Ronak wrote: > > > >> On Jun 22, 2018, at 7:59 PM, Ronak Patel wrote: >> >> >>> On Jun 22, 2018, at 5:03 PM, Carl Zwanzig wrote: >>> On 6/22/2018 1:37 PM, Ronak wrote: We have audio files that are more than 100 hours long, and we need them

Re: [FFmpeg-user] fMP4 generation speed

> On Jun 22, 2018, at 7:59 PM, Ronak Patel wrote: > > >> On Jun 22, 2018, at 5:03 PM, Carl Zwanzig wrote: >> >>> On 6/22/2018 1:37 PM, Ronak wrote: >>> We have audio files that are more than 100 hours long, and we need them >>> to be fragmented quickly. It totally seems like there's an I/O

Re: [FFmpeg-user] fMP4 generation speed

Sent from my iPhone > On Jun 22, 2018, at 5:03 PM, Carl Zwanzig wrote: > >> On 6/22/2018 1:37 PM, Ronak wrote: >> We have audio files that are more than 100 hours long, and we need them >> to be fragmented quickly. It totally seems like there's an I/O problem >> here because fragmentation is

Re: [FFmpeg-user] fMP4 generation speed

On 6/22/2018 1:37 PM, Ronak wrote: We have audio files that are more than 100 hours long, and we need them to be fragmented quickly. It totally seems like there's an I/O problem here because fragmentation is faster the longer we set our fragment size to. Sounds like it's time to break out iostat

Re: [FFmpeg-user] fMP4 generation speed

> On Jun 22, 2018, at 4:31 PM, Ronak wrote: > > > >> On Jun 22, 2018, at 3:59 PM, David Favor wrote: >> >> I'd say you're looking at a very long transcode time, >> as your video dump shows... >> >> Duration: 52:15:29.84, start: 0.00, bitrate: 63 kb/s >> >> So... a 52 hour video...

Re: [FFmpeg-user] fMP4 generation speed

> On Jun 22, 2018, at 3:59 PM, David Favor wrote: > > I'd say you're looking at a very long transcode time, > as your video dump shows... > > Duration: 52:15:29.84, start: 0.00, bitrate: 63 kb/s > > So... a 52 hour video... well... better fire up the popcorn > maker + settle in for a

Re: [FFmpeg-user] fMP4 generation speed

I'd say you're looking at a very long transcode time, as your video dump shows... Duration: 52:15:29.84, start: 0.00, bitrate: 63 kb/s So... a 52 hour video... well... better fire up the popcorn maker + settle in for a very long night... ___

Re: [FFmpeg-user] fMP4 generation speed

> On Jun 20, 2018, at 4:48 PM, Carl Eugen Hoyos wrote: > > 2018-06-20 18:37 GMT+02:00, Ronak : > >> 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

Re: [FFmpeg-user] fMP4 generation speed

On 6/20/2018 2:50 PM, Ronak wrote: What do you mean by top-post? I'm just responding to the email chain through the mailing list. What's the correct etiquette? Putting your reply _above_ what you're replying to (as you have done). It's more appropriate to put your reply _below_ and to remove

Re: [FFmpeg-user] fMP4 generation speed

What do you mean by top-post? I'm just responding to the email chain through the mailing list. What's the correct etiquette? > On Jun 20, 2018, at 4:48 PM, Carl Eugen Hoyos wrote: > > 2018-06-20 18:37 GMT+02:00, Ronak : > >> That command took the following time: >> >> real 3m19.316s >> user

Re: [FFmpeg-user] fMP4 generation speed

2018-06-20 18:37 GMT+02:00, Ronak : > 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. Yes. > I'm wondering if the

Re: [FFmpeg-user] fMP4 generation speed

Hey Carl, That command took the following time: real3m19.316s user3m14.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

Re: [FFmpeg-user] fMP4 generation speed

2018-06-20 16:51 GMT+02:00, Ronak : > 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

Re: [FFmpeg-user] fMP4 generation speed

Hi Gyan, This log is from this command: 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

Re: [FFmpeg-user] fMP4 generation speed

On 12-06-2018 11:59 PM, Ronak wrote: We've noticed that ffmpeg is really slow at segmenting the content at such a small fragmentation size. What's the reason behind this? Here's the command we're running: ffmpeg -i "${FILE}.mp4" -codec copy -hls_time 9.75238095238095 -hls_segment_type