Recherche avancée

Sur d’autres sites (5862)

• avcodec : Template creation for AAC decoder (SBR-module)

  20 juillet 2015, par Djordje Pesut

  avcodec : Template creation for AAC decoder (SBR-module)
  Move the existing code to a new template file.
  Signed-off-by : Nedeljko Babic <nedeljko.babic@imgtec.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/aacsbr.c
  • [DH] libavcodec/aacsbr.h
  • [DH] libavcodec/aacsbr_template.c
  • [DH] libavcodec/sbrdsp.c
  • [DH] libavcodec/sbrdsp_template.c

• FFMPEG passthrough recording RTSP/H264 to MP4 container bad encoding

  16 janvier 2019, par Cédric Verstraeten

  Hello I’m using the ffmpeg 3.4.2 to record a RTSP h264 steam from an IP camera. I have a working example however at the beginning I see some corrupted images, after a couple of seconds the video is shown properly. I was wondering if this is a timing issue.

  

  The source code which illustrates opening and reading a RTSP stream, and writing it into an MP4 container.

  #include 
  
  #include 
  
  #include 
  
  #include <iostream>
  
  #include <fstream>
  
  #include <sstream>
  
  #include <sys></sys>time.h>
  
  
  
  extern "C" {
  
    #include <libavcodec></libavcodec>avcodec.h>
  
    #include <libavutil></libavutil>opt.h>
  
    #include <libavutil></libavutil>imgutils.h>
  
    #include <libavformat></libavformat>avformat.h>
  
    #include <libavformat></libavformat>avio.h>
  
    #include <libswscale></libswscale>swscale.h>
  
  }
  
  
  
  time_t get_time()
  
  {
  
    struct timeval tv;
  
  
  
    gettimeofday( &amp;tv, NULL );
  
  
  
    return tv.tv_sec;
  
  }
  
  
  
  int main(int argc, char **argv)
  
  {
  
      const char *filename, *codec_name;
  
      const AVCodec *codec;
  
      AVCodecContext *c= NULL;
  
      int i, ret, x, y;
  
  
  
  
  
      // Open the initial context variables that are needed
  
      AVFormatContext* format_ctx = avformat_alloc_context();
  
      int video_stream_index;
  
  
  
      // Register everything
  
      av_register_all();
  
      avformat_network_init();
  
  
  
      //open RTSP
  
  
  
      AVDictionary *ifmtdict;
  
      av_dict_set(&amp;ifmtdict, "rtsp_transport", "tcp", 0);
  
  
  
      if (avformat_open_input(&amp;format_ctx, "rtsp://192.168.0.84/user=admin_password=_channel=1_stream=0.sdp",
  
              NULL, &amp;ifmtdict) != 0) {
  
          return EXIT_FAILURE;
  
      }
  
  
  
      if (avformat_find_stream_info(format_ctx, NULL) &lt; 0) {
  
          return EXIT_FAILURE;
  
      }
  
  
  
      //search video stream
  
      for (int i = 0; i &lt; format_ctx->nb_streams; i++) {
  
          if (format_ctx->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO)
  
              video_stream_index = i;
  
      }
  
  
  
      AVPacket packet;
  
      av_init_packet(&amp;packet);
  
  
  
      AVStream* stream = NULL;
  
      int cnt = 0;
  
  
  
      //start reading packets from stream and write them to file
  
      av_read_play(format_ctx);    //play RTSP
  
  
  
      // Get the codec
  
      codec = avcodec_find_decoder(AV_CODEC_ID_H264);
  
      if (!codec) {
  
          exit(1);
  
      }
  
  
  
      // Prepare the output
  
      AVFormatContext* oc = avformat_alloc_context();
  
      oc->oformat = av_guess_format(NULL, "video.mp4", NULL);
  
      avio_open2(&amp;oc->pb, "video.mp4", AVIO_FLAG_WRITE, NULL, NULL);
  
  
  
      // Write header
  
      stream = avformat_new_stream(oc, (AVCodec*) format_ctx->streams[video_stream_index]->codec->codec);
  
      avcodec_parameters_copy(stream->codecpar, format_ctx->streams[video_stream_index]->codecpar);
  
      stream->sample_aspect_ratio = format_ctx->streams[video_stream_index]->codec->sample_aspect_ratio;
  
      stream->codecpar->codec_tag  = 0;
  
      stream->time_base = format_ctx->streams[video_stream_index]->time_base;
  
      avformat_write_header(oc, NULL);
  
  
  
      time_t timenow, timestart;
  
      timestart = timenow = get_time();
  
      bool got_key_frame = 0;
  
  
  
      while (av_read_frame(format_ctx, &amp;packet) >= 0 &amp;&amp; cnt &lt; 200000) { //read ~ 200000 frames
  
          if (packet.stream_index == video_stream_index) {    //packet is video
  
              // Make sure we start on a key frame
  
              if ( !got_key_frame &amp;&amp; timestart == timenow &amp;&amp; ! ( packet.flags &amp; AV_PKT_FLAG_KEY ) ) {
  
                timestart = timenow = get_time();
  
                continue;
  
              }
  
              got_key_frame = 1;
  
              std::cout &lt;&lt; cnt &lt;&lt; std::endl;
  
              av_interleaved_write_frame( oc, &amp;packet );
  
              cnt++;
  
          }
  
        av_free_packet(&amp;packet);
  
        av_init_packet(&amp;packet);
  
        timenow = get_time();
  
      }
  
  
  
      av_write_trailer(oc);
  
      avcodec_close(stream->codec);
  
      avio_close(oc->pb);
  
      avformat_free_context(oc);
  
  
  
      av_read_pause(format_ctx);
  
  
  
      avcodec_free_context(&amp;c);
  
      avformat_network_deinit();
  
  
  
      return 0;
  
  }
  
  </sstream></fstream></iostream>

• Video files recorded in Google Chrome have stuttering audio

  4 juin 2018, par maxpaj

  Background

  I’m developing a platform where users can record videos of themselves or their screen and send them as video messages to customers / clients.

  I have limited users to only using my application with Google Chrome and I’m using the MediaRecorder API to record the video data from the users screen or webcamera. The codecs that are used for recording are VP8/OPUS (WEBM container).

  I need the videos to run in as many browsers as possible, so I’m using a 3rd party service to transcode videos from whatever format I’m getting from the users to a H.265/AAC MP4 container (caniuse MPEG-4/H.264).

  Issue

  Lately I’ve seen that some videos recorded on Mac OSX machines have the video and audio out of sync or that the video and audio stutters, depending on which player I’m using. I call these video files corrupt, for lack of a better word. Playing a corrupt file in Google Chrome renders smooth playing audio. Playing the video in VLC on my Windows machine renders stuttering audio.

  When I run the corrupt video files through the transcoding service I get video files with stuttering audio, no matter which player I’m using.

  This is an unwanted result and pretty much unacceptable since the audio needs to be smooth in order for the recipient of a video to not be bothered with the quality.

  Debugging

  According to the transcoding service support, this happens because of their mechanisms that try to sync up the audio and video from the corrupt file :

  Inspecting our encoding logs, I’ve noticed the following kind of
  warnings :

  [2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0] pcm_encode_frame :
  filling in for 5856 missing samples (122 ms) before pts 40800 to
  correct sync ! [2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0]
  pcm_encode_frame : dropping 2880 samples (60 ms) at pts 43392 to help
  correct sync to -3168 samples (-66 ms) !

  The problem here comes from the way that the audio in the original
  source file is encoded.

  -

  you should ensure that the audio is not out of sync (audio timestamps
  are correct) in your source file before submitting the job

  Running a corrupt file through ffmpeg on my own machine, re-encoding with the same codecs, produces the same kind of stuttering video. The logs produce an alarming amount of errors. Here is a sample of the log output :

  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 194.8kbits/s dup=0 drop=5 speed=0.31x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15394; changing to 15434. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15414; changing to 15434. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 193.3kbits/s dup=0 drop=5 speed=0.309x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15499; changing to 15539. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15519; changing to 15539. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 192.0kbits/s dup=0 drop=5 speed=0.308x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15627; changing to 15667. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15647; changing to 15667. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in time

  I tried running the same inputs through another transcoding service and those outputs worked a lot better - video was still stuttering but the audio played smoothly, which is more important to the use case of my application.

  To my knowledge, this have so far only occurred for users on Mac OSX machines.

  Questions

  1. Is there anything I can do to have the files work better ? Or is this entirely a consequence of how encoding of video and audio in Google Chrome works ?

  2. One step in the right direction would be to just be able to detect when the video is corrupt. How can I do that ?