Recherche avancée

Sur d’autres sites (12070)

• Issues with encoded video in Chrome playback

  4 novembre 2022, par Michael Joseph Aubry

  Chrome is very particular about how a video is encoded. An issue I am facing with a specific type of video is seeked either does not get called at all or at least within a 20s period of time within certain frames.

  


  I can consistently repeat this issue using this muxer https://github.com/redbrain/ytdl-core-muxer/blob/main/index.js

  


  When I paint each frame in puppeteer Lambda there are certain frames where either seeked never gets called or the 20s timeout is called before the frame can resolve.

  


  Here is an example of a log sequence for this particular frame that fails

  


  When I re-encode this video, simply by running ffmpeg -i VIDEO_URL then try with the new one there are no issues.

  


  In order to see the differences on a frame level I run ffprobe -show_frames goodvideo.mp4 > good.txt && ffprobe -show_frames badvideo.mp4 > bad.txt and here is what I see with the frames around the 117s mark where the first sign of corruption occurs

  


  Good Frame @ 117s

  


  [FRAME]
media_type=video
stream_index=0
key_frame=0
pts=7020013
pts_time=117.000217
pkt_dts=7020013
pkt_dts_time=117.000217
best_effort_timestamp=7020013
best_effort_timestamp_time=117.000217
pkt_duration=1001
pkt_duration_time=0.016683
pkt_pos=27029408
pkt_size=1741
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=B
coded_picture_number=7014
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]


  


  Bad Frame @ 117s

  


  [FRAME]
media_type=video
stream_index=0
key_frame=0
pts=117000
pts_time=117.000000
pkt_dts=117000
pkt_dts_time=117.000000
best_effort_timestamp=117000
best_effort_timestamp_time=117.000000
pkt_duration=16
pkt_duration_time=0.016000
pkt_pos=20592998
pkt_size=18067
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=P
coded_picture_number=7011
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]


  


  Does anyone know the differences and why the bad frame is causing my rendering function to have issues seeking ?

  


  This is how I am muxing the bad video, Im trying to avoid re-encoding, but by re-encoding it seems to fix the issue. Are there any settings I can apply to avoid re-encoding while making the video more durable on Chrome ?

  


  // default export: the ffmpeg muxer
const ytmux = (link, options: any = {}) => {
  const result = new stream.PassThrough({
    highWaterMark: options.highWaterMark || 1024 * 512
  });

  ytdl.getInfo(link, options).then((info: videoInfo) => {
    let audioStream: Readable = ytdl.downloadFromInfo(info, {
      ...options,
      quality: "highestaudio"
    });
    let videoStream: Readable = ytdl.downloadFromInfo(info, {
      ...options,
      quality: "highestvideo"
    });
    // create the ffmpeg process for muxing
    let ffmpegProcess: any = cp.spawn(
      ffmpegPath.path,
      [
        // supress non-crucial messages
        "-loglevel",
        "8",
        "-hide_banner",
        // input audio and video by pipe
        "-i",
        "pipe:3",

        "-i",
        "pipe:4",

        // map audio and video correspondingly
        "-map",
        "0:v",
        "-map",
        "1:a",

        // no need to change the codec
        "-c",
        "copy",

        // Allow output to be seekable, which is needed for mp4 output
        "-movflags",
        "frag_keyframe+empty_moov",

        "-fflags",
        "+genpts",

        "-f",
        "matroska",

        "pipe:5"
      ],
      {
        // no popup window for Windows users
        windowsHide: true,
        stdio: [
          // silence stdin/out, forward stderr,
          "inherit",
          "inherit",
          "inherit",
          // and pipe audio, video, output
          "pipe",
          "pipe",
          "pipe"
        ]
      }
    );

    audioStream.pipe(ffmpegProcess.stdio[4]);
    videoStream.pipe(ffmpegProcess.stdio[3]);
    ffmpegProcess.stdio[5].pipe(result);
  });
  return result;
};


  


• ffmpeg pipe Invalid data found when processing input

  28 mars 2021, par Ankit Maheshwari

  Here is my configuration.


  


  


  


  const ffmpegPath = require('@ffmpeg-installer/ffmpeg').path;
const spawn = require('child_process').spawn;

ffmpeg = spawn(ffmpegPath, [
      
// Remove this line, as well as `-shortest`, if you send audio from the browser.
      // '-f', 'lavfi', '-i', 'anullsrc',

      // FFmpeg will read input video from STDIN
      '-i', '-',

      // -re flag means to Read input at native frame rate.
      '-re', '-y',

      // thread_queue_size added to avoid err: Thread message queue blocking; consider raising the thread_queue_size option, required before each input - this is for image2
      // '-thread_queue_size', '2048',

      // REF TO OVERLAY 
      // https://stackoverflow.com/questions/10438713/overlay-animated-images-with-transparency-over-a-static-background-image-using-f?rq=1
      // -loop loops the background image input so that we don't just have one frame, crucial!

      // The image file muxer writes video frames to image files, http://underpop.online.fr/f/ffmpeg/help/image2-1.htm.gz
      '-f', 'image2',

      // The -loop option is specific to the image file demuxer and gif muxer, so it can't be used for typical video files, but it can be used to infinitely loop a series of input images.
      '-loop', '1',

      // pattern_type is used to determine the format of the images contained in the files.
      // Read images matching the "*.png" glob pattern, that is files terminating with the ".png" suffix
      '-pattern_type', 'glob',

      // '-i', `images/${streamConfigData.youtube_key}/destination/image-*.png`,

      '-i', `images/${streamConfigData.youtube_key}/overlay/abc.png`,

      // '-vf', 'scale=1920x1080:flags=lanczos',
      
      // -shortest ends encoding when the shortest input ends, which is necessary as looping the background means that that input will never end.
      // 'overlay=shortest=1',

      "-filter_complex", "[1:v]format=rgba,colorchannelmixer=aa=1[fg];[0][fg]overlay",
      
      // Because we're using a generated audio source which never ends,
      // specify that we'll stop at end of other input.  Remove this line if you
      // send audio from the browser.
      // '-shortest',
      
      // If we're encoding H.264 in-browser, we can set the video codec to 'copy'
      // so that we don't waste any CPU and quality with unnecessary transcoding.
      // If the browser doesn't support H.264, set the video codec to 'libx264'
      // or similar to transcode it to H.264 here on the server.
      // '-vcodec', 'libx264',
      // it is not possible to filter and stream copy the same stream at the same time. https://stackoverflow.com/a/53526514/4057143
      '-vcodec', 'copy',
      
      // if browser not supports encoding AAC, we must transcode the audio to AAC here on the server.
      // '-acodec', 'aac',

      // Use this rate control mode if you want to keep the best quality and care less about the file size. CRF scale is 0–51, where 0 is lossless, 23 is the default, and 51 is worst quality possible. A lower value generally leads to higher quality, https://trac.ffmpeg.org/wiki/Encode/H.264
      '-crf', '23',

      // preset provide a certain encoding speed to compression ratio. A slower preset will provide better compression. medium – default preset, https://trac.ffmpeg.org/wiki/Encode/H.264
      '-preset', 'ultrafast',

      // -r set the frame rate. Generally, -r. Use the filter when you need to change framerate before applying further filters.
      // '-r', '30',
      // '-framerate', '30',

      //debug level logs
      '-loglevel', 'debug',
      '-v', 'verbose',

      // -g GOP_LEN_IN_FRAMES, -g sets the keyframe interval. https://superuser.com/a/908325
      '-g', '60',

      // video timescale, not sure what it is!
      '-video_track_timescale', '1000',

      // a live stream with more/less constant bit rate, to be able to control the bandwidth used.
      // a live stream with limited bit rate
      '-b:v', '15000k',
      // '-maxrate', '4000k',
      // '-bufsize', '8000k',

      // FLV is the container format used in conjunction with RTMP
      '-f', 'flv',
      
      // The output RTMP URL.
      // For debugging, you could set this to a filename like 'test.flv', and play
      // the resulting file with VLC.
      rtmpUrl 
    ], {
      env: {
          NODE_ENV: 'production',
          PATH: process.env.PATH
      }
    });

  


  


  



• Revision 37308 : un trigger à la fin du rechargement

  15 avril 2010, par kent1@… — Log

  un trigger à la fin du rechargement