Recherche avancée

Sur d’autres sites (9671)

• avcodec/proresenc : fix alpha plane encoding bitstream

  26 décembre 2023, par Clément Bœsch

  avcodec/proresenc : fix alpha plane encoding bitstream
  These functions encode a slice of alpha (1 to 8 macroblocks) which are
  
  expected to be encoded as a repeated sequence of "[diff][run-1]", where
  
  diff is the running difference of the alpha value and run is how many
  
  times that value is expected to be duplicated (within the limit of a
  
  grand total of 2048 unpacked samples, corresponding to a slice of 8 MB).
  Even when run==0 (the run variable semantic is actually "run minus 1"),
  
  there is always a diff previously encoded that needs a counter of at
  
  least 1. This means we need to call put_alpha_run() unconditionally at
  
  the end of the bitstream to account for the last running diff.
  This commit fixes glitchy playbacks on QuickTime with M2 and M3 hardware
  
  (but not M1 for some mysterious reason) with files generated with
  
  commands such as :
    ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_aw -profile:v 4    -y aw.mov
  
    ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_ks -profile:v 4444 -y ks.mov
  The glitch expresses itself deterministically as blinking black
  
  rectangles on random frames (for example on frame 21, 54, 71, 79, ...).
  Even with the proresdec from FFmpeg, overreads actually happens while
  
  reading the run-minus-1 value (around val = get_bits(gb, 4) in
  
  unpack_alpha()). This doesn't seem to cause any particular issue because
  
  it simply overreads into the next slice, and because the decoder is
  
  resilient, but it's still a problem.
  The investigation leading to this fix was made possible because of paid
  
  work for Jitter (https://jitter.video).
  Fixes ticket #10255.
  

  • [DH] libavcodec/proresenc_anatoliy.c
  • [DH] libavcodec/proresenc_kostya.c

• Monitoring for failure and quickly restarting systemd service

  16 février 2024, par mzrt

  I am running a 24/7 youtube stream on Ubuntu. My ffmpeg command is wrapped in a systemd service. On several occasions the ffmpeg command has failed and systemd has not restarted quickly enough to keep the youtube stream alive. When this happens I need to daemon-reload and restart the systemd service.

  


  To counter this I have written a bash script that checks the log for stream ending errors, however, it does not seem to be working. I have had failures since implementing this script, and it did not seem to have been triggered.

  


  two questions :

  


  

  1. is there a more efficient way to do what I am doing ?

  


  2. if not, can anyone identify what I am doing wrong ?

  


  


  #!/bin/bash

RESET=0

while true; do
    # Get the current time minus 1 minute
    LAST_1_MINUTE=$(date -d '1 minute ago' '+%b %e %H:%M:%S')
    
    # Run the command to check for the error within the last minute
    if journalctl --since "$LAST_1_MINUTE" | grep -qi "Error writing trailer"; then
        if [ $RESET -lt 1 ]; then
            # Perform actions if error is detected
            sudo systemctl daemon-reload && \
            echo "Restarting master.service by monitor.sh script at $(date)" >> /var/log/monitor.log && \
            sudo systemctl restart master.service
            RESET=2
        fi
    else
        RESET=$((RESET - 1))
    fi

    # Wait for 20 seconds before the next iteration
    sleep 20
done


  


• avcodec/nvenc : rework on DTS generation

  17 juillet 2024, par Zhao Zhili

  avcodec/nvenc : rework on DTS generation
  Before the patch, the method to generate DTS only works with
  
  timebase equal to 1/fps. With timebase like 1/1000
  ./ffmpeg -i foo.mp4 -an -c:v h264_nvenc -enc_time_base 1/1000 bar.mp4
  pts 0    dts -3
  
  pts 160  dts 37
  
  pts 80   dts 77
  
  pts 40   dts 117 <— invalid
  
  pts 120  dts 157
  
  pts 320  dts 197
  
  pts 240  dts 237
  
  pts 200  dts 277 <— invalid
  
  pts 280  dts 317 <— invalid
  The generated DTS can be larger than PTS, since it only reorder the
  
  input PTS and minus the number of frame delay, which doesn't take
  
  timebase into account. It should minus the "time" of frame delay.
  9a245bd trying to fix the issue, but the implementation is incomplete,
  
  which only use time_base.num. Then it got reverted by ac7c265b33b.
  After this patch :
  pts 0    dts -120
  
  pts 160  dts -80
  
  pts 80   dts -40
  
  pts 40   dts 0
  
  pts 120  dts 40
  
  pts 320  dts 80
  
  pts 240  dts 120
  
  pts 200  dts 160
  
  pts 280  dts 200
  Signed-off-by : Timo Rothenpieler <timo@rothenpieler.org>
  

  • [DH] libavcodec/nvenc.c
  • [DH] libavcodec/nvenc.h