Recherche avancée

Sur d’autres sites (10397)

• 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.

  


• How to interpret ffmpeg recording options available for a webcam (directshow) ?

  5 janvier 2023, par Jones659

  I am trying to create a GUI for personal use, that allows someone to customise recording and converting options of ffmpeg, without directly using the command line. At the moment, I am learning about different parameters and flags in ffmpeg.

  


  Apologies in advance if I end up asking some stupid questions, I am on a learning journey at the moment, unfortunately not all of this info is available online in an easily understandable way.

  


  I have a USB webcam which reported having the following options available to it :

  


  [dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=640x480 fps=5 max s=640x480 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=640x480 fps=5 max s=640x480 fps=30 (tv, bt470bg/bt709/unknown, topleft) chroma_location=topleft
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=352x288 fps=5 max s=352x288 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=352x288 fps=5 max s=352x288 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=320x240 fps=5 max s=320x240 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=320x240 fps=5 max s=320x240 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=176x144 fps=5 max s=176x144 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=176x144 fps=5 max s=176x144 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=160x120 fps=5 max s=160x120 fps=30
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=160x120 fps=5 max s=160x120 fps=30 (tv, bt470bg/bt709/unknown, topleft)
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=1280x1024 fps=5 max s=1280x1024 fps=9
[dshow @ 00000000003f9340]   pixel_format=yuyv422  min s=1280x1024 fps=5 max s=1280x1024 fps=9 (tv, bt470bg/bt709/unknown, topleft)


  


  I just want to get to the bottom of how I should interpret this, apologies that I will ask multiple questions :

  


  


  1. The fact that both resolution and fps have a min and max value (for every option) seems to imply that these two parameters are supposably uncontrollably variable, right ? In practice, the fps has been variable depending on brightness, however the resolution has not been - is it safe to assume that video imaging devices (especially such as a webcam) do not have variable resolution ?

     


  


  2. Secondly, why is it that every option is listed twice, except half of them specify extra info, such as color_range, color_space, and chroma_location ? Is this just a quirk ? Surely those extra parameter options should not be discarded ?

     


  


  3. It's hard to know how to make sense of this, but or example : the fact that only "tv" is ever shown, does that impliy that the webcam can only ever do limited color range, and there is no point trying to get full 0,255 out of it ? I read somewhere that "pc" implies full range of 0-255, whereas "tv" implies a range of 16-235

     


  


  4. With regards to color space, is it acceptable to record the webcam as raw (un-encoded), and then later convert to a different color space later down the line ? Which approach to dealing with the color-space yields the least amount of lost color ? My only previous experience with color spaces is in the realm of images - where for example, it makes no sense to convert sRGB to ROMM16 RGB, because you're going to a color space which has wider coverage, and extra colors won't be created out of thin air, you'd want to go once from raw to a color space, and avoid converting between color spaces afterwards. Also, what does "unknown" mean in the color space options ?

     


  


  


  Here's the culmination of some research/testing i've done, is there anything correct, or seriously wrong, in the conclusions and assumptions I've made below ?

  


  My understanding of pixel_format is as follows : when you're recording, (even to raw), you specify the pixel format using something like "-pixel_format yuyv422", this is a "packed", not "planar" format, which is produced by the webcam. When you convert from raw to something like mkv using libx264, you can't specify a "packed" pixel format such as "yuyv422", but must instead use an appropriate planar counterpart, such as "yuv422p", which would be specified using "-pix_fmt yuv422p".

  


  I did a raw recording of the webcam (in which I recorded a bright light, in the dark), I didn't set any of the options in the brackets above. I then converted this video using libx264 with the flags "-dst_range 1 -color_range 2" which I saw elsewhere on the internet.

  


  Taking a screenshot of this video using vlc, and putting it through imagemagick identify -verbose, shows that the color range of the screenshot is 0,255, as for the video itself, "MediaInfo" reports "color range:Full", VLC's codec info says "Decoded format : Planar 4:2:2 YUV full scale - is this info worth anything, or is it just meta-data that the video got tagged with ?

  


  At first I was happy about imagemagick's color range reporting, but I am thinking now, the 0, 255 range could be a result of "overshoot" values produced by the camera, which aren't actually supposed to be mapped linearly.

  


  I appreciate that this probably feels like some school-kiddy offloading their homework assignment to avoid doing work, but I hope it can be seen that I've looked into these things prior to putting this post together.

  


  Thanks in advance, if anyone takes the time to answer anything.

  


• How to Simply Remove Duplicate Frames from a Video using ffmpeg

  29 janvier 2017, par Skeeve

  First of all, I’d preface this by saying I’m NO EXPERT with video manipulation,
  although I’ve been fiddling with ffmpeg for years (in a fairly limited way). Hence, I’m not too flash with all the language folk often use... and how it affects what I’m trying to do in my manipulations... but I’ll have a go with this anyway...

  I’ve checked a few links here, for example :
  ffmpeg - remove sequentially duplicate frames

  ...but the content didn’t really help me.

  I have some hundreds of video clips that have been created under both Windows and Linux using both ffmpeg and other similar applications. However, they have some problems with times in the video where the display is ’motionless’.

  As an example, let’s say we have some web site that streams a live video into, say, a Flash video player/plugin in a web browser. In this case, we’re talking about a traffic camera video stream, for example.

  There’s an instance of ffmpeg running that is capturing a region of the (Windows) desktop into a video file, viz :-

  ffmpeg -hide_banner -y -f dshow ^
  
        -i video="screen-capture-recorder" ^
  
        -vf "setpts=1.00*PTS,crop=448:336:620:360" ^
  
        -an -r 25 -vcodec libx264 -crf 0 -qp 0 ^
  
        -preset ultrafast SAMPLE.flv

  Let’s say the actual ’display’ that is being captured looks like this :-

  123456789 XXXXX 1234567 XXXXXXXXXXX 123456789 XXXXXXX
  
  ^---a---^ ^-P-^ ^--b--^ ^----Q----^ ^---c---^ ^--R--^ 

  ...where each character position represents a (sequence of) frame(s). Owing to a poor internet connection, a "single frame" can be displayed for an extended period (the ’X’ characters being an (almost) exact copy of the immediately previous frame). So this means we have segments of the captured video where the image doesn’t change at all (to the naked eye, anyway).

  How can we deal with the duplicate frames ?... and how does our approach change if the ’duplicates’ are NOT the same to ffmpeg but LOOK more-or-less the same to the viewer ?

  If we simply remove the duplicate frames, the ’pacing’ of the video is lost, and what used to take, maybe, 5 seconds to display, now takes a fraction of a second, giving a very jerky, unnatural motion, although there are no duplicate images in the video. This seems to be achievable using ffmpeg with an ’mp_decimate’ option, viz :-

       ffmpeg -i SAMPLE.flv ^                      ... (i)
  
          -r 25 ^
  
          -vf mpdecimate,setpts=N/FRAME_RATE/TB DEC_SAMPLE.mp4

  That reference I quoted uses a command that shows which frames ’mp_decimate’ will remove when it considers them to be ’the same’, viz :-

       ffmpeg -i SAMPLE.flv ^                      ... (ii)
  
          -vf mpdecimate ^
  
          -loglevel debug -f null -

  ...but knowing that (complicated formatted) information, how can we re-organize the video without executing multiple runs of ffmpeg to extract ’slices’ of video for re-combining later ?

  In that case, I’m guessing we’d have to run something like :-

  • user specifies a ’threshold duration’ for the duplicates
    (maybe run for 1 sec only)
  • determine & save main video information (fps, etc - assuming
    constant frame rate)
  • map the (frame/time where duplicates start)->no. of
    frames/duration of duplicates
  • if the duration of duplicates is less than the user threshold,
    don’t consider this period as a ’series of duplicate frames’
    and move on
  • extract the ’non-duplicate’ video segments (a, b & c in the
    diagram above)
  • create ’new video’ (empty) with original video’s specs
  • for each video segment
    extract the last frame of the segment
    create a short video clip with repeated frames of the frame
    just extracted (duration = user spec. = 1 sec)
    append (current video segment+short clip) to ’new video’
    and repeat

  ...but in my case, a lot of the captured videos might be 30 minutes long and have hundreds of 10 sec long pauses, so the ’rebuilding’ of the videos will take a long time using this method.

  This is why I’m hoping there’s some "reliable" and "more intelligent" way to use
  ffmepg (with/without the ’mp_decimate’ filter) to do the ’decimate’ function in only a couple of passes or so... Maybe there’s a way that the required segments could even be specified (in a text file, for example) and as ffmpeg runs it will
  stop/restart it’s transcoding at specified times/frame numbers ?

  Short of this, is there another application (for use on Windows or Linux) that could do what I’m looking for, without having to manually set start/stop points,
  extracting/combining video segments manually...?

  I’ve been trying to do all this with ffmpeg N-79824-gcaee88d under Win7-SP1 and (a different version I don’t currently remember) under Puppy Linux Slacko 5.6.4.

  Thanks a heap for any clues.