Sur d’autres sites (16239)

• ffmpeg audio stream retiming for infinite input

  26 février 2020, par Aeon

  I have a ffmpeg process that reads input data from stdout infinitely.
  Its input data are mkv (matroska) containers (sent to stdin by another process), each container contains 4 audio streams (without any video) - 3 ACC streams and 1 FLAC stream. The output of this process is dash muxer.

  ffmpeg -hide_banner -re -fflags +getpts -avoid_negative_ts make_non_negative -stream_loop -1 -f matroska -i pipe: -map 0 -c:a copy -strict -2 -f dash -use_timeline 1 -use_template 1 -seg_duration 5 -dash_segment_type mp4 manifest.mpd

  The problem occurs after the first muxing of obtained mkv file. When it’s time to mux the next one from pipe, I get following messages :

  [matroska,webm @ 000001d3050bba40] Found unknown-length element with ID 0x18538067 at pos. 0x54c766 for which no syntax for parsing is available.
  
  [matroska,webm @ 000001d3050bba40] Seek to desired resync point failed. Seeking to earliest point available instead.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:0; previous: 881714, current: 51200; changing to 881715. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:1; previous: 881714, current: 51200; changing to 881715. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:2; previous: 881714, current: 51200; changing to 881715. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:3; previous: 884005, current: 51200; changing to 884006. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:3; previous: 884006, current: 51244; changing to 884007. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:3; previous: 884007, current: 51244; changing to 884008. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:3; previous: 884008, current: 51288; changing to 884009. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:3; previous: 884009, current: 51288; changing to 884010. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:3; previous: 884010, current: 51332; changing to 884011. This may result in incorrect timestamps in the output file.
  
  [dash @ 000001ac98349080] Non-monotonous DTS in output stream 0:3; previous: 884011, current: 51332; changing to 884012. This may resul
  
  ...

  and dash muxer simply stops generating new segments. I do understand that it’s an issue with timestamps, but I don’t know how to fix that.

  I’ve tried to use -fflags +getpts - no success.
  use_wallclock_as_timestamps 1 solves the "Non-monotonous DTS..." issue, but brings in a bunch of issues with playback, like freezing, breaking, etc., so the playback becomes completely unlistenable.
  Something strange also happens to the SegmentTemplate node of the manifest - its timescale attribute is set to 44100, although there should be 1000000 (-frag_duration 1 is ignored in this case)

  Question : I’m asking for your help in re-timing, i.e. generating the correct timestamps for dash muxing for each new incoming file in the pipe.

• Is there some way to configure ffmpeg to include support for signed 24-bit WAV output ?

  10 mars 2020, par Greg

  24-bit sample sizes are not at all uncommon for PCM/WAV data, so I was surprised to see this :

  Invalid sample format 's24'

  ... when I ran this :

  ffmpeg -i input.oga -y -f wav -ar 44100 -sample_fmt s24 -ac 2 output.wav

  When I look at the ffmpeg FAQ page it says that it doesn’t support signed 24-bit sample sizes.

  Fair enough, but I’m having a hard time accepting that this very powerful tool which supports an impressively large number of formats is somehow missing support for this really common sample width.

  All I can think of is that maybe it’s a build configuration issue.

  So this question is...

  Is there some way to configure ffmpeg to include support for signed 24-bit WAV output ?

• How to get a list of video devices with a particular VendorID and/or ProductID using FFmpeg (on Mac OS)

  26 mai 2020, par mcgregor94086

  The master task :

  



  I am writing software for a multiple USB camera array. The camera may be connected to a CPU that has other USB cameras builtin or attached. I need to capture one 1920x1080 JPG image from EACH of MY array's cameras into a directory of images - but I need to EXCLUDE any OTHER cameras when taking pictures.

  



  Right now I am trying to implement for MacOS, but in the future I will be implementing for Windows, Linux, iOS and Android.

  



  What is known :

  



  I know the VendorID, ProductID and UniqueID (reported by the MacOS USB system System Hardware Report) for each of the cameras in the camera array.

  



  UNIQUESKY_CAR_CAMERA #5:

  Model ID: UVC Camera VendorID_7119 ProductID_2825
  Unique ID:    0x143400001bcf0b09

UNIQUESKY_CAR_CAMERA #6:

  Model ID: UVC Camera VendorID_7119 ProductID_2825
  Unique ID:    0x143300001bcf0b09


  



  The problem code :

  



  I made the following call to FFmpeg

  



  ffmpeg -nostdin -hide_banner -an -sn -dn  -f avfoundation -list_devices true -I 1


  



  I received the following result in stderr :

  



      [AVFoundation indev @ 0x7fc870e21800] AVFoundation video devices:
    [AVFoundation indev @ 0x7fc870e21800] [0] FaceTime HD Camera (Built-in)
    [AVFoundation indev @ 0x7fc870e21800] [1] UNIQUESKY_CAR_CAMERA #5
    [AVFoundation indev @ 0x7fc870e21800] [2] UNIQUESKY_CAR_CAMERA #6
    [AVFoundation indev @ 0x7fc870e21800] [3] Capture screen 0
    [AVFoundation indev @ 0x7fc870e21800] [4] Capture screen 1
    [AVFoundation indev @ 0x7fc870e21800] AVFoundation audio devices:
    [AVFoundation indev @ 0x7fc870e21800] [0] MacBook Pro Microphone
    1: Input/output error


  



  Of these devices listed in the output, I happen to know (in this particular TEST CASE) that the cameras in my test array, are only these two :

  



  [1] UNIQUESKY_CAR_CAMERA #5
[2] UNIQUESKY_CAR_CAMERA #6


  



  With this knowledge, I can select the indices (1 2) that I need, and then use the following code to capture an image from each :

  



  for i in 1 2; 
do
    ffmpeg  -y -hide_banner  -f avfoundation  -r 15 -video_size 1920x1080 -i 1  -f image2 -qscale:v 1 -qmin 1 -qmax 1 -frames:v 1 img$i.jpg;
done



  



  Unfortunately, in production use (i.e. outside of this test case), I CAN NOT rely on cameras all identifying themselves with the same TEXT "name" prefix (e.g. "UNIQUESKY_CAR_CAMERA"), so I can't just use grep to select the ones I want.

  



  But I CAN be sure that I will know their VendorID, ProductID and UniqueIDs.

  



  So, IF I could get

  



  ffmpeg  -nostdin -hide_banner -an -sn -dn  -f avfoundation -list_devices true -I 1


  



  to also list the VendorID and ProductID, then I could grep for those values.

  



  Is this solution possible ? I can't find syntax in the documentation or examples for how to set such limits.

  



  ALTERNATIVELY : if I could specify to FFmpeg -list_devices to limit the output list to just those with my specified VendorID and ProductIDs then I could easily get the list of device indices I will need for the succeeding image extraction.

  



  Is this solution possible ? I can't find syntax in the documentation or examples for how to set such limits.

  



  Special Note :
  
The cameras I am using are all 1920x1080, and that resolution is necessary for my application. As has been noted by many Mac users on the web, other image capture programs (such as imagesnap) sometimes capture images at lower resolution (1024x720) than the cameras are capable of, and will not capture images at higher resolutions such as (1920x1080). For this reason, and because it is available on ALL the OS platforms of interest to us, I chose to use FFmpeg.