fMP4 generation speed

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

fMP4 generation speed

Ronak Patel
Hi all,

So we're investigating using ffmpeg to generate fMP4 assets at a 1s fragmentation size for our audio content. Our content has no video.

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 fmp4 -hls_flags single_file+append_list -hls_playlist_type vod "${FILE}_10sec_v7.m3u8"

There's no encoding here, so what's causing ffmpeg to take so long?

Ronak
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Gyan Doshi


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 fmp4 -hls_flags single_file+append_list -hls_playlist_type vod "${FILE}_10sec_v7.m3u8"
>
> There's no encoding here, so what's causing ffmpeg to take so long?

What speed do you get? Share full log.


Regards,
Gyan
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel
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 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. Is there a way to cut this down to several minutes instead of days?

ffmpeg version N-91283-gdaf38d0 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
  configuration: --prefix=/home/ronakp/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/ronakp/ffmpeg_build/include --extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread --extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-nonfree
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 20.101 / 58. 20.101
  libavformat    58. 17.100 / 58. 17.100
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 25.100 /  7. 25.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bk_argo_001199_44_64.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isom
    creation_time   : 2016-10-20T23:05:48.000000Z
  Duration: 52:15:29.84, start: 0.000000, bitrate: 63 kb/s
    Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 61 kb/s (default)
    Metadata:
      creation_time   : 2016-10-20T23:04:25.000000Z
      handler_name    : awdenewlogo_aax_lc_44_64_2_y.aac - Imported with GPAC 0.5.0-rev00000
[dash @ 0x22c3fc0] The min_seg_duration option is deprecated and will be removed. Please use the -seg_duration
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for writing
Output #0, dash, to 'bk_argo_001199_44_64_1sec.mpd':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isom
    encoder         : Lavf58.17.100
    Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 61 kb/s (default)
    Metadata:
      creation_time   : 2016-10-20T23:04:25.000000Z
      handler_name    : awdenewlogo_aax_lc_44_64_2_y.aac - Imported with GPAC 0.5.0-rev00000
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=00:33:37.79 bitrate=N/A speed= 128x
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=00:34:36.30 bitrate=N/A speed= 128x
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=01:03:05.89 bitrate=N/A speed= 104x  
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
...
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=01:16:38.27 bitrate=N/A speed=95.4x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:38:49.04 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
...
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:38:56.84 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:04.64 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:12.44 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:20.25 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:28.05 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:35.85 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:43.65 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:51.45 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:39:58.28 bitrate=N/A speed=27.2x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=07:40:06.08 bitrate=N/A speed=27.2x    
...
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=14:40:36.49 bitrate=N/A speed=15.5x    
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=14:40:41.37 bitrate=N/A speed=15.5x    
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=14:40:46.24 bitrate=N/A speed=15.5x    
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=14:40:51.12 bitrate=N/A speed=15.5x    
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=14:40:56.00 bitrate=N/A speed=15.5x    
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.m4s' for reading
[dash @ 0x22c3e80] Opening 'bk_acx0_006556_22_32_1sec.mpd.tmp' for writing
[dash @ 0x22c3e80] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=14:41:00.87 bitrate=N/A speed=15.5x  
...
size=N/A time=52:15:27.35 bitrate=N/A speed=4.52x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=52:15:29.30 bitrate=N/A speed=4.52x    
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=52:15:29.81 bitrate=N/A speed=4.52x    
video:0kB audio:1414506kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

Ronak




> On Jun 12, 2018, at 2:48 PM, Gyan Doshi <[hidden email]> wrote:
>
>
>
> 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 fmp4 -hls_flags single_file+append_list -hls_playlist_type vod "${FILE}_10sec_v7.m3u8"
>> There's no encoding here, so what's causing ffmpeg to take so long?
>
> What speed do you get? Share full log.
>
>
> Regards,
> Gyan
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Carl Eugen Hoyos-2
2018-06-20 16:51 GMT+02:00, Ronak <[hidden email]>:

> 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
[hidden email]
http://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: fMP4 generation speed

Ronak Patel
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 <[hidden email]> wrote:
>
> 2018-06-20 16:51 GMT+02:00, Ronak <[hidden email]>:
>
>> 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
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Carl Eugen Hoyos-2
2018-06-20 18:37 GMT+02:00, Ronak <[hidden email]>:

> 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 extra file I/O is the culprit here?

Yes.

You can now specify "-loglevel verbose" to get some useful
I/O info at the end of the console output.

Please remember not to top-post here, Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel
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 <[hidden email]> wrote:
>
> 2018-06-20 18:37 GMT+02:00, Ronak <[hidden email]>:
>
>> 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 extra file I/O is the culprit here?
>
> Yes.
>
> You can now specify "-loglevel verbose" to get some useful
> I/O info at the end of the console output.
>
> Please remember not to top-post here, Carl Eugen
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Carl Zwanzig
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 extraneous text and
is the preferred style for this mailing list.

You can read about top- and bottom-posting at
https://en.wikipedia.org/wiki/Posting_style

z!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel
In reply to this post by Carl Eugen Hoyos-2


> On Jun 20, 2018, at 4:48 PM, Carl Eugen Hoyos <[hidden email]> wrote:
>
> 2018-06-20 18:37 GMT+02:00, Ronak <[hidden email]>:
>
>> 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 extra file I/O is the culprit here?
>
> Yes.
>
> You can now specify "-loglevel verbose" to get some useful
> I/O info at the end of the console output.
>
> Please remember not to top-post here, Carl Eugen


Hi Carl,

I got more logs, here's what I got:

[dash @ 0x22c3f80] Opening 'bk_potr_000006_22_64_1sec_test.m4s' for reading
[file @ 0x2382c80] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 4236 bytes read, 1 seeks
[dash @ 0x22c3f80] Representation 0 media segment 69894 written to: bk_potr_000006_22_64_1sec_test.m4s
[dash @ 0x22c3f80] Opening 'bk_potr_000006_22_64_1sec_test.mpd.tmp' for writing
[file @ 0x2382c80] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 0 seeks, 15 writeouts
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467754, dts 68162362630
size=N/A time=18:56:02.36 bitrate=N/A speed=9.37x    
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467755, dts 68162409070
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467756, dts 68162455510
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467757, dts 68162501950
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467758, dts 68162548390
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467759, dts 68162594830
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467760, dts 68162641270
No more output streams to write to, finishing.
[dash @ 0x22c3f80] Opening 'bk_potr_000006_22_64_1sec_test.m4s' for reading
[file @ 0x23540c0] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 0 bytes read, 1 seeks
[dash @ 0x22c3f80] Representation 0 media segment 69895 written to: bk_potr_000006_22_64_1sec_test.m4s
[dash @ 0x22c3f80] Opening 'bk_potr_000006_22_64_1sec_test.mpd.tmp' for writing
[file @ 0x2382c80] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 0 seeks, 15 writeouts
[AVIOContext @ 0x2310e80] Statistics: 0 seeks, 2107 writeouts
size=N/A time=18:56:02.64 bitrate=N/A speed=9.37x    
video:0kB audio:522488kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Input file #0 (bk_potr_000006_22_64.mp4):
  Input stream #0:0 (audio): 1467761 packets read (535027204 bytes);
  Total: 1467761 packets (535027204 bytes) demuxed
Output file #0 (bk_potr_000006_22_64_1sec_test.mpd):
  Output stream #0:0 (audio): 1467761 packets muxed (535027204 bytes);
  Total: 1467761 packets (535027204 bytes) muxed
0 frames successfully decoded, 0 decoding errors
[AVIOContext @ 0x22c72c0] Statistics: 541488832 bytes read, 2 seeks

This file took about 6 hours of clock time to get through on a 4 Core Computer running at 2.4 Ghz with 16 GB of RAM.

Are there any options for parallelization that we can use so the load is spread across the cores? Or does ffmpeg does this already?
If we're strictly I/O bound for this, is it possible to buffer more individual fragments in RAM before we write them out to disk?

Ronak

> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

David Favor
In reply to this post by Carl Zwanzig
I'd say you're looking at a very long transcode time,
as your video dump shows...

    Duration: 52:15:29.84, start: 0.000000, bitrate: 63 kb/s

So... a 52 hour video... well... better fire up the popcorn
maker + settle in for a very long night...
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel


> On Jun 22, 2018, at 3:59 PM, David Favor <[hidden email]> 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.000000, bitrate: 63 kb/s
>
> So... a 52 hour video... well... better fire up the popcorn
> maker + settle in for a very long night...


This is not video, only AAC audio. And there shouldn't be any transcoding here. I'm using -codec copy. We're going from MP4 -> fMP4 here.

> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel


> On Jun 22, 2018, at 4:31 PM, Ronak <[hidden email]> wrote:
>
>
>
>> On Jun 22, 2018, at 3:59 PM, David Favor <[hidden email]> 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.000000, bitrate: 63 kb/s
>>
>> So... a 52 hour video... well... better fire up the popcorn
>> maker + settle in for a very long night...
>
>
> This is not video, only AAC audio. And there shouldn't be any transcoding here. I'm using -codec copy. We're going from MP4 -> fMP4 here.

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.
I don't imagine the cost of creating more fMP4 boxes would tax the CPU and slow everything down.

>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Carl Zwanzig
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 or sar (or even dtrace) and do
some snooping.

Are you reading and writing to different drives?  (The usual metric for a
spinning drive is 150 IOPS for random access, RAID doesn't necessarily speed
that up.)

Later,

z!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel


Sent from my iPhone

> On Jun 22, 2018, at 5:03 PM, Carl Zwanzig <[hidden email]> 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 faster the longer we set our fragment size
>> to.
> Sounds like it's time to break out iostat or sar (or even dtrace) and do some snooping.
>
> Are you reading and writing to different drives?  (The usual metric for a spinning drive is 150 IOPS for random access, RAID doesn't necessarily speed that up.)
>

Nope it’s the same disk that we’re reading and writing to. I’m really curious why we can’t just buffer fragments in ram and write them out in larger bursts. Why not make this an option we can set?

This would simulate the performance for a 10 sec fragment size.

I’d imagine you have the same reading buffer regardless of the fragment size.

I’m thinking of running this on even more powerful machines to see if I can get the times down. But is it possible to get an option to tweak the output buffer size?

> Later,
>
> z!
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel


> On Jun 22, 2018, at 7:59 PM, Ronak Patel <[hidden email]> wrote:
>
>
>> On Jun 22, 2018, at 5:03 PM, Carl Zwanzig <[hidden email]> 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 faster the longer we set our fragment size
>>> to.
>> Sounds like it's time to break out iostat or sar (or even dtrace) and do some snooping.
>>
>> Are you reading and writing to different drives?  (The usual metric for a spinning drive is 150 IOPS for random access, RAID doesn't necessarily speed that up.)
>>
>
> Nope it’s the same disk that we’re reading and writing to. I’m really curious why we can’t just buffer fragments in ram and write them out in larger bursts. Why not make this an option we can set?
>
> This would simulate the performance for a 10 sec fragment size.
>
> I’d imagine you have the same reading buffer regardless of the fragment size.
>
> I’m thinking of running this on even more powerful machines to see if I can get the times down. But is it possible to get an option to tweak the output buffer size?
>

The problem is probably because of this:

[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
[dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
[dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing

Ffmpeg constantly makes this tmp files, and seems to be opening and closing the file handles constantly.
Is there a way to just keep the main files open and just keep appending to it? Why make temp files at all?

>> Later,
>>
>> z!
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Ronak Patel

> On Jun 23, 2018, at 12:07 AM, Ronak <[hidden email]> wrote:
>
>
>
>> On Jun 22, 2018, at 7:59 PM, Ronak Patel <[hidden email]> wrote:
>>
>>
>>> On Jun 22, 2018, at 5:03 PM, Carl Zwanzig <[hidden email]> 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 faster the longer we set our fragment size
>>>> to.
>>> Sounds like it's time to break out iostat or sar (or even dtrace) and do some snooping.
>>>
>>> Are you reading and writing to different drives?  (The usual metric for a spinning drive is 150 IOPS for random access, RAID doesn't necessarily speed that up.)
>>>
>>
>> Nope it’s the same disk that we’re reading and writing to. I’m really curious why we can’t just buffer fragments in ram and write them out in larger bursts. Why not make this an option we can set?
>>
>> This would simulate the performance for a 10 sec fragment size.
>>
>> I’d imagine you have the same reading buffer regardless of the fragment size.
>>
>> I’m thinking of running this on even more powerful machines to see if I can get the times down. But is it possible to get an option to tweak the output buffer size?
>>
>
> The problem is probably because of this:
>
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
>
> Ffmpeg constantly makes this tmp files, and seems to be opening and closing the file handles constantly.
> Is there a way to just keep the main files open and just keep appending to it? Why make temp files at all?
>

I just tested Apple's segmentation tools: mediafilesegmenter, and I can confirm that a 26 hour file took only:

real 1m35.576s
user 1m32.617s
sys 0m29.705s

time to fragment on a 2015 Macbook Pro 2.2 GHz, 16 GB of RAM.

The big differences I see are:

1. Apple does not create temp files nor open & close file handles repeatedly.
2. Apple does not write out sidx boxes, only moof for these fMP4 files. It seems like sidx boxes are not required when the content only contains audio. Is this true? Can ffmpeg be configured to skip generating them?
3. Apple's fragmentation is consistent. Every single fragment has exactly the same duration.
4. Apple sets the defaultSampleDuration in the moof atoms to 1024 for HE-AACv2 streams, the same as LC-AAC at the same sampling rate.

I would like to see how I can fix these 4 flaws in ffmpeg

Can anyone please give me pointers on which source files to look at and pointers on how to make these code changes?
I'd like to submit patches for these issues soon.

Thanks,

Ronak

>>> Later,
>>>
>>> z!
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user <http://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>>
>>> To unsubscribe, visit link above, or email
>>> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user <http://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email
> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Carl Eugen Hoyos-2
In reply to this post by Ronak Patel
2018-06-22 21:53 GMT+02:00, Ronak <[hidden email]>:

>
>
>> On Jun 20, 2018, at 4:48 PM, Carl Eugen Hoyos <[hidden email]> wrote:
>>
>> 2018-06-20 18:37 GMT+02:00, Ronak <[hidden email]>:
>>
>>> 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 extra file I/O is the culprit here?
>>
>> Yes.
>>
>> You can now specify "-loglevel verbose" to get some useful
>> I/O info at the end of the console output.

> [AVIOContext @ 0x23b9140] Statistics: 0 seeks, 15 writeouts
> [AVIOContext @ 0x2310e80] Statistics: 0 seeks, 2107 writeouts
> [AVIOContext @ 0x22c72c0] Statistics: 541488832 bytes read, 2 seeks

This indicates that nothing absurd with regard to seeking happens.

Try with different drives for input and output to make sure we know
the culprit.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Carl Eugen Hoyos-2
In reply to this post by Ronak Patel
2018-06-25 15:02 GMT+02:00, Ronak <[hidden email]>:

> 1. Apple does not create temp files

Isn't that generally a disadvantage?

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Phil Rhodes-3
 



On Monday, 25 June 2018, 22:41:42 BST, Carl Eugen Hoyos <[hidden email]> wrote:


>2018-06-25 15:02 GMT+02:00, Ronak <[hidden email]>:

>> 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.
Phil  
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: fMP4 generation speed

Carl Zwanzig
In reply to this post by Carl Eugen Hoyos-2
On 6/25/2018 2:41 PM, Carl Eugen Hoyos wrote:
> 2018-06-25 15:02 GMT+02:00, Ronak<[hidden email]>:
>> 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 and where
does it put them? If the files are created in the CWD and that's on a
spinning drive, it's going to be slow; OTOH if they're created in /tmp and
that's in a memory-resident file system it won't be much slower than just
keeping large buffers.

Anyway, different drives for source and output files is usually a very good
idea, as is a memory-resident /tmp file system (assuming you have the memory
to hold it). Another option is turn off atime on those file systems;
updating that can take up a lot of time and usually isn't useful.

Phil- I'm not sure I agree with you about temp files (in general), a lot
depends on the what/where/how-many files are being used.

Later,

z!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12