Recherche avancée

Sur d’autres sites (9502)

• 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 throws "cur_dts is invalid" error when trying to get stream from IP camera

  17 octobre 2022, par Max

  I'm trying to stream from an IP camera with the following ffmpeg command :

  


  const command = [
        '-loglevel',
        'debug',
        '-timeout',
        '10000000',
        '-rtsp_transport',
        'tcp',
        '-i',
        this.cameraInfo.url,
        '-c:v',
        'copy',
        '-c:a',
        'aac',
        '-f',
        'mp4',
        '-movflags',
        '+faststart+frag_every_frame+empty_moov+default_base_moof',
        "-min_frag_duration",
        this.livestreamSegmentDuration,
        'pipe:1',
    ];


  


  With this command I pass an output to another stream transformer and stream as HLS using "mp4" instead of "ts" to avoid transcoding.

  


  Everything works smoothly with different cams, but when I try to get the stream from "Meldana" (issue is related to all ip cameras of this manufacturer), it constantly throws the following error and does not stream :

  


  cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:1 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:1 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:1 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:1 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:1 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:1 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:1 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)


  


  Even though it does not work with ffmpeg, I can watch the stream just fine in VLC.
What might be the problem ? Is there anything that could be corrected in the ffmpeg command ?

  


• Why is ffmpeg faster than this minimal example ?

  23 juillet 2022, par Dave Ceddia

  I'm wanting to read the audio out of a video file as fast as possible, using the libav libraries. It's all working fine, but it seems like it could be faster.

  


  To get a performance baseline, I ran this ffmpeg command and timed it :

  


  time ffmpeg -threads 1 -i file -map 0:a:0 -f null -


  


  On a test file (a 2.5gb 2hr .MOV with pcm_s16be audio) this comes out to about 1.35 seconds on my M1 Macbook Pro.

  


  On the other hand, this minimal C code (based on FFmpeg's "Demuxing and decoding" example) is consistently around 0.3 seconds slower.

  


  #include <libavcodec></libavcodec>avcodec.h>&#xA;#include <libavformat></libavformat>avformat.h>&#xA;&#xA;static int decode_packet(AVCodecContext *dec, const AVPacket *pkt, AVFrame *frame)&#xA;{&#xA;    int ret = 0;&#xA;&#xA;    // submit the packet to the decoder&#xA;    ret = avcodec_send_packet(dec, pkt);&#xA;&#xA;    // get all the available frames from the decoder&#xA;    while (ret >= 0) {&#xA;        ret = avcodec_receive_frame(dec, frame);&#xA;        av_frame_unref(frame);&#xA;    }&#xA;&#xA;    return 0;&#xA;}&#xA;&#xA;int main (int argc, char **argv)&#xA;{&#xA;    int ret = 0;&#xA;    AVFormatContext *fmt_ctx = NULL;&#xA;    AVCodecContext  *dec_ctx = NULL;&#xA;    AVFrame *frame = NULL;&#xA;    AVPacket *pkt = NULL;&#xA;&#xA;    if (argc != 3) {&#xA;        exit(1);&#xA;    }&#xA;&#xA;    int stream_idx = atoi(argv[2]);&#xA;&#xA;    /* open input file, and allocate format context */&#xA;    avformat_open_input(&amp;fmt_ctx, argv[1], NULL, NULL);&#xA;&#xA;    /* get the stream */&#xA;    AVStream *st = fmt_ctx->streams[stream_idx];&#xA;&#xA;    /* find a decoder for the stream */&#xA;    AVCodec *dec = avcodec_find_decoder(st->codecpar->codec_id);&#xA;&#xA;    /* allocate a codec context for the decoder */&#xA;    dec_ctx = avcodec_alloc_context3(dec);&#xA;&#xA;    /* copy codec parameters from input stream to output codec context */&#xA;    avcodec_parameters_to_context(dec_ctx, st->codecpar);&#xA;&#xA;    /* init the decoder */&#xA;    avcodec_open2(dec_ctx, dec, NULL);&#xA;&#xA;    /* allocate frame and packet structs */&#xA;    frame = av_frame_alloc();&#xA;    pkt = av_packet_alloc();&#xA;&#xA;    /* read frames from the specified stream */&#xA;    while (av_read_frame(fmt_ctx, pkt) >= 0) {&#xA;        if (pkt->stream_index == stream_idx)&#xA;            ret = decode_packet(dec_ctx, pkt, frame);&#xA;&#xA;        av_packet_unref(pkt);&#xA;        if (ret &lt; 0)&#xA;            break;&#xA;    }&#xA;&#xA;    /* flush the decoders */&#xA;    decode_packet(dec_ctx, NULL, frame);&#xA;&#xA;    return ret &lt; 0;&#xA;}&#xA;

  


  I tried measuring parts of this program to see if it was spending a lot of time in the setup, but it's not – at least 1.5 seconds of the runtime is the loop where it's reading frames.

  


  So I took some flamegraph recordings (using cargo-flamegraph) and ran each a few times to make sure the timing was consistent. There's probably some overhead since both were consistently higher than running normally, but they still have the 0.3 second delta.

  


  # 1.812 total
time sudo flamegraph ./minimal file 1

# 1.542 total
time sudo flamegraph ffmpeg -threads 1 -i file -map 0:a:0 -f null - 2>&1


  


  Here are the flamegraphs stacked up, scaled so that the faster one is only 85% as wide as the slower one. (click for larger)

  


  

  


  The interesting thing that stands out to me is how long is spent on read in the minimal example vs. ffmpeg :

  


  

  


  The time spent on lseek is also a lot longer in the minimal program – it's plainly visible in that flamegraph, but in the ffmpeg flamegraph, lseek is a single pixel wide.

  


  What's causing this discrepancy ? Is ffmpeg actually doing less work than I think it is here ? Is the minimal code doing something naive ? Is there some buffering or other I/O optimizations that ffmpeg has enabled ?

  


  How can I shave 0.3 seconds off of the minimal example's runtime ?