Recherche avancée

Sur d’autres sites (11591)

• Playing 120fps in browser between original and re-made video, original is normal speed, new video is slo-mo

  1er mars 2023, par Patrick Vellia

  I used my GoPro Hero10 to record at 4k 120fps on a green screen. This original video plays slo-mo in QuickTime but "normal" speed in the browser. I want it playing normal speed, and if end user wants to slow it down they have the extra frames for that to maintain clarity, which is why I record at 120.

  


  I then used FFMPEG to create an image sequence of the video.

  


  Then I ran Image Magic to create the transparent frames.

  


  Then I put it back together with the following command for a HEVC mov file :

  


  ffmpeg -r 120 -f image2 -i transparent/image_transparent_%08d.png -vcodec hevc_videotoolbox -crf 28 -alpha_quality 1  -tag:v hvc1 output.mov


  


  I am still on an Intel MacBook Pro running FFMPEG 4.6 (as I've found 5+ was buggy with one of my commands a few months ago but can't remember which one, I think it was the videotoolbox).

  


  The GoPro video has the following stream data as input to the FFMPEG :

  


  Duration: 00:00:08.15, start: 0.000000, bitrate: 60160 kb/s
  Stream #0:0(eng): Video: hevc (Main) (hvc1 / 0x31637668), yuvj420p(pc, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 59891 kb/s, 119.88 fps, 119.88 tbr, 120k tbn, 119.88 tbc (default)
    Metadata:
      creation_time   : 2023-02-28T19:06:41.000000Z
      handler_name    : GoPro H.265
      vendor_id       : [0][0][0][0]
      encoder         : GoPro H.265 encoder
      timecode        : 19:05:32:105
  Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s (default)
    Metadata:
      creation_time   : 2023-02-28T19:06:41.000000Z
      handler_name    : GoPro AAC  
      vendor_id       : [0][0][0][0]
      timecode        : 19:05:32:105
  Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
    Metadata:
      creation_time   : 2023-02-28T19:06:41.000000Z
      handler_name    : GoPro TCD  
      timecode        : 19:05:32:105
  Stream #0:3(eng): Data: bin_data (gpmd / 0x646D7067), 76 kb/s (default)
    Metadata:
      creation_time   : 2023-02-28T19:06:41.000000Z
      handler_name    : GoPro MET  


  


  Whereas the re-constructed video has the following data :

  


  Duration: 00:00:08.13, start: 0.000000, bitrate: 763650 kb/s
  Stream #0:0: Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 763696 kb/s, 120 fps, 120 tbr, 15360 tbn, 15360 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : FFMP
      encoder         : Lavc58.134.100 hevc_videotoolbo


  


  When this re-constructed video plays in the browser, it is in slow-mo and I need to set the playbackRate to 4.0 for it to play "normally".

  


  Is there something I need to add to the video for the browser to play it at "normal" speed ?

  


• How to append dummy frames to FFmpeg pipe after EOF to prevent Shaka Packager from stopping (LL-HLS/LL-DASH) ? [closed]

  6 août, par Arjit

  I am working on a live streaming pipeline where I pipe FFmpeg into Shaka Packager to generate LL-HLS and LL-DASH output from an RTMP stream.

  


  Scenario :

  


  

  • FFmpeg receives the RTMP stream and pipes the output to Shaka Packager.

  


  • When the RTMP publisher stops streaming, FFmpeg naturally ends, sending an EOF (end-of-file) to the pipe.

  


  • This causes Shaka Packager to stop processing, as it closes its read stream on EOF.

  


  


  What I want :

  


  Before FFmpeg terminates, or even after, I want to append 5 seconds of black dummy frames (video + silent audio) to the pipe, so that :

  


  

  1. Shaka Packager can finalize the last segment properly.

  


  2. Shaka Packager doesn't terminate prematurely on EOF but processes these dummy frames.

  


  3. This is needed for clean stream finalization for LL-HLS/LL-DASH workflows.

  


  


  The Problem :

  


  

  • When FFmpeg exits, the pipe reaches EOF.

  


  • Any attempt to write additional data (like dummy frames) into the same pipe after EOF results in a "broken pipe" error because Shaka Packager has already closed its read end.

  


  • I can't find a way to inject those black frames into the stream after the original FFmpeg exits, without Shaka shutting down.

  


  


  What I've Tried :

  


  

  • Tried spawning another FFmpeg process to write black frames to the same pipe after the main FFmpeg process exits. But by then, the pipe is already closed by Shaka Packager.

  


  • Attempted using mkfifo with multiple writers but it doesn't work since FIFO allows only one writer and one reader at a time.

  


  • Can't just "delay" killing FFmpeg as the input stream is dynamic, and I need to programmatically pad with dummy frames at the end.

  


  


  My Question :

  


  How can I keep the pipe "open" to allow appending dummy black frames after the main FFmpeg process ends, so that Shaka Packager continues processing and properly finalizes the segments instead of exiting on EOF ?

  


  Is there a way to chain multiple FFmpeg processes or a muxer that can act as a "keep-alive" buffer for Shaka Packager until I explicitly tell it to end ?
  
Or is there a recommended way to handle such "end of live stream padding" when using FFmpeg → Shaka Packager pipelines ?

  


• What's the single ffmpeg command for converting a video file to mpeg-dash format with adaptive bitrate ?

  28 février 2021, par Tariq Hasan

  Resultant resolutions should be of 240p, 480p, 720p and 1080p. The resultant .mpd file must be a single file.