Recherche avancée

Sur d’autres sites (8676)

• avformat/mpegtsenc : Fix mpegts_write_pes() for private_stream_2 and other types

  25 avril 2021, par zheng qian

  avformat/mpegtsenc : Fix mpegts_write_pes() for private_stream_2 and other types
  According to the PES packet definition defined in Table 2-17 of ISO_IEC_13818-1
  
  specification, some fields like PTS/DTS or pes_extension could only appears if
  
  the stream_id meets the condition :
  if (stream_id != 0xBC &&  // program_stream_map
  
      stream_id != 0xBE &&  // padding_stream
  
      stream_id != 0xBF &&  // private_stream_2
  
      stream_id != 0xF0 &&  // ECM
  
      stream_id != 0xF1 &&  // EMM
  
      stream_id != 0xFF &&  // program_stream_directory
  
      stream_id != 0xF2 &&  // DSMCC_stream
  
      stream_id != 0xF8)    // ITU-T Rec. H.222.1 type E stream
  And the following stream_id types don't have fields like PTS/DTS :
  else if ( stream_id == program_stream_map
  
  || stream_id == private_stream_2
  
  || stream_id == ECM
  
  || stream_id == EMM
  
  || stream_id == program_stream_directory
  
  || stream_id == DSMCC_stream
  
  || stream_id == ITU-T Rec. H.222.1 type E stream ) 
  
      for (i = 0 ; i < PES_packet_length ; i++) 
  
          PES_packet_data_byte
  
      
  
  
  Current implementation skipped the check of stream_id causing some kind of
  
  streams like private_stream_2 to be incorrectly written with actually a
  
  private_stream_1-like PES header with PTS/DTS field. For example, Japan DTV
  
  transmits news and alerts through ARIB superimpose that utilizes
  
  private_stream_2 still could not be remuxed correctly for now.
  This patch set fixes the remuxing for private_stream_2 and
  
  other stream_id types.
  Signed-off-by : zheng qian <xqq@xqq.im>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavformat/mpegtsenc.c

• ffmpeg FPS information mismatch with the video

  8 décembre 2017, par Adorn

  I have a bunch of videos with some statistics of what is happening inside a video. One such piece of information is given in terms of time of the video in seconds up to one decimal point.

  To get the FPS of a video, I am using ffmpeg -i

  But when I manually compute one particular frame’s time using given FPS, it does not match.

  For example, ffmpeg outputs FPS = 30.

  I look at the video statistics, the frame at the 156.8 = 2.368 has to be
  4704'th frame. I open the video using ’skvideo’, read all the frames, and view the 4704'th frame. It is some frame around time 2.12 ?. I checked multiple such instances in multiple videos and this is a common behavior.

  I do not understand why this is so and how can I get around the problem ?

  As such I am not bounded by ffmpeg. Skvideo is being used to read the videos. I tried opencv, as of now it does not work with VideoCapture, and reinstalling it is costly for me time wise. But I guess ’opencv/skvideo’ should not matter, one can count the frames manually as well.

  So, in the solution, I am looking out for -

  1. Given timestamps of inside of a video, how can I find a frame of that particular time location ?

  2. In case someone might have already worked on this, this is related to THUMOS dataset. I am on Ubuntu 16.04

  EDIT_1

  Actually I can be more specific as it is a publicly available data. The time bounds are of an important activity. For example, in a video, when does basketball dunk occurs ? It is given in pairs - [start end]. Some videos have multiple activities, some have only one.

  Here is a sample video, and following are the activity times.

  [[  16.5, 20.8],
  
  [  26.6, 32.2],
  
  [  34.8, 42.1],
  
  [  47.8, 50.0],
  
  [  58.1, 62.9],
  
  [  65.6, 67.2],
  
  [  68.5, 74.0],
  
  [  76.4, 78.3],
  
  [  78.7, 79.8],
  
  [  80.8, 82.1],
  
  [  85.0, 87.3],
  
  [  90.1, 91.4],
  
  [  98.5, 100.3]]

  I also tried checking manually, 32.87 FPS "almost" works for few videos but not for all. and almost means it is off by 10 frames. This is a huge difference for my task, and I need exact frame.

  Also, there has to be some way, because it can be visually observed with multiple video players that times in the dataset are correct.

• How can I get my saved mp4 to exactly match the output of plot.show() ?

  10 mai 2019, par Jimmy

  When I try to save the results of an animation to mp4 using ffmpeg, I am getting a jumbled mess.

  plt.show() shows exactly what I want it to show in the animation. However, when I save it using ffmpeg, the result is very different from what plt.show() returns. I have tried various arguments for fps etc. but nothing has helped.

  %matplotlib
  
  import pandas as pd
  
  import matplotlib as mpl ## uncomment this if you are running this on a Mac
  
  #mpl.use('TkAgg')         ## and want to use blit=True
  
  import matplotlib.pyplot as plt 
  
  import matplotlib.animation as animation 
  
  import numpy as np 
  
  import csv
  
  
  
  people = ('','Jim', 'Dan')
  
  plt.rcdefaults()
  
  fig, ax = plt.subplots()
  
  y_pos = np.arange(len(people))
  
  
  
  ax.set_xlim(0,10)
  
  ax.set_yticks(y_pos)
  
  ax.set_yticklabels(people)
  
  ax.invert_yaxis() 
  
  ax.set_xlabel('Skill')
  
  titleList=['Basketball','Hockey','Baseball']
  
  df=[[0,5,7],[0,4,9],[0,2,6]]
  
  def animate(i):
  
     # Example data
  
      while i<3:
  
          ax.set_yticks(y_pos)
  
          ax.set_yticklabels(people)
  
          ax.set_xlabel(titleList[i])
  
          performance=df[i]
  
  
  
          title = ax.text(0.5,0.95,str(titleList[i]), bbox={'facecolor':'w', 'alpha':0.5, 'pad':5},transform=ax.transAxes, ha="center")
  
  
  
          rects = ax.barh(y_pos, performance, align='center',
  
                  color='blue', ecolor='None')
  
          return [rect for rect in rects] + [title]
  
  
  
  
  
  ani = animation.FuncAnimation(fig,animate, frames=3, blit=True
  
                              ,interval=2000,repeat=False)
  
  
  
  plt.rcParams['animation.ffmpeg_path'] = 'C:\\ffmpeg\\bin\\ffmpeg.exe'
  
  Writer = animation.writers['ffmpeg']
  
  ani.save('test.mp4')
  
  plt.show() 

  The result is a very fast video where all the data gets written over (similar to the plt.show() results when blit=False).