Recherche avancée

Sur d’autres sites (6687)

• Aspect ratio problems at transcoding with ffmpeg [closed]

  19 novembre 2023, par udippel

  I have a huge collection of videos from the last 20+ years, videos in all sorts of formats. I use gerbera as open source UPnP-AV media server. Our TV handles only very limited of these formats. Therefore I use the transcoding feature of gerbera (I don't want to convert the 2000+ files ; thereby avoiding loss of multiple audio tracks, (multiple) subtitles, and so forth).

  


  This is my current unified argument line for ffmpeg :
-c:v mpeg2video -maxrate 20000k -vf setdar=16/9 -r 24000/1001 -qscale:v 4 -top 1 -c:a mp2 -f mpeg -y
It works pretty okay, except of the aspect ratios. Well, I don't understand this fully, because ffprobe for File A states :
Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 624x464 [SAR 1:1 DAR 39:29], 1500 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
This file displays very well.
File B comes as :
Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709, progressive), 960x720, SAR 1:1 DAR 4:3, 23.98 fps, 23.98 tbr, 1k tbn, 180k tbc (default)
This file displays horribly squeezed vertically and doesn't fill the screen left and right neither, with the same settings of the TV. Also, playing this file (and others, naturally) the TV doesn't offer the 14:9 display option, which is available e.g. for the file further up.

  


  Both have same SAR, DAR, almost identical H:V ratios (1.345, 1.333) ; and almost identical DAR.

  


  My questions :

  


  

  1. Why, despite of almost identical pixel ratios, DAR and SAR are these files handled so differently in one and the same session on the same TV (SONY), please ?

  


  2. With which method could I instruct ffmpeg to display the second file properly, too, please ?
(I have already tried 'scale' ; but to no avail. Which could have been foreseen, since the ratios are already very close.)
My guess is, that the (tv, bt709, progressive) mess things up.
(I have already tried to add the yuv420p in the argument line, also to no avail.)

  


  


  Appreciate any help,

  


  Uwe

  


  I have already tried to add a 'scale' option ; but to no avail. Which could have been foreseen, since the ratios are already very close.
I have already tried to add the yuv420p in the argument line, also to no avail.
I have already tried force_original_aspect_ratio, but also here, nothing improving.
Also, I played with -aspect, but the aspects are okay, and would need individual corrections, which I can't and don't to do for 2000+ files. A simple 16:9 doesn't cut it.

  


• Why doesn't the ffmpeg output display the stream in the browser ? [closed]

  10 mai 2024, par Tebyy

  Why is it that when I create a livestream in Python using ffmpeg, and then I open the browser and visit the page, the page keeps loading continuously, and in PyCharm logs, I see binary data ? There are no errors displayed, and the code seems correct to me. I even tried saving to a file for testing purposes, and when I play the video, everything works fine. Does anyone know what might be wrong here ?

  


  Code :

  


  def generate_frames():
    cap = cv2.VideoCapture(os.path.normpath(app_root_dir().joinpath("data/temp", "video-979257305707693982.mp4")))
    while cap.isOpened():
        ret, frame = cap.read()
        if not ret:
            break

        yield frame


@app.route('/video_feed')
def video_feed():
    ffmpeg_command = [
        'ffmpeg', '-f', 'rawvideo', '-pix_fmt', 'bgr24',
        '-s:v', '1920x1080', '-r', '60',
        '-i', '-', '-vf', 'setpts=2.5*PTS', # Video Speed
        '-c:v', 'libvpx-vp9', '-g', '60', '-keyint_min', '60',
        '-b:v', '6M', '-minrate', '4M', '-maxrate', '12M', '-bufsize', '8M',
        '-crf', '0', '-deadline', 'realtime', '-tune', 'psnr', '-quality', 'good',
        '-tile-columns', '6', '-threads', '8', '-lag-in-frames', '16',
        '-f', 'webm', '-'
    ]
    ffmpeg_process = subprocess.Popen(ffmpeg_command, stdin=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=-1)
    frames_generator = generate_frames()
    for frame in frames_generator:
        ffmpeg_process.stdin.write(frame)
        ffmpeg_process.stdin.flush()

    ffmpeg_process.stdin.close()
    ffmpeg_process.wait()

    def generate_video_stream(process):
        startTime = time.time()
        buffer = []
        sentBurst = False
        for chunk in iter(lambda: process.stderr.read(4096), b''):
            buffer.append(chunk)

            # Minimum buffer time, 3 seconds
            if sentBurst is False and time.time() > startTime + 3 and len(buffer) > 0:
                sentBurst = True
                for i in range(0, len(buffer) - 2):
                    print("Send initial burst #", i)
                    yield buffer.pop(0)

            elif time.time() > startTime + 3 and len(buffer) > 0:
                yield buffer.pop(0)

            process.poll()
            if isinstance(process.returncode, int):
                if process.returncode > 0:
                    print('FFmpeg Error', process.returncode)

                break

    return Response(stream_with_context(generate_video_stream(ffmpeg_process)), mimetype='video/webm', content_type="video/webm; codecs=vp9", headers=Headers([("Connection", "close")]))



  


• avfilter/f_ebur128 : add all sample rates support

  4 mars 2021, par Paul B Mahol

  avfilter/f_ebur128 : add all sample rates support
  The magic constants come from the unofficial "ITU-R BS.1770-1 filter
  
  specifications"¹ by Raiden (libebur128) which relies on "Parameter
  
  Quantization in Direct-Form Recursive Audio Filters"² by Brian
  
  Neunaber.
  The constants seem to include a quantization bias, for example :
  
   Vb is supposed to be exactly √Vh in a high shelf filter
  
   the Pre-filter Gain should likely be 4dB
  
   Pre Q and RLB Q are respectively very close to √½ and ½
  Those are not adjusted to prevent the values from drifting away from
  
  the official specifications.
  An alternative to this approach would be to requantize on the fly as
  
  proposed by pbelkner³, where the 48kHz code path would use the exact
  
  specifications constants while derivating constants for other
  
  frequencies.
  [1] : https://www.scribd.com/document/49991813/ITU-R-BS-1770-1-filters
  
  [2] : https://www.scribd.com/document/6531763/Direct-Form-Filter-Parameter-Quantization
  
  [3] : https://hydrogenaud.io/index.php?topic=86116.msg740092#msg740092
  

  • [DH] libavfilter/f_ebur128.c