Recherche avancée

Sur d’autres sites (7747)

• Export .osp OpenShot project to ffmpeg script as workaround to video export freeze or crash by swap hell

  30 août 2018, par 1000i100

  I have a big video rush 35".

  With OpenShot i’ve cut more than 30 small sequences and concatenate them into one 25" sequence.

  Now i try to export the result as video file but OneShot randomly crash or freeze during the export/encoding between 40% and 80% so after more than an hour of encoding. It look to be a memory leek and a swap saturation with memory allocation deny because no space left.

  I’ve tried with x264(mp4) and vp8(webm) encoding, but nothing worked.

  I’ve opened the .osp file, it’s a big json file with all the clips referred like this :

  {
  
    clips:[
  
      {
  
        title: "",
  
        start:<seconds>.<decimals>,
  
        end:<seconds>.<decimals>,
  
        position:<seconds>.<decimals>
  
      }
  
    ]
  
  }
  
  </decimals></seconds></decimals></seconds></decimals></seconds>

  • title if not renamed is the inputFileName.
  • start clip start time from the input file beginning
  • end clip end time from the input file beginning
  • position clip start position in the output file timeline

  I’ve read ffmpeg can extract video parts / subclip / sequences with cut function :

  ffmpeg -ss 00:00:09.000 -i input.mp4 -to 00:00:20 output.mp4

  Time can be hh:mm:ss.xxx or hh:mm:ss or any amount of seconds, allowing decimals.

  I’ve also read ffmpeg can concat sequences :

  ffmpeg -i "concat:input1.ts|input2.ts|input3.ts" output.ts

  So, how to encode my video with these project data ?

• ffmpeg same bit rate in hls file across resolutions

  4 août 2019, par Saurabh

  We are using following command to generate dash and hls file for a given video :

  ffmpeg -y -nostdin -loglevel error -i input.mp4 \
  
          -map 0:v:0  -map 0:v:0 -map 0:v:0  -map 0:v:0  -map 0:v:0  -map 0:v:0 -map 0:a\?:0  \
  
          -maxrate:v:0 350k -bufsize:v:0 700k  -c:v:0 libx264 -filter:v:0 "scale=320:-2"  \
  
          -maxrate:v:1 1000k -bufsize:v:0 2000k -c:v:1 libx264 -filter:v:1 "scale=640:-2"  \
  
          -maxrate:v:2 3000k -bufsize:v:0 6000k -c:v:2 libx264 -filter:v:2 "scale=1280:-2" \
  
          -maxrate:v:3 245k -bufsize:v:3 600k -c:v:3 libvpx-vp9 -filter:v:3 "scale=320:-2"  \
  
          -maxrate:v:4 700k  -bufsize:v:3 1400k -c:v:4 libvpx-vp9 -filter:v:4 "scale=640:-2"  \
  
          -maxrate:v:5 2100k -bufsize:v:3 4200k -c:v:5 libvpx-vp9 -filter:v:5 "scale=1280:-2"  \
  
          -use_timeline 1 -use_template 1 -adaptation_sets "id=0,streams=v  id=1,streams=a" \
  
          -threads 8 -seg_duration 5 -hls_playlist true -f dash output/output.mpd

  This works and generates hls files also as expected, one sample m3u8 file below :

  #EXTM3U
  
  #EXT-X-VERSION:7
  
  #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_A1",NAME="audio_6",DEFAULT=YES,URI="media_6.m3u8"
  
  #EXT-X-STREAM-INF:BANDWIDTH=129663,RESOLUTION=320x168,CODECS="avc1.64000c,mp4a.40.2",AUDIO="group_A1"
  
  media_0.m3u8
  
  
  
  #EXT-X-STREAM-INF:BANDWIDTH=129663,RESOLUTION=640x336,CODECS="avc1.64001e,mp4a.40.2",AUDIO="group_A1"
  
  media_1.m3u8
  
  
  
  #EXT-X-STREAM-INF:BANDWIDTH=129663,RESOLUTION=1280x670,CODECS="avc1.64001f,mp4a.40.2",AUDIO="group_A1"
  
  media_2.m3u8
  
  
  
  #EXT-X-STREAM-INF:BANDWIDTH=330756,RESOLUTION=320x168,CODECS="vp09.00.11.08,mp4a.40.2",AUDIO="group_A1"
  
  media_3.m3u8
  
  
  
  #EXT-X-STREAM-INF:BANDWIDTH=329663,RESOLUTION=640x336,CODECS="vp09.00.21.08,mp4a.40.2",AUDIO="group_A1"
  
  media_4.m3u8
  
  
  
  #EXT-X-STREAM-INF:BANDWIDTH=329663,RESOLUTION=1280x670,CODECS="vp09.00.31.08,mp4a.40.2",AUDIO="group_A1"
  
  media_5.m3u8

  Now as you notice, the Bandwidth is same for resolution of 320x168, 640x336 and 1280x670, which might have happened because of nature of video.

  But the issue with this is in iOS’s AVPlayer it always picks the minimum resolution one and never picks the better resolution stream even if it is available because of same bitrate.

  So the question I want to ask is : is there some option available to ensure - I always have some difference in the bitrates of different resolutions or more specific, bit rate always increase(may be just by few bytes) for increasing resolutions.

  ---

  EDIT

  Earlier I was using -b:v option per output instead of -maxrate:v, I was getting following output for same video :

  #EXT-X-STREAM-INF:BANDWIDTH=479663,RESOLUTION=320x168,CODECS="avc1.64000c,mp4a.40.2",AUDIO="group_A1"
  
  media_0.m3u8
  
  
  
  #EXT-X-STREAM-INF:BANDWIDTH=1129663,RESOLUTION=640x336,CODECS="avc1.64001e,mp4a.40.2",AUDIO="group_A1"
  
  media_1.m3u8
  
  
  
  #EXT-X-STREAM-INF:BANDWIDTH=3129663,RESOLUTION=1280x670,CODECS="avc1.64001f,mp4a.40.2",AUDIO="group_A1"
  
  media_2.m3u8

  If you see, Bandwidth has increased considerably, for the same video and same video quality, also all the file sizes also increased 4x. as par my understanding with maxrate option, ffmpeg optimises the output and provides only required bandwidth, while with b:v option it forcefully increases the bandwidth to given values without any benefit in terms of quality. So essentially you get same quality video at much higher bandwidth.

  Which is why I want to use maxrate option but with increasing bandwidth. If I manually change the bandwidth to increasing order in the output with maxrate option, adaptive bit rate starts to work in iOS’s AVPlayer.

• avformat/matroskaenc : Avoid unnecessary seek

  29 décembre 2019, par Andreas Rheinhardt

  avformat/matroskaenc : Avoid unnecessary seek
  When writing the SeekHead (a form of index) at the end of the muxing
  
  process, mkv_write_seekhead() would first seek to the position where the
  
  SeekHead ought to be written, then write it there and seek back to the
  
  original position afterwards. Which means : To the end of the file.
  
  Afterwards, a seek to the beginning of the file is performed to update
  
  further values. This of course means that the second seek in
  
  mkv_write_seekhead() was unnecessary.
  This has been changed : A new parameter was added to mkv_write_seekhead()
  
  containing the destination for the second seek, effectively eliminating
  
  the seek to the end of the file after writing the SeekHead.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c