Recherche avancée

Sur d’autres sites (9867)

• ffmpeg, /dev/video0, -f decklink

  20 mars 2019, par Camille Goudeseune

  I’m trying to capture video from a PCI card, the Blackmagic DeckLink Mini Recorder, via ffmpeg, on a headless host running Ubuntu 18.04.2 LTS, hopefully with a command like

  ffmpeg -f decklink -i /dev/video0 ...

  How can I make that work ? I have two obstacles.

  No /dev/video0

  ffmpeg -i /dev/video0 ... fails : /dev/video0: No such device or address.
  v4l2-ctl --list-devices fails with the same error message.

  I built /dev/video0, and it looks okay :

  mknod /dev/video0 c 81 0
  
  chown root.video /dev/video0
  
  chmod g+rw /dev/video0

  To compare this file with a working one, I ran strace cat /dev/video0 on this host, and on another host (Ubuntu 14) with a working /dev/video0. The outputs began to differ here (good, then bad) :

  fstat(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
  
  open("/dev/video0", O_RDONLY)           = 3  
  
  fstat(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(81, 0), ...}) = 0
  
  fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
  
  ----
  
  
  
  fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
  
  openat(AT_FDCWD, "/dev/video0", O_RDONLY) = -1 ENXIO (No such device or address)

  So /dev/video0 is broken at a level lower than ffmpeg or v4l2 or even cat.

  On Ubuntu 14, man 8 MAKEDEV suggests that the error message means that "the kernel does not have the driver configured or loaded."

  This Ubuntu 18 host lacks that manpage, but it does have a few /snap/core/*/sbin/MAKEDEV, all the same, so I tried

  /snap/core/6350/sbin/MAKEDEV -n -v video

  It would have created over a hundred devices videoXX, radioXX, vtxXX, vbiXX. Those devices didn’t exist yet, so it seemed harmless to try it.

  rm /dev/video0; /snap/core/6350/sbin/MAKEDEV video

  That rebuilt /dev/video0, but "No such device" remains, from cat or ffmpeg.

  No decklink

  ffmpeg -f decklink ... fails with Unknown input format: 'decklink'.

  Neither black nor deck nor link is mentioned by ffmpeg -devices (fbdev, lavfi, oss, v4l2) and ffmpeg -formats (about 350), either for Ubuntu’s own version 3.4.4-0ubuntu0.18.04.1, or for version N-93330-g7ff89574c7 compiled from source on 2019 Mar 13 :

  git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
  
  cd ffmpeg
  
  ./configure --enable-nonfree --disable-doc --disable-w32threads --enable-pthreads

  (Although ./configure --help mentions --enable-decklink, using that yielded "ERROR : DeckLinkAPI.h not found." updatedb && locate DeckLinkAPI.h finds no file with that name, either.)

  The DeckLink PCI card is recognized by hwinfo and lspci.

  lsmod reports the loaded modules blackmagic and blackmagic_io.

  Maybe the PCI card is installed ok, but ffmpeg just can’t reach it because I can’t configure it for that.

  Edit : Rebooting didn’t fix anything.

• FFMPEG stereo track stops capturing at random times during a capture session

  26 mai 2022, par mrwassen

  I am currently working on building a workflow to capture and archive a large stash of family and friends PAL and NTSC VHS tapes. The hardware setup is as follows :

  


  

  • JVC HR-7860S VCR

  


  • s-video / RCA audio >

  


  • ADVC-3000 converter

  


  • SDI / BNC cable >

  


  • Blackmagic Decklink Mini Recorder 4K PCIe card

  


  • installed in a fairly hi-spec windows machine : AMD Ryzen 9 5900X 3.7 Ghz base 12 core, GEFORCE RTX 3060 12 gB, 32 gB ram

  


  


  The plan is to capture to lossless AVI, then drop into an NLE (Vegas Pro v.16) to do a minimal amount of cleanup / trimming, then render to a more compressed video format (TBD) for upload to AWS S3 accessible through a family website.

  


  The issue I am having is that when I run the capture using ffmpeg/directshow e.g. for a perfectly fine 90 min. PAL tape, at some random point of time during the capture one of the 2 stereo channels just stops capturing. This has happened with all of the tapes I have tested so far, and it happens at different times during the same video. I have examined the frames surrounding points in time when this happens, and it doesn't correlate to any transitions or jitter, but often just randomly in the middle of a perfectly smooth scene. Once the one channel stops capturing it never starts back up again during that capture session.

  


  The ADVC-3000 and the VCR are both showing both stereo channels playing normally throughout the capture. The windows machine running the capture hardly breaks a sweat at any time, and the transfer easily keeps up constantly showing a speed = 1x which I assume means nothing lagging. Also there are no video/audio sync issues at any point in time even towards the end of long tapes e.g. 90 mins.

  


  I am fairly new at ffmpeg, so I have spent extensive amounts of time reading up on forum posts and experimenting and have ended up with the following syntax :

  


  ffmpeg -y -f dshow -rtbufsize 2000M -i video="Blackmagic WDM Capture":audio="Blackmagic WDM Capture" -codec:v v210 -pix_fmt yuv422p -codec:a pcm_s16le -b:a 128k -t 02:00:00 -r 25 -threads 4 -maxrate 2500k -filter:a "volume=1.5" output_v210_audio.avi


  


  The capture runs without a single dropped frame, the only error I am getting when launching (and perhaps this is a smoking gun ?) is :

  


  


  "Non-monotonous DTS in output stream 0:1 ; previous : 0, current : -30 ;
changing to 1. This may result in incorrect timestamps in the output
file."

  


  


  I have tried to troubleshoot this in the hopes that it is tied to my issue but so far without luck.

  


  Hoping somebody can help correct or modify my command line or perhaps other ideas to help resolve the issue.

  


• Simply beyond ridiculous

  7 mai 2010, par Dark Shikari — H.265, speed

  For the past few years, various improvements on H.264 have been periodically proposed, ranging from larger transforms to better intra prediction. These finally came together in the JCT-VC meeting this past April, where over two dozen proposals were made for a next-generation video coding standard. Of course, all of these were in very rough-draft form ; it will likely take years to filter it down into a usable standard. In the process, they’ll pick the most useful features (hopefully) from each proposal and combine them into something a bit more sane. But, of course, it all has to start somewhere.

  A number of features were common : larger block sizes, larger transform sizes, fancier interpolation filters, improved intra prediction schemes, improved motion vector prediction, increased internal bit depth, new entropy coding schemes, and so forth. A lot of these are potentially quite promising and resolve a lot of complaints I’ve had about H.264, so I decided to try out the proposal that appeared the most interesting : the Samsung+BBC proposal (A124), which claims compression improvements of around 40%.

  The proposal combines a bouillabaisse of new features, ranging from a 12-tap interpolation filter to 12thpel motion compensation and transforms as large as 64×64. Overall, I would say it’s a good proposal and I don’t doubt their results given the sheer volume of useful features they’ve dumped into it. I was a bit worried about complexity, however, as 12-tap interpolation filters don’t exactly scream “fast”.

  I prepared myself for the slowness of an unoptimized encoder implementation, compiled their tool, and started a test encode with their recommended settings.

  I waited. The first frame, an I-frame, completed.

  I took a nap.

  I waited. The second frame, a P-frame, was done.

  I played a game of Settlers.

  I waited. The third frame, a B-frame, was done.

  I worked on a term paper.

  I waited. The fourth frame, a B-frame, was done.

  After a full 6 hours, 8 frames had encoded. Yes, at this rate, it would take a full two weeks to encode 10 seconds of HD video. On a Core i7. This is not merely slow ; this is over 1000 times slower than x264 on “placebo” mode. This is so slow that it is not merely impractical ; it is impossible to even test. This encoder is apparently designed for some sort of hypothetical future computer from space. And word from other developers is that the Intel proposal is even slower.

  This has led me to suspect that there is a great deal of cheating going on in the H.265 proposals. The goal of the proposals, of course, is to pick the best feature set for the next generation video compression standard. But there is an extra motivation : organizations whose features get accepted get patents on the resulting standard, and thus income. With such large sums of money in the picture, dishonesty becomes all the more profitable.

  There is a set of rules, of course, to limit how the proposals can optimize their encoders. If different encoders use different optimization techniques, the results will no longer be comparable — remember, they are trying to compare compression features, not methods of optimizing encoder-side decisions. Thus all encoders are required to use a constant quantizer, specified frame types, and so forth. But there are no limits on how slow an encoder can be or what algorithms it can use.

  It would be one thing if the proposed encoder was a mere 10 times slower than the current reference ; that would be reasonable, given the low level of optimization and higher complexity of the new standard. But this is beyond ridiculous. With the prize given to whoever can eke out the most PSNR at a given quantizer at the lowest bitrate (with no limits on speed), we’re just going to get an arms race of slow encoders, with every company trying to use the most ridiculous optimizations possible, even if they involve encoding the frame 100,000 times over to choose the optimal parameters. And the end result will be as I encountered here : encoders so slow that they are simply impossible to even test.

  Such an arms race certainly does little good in optimizing for reality where we don’t have 30 years to encode an HD movie : a feature that gives great compression improvements is useless if it’s impossible to optimize for in a reasonable amount of time. Certainly once the standard is finalized practical encoders will be written — but it makes no sense to optimize the standard for a use-case that doesn’t exist. And even attempting to “optimize” anything is difficult when encoding a few seconds of video takes weeks.

  Update : The people involved have contacted me and insist that there was in fact no cheating going on. This is probably correct ; the problem appears to be that the rules that were set out were simply not strict enough, making many changes that I would intuitively consider “cheating” to be perfectly allowed, and thus everyone can do it.

  I would like to apologize if I implied that the results weren’t valid ; they are — the Samsung-BBC proposal is definitely one of the best, which is why I picked it to test with. It’s just that I think any situation in which it’s impossible to test your own software is unreasonable, and thus the entire situation is an inherently broken one, given the lax rules, slow baseline encoder, and no restrictions on compute time.