Recherche avancée

Sur d’autres sites (11926)

• ffmpeg expert to help me with an encoding problem [closed]

  22 août 2022, par Michael Heuberger

  I'm the developer of www.videomail.io and experience issues with audio. It's a heavily used, free service to enable Deaf people to email in Sign Language. Runs on ffmpeg (under node-fluent-ffmpeg) and JavaScript (Node.js).

  


  Since I am Deaf myself, I am unable to repair some audio-related issues while muxing video with audio together on server side via ffmpeg. Reason for adding audio is to expand the target audience.

  


  That said, I'm searching for someone to help me with this. It's a paid job !

  


  Requirements :

  


  

  • Must know ffmpeg very well, especially on how to encode audio (WAV) and video (MP4) together without any audio delays.

  


  • Knowing JavaScript would be a massive plus for writing code

  


  • Has time in the following weeks, I guess about 10 hours or so.

  


  


  If you are keen, ping me please. My page is www.binarykitchen.com - thanks !

  


• avcodec/cfhddata : Reduce stack usage

  3 septembre 2022, par Andreas Rheinhardt

  avcodec/cfhddata : Reduce stack usage
  Creating CFHD RL VLC tables works by first extending
  
  the codes by the sign, followed by creating a VLC,
  
  followed by deriving the RL VLC from this VLC (which
  
  is then discarded). Extending the codes uses stack arrays.
  The tables used to initialize the VLC are already sorted
  
  from left-to-right in the tree. This means that the
  
  corresponding VLC entries are generally also ascending,
  
  but not always : Entries from subtables always follow
  
  the corresponding main table although it is possible
  
  for the right-most node to fit into the main table.
  This suggests that one can try to use the final destination
  
  buffer as scratch buffer for the tables with sign included.
  
  Unfortunately it works for neither of the tables if one
  
  uses the right-most part of the RL VLC buffer as scratch buffer ;
  
  using the left-most part of the RL VLC buffer as scratch buffer
  
  might work if one traverses the VLC entries from end to start.
  
  But it works only for the little RL VLC (table 9), not for table 18.
  Therefore this patch uses the RL VLC buffer for table 9
  
  as scratch buffer for creating the bigger table 18.
  
  Afterwards the left part of the buffer for table 9 is
  
  used as scratch buffer to create table 9.
  This fixes the cfhd part of ticket #9399 (if it is not already fixed).
  
  Notice that I do not consider the previous stack usage excessive.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/cfhddata.c

• 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;
};