Recherche avancée

Sur d’autres sites (5835)

• Ask Help for Reproduce AccMPEG coded by Du Kuntai

  30 novembre 2022, par censhallwe

  Here is his github : https://github.com/KuntaiDu/AccMPEG
When I follow his steps to reproduce AccMPEG, I meet some problems. It's my first time to reproduce others' paper. When I set up the conda environment, the conda_env.yml has some pip errors and stop like picture1 :
  
PIC 1.
  
So I change its name to accmpeg (originally diff) and delete some code about torch/torchvision/torchaudio/detectron2. After setup the environment, I run generate_mpeg_curve.py and meet some errors like picture2 :
  
PIC 2.
  
Maybe I failed to setup the environment. And when I run batch_blackgen_roi.py, I meet some errors like these :
  
IMG 3.
  
I search accmpeg and want to try to find solution from the Internet. But I don't get useful information. Therefore, I try to seek help. If you can give me a hand, I am very grateful.
  
If you can reproduce it well, please teach me how to operate. It's better if you have some useful pictures.Thanks very much !

  


• ffmpeg stream freezes so often (it stays alive and working for no more than 30mins) when trying to stream with a cloud ubuntu linux instance

  22 novembre 2022, par MohamedElShab

  I'm trying to stream on Youtube with a cloud ubuntu 22.04 instance, but it freezes after no more than 30 mins or so, the ffmpeg process keeps running in the background, and Youtube is keeping the stream up, no video, no music, it's just there loading, frozen, I kill the process and rerun it with nohup in the background, and it freezes again after a short amount of time, the log file from nohup contains only warnings of things like :
[libx264 @ 0xaaaaee6feb60] VBV is incompatible with constant QP, ignored.
which I think are not really important, but I see in the log that it exits normally :
Exiting normally, received signal 15.

  


  I'm using this bash script to stream :

  


  #! /bin/bash

VBR="4500k"
FPS="24"
QUAL="ultrafast"

YOUTUBE_URL="rtmp://a.rtmp.youtube.com/live2"
KEY="XXXX-XXXX-XXXX-XXXX-XXXX"


VIDEO_SOURCE="/home/ubuntu/video.mp4"
AUDIO_SOURCE="/home/ubuntu/audio.mp3"

ffmpeg \
    -re -f lavfi -i "movie=filename=$VIDEO_SOURCE:loop=0, setpts=N/(FRAME_RATE*TB)" \
    -thread_queue_size 512 -i "$AUDIO_SOURCE" \
    -map 0:v:0 -map 1:a:0 \
    -map_metadata:g 1:g \
    -vcodec libx264 -pix_fmt yuv420p -preset $QUAL -crf 0 -r $FPS -g $(($FPS * 2)) -b:v $VBR \
    -acodec libmp3lame -ar 44100 -threads 6 -crf 0 -b:a 320000 -bufsize 512k \
    -f flv \
    -flvflags no_duration_filesize \
    "$YOUTUBE_URL/$KEY"


  


  I'm unexperienced in this, so if anyone knows a solution, please explain in details if possible and with commands.

  


• avcodec/svq1enc : Workaround GCC bug 102513

  25 octobre 2022, par Andreas Rheinhardt

  avcodec/svq1enc : Workaround GCC bug 102513
  GCC 11 has a bug : When it creates clones of recursive functions
  
  (to inline some parameters), it clones a recursive function
  
  eight times by default, even when this exceeds the recursion
  
  depth. This happens with encode_block() in libavcodec/svq1enc.c
  
  where a parameter level is always in the range 0..5 ;
  
  but GCC 11 also creates functions corresponding to level UINT_MAX
  
  and UINT_MAX - 1 (on -O3 ; -O2 is fine).
  Using such levels would produce undefined behaviour and because
  
  of this GCC emits bogus -Warray-bounds warnings for these clones.
  Since commit d08b2900a9f0935959303da668cb00a8a7245228, certain
  
  symbols that are accessed like ff_svq1_inter_multistage_vlc[level]
  
  are declared with hidden visibility, which allows compilers
  
  to bake the offset implied by level into the instructions
  
  if level is a compile-time constant as it is in the clones.
  
  Yet this leads to insane offsets for level == UINT_MAX which
  
  can be incompatible with the supported offset ranges of relocations.
  
  This happens in the small code model (the default code model for
  
  AArch64).
  This commit therefore works around this bug by disabling cloning
  
  recursive functions for GCC 10 and 11. GCC 10 is affected by the
  
  underlying bug (see
  
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513), so the workaround
  
  also targets it, although it only produces three versions of
  
  encode_block(), so it does not seem to trigger the actual issue here.
  The issue has been mitigated in GCC 12.1 (it no longer creates clones
  
  for impossible values ; see also commit
  
  1cb7fd317c84117bbb13b14851d62f77f57bb9ce), so the workaround
  
  does not target it.
  Reported-by : J. Dekker <jdek@itanimul.li>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  
  Signed-off-by : J. Dekker <jdek@itanimul.li>
  

  • [DH] libavcodec/svq1enc.c