Recherche avancée

Sur d’autres sites (7014)

• FFMPEG - frame PTS and DTS increasing faster than it should

  20 juillet 2022, par hi im Bacon

  I am pulling footage from an RTSP camera, standardising it, and then segmenting the footage for processing. I am standardising by reducing the resolution and setting the frame rate to 12 fps.

  


  I am encoding in the PTS times the wall time of each frame as the camera is a live source and I'd like to be able to know exactly when a frame is occurring (I'm not fussed that it's not going to be perfectly on, if it's all out by a second or two because of latency that is fine by me)

  


  FFMPEG is run from python subprocessing using the following command :

  


  command = [
    "ffmpeg", "-y",
    "-rtsp_transport", "tcp", URL,
    "-pix_fmt", "yuvj422p",
    "-c:v", "libx264", # Change the video codec to the kinesis required codec
    "-an", # Remove any audio channels
    "-vf", "scale='min(1280,iw)':'min(720,ih)':force_original_aspect_ratio=decrease",
    "-r", "12",
    "-vsync", "cfr",
    "-x264opts", "keyint=12:min-keyint=12",,
    "-f", "segment",  # Set the output format as chuncked segments
    "-segment_format", segment_format,  # Set each segments format E.G. matroska, mp4
    "-segment_time", str(segment_length),  # Set the length of the segment in seconds
    "-initial_offset", str(initial_pts_offset),
    "-strftime", "1",  # Use the strformat notication in naming of the video segements
    "{}/%Y-%m-%dT%H%M%S.{}".format(directory, extension)  # Define the name and location of the segments,
    '-loglevel', 'error'
]


  


  The problem I am having is that the timestamps of the frames increase at a faster than real time rate. The initial offset is set to the time that FFMPEG is kicked off, the frames received should always be less than right now. I am using a segment length of 30 seconds and after only 5 minutes, finished segments will have a start timestamp greater than the present wall time.

  


  The rate of increase looks around 3-4 times faster than it should.

  


  Why is this the case ? how can I avoid this ? is my understand of -r right ?

  


  I believed that -r drops extra frames, evens out the frame times creating new frames where needed, but not actually changing the perceived speed of the footage. The final frame time should not be greater than the segment length away from the first frame time.

  


  I have tried using a system (filter) that sets the PTS time according to the consumer wall time setpts='time(0)/TB' but this has led to quite choppy footage as the frames can be received/processed at different rates based on the connection.

  


  The quality of the segments is great, all the data is there... just getting the times right is seeming impossible.

  


• Scene detection and concat makes my video longer (FFMPEG)

  12 avril 2019, par araujo

  I’m encoding videos by scenes. At this moment I got two solutions in order to do so. The first one is using a Python application which gives me a list of frames that represent scenes. Like this :

  285
  
  378
  
  553
  
  1145
  
  ...

  The first scene begins from the frame 1 to 285, the second from 285 to 378 and so on. So, I made a bash script which encodes all this scenes. Basically what it does is to take the current and previous frames, then convert them to time and finally run the ffmpeg command :

  begin=$(awk 'BEGIN{ print "'$previous'"/"'24'" }') 
  
  end=$(awk 'BEGIN{ print "'$current'"/"'24'" }') 
  
  time=$(awk 'BEGIN{ print "'$end'"-"'$begin'" }') 
  
  
  
  ffmpeg -i $video -r 24 -c:v libx265  -f mp4 -c:a aac -strict experimental -b:v 1.5M -ss $begin -t $time "output$count.mp4" -nostdin

  This works perfect. The second method is using ffmpeg itself. I run this commands and gives me a list of times. Like this :

  15.75
  
  23.0417
  
  56.0833
  
  71.2917
  
  ...

  Again I made a bash script that encodes all these times. In this case I don’t have to convert to times because what I got are times :

  time=$(awk 'BEGIN{ print "'$current'"-"'$previous'" }') 
  
  ffmpeg -i $video -r 24 -c:v libx265  -f mp4 -c:a aac -strict experimental -b:v 1.5M -ss $previous -t $time "output$count.mp4" -nostdin

  After all this explained it comes the problem. Once all the scenes are encoded I need to concat them and for that what I do is to create a list with the video names and then run the ffmpeg command.

  list.txt

  file 'output1.mp4'
  
  file 'output2.mp4'
  
  file 'output3.mp4'
  
  file 'output4.mp4'

  command :

  ffmpeg -f concat -i list.txt -c copy big_buck_bunny.mp4

  The problem is that the "concated" video is longer than the original by 2.11 seconds. The original one lasts 596.45 seconds and the encoded lasts 598.56. I added up every video duration and I got 598.56. So, I think the problem is in the encoding process. Both videos have the same frames number. My goal is to get metrics about the encoding process, when I run VQMT to get the PSNR and SSIM I get weird results, I think is for this problem.

  By the way, I’m using the big_buck_bunny video.

• Is there a way to get FFprobe to return codec_name from firs first video, audio, and subtitle stream in a video in a single call to FFprobe ?

  26 août 2023, par Chase Westlye

  ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 (filename) 


  


  is how to retrieve the codec_name of the first video stream in a file via FFprobe.

  


  Replace v:0 with a:0 to get the first audio stream, and it returns the codec_name of the first audio stream in the file.

  


  And replace v:0 with s:0 to get the codec_name of the first subtitle stream in the file.

  


  Awesome.

  


  What isn't awesome, is having to call FFprobe three times for these operations and having to hit the file three times.

  


  Is there a way to call FFProbe once, and have FFProbe return the codec_name of the first video, audio, and subtitle stream (instead of separate calls) ?