Recherche avancée

Sur d’autres sites (13264)

• FFMEPG - How to resolve 'Reinit context to WxH ... deprecated pixel format'

  30 juin 2022, par hi im Bacon

  I am using the pyav library to read and process video data and as I am reading through the videos I am getting lots (and lots) of the following output.

  


  I am creating the videos by segmenting either a much larger source file or RTSP/HTTP IP camera.

  


  I would love to understand what this output actually means, and what I can do to prevent its output

  


  ffmpeg creating videos :

  


  ffmpeg -y -i https://manifest.googlevideo.com/api/... -pix_fmt yuvj422p -c:v libx264 -an -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 -segment_format matroska -segment_time 5 -initial_offset 1656497474.686672 -strftime 1 /tmp/tmp87cc1n2o/%Y-%m-%dT%H%M%S.mkv -loglevel error


  


  python :

  


  container = av.open(io.BytesIO(...))
for frame in container.decode(video=0):
   ...


  


  2022-06-30 14:45:00,964 DEBUG:****:Creating <***.core.generators.av.AVGenerator object at 0x7f13340abd50> with target path: <_io.BytesIO object at 0x7f13341c93b0>
2022-06-30 14:45:00,966 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
2022-06-30 14:45:00,966 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuvj422p
2022-06-30 14:45:00,984 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
2022-06-30 14:45:01,045 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
2022-06-30 14:45:01,046 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuvj422p
deprecated pixel format used, make sure you did set range correctly
deprecated pixel format used, make sure you did set range correctly
 (repeated 9 more times)
2022-06-30 14:45:01,194 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
deprecated pixel format used, make sure you did set range correctly
deprecated pixel format used, make sure you did set range correctly
2022-06-30 14:45:01,215 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
deprecated pixel format used, make sure you did set range correctly
deprecated pixel format used, make sure you did set range correctly
 (repeated 17 more times)
2022-06-30 14:45:01,384 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
deprecated pixel format used, make sure you did set range correctly
deprecated pixel format used, make sure you did set range correctly
 (repeated 3 more times)
2022-06-30 14:45:01,398 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
deprecated pixel format used, make sure you did set range correctly
deprecated pixel format used, make sure you did set range correctly
 (repeated 22 more times)
2022-06-30 14:45:01,550 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p
deprecated pixel format used, make sure you did set range correctly
deprecated pixel format used, make sure you did set range correctly
 (repeated 2 more times)
2022-06-30 14:45:01,592 DEBUG:libav.h264:Reinit context to 1280x720, pix_fmt: yuv420p


  


• Slowing down audio using FFMPEG

  24 janvier 2020, par Maxim_A

  For example I have a source file which is the duration of 6.40 seconds.
  I divide this duration into 10 sections. Then each section is slowed down by a certain value. This works great.

  ffmpeg.exe -i preresult.mp4 -filter_complex 
  
  "[0:v]trim=0:0.5,setpts=PTS-STARTPTS[vv0]; 
  
  [0:v]trim=0.5:1,setpts=PTS-STARTPTS[vv1]; 
  
  [0:v]trim=1:1.5,setpts=PTS-STARTPTS[vv2]; 
  
  [0:v]trim=1.5:2,setpts=PTS-STARTPTS[vv3]; 
  
  [0:v]trim=2:2.5,setpts=PTS-STARTPTS[vv4]; 
  
  [0:v]trim=2.5:3,setpts=PTS-STARTPTS[vv5]; 
  
  [0:v]trim=3:3.5,setpts=PTS-STARTPTS[vv6]; 
  
  [0:v]trim=3.5:4,setpts=PTS-STARTPTS[vv7]; 
  
  [0:v]trim=4:4.5,setpts=PTS-STARTPTS[vv8]; 
  
  [0:v]trim=4.5:6.40,setpts=PTS-STARTPTS[vv9];
  
  
  
  [vv0]setpts=PTS*2[slowv0];
  
  [vv1]setpts=PTS*4[slowv1];
  
  [vv2]setpts=PTS*5[slowv2];
  
  [vv3]setpts=PTS*2[slowv3];
  
  [vv4]setpts=PTS*3[slowv4];
  
  [vv5]setpts=PTS*6[slowv5];
  
  [vv6]setpts=PTS*3[slowv6];
  
  [vv7]setpts=PTS*5[slowv7];
  
  [vv8]setpts=PTS*2[slowv8];
  
  [vv9]setpts=PTS*6[slowv9];
  
  
  
  [slowv0][slowv1][slowv2][slowv3][slowv4][slowv5][slowv6][slowv7][slowv8][slowv9]concat=n=10:v=1:a=0[v1]"  
  
  -r 30 -map "[v1]" -y result.mp4

  Then I needed to slow down along with the video and audio stream. In the documentation I found out about the atempo filter. The documentation says that the extreme boundaries of the value of this filter are from 0.5 to 100. To slow down by half, you need to use the value 0.5. I also learned that if you need to slow down the audio by 4 times, then you just need to apply two filters.

  [aa0]atempo=0.5[aslowv0] //Slowdown x2
  
  [aa0]atempo=0.5, atempo=0.5[aslowv0] //Slowdown x4

  Question 1 :
  How can i slow down audio an odd number of times ? for example, slow down audio by 3.5.7 times. There is no explanation of this point in the documentation.

  Question 2 :
  Do i understand correctly that if you slow down separately the audio stream and the video stream, they will have the same duration ?

  Thank you all in advance !

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