Recherche avancée

Sur d’autres sites (10993)

• HLS implementation with FFmpeg

  6 juin 2017, par Joseph K

  I am trying to implement HLS using FFmpeg for transcoding + segmenting but have been facing a couple of issues that have been bugging me for the past week.

  Issue

  Webserver currently receives live MP4 fragments being recorded on-the-go and needs to take care of transcoding and segmentation.

  As mp4 fragments are being received, they need to be encoded. Then segmented. If i run a segmenter (be it ffmpeg or apple mediastreamsegmenter), every mp4 fragment is being treated as a VOD by itself and I’m not being able to integrate them as part of a larger live event implementation.

  I thought of a solution where every time I receive an mp4 fragment, I first use fmpeg to concatenate it with previous ones to form the larger mp4 that I then pass to be segmented for HLS. That did not work either because the entire stream has to be re-segmented each and every time and existing TS fragments replaced by new ones that are similar yet shifted in time.

  Implementation 1

  ffmpeg -re -i fragmentX.mp4 -b:v 118k -b:a 32k -vcodec copy -preset:v veryfast -acodec aac -strict -2 -ac 2 -f mpegts -y fragmentX.ts

  I manage the m3u8 manifest on my own, deleting old fragments and appending new ones.

  When validating the stream, I find it stacked with EXT-X-DISCONTINUITY tags making the stream unwatchable.

  Implementation 2

  First combine latest fragment with overall.mp4

  ffmpeg -i "concat:newfragment.mp4|existing.mp4" -c copy overall.mp4

  Then pass the combination to ffmpeg for HLS segmentation

  ffmpeg -re -i overall.mp4 -ac 2 -r 20 -vcodec libx264 -b:v 318k -preset:v veryfast -acodec aac -strict -2 -b:a 32k -hls_time 2 -hls_list_size 3 -hls_allow_cache 0 -hls_base_url /Users/JosephKalash/Desktop/test/350/ -hls_segment_filename ’350/fragment%03d.ts’ -hls_flags delete_segments 350/index.m3u8

  Concatenation is not perfect and there are noticeable glitches where the fragments are supposed to be stitched. Segmentation replaces older fragments and the manifest is rewritten as if it’s a new HLS stream every time ffmpeg is called.

  I cannot figure out how to get this to work properly.

  Any ideas ?

• Why is one ffmpeg webm dash stream much larger than the others ?

  5 janvier 2017, par ranvel

  Over the summer, I worked on putting together a script which took a x264 video/mp3 stream and broke it up into the different streams so that it would work via MSE-DASH. (Based heavily on the instructions on the webmproject.org website) Those same scripts have ceased to work, turning a 6GB video into several 25 Gb videos. I kept up with updates of ffmpeg and so I don’t know when it stopped working, but I am guessing it was due to the way that their DASH Webm implementation was updated.

  I found new method which works better, but still has a major problem with one stream. I was hoping someone could explain how this encoding works so that I could understand the underlying cause.

  #!/bin/bash
  
  COMMON_OPTS="-map 0:0 -an -threads 11 -cpu-used 4 -cmp chroma"
  
  WEBM_OPTS="-f webm -c:v vp9 -keyint_min 50 -g 50 -dash 1"
  
  
  
  ffmpeg -i $1 -vn -acodec libvorbis -ab 128k audio.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 500k -vf scale=1280:720 -y vid-500k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 700k -vf scale=1280:720 -y vid-700k.webm & 
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1000k -vf scale=1280:720 -y vid-1000k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1500k -vf scale=1280:720 -y vid-1500k.webm  

  The transcode is not yet complete, but you can see where this is headed :

  -rw-r--r--  1 user  staff    87M Jan  4 23:27 audio.webm
  
  -rw-r--r--  1 user  staff    27M Jan  4 23:42 vid-1000k.webm
  
  -rw-r--r--  1 user  staff   285M Jan  4 23:42 vid-1500k.webm
  
  -rw-r--r--  1 user  staff    15M Jan  4 23:42 vid-500k.webm
  
  -rw-r--r--  1 user  staff    20M Jan  4 23:42 vid-700k.webm

  The 1500k variant is disproportionately larger than the other streams.

  The other problem is that when I use a shorter video, lets say eight or nine minutes, the above configuration runs as expected and everything is perfect. I don’t know where the limit for this is since each test costs a lot of processing power and time, but if it’s less than ten minutes, it works and if its longer than an hour, it produces massive files.

• Lossless trim and crop of MJPEG video

  28 avril 2021, par prouast

  I am working on a project where I need to trim and crop MJPEG videos without any re-encoding. I have working code that accomplishes this by exporting the relevant frames as JPEGs, cropping them individually, and then joining them back together into an MJPEG.

  


  However, this seems quite inefficient and slow. I am looking for pointers how to improve this approach. For example, would it be possible to store the JPEGs in-memory ?

  


  import ffmpeg
import os
import shutil
import subprocess

def lossless_trim_and_crop(path, output_path, start, end, x, y, width, height, fps):
  # Trim the video in time and export all individual jpeg with ffmpeg + mjpeg2jpeg
  jpeg_folder = os.path.splitext(output_path)[0]
  jpeg_path = os.path.join(jpeg_folder, "frame_%03d.jpg")
  stream = ffmpeg.input(path, ss=start/fps, t=(end-start)/fps)
  stream = ffmpeg.output(stream, jpeg_path, vcodec='copy', **{'bsf:v': 'mjpeg2jpeg'})
  stream.run(quiet=True)
  # Crop all individual jpeg with jpegtran
  for filename in os.listdir(jpeg_folder):
    filepath = os.path.join(jpeg_folder, filename)
    out_filepath = os.path.splitext(filepath)[0] + "_c.jpg"
    subprocess.call(
      "jpegtran -perfect -crop {}x{}+{}+{} -outfile {} {}".format(
        width, height, x, y, out_filepath, filepath), shell=True)
    os.remove(filepath)
  # Join individual jpg back together
  cropped_jpeg_path = os.path.join(jpeg_folder, "frame_%03d_c.jpg")
  stream = ffmpeg.input(cropped_jpeg_path, framerate=fps)
  stream = ffmpeg.output(stream, output_path, vcodec='copy')
  stream.run(quiet=True)
  # Delete jpeg directory
  shutil.rmtree(jpeg_folder)