Recherche avancée

Sur d’autres sites (6609)

• Live HTML5 Video to Node.js to HTML5 Video streaming

  28 mars 2017, par sandorvasas

  I’ve searched around in similar topics, but haven’t really found the answer for my question.
  I’m making a webcam live-streaming site, and reading video input from HTML5 , periodically uploading the frames via WebSocket to a Node.js server, which -so far as I understood-, should write the incoming frames’ data to a videofile, so that file can be streamed with ffmpeg or gstreamer to broadcast the live stream to multiple viewers.

  I’m planning to use livecam, since it can stream from a file as well.

  My uncertainty arises at the point when the frames are received from the broadcaster :

  I have this simple node RTC endpoint :

  const RTCAPI = (apiServer) => {
  
  
  
    let primus = new Primus(apiServer, { 
  
      transformer: 'uws', 
  
      parser: 'binary',
  
      pathname: '/messaging',
  
      plugin: {
  
        rooms: PrimusRooms,
  
        responder: PrimusResponder
  
      }
  
    });
  
  
  
  
  
    let clients = {};
  
  
  
    primus.on('connection', spark => {
  
      clients[spark.id] = spark;
  
  
  
      spark.on('data', data => {
  
  
  
          // here -- fs.createWriteStream? 
  
  
  
      });
  
  
  
    });
  
  
  
  }

  A side question is, how can I safely write the frames to a file that ffmpeg/gstreamer could stream ? Is it safe append raw incoming data to the file ?

  Since this would be live-stream only, I won’t need to keep the recorded files, so I guess the file should only keep the last N frames, deleting the last one when adding a new. I’m not sure how can I achieve this. I’m not even sure I have to deal with these manually or ffmpeg/gstreamer supports the ’moving window of frames’ out of the box.

  Any advice would be greatly appreciated !

  Thanks.

• avformat/movenc : Explicitly address potential division by zero.

  27 avril 2017, par Lucas Cooper

  avformat/movenc : Explicitly address potential division by zero.
  find_fps attempts to infer framerate from AVCodec's timebase. When this
  
  results in a frame rate that isn't explicitly marked as supported in
  
  av_timecode_check_frame_rate, find_fps returns the AVStream's
  
  avg_frame_rate, which, per avformat.h, _may_ be set (or not).
  mov_get_mpeg2_xdcam_codec_tag, mov_get_h264_codec_tag and
  
  find_compressor attempt to call av_q2d on the return value of find_fps,
  
  which in the above case, may result in division by zero and therefore,
  
  an undefined frame rate when NaN is converted to int.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/movenc.c

• Watson speech-to-text : Narrowband producing better results than Broadband ?

  22 juin 2017, par Irman A

  I’m using IBM Watson to transcribe a video library that we have. I’m currently doing initial research into it’s efficacy and accuracy.

  The videos in question have OK to very good sound quality and based on Watson documentation I should be using the Broadband model to transcribe them.

  I’ve however tested using both Narrow and Broadband and I’m finding that Narrowband always either slightly better or a lot better in some cases (up to 10%).

  Has anyone else done any similar testing ? It’s contrary to the documentation so I’m a little reluctant to just go ahead and use Narrowband for everything, but I may have to based on the results.

  I’m using ffmpeg to convert the videos to audio files to send to Watson, and the audio files show 48KHz sampling rates, which again means I should be using and getting better results using Broadband.

  Hoping someone out there has done similar research and can help.

  Thanks in advance.