Recherche avancée

Sur d’autres sites (9556)

• ffmpeg have unmet dependencies (Ubuntu20) [closed]

  10 août 2024, par mojiang

  when installing ffmpeg with ubuntu20(fosal), it have conflict dependencies :

  


  # sudo apt-get install ffmpeg
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ffmpeg : Depends: libavdevice58 (= 7:4.2.7-0ubuntu0.1) but it is not going to be installed
          Depends: libavfilter7 (= 7:4.2.7-0ubuntu0.1)
          Depends: libavformat58 (= 7:4.2.7-0ubuntu0.1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


  


  I solved it by install the reason of conflit library with a specific version, may be someone will need the solution.

  


  step 1. fix-broken

  


  sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree       
Reading state information... Done


  


  step2. find the reason of unmet dependencies :

  


  # sudo apt install libavdevice58=7:4.2.7-0ubuntu0.1 libavfilter7=7:4.2.7-0ubuntu0.1 libavformat58=7:4.2.7-0ubuntu0.1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libavformat58 : Depends: libchromaprint1 (>= 1.3.2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


  


  Here the problem is from libchromaprint1

  


  step3. find candidate versions of libchromaprint1(conflict reason)

  


  # apt-cache policy libchromaprint1
libchromaprint1:
  Installed: (none)
  Candidate: 1.5.1-1~20.04.sav0
  Version table:
     1.5.1-1~20.04.sav0 500
        500 http://ppa.launchpad.net/savoury1/multimedia/ubuntu focal/main amd64 Packages
     1.4.3-3build1 500
        500 http://mirrors.cloud.aliyuncs.com/ubuntu focal/universe amd64 Packages
        500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages


  


  step4. install the old version of libchromaprint1 to solve the conflicts

  


  # sudo apt install libchromaprint1=1.4.3-3build1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  libchromaprint1
0 upgraded, 1 newly installed, 0 to remove and 223 not upgraded.
Need to get 37.6 kB of archives.


  


  step5. reinstall ffmpeg

  


  # sudo apt install ffmpeg
Reading package lists... Done
Building dependency tree       
Reading state information... Done


  


  Done. the reason of conflict is that the latest version of libraries have conflict, by install old version of the conflicted ones to solve it.

  


• Best intra-frame codec for editing ? Having color issues with DNxHR and serious sync issues with Prores

  23 janvier 2020, par Raulo1985

  I have a couple of questions regarding intra-frame codecs for editing purposes (in Premiere Pro).

  A LITTLE CONTEXT :

  I ripped a HDR movie to a MP4 container some months ago, using H.264 as codec (high 10, level 5, UHD, YUV, subsampling 4:2:0). The video looks great, as it should. Now I want to edit a trailer for that movie (I edit in Adobe Premiere Pro, current version), and for fast playback I need to work with proxies or transcode the source file to an intra-frame non long GOP file and use it as the source file (hopefully as lossless as that transcoding step can be). I tried for several days to transcode the source file to DNxHR 444 10 bits (using FFmpeg and then Adobe Media Encoder), but the result was always a video with the colors messed up (sometimes very washed out, sometimes over saturated).

  FFprobe of the resulting DNxHR file said that the color space was BT709 (source file is obviously BT2020), and I don’t know why. The transcoding involved upsampling since the source file is 4:2:0 and DNxHR doesn’t support it, but I tried upsampling to 4:4:4 and also to 4:2:2, and both of those files looked exactly the same to me, and very different from the original footage (so, I don’t think upsampling is the cause of the color issue, but maybe the apparent color space change or something wrong with the metadata). The results were the same when transcoding with Adobe Media Encoder. Anyway, I seem to have given up transcoding to DNxHR and use it as the source file, unless someone has an idea of what’s causing this problem. I could have worked with the source file for exporting and DNxHR LB for proxies, but there were sync issues (between source file and proxy) that defeated all purposes while editing. Prores is out of the picture, sync issues were worse (several seconds of delay).

  For the record, the command used that didn’t work as expected (color wise) is :

  ffmpeg -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -vf "scale=in_range=limited:out_range=full" -color_range 2 -profile:v dnxhr_444 -pix_fmt yuv444p10le -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf

  I also tried without the commands "scale=in_range=limited:out_range=full" and "-color_range 2", with same results. Always used FFmpeg latest version, and I’m working in Windows 10 Pro, latest drivers and latest Klite codec pack. Video files were compared with Mediainfo, FFprobe, and visually with VLC.

  Well, like I said, I’m giving up using DNxHR as the source file for my project (it would have been ideal since it doesn’t have sync issues with the DNxHR proxies, and file size is not a problem for me). A user here at the forums suggested transcoding and use H.264 intra-frame as source file, which I didn’t know was an option (I didn’t know H.264 was capable of intra-frame, my bad). I’m aware that one should avoid unnecesary transcoding steps, but I can’t work with a H.264 UHD HDR source file (ultra slow playback), and the sync issues with proxies, no matter the codec, make it impossible to make accurate cuts.
  So, bottom line, I need to find a way to fix the color issue when transcoding to DNxHR, or try with an inter-frame codec that’s not DNxHR and that’s capable of preserving all the HDR info (and then see if it doesn’t have sync issues. I’m assuming that those may dissapear when using intra-frame for both source file and proxies).

  NOTE : When importing the DNxHR 444 file to Premiere Pro and looking at the Lumetri scopes tab, you can tell that the colors are clipped at 100 nits, like a regular SDR video. So apparently the color space was really reduced to BT709, and I don’t know why. The H.264 source file behaves as expected, with colors going past 100 nits.

  MY QUESTIONS :

  1) Is H.264 intra-frame a good format for editing with a good playback performance ?

  2) If H.264 intra-frame is a good option, what would be the advantages of the DNxHR codec (or Prores) over it for editing purposes ? Everybody suggests DNxHD/DNxHR or Prores as intermediate codecs, but if intra-frame H.264 has the same advantages for editing and supports HDR, what would be the reason to choose another codec like DNxHR ?

  3) Any ideas on what could be the cause of the colors not transcoding correctly from the H.264 source file to the DNxHR 444 10 bits one ? The command looks ok to me, but FFprobe output says the DNxHR video is BT709, while with the source file it says BT2020. Like I said, apparently there’s something wrong with the transcoding process regarding metadata or color space.

  4) I haven’t tried to transcode the source file to a DNxHR 444 10 bits video file, but in a MOV container. I don’t know how this works internally, but maybe the color issue has something to do with the container metadata or something. I may try this if there’s not another suggestion (transcoding this kind of files, as you know, takes time, so I’ll wait for some ideas first).

  NOTE : I tried to transcode the source file in the same way (DNxHR 444, 10 bits, etc) with Adobe Media Encoder 2020 and the result was the same, with colors messed up and FFprobe saying the video is BT709. Also tried transcoding to DNxHR HQX profile (10 bits), same result.

  Any help would be greatly appreciated.

  Thanks in advance.

• SOLVED ffmpeg : consider increasing probesize error, but it is never satisfied

  27 octobre 2020, par Jaz

  I was trying to use an Arch solution for streaming to twitch today through FFMPEG, but all of my attempts were in vain because of one simple thing on FFMPEG. it says that the probesize is not large enough, so I instinctively increased the probesize value more and more... and now it is -probesize "500M" yet it is still saying it is not enough. here is the code snippet

  


  [x11grab @ 0x5631f846cd00] Stream #0: not enough frames to estimate rate; consider increasing probesize
Input #0, x11grab, from ':0.0':
  Duration: N/A, start: 1603397505.341400, bitrate: 1007124 kb/s
    Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1366x768, 1007124 kb/s, 30 fps, 1000k tbr, 1000k tbn, 1000k tbc
0: Input/output error


  


  and the code

  


  #!/bin/bash
     INRES="1366x768" # input resolution
     OUTRES="1366x768" # output resolution
     FPS="30" # target FPS
     GOP="60" # i-frame interval, should be double of FPS,
     GOPMIN="30" # min i-frame interval, should be equal to fps,
     THREADS="2" # max 6
     CBR="1000k" # constant bitrate (should be between 1000k - 3000k)
     QUALITY="ultrafast"  # one of the many FFMPEG preset
     AUDIO_RATE="44100"
     PROBESZ="500M" # specify a size for the ffmpeg tool to assess frames
     STREAM_KEY="$1" # paste the stream key after calling stream_now
     SERVER="live-mia" # twitch server in miami Florida, see https://stream.twitch.tv/ingests/ for list

     ffmpeg -f x11grab -s "$INRES" -r "$FPS" -i :0.0 -f pulse -i 0 -f flv -ac 2 -ar $AUDIO_RATE \
       -vcodec libx264 -g $GOP -keyint_min $GOPMIN -b:v $CBR -minrate $CBR -maxrate $CBR -pix_fmt yuv420p\
       -s $OUTRES -preset $QUALITY -tune film -acodec aac -threads $THREADS -strict normal \
       -bufsize $CBR -probesize $PROBESZ "rtmp://$SERVER.twitch.tv/app/$STREAM_KEY"


  


  even though it was a solution to store in .bashrc, I stored it in a script to call manually.

  


  and if this is helpful, here is the fancy banner ffmpeg shows before the error

  


  ffmpeg version n4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 10.1.0 (GCC)
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librav1e --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100