Recherche avancée

Sur d’autres sites (4552)

• ffmpeg not recording frames

  28 mai 2024, par RCam

  I am using Python to record 5 second videos from 3 webcams at once using ffmpeg. The recordings repeat at intervals of 25 seconds. The code seems to work except intermittently a recording from one of the cameras will be 0 seconds long. There don't seem to be any obvious errors, and the file is created it just doesn't contain any frames. The key components of the code are :

  


  def take_vid1(path1, video_length, sampleN):  
    dt = datetime.now().strftime("%Y_%m_%d_%H_%M_%S")
    save1 = os.path.join(path1, dt+'_1'+sampleN+'.mp4')
    command = [ffmpeg_path, '-hide_banner', '-y', '-f', 'dshow', '-thread_queue_size', '4096', '-rtbufsize', '500M', '-c:v', 'mjpeg', '-video_size', '1600x896', '-framerate', '30', '-i', 'video='+dev1, '-map', '0', '-t', video_length, save1]
    sp = subprocess.run(command, capture_output=True, text=True) 
    print(dt + ' vid1 returncode: ' + str(sp.returncode)) 
def take_vid2(path2, video_length, sampleN):  
    dt = datetime.now().strftime("%Y_%m_%d_%H_%M_%S")
    save2 = os.path.join(path2, dt+'_2'+sampleN+'.mp4')
    command = [ffmpeg_path, '-hide_banner', '-y', '-f', 'dshow', '-thread_queue_size', '4096', '-rtbufsize', '500M', '-c:v', 'mjpeg', '-video_size', '1600x896', '-framerate', '30', '-i', 'video='+dev2, '-map', '0', '-t', video_length, save2]
    sp = subprocess.run(command, capture_output=True, text=True) 
    print(dt + ' vid2 returncode: ' + str(sp.returncode))  
def take_vid3(path3, video_length, sampleN):  
    dt = datetime.now().strftime("%Y_%m_%d_%H_%M_%S")
    save3 = os.path.join(path3, dt+'_3'+sampleN+'.mp4')
    command = [ffmpeg_path, '-hide_banner', '-y', '-f', 'dshow', '-thread_queue_size', '4096', '-rtbufsize', '500M', '-c:v', 'mjpeg', '-video_size', '1600x896', '-framerate', '30', '-i', 'video='+dev3, '-report', '-map', '0', '-t', video_length, save3]
    sp = subprocess.run(command, capture_output=True, text=True) 
    print(dt + ' vid3 returncode: ' + str(sp.returncode))  

t1 = Thread(target=take_vid1, args=[cam1Path, video_length,sampleN])
t2 = Thread(target=take_vid2, args=[cam2Path, video_length,sampleN])
t3 = Thread(target=take_vid3, args=[cam3Path, video_length,sampleN])
threads = [t1,t2,t3]
if __name__ == '__main__':
    for t in threads:
        t.start()
    for t in threads:
        t.join()


  


  I'm not sure if this is a coincidence but this issue only affects recordings from camera 3. It doesn't seem to be hardware related because I have switched camera 3 with another camera and it still happens. I've tried calling the threads in different orders, no change. I've updated ffmpeg to the most recent static build. CPU usage and memory are reasonable when the recordings are taking place. At this point I don't know what could be causing ffmpeg to fail to write frames. The link to the log file from a failed recording is below, I'm hoping someone might see something to indicate what is going on or at least have suggestions as to what to try next ?

  


  https://drive.google.com/file/d/1VKBBsf8pZbqNyYLE6o2C0kFHeBAh2kZ1/view?usp=sharing

  


• Ffmpeg converting to mp4 from mkv[mpeg@ 0x7f9c19800000] start time for stream 0 is not set in estimate_timings_from_pts

  6 février 2018, par croakouttatune

  I recently converted a number of anime episodes from MKV to MP4 to burn and watch on my SamsungBRPlayer, however during the process I wasn’t able to convert the subtitle stream #0:2 through ffmpeg from .ssa to .srt thru their respective codecs (SSA to MOV_TEXT, can also be SUBRIP). I eventually decided to extract the SSA files and encode them as .srt... one for each episode. I converted these to .srt and plugged them back into the 8 episodes.

  for i in *.mkv;do ffmpeg -i "$i" -i *.srt -c copy -c:s mov_text -c:v h264_videotoolbox -c:a aac -b:a 128k -target ntsc-dvd -y "yfolder/${i%.mkv*}.mp4"; done

  After testing the compatibility of these files I know that this video codec will work, and the BluRay player I use also recognizes the subtitle files ; However , when looking back at the streams #0:0 which is where the subtitles are stored gives me "[mpeg @ 0x7f8621000000] start time for stream 0 is not set in estimate_timings_from_pts." This stream #0:O is now a data stream...0:1 video 0:2 being audio ...
  One of the reasons I thought that I could have received this message is from an Attachment from the original MKV files in the #0:3 stream, which because it wasn’t anything more than metadata I ignored.
  Another would probably be from the code mentioned above importing multiple .srt files into each of the new .mp4 files. I did find a solution however I’m not able to utilize the coding.

  $ for video in *.mkv 
  
  do 
  
  base=${video%.mkv} ffmpeg -i $base.mkv -vf subtitles=$base.srt  
  
  $base-out.mkv ; done

  I couldn’t seem to get it to work. My files were as follows :

  [AnimeGT] Hansom Gold - 001 [720p] [suitup].mp4

  [AnimeGT] Hansom Gold - 002 [720p] [suitup].mp4

  [AnimeGT] Hansom Gold - 003 [720p] [suitup].mp4

  [AnimeGT] Hansom Gold - 004 [720p] [suitup].mp4

  [AnimeGT] Hansom Gold - 005 [720p] [suitup].mp4

  [AnimeGT] Hansom Gold - 006 [720p] [suitup].mp4

  [AnimeGT] Hansom Gold - 007 [720p] [suitup].mp4

  [AnimeGT] Hansom Gold - 008 [720p] [suitup].mp4

  So the titles are obviously fake but whatever. What I need to know is how to use the ${I%.*}.mp4 and ${h%.*}.srt to represent both the base and the video variables in the coding I failed at above.
  While keeping the data stream from each file.
  if that’s the problem. Some help would be nice.

  [mpeg @ 0x7f9c19800000] start time for stream 0 is not set in estimate_timings_from_pts

  I need to know how to deal with this.

• avcodec/svq3 : Avoid overhead of AVBuffer API

  13 septembre 2020, par Andreas Rheinhardt

  avcodec/svq3 : Avoid overhead of AVBuffer API
  Up until now, the SVQ3 decoder allocated several refcounted buffers,
  
  despite no sharing/refcounting happening at all : Their refcount never
  
  exceeds one and they are treated like ordinary buffers (with the
  
  exception that the pointer used to access them is in the middle of the
  
  allocated buffer, but this does not warrant using the AVBuffer API at
  
  all). Given that using the AVBuffer API incurs overhead, it is no longer
  
  used at all.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/svq3.c