Recherche avancée

Sur d’autres sites (7066)

• Query on ffmpeg's concat demuxer parameters to end segments at outpoint timestamps and retain most properties same as input (fps, time_base etc)

  17 octobre 2024, par code

  In order to concatenate video files of matching fps, codec, resolution, time_base (in fact some are segments from same video), ffmpeg concat demuxer (to prevent re-encoding) approach has been used.
But ffmpeg did not stop concatenating segments at outpoint time specified in input demuxer text file !

  


  (Note : From Python code programmatically via sub-process approach, ffmpeg has been invoked )

  


  input.txt file for concat demuxer contained :

  


  ffconcat version 1.0
file 'numbered.mp4'
inpoint  2.083333
outpoint 2.166667



  


  (the time stamps provided above are of 50th (frame pts 49 in video, this is a keyframe) to 52nd (frame pts 51 in video, non-key frame), total 3 consecutive frames, inpoints given in this query are of a key-frame

  


  (video file referred in it i.e 'numbered.mp4' has each frame displaying its frame number ; it has h264 high coded 480p resolution, 10-seconds long with 240 frames and 24fps , <1MB in size shared at : https://filetransfer.io/data-package/F5caZ0xT#link )

  &#xA;

  ffmpeg command invoked programmatically with parameters :

  &#xA;

  &#xA;

  ffmpeg -f concat -safe 0 -fflags +genpts -i -c copy -video_track_timescale 24

  &#xA;

  &#xA;

  Output snippet contained :

  &#xA;

  &#xA;

  frame= 5 fps=0.0 q=-1.0 Lsize= 28KiB time=00:00:00.12 bitrate=1857.8kbits/s speed= 56x

  &#xA;

  &#xA;

  Problem 1 : It Shows there are 5 frames ! ffmpeg has concatenated 2 more frames beyond outpoint timestamp !

  &#xA;

  Query 1) : What are right parameter values to be given to ffmpeg concat demuxer method(or in concat demuxer input file) to make ffmpeg concatenate segments accurately till frames matching outpoint timestamp without overshooting or concatenating frames beyond outpoint timestamps ?

  &#xA;

  Problem2 : When another segment from same input file is referenced in concat demuxer input file, frame pts and timestamps were messed up in resultant output !

  &#xA;

  concat demuxer input file content(updated) :

  &#xA;

  ffconcat version 1.0
file 'numbered.mp4'
inpoint  0
outpoint 0.125000
file 'numbered.mp4'
inpoint  2.083333
outpoint 2.166667



  &#xA;

  command invoked was :

  &#xA;

  ffmpeg -f **concat **-safe 0 -fflags +genpts   -i \ -c copy 
  -video_track_timescale 24  \


  &#xA;

  ffprobe output (on above output file, edited to reduce size) :

  &#xA;

  
key_frame=1, pts=0
    pts_time=0.000000
key_frame=0, pts=1
    pts_time=0.041667
key_frame=0, pts=2
    pts_time=0.083333
key_frame=0, pts=3
    pts_time=0.125000
key_frame=0, pts=4
    pts_time=0.166667
key_frame=1, pts=3
    pts_time=0.125000
key_frame=0, pts=6
    pts_time=0.250000
key_frame=0, pts=5
    pts_time=0.208333
key_frame=0, pts=7
    pts_time=0.291667
key_frame=0, pts=7
    pts_time=0.291667


  &#xA;

  Confirms both pts and pts_time values are messed up (though segments referred in demuxer input file were several frames away with no overlapping ).

  &#xA;

  Query 2) What are accurate parameters to be given to concatenate segments represented by input demuxer file without causing this pts or pts_time issues ?

  &#xA;

  (In this test, all segments referred by demuxer have same parameters and are different segments of same video file itself ! so mismatch in codec parameters may not be the cause )

  &#xA;

  problem 3 : while input video had bitrate of 412654 (412.654kbps), concat demuxer resulted in output file with bitrate 1318777 (1.318 Mbps) over 3x the input bitrate.

  &#xA;

  Query 3) : What are accurate parameters to be given to retain all (almost) codec parameters same as input video and only perform concatenation without modifying time_base or framerate ?

  &#xA;

  Note : when -video_track_timescale 24 parameter is not provided as input parameter to concat demuxer, time_base in resultant output was different value (1/1000 ) instead of input files' time_base 1/24 !

  &#xA;

  ( when the Pts times are messed up, Non-monotonic DTS .. errors were observed in output : [vost#0:0/copy @ 000002c1b9b41140] Non-monotonic DTS ; previous : 2, current : 1 ; changing to 3. This may result in incorrect timestamps in the output file..)

  &#xA;

  To clarify, reason to use concat demuxer is to prevent re-encoding video, final usage would be to concatenate some segments of input video file with a few more video files all containing same codec parameters like fps,resolution,time_base etc.

  &#xA;

  Query 4) : Is it accurate at frame level to take pts_time values from ffprobe output and use these in ffmpeg concat demuxer input file for inpoint/outpoint values ?

  &#xA;

  (as ffprobe pts_time values possibly might be aligned with ffmpeg expectations, thought of taking pts_time values from ffprobe command output instead of venturing into computing frame start time)

  &#xA;

  the small (<1MB) input video file used in this test has been shared at : https://filetransfer.io/data-package/F5caZ0xT#link

  &#xA;

  input video file's ffprobe output has been pasted(trimmed to save space) :

  &#xA;

  "codec_name": "h264",
"codec_long_name": "H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10",
"profile": "High",
"codec_type": "video",
"codec_tag_string": "avc1",
"codec_tag": "0x31637661",
"width": 640,
"height": 480,
"coded_width": 640,
"coded_height": 480,
"closed_captions": 0,
"film_grain": 0,
"has_b_frames": 2,
"sample_aspect_ratio": "1:1",
"display_aspect_ratio": "4:3",
"pix_fmt": "yuv420p",
"level": 41,
"color_range": "tv",
"color_space": "smpte170m",
"chroma_location": "left",
"field_order": "progressive",
"refs": 1,
"is_avc": "true",
"nal_length_size": "4",
"id": "0x1",
"r_frame_rate": "24/1",
"avg_frame_rate": "24/1",
"time_base": "1/24",
"start_pts": 0,
"start_time": "0.000000",
"duration_ts": 240,
"duration": "10.000000",
"bit_rate": "409628",
"bits_per_raw_sample": "8",
"nb_frames": "240",
"extradata_size": 49,


  &#xA;

  Searched quite a lot online for a solution but searches didnot result in finding a fix for this concat demuxer situation&#xA;I seek helpful answers to the queries presented above, Thanks All

  &#xA;

  (while some workarounds like converting to raw h264 and then applying time scale again to each segment is suggested in other discussions, in current scenario, the input video file is just 1 so it appears accurate parameters to ffmpeg concat demuxer method are needed and be helpful to others facing similar issue)

  &#xA;

• vulkan : retrieve Vulkan 1.1 properties

  18 novembre 2024, par Lynne

  vulkan : retrieve Vulkan 1.1 properties
  Required to know the subgroup size.
  

  • [DH] libavutil/vulkan.c
  • [DH] libavutil/vulkan.h

• hwcontext_vulkan : require storage properties to claim formats as supported

  24 novembre 2024, par Lynne

  hwcontext_vulkan : require storage properties to claim formats as supported
  This function dates back a long time ago, before vkfmt_from_pixfmt2.
  
  When it was converted over, the thought was that this was far too
  
  restrictive to demand storage images for each format.
  
  With the new clever function, it makes sure to check that the compatible
  
  subformats a format can be used as support storage capabilities.
  This gets rid of fake support for RGB48/RGB96 which some implementations
  
  offer but don't support using as storage images.
  

  • [DH] libavutil/hwcontext_vulkan.c