Recherche avancée

Sur d’autres sites (5481)

• avformat/mov : fix seeking with HEVC open GOP files

  18 février 2022, par Clément Bœsch

  avformat/mov : fix seeking with HEVC open GOP files
  This was tested with medias recorded from an iPhone XR and an iPhone 13.
  Here is how a typical stream looks like in coding order :
      ┌────────┬─────┬─────┬──────────┐
  
      │ sample | PTS | DTS | keyframe |
  
      ├────────┼─────┼─────┼──────────┤
  
      ┊        ┊     ┊     ┊          ┊
  
      │   53   │ 560 │ 510 │    No    │
  
      │   54   │ 540 │ 520 │    No    │
  
      │   55   │ 530 │ 530 │    No    │
  
      │   56   │ 550 │ 540 │    No    │
  
      │   57   │ 600 │ 550 │    Yes   │
  
      │ * 58   │ 580 │ 560 │    No    │
  
      │ * 59   │ 570 │ 570 │    No    │
  
      │ * 60   │ 590 │ 580 │    No    │
  
      │   61   │ 640 │ 590 │    No    │
  
      │   62   │ 620 │ 600 │    No    │
  
      ┊        ┊     ┊     ┊          ┊
  In composition/display order :
      ┌────────┬─────┬─────┬──────────┐
  
      │ sample | PTS | DTS | keyframe |
  
      ├────────┼─────┼─────┼──────────┤
  
      ┊        ┊     ┊     ┊          ┊
  
      │   55   │ 530 │ 530 │    No    │
  
      │   54   │ 540 │ 520 │    No    │
  
      │   56   │ 550 │ 540 │    No    │
  
      │   53   │ 560 │ 510 │    No    │
  
      │ * 59   │ 570 │ 570 │    No    │
  
      │ * 58   │ 580 │ 560 │    No    │
  
      │ * 60   │ 590 │ 580 │    No    │
  
      │   57   │ 600 │ 550 │    Yes   │
  
      │   63   │ 610 │ 610 │    No    │
  
      │   62   │ 620 │ 600 │    No    │
  
      ┊        ┊     ┊     ┊          ┊
  Sample/frame 58, 59 and 60 are B-frames which actually depends on the
  
  key frame (57). Here the key frame is not an IDR but a "CRA" (Clean
  
  Random Access).
  Initially, I thought I could rely on the sdtp box (independent and
  
  disposable samples), but unfortunately :
      sdtp[54] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
  
      sdtp[55] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
  
      sdtp[56] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
  
      sdtp[57] is_leading:0 sample_depends_on:2 sample_is_depended_on:0 sample_has_redundancy:0
  
      sdtp[58] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
  
      sdtp[59] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
  
      sdtp[60] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
  
      sdtp[61] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
  
      sdtp[62] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
  The information that might have been useful here would have been
  
  is_leading, but all the samples are set to 0 so this was unusable.
  Instead, we need to rely on sgpd/sbgp tables. In my case the video track
  
  contained 3 sgpd tables with the following grouping types : tscl, sync
  
  and tsas. In the sync table we have the following 2 entries (only) :
      sgpd.sync[1] : sync nal_unit_type:0x14
  
      sgpd.sync[2] : sync nal_unit_type:0x15
  (The count starts at 1 because 0 carries the undefined semantic, we'll
  
  see that later in the reference table).
  The NAL unit types presented here correspond to :
      libavcodec/hevc.h :    HEVC_NAL_IDR_N_LP       = 20,
  
      libavcodec/hevc.h :    HEVC_NAL_CRA_NUT        = 21,
  In parallel, the sbgp sync table contains the following :
      ┌────┬───────┬─────┐
  
      │ id │ count │ gdi │
  
      ├────┼───────┼─────┤
  
      │  0 │   1   │  1  │
  
      │  1 │   56  │  0  │
  
      │  2 │   1   │  2  │
  
      │  3 │   59  │  0  │
  
      │  4 │   1   │  2  │
  
      │  5 │   59  │  0  │
  
      │  6 │   1   │  2  │
  
      │  7 │   59  │  0  │
  
      │  8 │   1   │  2  │
  
      │  9 │   59  │  0  │
  
      │ 10 │   1   │  2  │
  
      │ 11 │   11  │  0  │
  
      └────┴───────┴─────┘
  The gdi column (group description index) directly refers to the index in
  
  the sgpd.sync table. This means the first frame is an IDR, then we have
  
  batches of undefined frames interlaced with CRA frames. No IDR ever
  
  appears again (tried on a 30+ seconds sample).
  With that information, we can build an heuristic using the presentation
  
  order.
  A few things needed to be introduced in this commit :
  1. min_sample_duration is extracted from the stts : we need the minimal
  
     step between sample in order to PTS-step backward to a valid point
  
  2. In order to avoid a loop over the ctts table systematically during a
  
     seek, we build an expanded list of sample offsets which will be used
  
     to translate from DTS to PTS
  
  3. An open_key_samples index to keep track of all the non-IDR key
  
     frames ; for now it only supports HEVC CRA frames. We should probably
  
     add BLA frames as well, but I don't have any sample so I prefered to
  
     leave that for later
  It is entirely possible I missed something obvious in my approach, but I
  
  couldn't come up with a better solution. Also, as mentioned in the diff,
  
  we could optimize is_open_key_sample(), but the linear scaling overhead
  
  should be fine for now since it only happens in seek events.
  Fixing this issue prevents sending broken packets to the decoder. With
  
  FFmpeg hevc decoder the frames are skipped, with VideoToolbox the frames
  
  are glitching.
  

  • [DH] libavformat/isom.h
  • [DH] libavformat/mov.c

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

  


• ValueError : I/O operation on closed file with ffmpeg

  22 mars 2018, par AstroCoda

  I’m trying to get this (minimal working example) code to compile in a virtual environment on Anaconda which I’ve set up in a supercomputing cluster :

  import numpy as np
  
  import matplotlib
  
  matplotlib.use("Agg")
  
  import matplotlib.pyplot as plt
  
  import matplotlib.animation as manimation
  
  
  
  FFMpegWriter = manimation.writers['ffmpeg']
  
  metadata = dict(title='Movie Test', artist='Matplotlib',
  
              comment='Movie support!')
  
  writer = FFMpegWriter(fps=15, metadata=metadata)
  
  
  
  fig = plt.figure()
  
  l, = plt.plot([], [], 'k-o')
  
  
  
  plt.xlim(-5, 5)
  
  plt.ylim(-5, 5)
  
  
  
  x0, y0 = 0, 0
  
  
  
  with writer.saving(fig, "writer_test.mp4", 100):
  
      for i in range(100):
  
          x0 += 0.1 * np.random.randn()
  
          y0 += 0.1 * np.random.randn()
  
          l.set_data(x0, y0)
  
          writer.grab_frame()

  The thing is, this code works absolutely fine on my local machine (MacOSX) - Anaconda distribution ; Python 2.7 ; same matplotlib and numpy version, and I have ffmpeg on Anaconda ; I have ffmpeg on the cluster as well, albeit at a different version to the one on Python (but no issue with this on my local machine). When I run the code on the cluster, I get :

  Traceback (most recent call last):
  
    File "movie_test.py", line 25, in <module>
  
      writer.grab_frame()
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/contextlib.py", line 35, in __exit__
  
      self.gen.throw(type, value, traceback)
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/site-packages/matplotlib/animation.py", line 241, in saving
  
      self.finish()
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/site-packages/matplotlib/animation.py", line 367, in finish
  
      self.cleanup()
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/site-packages/matplotlib/animation.py", line 405, in cleanup
  
      out, err = self._proc.communicate()
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/site-packages/subprocess32.py", line 927, in communicate
  
      stdout, stderr = self._communicate(input, endtime, timeout)
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/site-packages/subprocess32.py", line 1713, in _communicate
  
      orig_timeout)
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/site-packages/subprocess32.py", line 1769, in _communicate_with_poll
  
      register_and_append(self.stdout, select_POLLIN_POLLPRI)
  
    File "~/anaconda2/envs/test_movie/lib/python2.7/site-packages/subprocess32.py", line 1748, in register_and_append
  
      poller.register(file_obj.fileno(), eventmask)
  
  ValueError: I/O operation on closed file
  
  </module>

  All the searches I’ve made correspond to relatively simple text write in/out operations, but not for videos. Thanks in advance for the help !