Recherche avancée

Sur d’autres sites (7291)

• Proxying an RTSP url using an RTSP Proxy Server

  21 juin 2018, par Sleeba Paul

  I have a use case where I need to restream an RTSP URL.

  For all the below cases, Live555 is built locally by cloning the source.

  For all the below cases, required ports are opened for RTSP in respective servers.

  First I set up a file to be streamed using Live555MediaServer. This is in an AWS instance (AWS1).

  ./Live555MediaServer ashi.webm gives

  rtsp://public_IP_of_instance:8554/ashi.web

  I check whether an incoming stream is working or not, by trying to play it in VLC player. This incoming stream is working fine and playing well on VLC.

  Now, to restream, I tried Live555ProxyServer. Now incoming stream from AWS1 is restreamed to another URL by running Live555ProxyServer on my Mac.

  ./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web gives,

  rtsp://localhost:8554/ProxyStream

  This URL is also playable in VLC.

  Now I setup another AWS instance (AWS2) and run ProxyServer on it, listening to AWS1.

  That is,

  ./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web gives,

  rtsp://public_IP_of_instance_two:8554/ProxyStream

  This URL is not playable.

  I tried using -t flag for TCP instead of UDP. I tried checking the incoming RTSP stream with ffprobe and the stream is showing all the required details.

  What could be the possible reason ? What is the missing piece in this pipeline ? Do we’ve great industry-grade open source RTSP servers ?

  EDIT :

  I don’t know what is exactly happened, but using VLC as the client to check the stream was the problem. I moved to ffmpeg and tried to write it to a file using

  ffmpeg -i rtsp://public_IP_of_instance_two:8554/proxyStream -acodec copy -vcodec copy abc.webm

  So the stream from ProxyServer is fine.

  The lead to the change of client was the repeated warning from live555ProxyServer about outdated firmware explained here.

  I’m currently using VLC Version 3.0.3 Vetinari (Intel 64bit) in Mac which is the latest version. Maybe VLC is using an old version of Live555 internally.

• FFMPEG : multiplexing streams with different duration

  16 avril 2018, par Michael IV

  I am multiplexing video and audio streams. Video stream comes from generated image data. The audio stream comes from aac file. Some audio files are longer than total video time I set so my strategy to stop audio stream muxer when its time becomes larger than the total video time(the last one I control by number encoded video frames).

  I won’t put here the whole setup code, but it is similar to muxing.c example from the latest FFMPEG repo. The only difference is that I use audio stream from file,as I said, not from synthetically generated encoded frame. I am pretty sure the issue is in my wrong sync during muxer loop.Here is what I do :

  void AudioSetup(const char* audioInFileName)
  
  {
  
      AVOutputFormat* outputF = mOutputFormatContext->oformat;
  
      auto audioCodecId = outputF->audio_codec;
  
  
  
      if (audioCodecId == AV_CODEC_ID_NONE) {
  
          return false;
  
      }
  
  
  
      audio_codec = avcodec_find_encoder(audioCodecId);
  
  
  
      avformat_open_input(&mInputAudioFormatContext,
  
      audioInFileName, 0, 0);
  
      avformat_find_stream_info(mInputAudioFormatContext, 0);
  
  
  
      av_dump_format(mInputAudioFormatContext, 0, audioInFileName, 0);
  
  
  
  
  
      for (size_t i = 0; i < mInputAudioFormatContext->nb_streams; i++) {
  
          if (mInputAudioFormatContext->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
  
              inAudioStream = mInputAudioFormatContext->streams[i];
  
  
  
              AVCodecParameters *in_codecpar = inAudioStream->codecpar;
  
              mAudioOutStream.st = avformat_new_stream(mOutputFormatContext, NULL);
  
              mAudioOutStream.st->id = mOutputFormatContext->nb_streams - 1;
  
              AVCodecContext* c = avcodec_alloc_context3(audio_codec);
  
              mAudioOutStream.enc = c;
  
              c->sample_fmt = audio_codec->sample_fmts[0];
  
              avcodec_parameters_to_context(c, inAudioStream->codecpar);
  
              //copyparams from input to autput audio stream:
  
              avcodec_parameters_copy(mAudioOutStream.st->codecpar, inAudioStream->codecpar);
  
  
  
              mAudioOutStream.st->time_base.num = 1;
  
              mAudioOutStream.st->time_base.den = c->sample_rate;
  
  
  
              c->time_base = mAudioOutStream.st->time_base;
  
  
  
              if (mOutputFormatContext->oformat->flags & AVFMT_GLOBALHEADER) {
  
                  c->flags |= CODEC_FLAG_GLOBAL_HEADER;
  
              }
  
              break;
  
          }
  
      }
  
  }
  
  
  
  void Encode()
  
  {
  
      int cc = av_compare_ts(mVideoOutStream.next_pts, mVideoOutStream.enc->time_base,
  
      mAudioOutStream.next_pts, mAudioOutStream.enc->time_base);
  
  
  
      if (mAudioOutStream.st == NULL || cc <= 0) {
  
          uint8_t* data = GetYUVFrame();//returns ready video YUV frame to work with
  
          int ret = 0;
  
          AVPacket pkt = { 0 };
  
          av_init_packet(&pkt);
  
          pkt.size = packet->dataSize;
  
          pkt.data = data;
  
          const int64_t duration = av_rescale_q(1, mVideoOutStream.enc->time_base, mVideoOutStream.st->time_base);
  
  
  
          pkt.duration = duration;
  
          pkt.pts = mVideoOutStream.next_pts;
  
          pkt.dts = mVideoOutStream.next_pts;
  
          mVideoOutStream.next_pts += duration;
  
  
  
          pkt.stream_index = mVideoOutStream.st->index;
  
          ret = av_interleaved_write_frame(mOutputFormatContext, &pkt);
  
      } else
  
      if(audio_time <  video_time) {
  
          //5 -  duration of video in seconds
  
          AVRational r = {  60, 1 };
  
  
  
          auto cmp= av_compare_ts(mAudioOutStream.next_pts, mAudioOutStream.enc->time_base, 5, r);
  
          if (cmp >= 0) {
  
              mAudioOutStream.next_pts = (int64_t)std::numeric_limits::max();
  
              return true; //don't mux audio anymore
  
          }
  
  
  
          AVPacket a_pkt = { 0 };
  
          av_init_packet(&a_pkt);
  
  
  
          int ret = 0;
  
          ret = av_read_frame(mInputAudioFormatContext, &a_pkt);
  
          //if audio file is shorter than stop muxing when at the end of the file
  
          if (ret == AVERROR_EOF) {
  
              mAudioOutStream.next_pts = (int64_t)std::numeric_limits::max(); 
  
              return true;
  
          }
  
          a_pkt.stream_index = mAudioOutStream.st->index;
  
  
  
          av_packet_rescale_ts(&a_pkt, inAudioStream->time_base, mAudioOutStream.st->time_base);
  
          mAudioOutStream.next_pts += a_pkt.pts;
  
  
  
          ret = av_interleaved_write_frame(mOutputFormatContext, &a_pkt);
  
      }
  
  }

  Now, the video part is flawless. But if the audio track is longer than video duration, I am getting total video length longer by around 5% - 20%, and it is clear that audio is contributing to that as video frames are finished exactly where there’re supposed to be.

  The closest ’hack’ I came with is this part :

  AVRational r = {  60 ,1 };
  
  auto cmp= av_compare_ts(mAudioOutStream.next_pts, mAudioOutStream.enc->time_base, 5, r);
  
  if (cmp >= 0) {
  
      mAudioOutStream.next_pts = (int64_t)std::numeric_limits::max();
  
      return true;
  
  } 

  Here I was trying to compare next_pts of the audio stream with the total time set for video file,which is 5 seconds. By setting r = {60,1} I am converting those seconds by the time_base of the audio stream. At least that’s what I believe I am doing. With this hack, I am getting very small deviation from the correct movie length when using standard AAC files,that’s sample rate of 44100,stereo. But if I test with more problematic samples,like AAC sample rate 16000,mono - then the video file adds almost a whole second to its size.
  I will appreciate if someone can point out what I am doing wrong here.

  Important note : I don’t set duration on for any of the contexts. I control the termination of the muxing session, which is based on video frames count.The audio input stream has duration, of course, but it doesn’t help me as video duration is what defines the movie length.

  UPDATE :

  This is second bounty attempt.

  UPDATE 2 :

  Actually,my audio timestamp of den,num was wrong,while 1,1 is indeed the way to go,as explained by the answer. What was preventing it from working was a bug in this line (my bad) :

       mAudioOutStream.next_pts += a_pkt.pts;

  Which must be :

       mAudioOutStream.next_pts = a_pkt.pts;

  The bug resulted in exponential increment of pts,which caused very early reach to the end of stream (in terms of pts) and therefore caused the audio stream to be terminated much earlier than it supposed to be.

• Thinking about switching to GeoIP2 for better location detection ? Here’s what you should know

  5 juin 2018, par Matomo Core Team

  In Matomo 3.5.0 we added a new feature to improve the location detection (country, region, city) of your visitors. Especially when it comes to IPv6 addresses, you will see less “Unknown” locations and more accurate results in general. This feature is now enabled for all new installations but needs to be manually enabled for existing Matomo self-hosted users.

  

  Why is the Matomo plugin not enabled for existing users ?

  When you enable the GeoIP2 plugin, a database update will need to be executed on two datatable tables (“log_visit” and “log_conversion”) which stores some of the raw data. Please be aware that this update could take several hours depending on the size of your database.

  If you store many visits in your database, it is recommended to execute the update through the command line by executing the command ./console core:update to avoid the update from timing out. You may also have to put your Matomo into maintenance mode during this time and replay the missed traffic from logs afterwards as explained in the FAQ article.

  GeoIP2 may slow down your tracking

  In the past we have seen that a few Matomo databases with high traffic volumes struggle to handle all the tracking requests after enabling GeoIP2. The reason for this is the location database now contains many more entries because it has to store all the IPv6 addresses and the database itself has a different format. Hence, the location lookup takes longer.

  It is hard to say how much slower the location lookup gets, but we found GeoIP2-PHP is about 20 times slower than GeoIP1-PHP. On a fast CPU the lookup time for an IP with GeoIP2 takes about 1ms, but can also take much longer depending on the server.

  Making location lookups fast again

  There is a PHP extension available that makes lookups very fast, even faster than the old GeoIP1-PHP provider. If you can install additional PHP extensions on your server and have a high traffic website, you may want to install the GeoIP2 extension.

  There is also an Nginx module and an Apache module. Unfortunately, we don’t have any performance metrics for these providers.

  How do I activate the GeoIP2 location provider ?

  As a Super User, log in to your Matomo and go to “Administration => Plugins”. There you can activate the “GeoIP2” plugin. As mentioned, this will trigger a database update which can take a while and you may want to perform this update through the command line.

  Now you can go to “Administration => Geolocation”. Here you will first need to install the GeoIP2 databases at the bottom of the page before you can activate the GeoIP2-PHP provider. To activate any of the other GeoIP2 providers, you will need to install the required modules.

  You will be able to check if the detection works on the right next to location provider. Once you selected one of the available providers, you’re all good to go.

  The post Thinking about switching to GeoIP2 for better location detection ? Here’s what you should know appeared first on Analytics Platform - Matomo.