Recherche avancée

Sur d’autres sites (10199)

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

• How to split a 1 hour video .mp4 file into 5 seconds segments for Media Source Extension API

  15 avril 2018, par Harpreet Singh

  I’m designing a web media player with the Media Source Extension API. I really like the process of how dash.js distributes the media by having the original media split into number of small files and be played in the web. I have visited the source storage of the bbb_30fps at https://dash.akamaized.net/akamai/bbb_30fps. And I looked at the 720p video quality directory at https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_1280x720_4000k and the audio directory at https://dash.akamaized.net/akamai/bbb_30fps/bbb_a64k. I saw that the original 10 min video has been split into small segments of 720p quality excluding the audio with the file type of .m4v and small segments of the audio excluding the video with the file type of m4a.

  I want to have my 1 hour .mp4 video split into 720p quality with separate segments of duration 5 seconds excluding the audio and with the file type of .m4v. I also want to split the audio into separate segments of 5 seconds excluding the video with the file type of .m4a. If someone can help me please comment below. Thanks

  So far I have visited http://www.instructables.com/id/Making-Your-Own-Simple-DASH-MPEG-Server-Windows-10/ but it want not able to help me with my needs. And I have tried number of other methods with MP4Box but I can’t get the result I want.

• mp3/aac trim precision issue

  27 janvier 2020, par Massimo Vantaggio

  Due to mp3/aac codec doesn’t support that level of trim precision so im unable to get rounded container duration (without this 6 ms) :

  ffprobe -v error -show_entries format=duration \
  
  >   -of default=noprint_wrappers=1:nokey=1 output_audio.mp4
  
  372.006000

  MP4box generation get 6 ms more for every cycle :

  [...]
  
  Next generation scheduled in 3895 ms (DASH time 412006 ms)
  
  [...]
  
  Next generation scheduled in 3895 ms (DASH time 414012 ms)

  My MP4box command :

  MP4Box -dash-live 2000 -subdur 4000 -bound -segment-timeline -no-cache -profile dashavc264:live -subsegs-per-sidx -1 -mpd-refresh 4 -time-shift 16 -min-buffer 2000 -url-template -insert-utc -bs-switching no -run-for 86400000 -dash-ctx ../../live/log.txt -out ../../live/manifest.mpd ../current/output_1080.mp4:bandwidth=4800000#video ../current/output_720.mp4:bandwidth=2400000#video ../current/output_360.mp4:bandwidth=800000#video ../current/output_audio.mp4:bandwidth=384000#audio

  after 50% of the advertised duration an error will occur (probably)

  I say probably because the time for testing it is very long so may ask if the mp4box command provide for a stable loop or if the error will occur, and if yes, it will occur, may ask an help to debug my command line on mp4box to avoid this issue ?

  Im sorry but trial and error it’s too long since every try is about 24 hours..

  Dash.js web based purpose.

  Thansk in advance !