Recherche avancée

Sur d’autres sites (7274)

• Why does my Blink based browser play hide and seek ?

  21 janvier 2016, par Caius Jard

  We have a C# tool (that I wrote) that records online broadcasts taking place a custom written (that we wrote) flash app. (There are no DRM or copyright issues here.)

  We’ve coded up a system whereby this tool is installed on a Windows Server 2012 R2 Amazon AWS instance. After we boot the instance, the tool loads, waits for the right time to start recording, launches a browser and passes the command line argument of the URL to access the broadcast. The browser will then load the flash app and the interview audio and video will start arriving at the browser instance on AWS

  By way of a virtual audio cable driver, screen / audio capture directshow filters and ffmpeg a screen recording is taken. The C# tool calls ffmpeg and ffmpeg will record the screen reliably for the entire interview, then the tool shuts the whole thing down

  The problem I’m having is that both Chrome and Electron browser sometimes simply don’t draw themselves on the screen so all ffmpeg ends up recording is a blank desktop and the audio of the broadcast (hence, the browser IS running)

  We found this out when recordings started turning up with X hours of merely recording the windows desktop and the tool’s main window with a countdown timer.

  A screenshotting facility was built into the tool and added to its web control interface, and this way we can test whether the browser is visible - a human looks at the screenshot of every broadcast, just after recording has started (the browser is supposed to be on show by this time)

  We notice that 50% of the time, the browser isn’t drawing itself on screen. By 50% I mean that every other recording that the AWS instance carries out, will be blank : AWS starts, records ok, shuts down. AWS starts again an hour later for a different broadcast, recording is blank, shuts down.. Starts/ok/shutdown. Starts/blank/shutdown. Repeat ad infinitum

  What’s even more strange is that if I run VNCviewer on my dev machine and connect up to an instance that is having a problem, the instant that the VNC connection is up and the remote desktop is showing on my screen, the browser suddenly appears as if nothing was ever wrong. A screenshot from before the VNC connect shows blank desktop, connect VNC, take another screenshot and the browser is there. All through it the audio is fine - the browser connected to the boadcast is fine, for sure

  It’s as though Chrome/Electron thinks "you know what, noone is looking at me so I’m not going to bother drawing myself". No screen saver is set, though the power plan has the setting "turn off the display after 15 minutes".

  Perhaps Chrome/Electron have a test amounts to "if the display is off, don’t draw". I can’t explain the inconsistency though - the recorder launches at least 1 hour before it’s needed, and sits there idle until it’s time to start the browser. You’d hence imagine that the "power off the monitor after 15 mins" setting would reliably have ensured the "monitor" is "off" by the time every recording start comes around

  This behaviour doesn’t happen with any of the other browsers (but unfortunately the app doesn’t and cannot work in them because it uses some weird chrome-only technology/API).

  Can anyone suggest anything to look at to help debug this, or anything I can build into the C# tool to overcome the problem ? Coding it up to connect to itself via VNC for a few seconds after it has launched the browser.. Well that just tastes nasty.

  Naturally, as soon as I connect to the machine via VNC (rather than RDP - RDP isn’t usable because the recording context is in a logged on session for a particular user) the problem goes away, which makes it frustratingly hard to debug.

• Trouble syncing libavformat/ffmpeg with x264 and RTP

  26 décembre 2012, par Jacob Peddicord

  I've been working on some streaming software that takes live feeds
  from various kinds of cameras and streams over the network using
  H.264. To accomplish this, I'm using the x264 encoder directly (with
  the "zerolatency" preset) and feeding NALs as they are available to
  libavformat to pack into RTP (ultimately RTSP). Ideally, this
  application should be as real-time as possible. For the most part,
  this has been working well.

  Unfortunately, however, there is some sort of synchronization issue :
  any video playback on clients seems to show a few smooth frames,
  followed by a short pause, then more frames ; repeat. Additionally,
  there appears to be approximately a 4-second delay. This happens with
  every video player I've tried : Totem, VLC, and basic gstreamer pipes.

  I've boiled it all down to a somewhat small test case :

  #include 
  
  #include 
  
  #include 
  
  #include 
  
  #include <libavformat></libavformat>avformat.h>
  
  #include <libswscale></libswscale>swscale.h>
  
  
  
  #define WIDTH       640
  
  #define HEIGHT      480
  
  #define FPS         30
  
  #define BITRATE     400000
  
  #define RTP_ADDRESS "127.0.0.1"
  
  #define RTP_PORT    49990
  
  
  
  struct AVFormatContext* avctx;
  
  struct x264_t* encoder;
  
  struct SwsContext* imgctx;
  
  
  
  uint8_t test = 0x80;
  
  
  
  
  
  void create_sample_picture(x264_picture_t* picture)
  
  {
  
      // create a frame to store in
  
      x264_picture_alloc(picture, X264_CSP_I420, WIDTH, HEIGHT);
  
  
  
      // fake image generation
  
      // disregard how wrong this is; just writing a quick test
  
      int strides = WIDTH / 8;
  
      uint8_t* data = malloc(WIDTH * HEIGHT * 3);
  
      memset(data, test, WIDTH * HEIGHT * 3);
  
      test = (test &lt;&lt; 1) | (test >> (8 - 1));
  
  
  
      // scale the image
  
      sws_scale(imgctx, (const uint8_t* const*) &amp;data, &amp;strides, 0, HEIGHT,
  
                picture->img.plane, picture->img.i_stride);
  
  }
  
  
  
  int encode_frame(x264_picture_t* picture, x264_nal_t** nals)
  
  {
  
      // encode a frame
  
      x264_picture_t pic_out;
  
      int num_nals;
  
      int frame_size = x264_encoder_encode(encoder, nals, &amp;num_nals, picture, &amp;pic_out);
  
  
  
      // ignore bad frames
  
      if (frame_size &lt; 0)
  
      {
  
          return frame_size;
  
      }
  
  
  
      return num_nals;
  
  }
  
  
  
  void stream_frame(uint8_t* payload, int size)
  
  {
  
      // initalize a packet
  
      AVPacket p;
  
      av_init_packet(&amp;p);
  
      p.data = payload;
  
      p.size = size;
  
      p.stream_index = 0;
  
      p.flags = AV_PKT_FLAG_KEY;
  
      p.pts = AV_NOPTS_VALUE;
  
      p.dts = AV_NOPTS_VALUE;
  
  
  
      // send it out
  
      av_interleaved_write_frame(avctx, &amp;p);
  
  }
  
  
  
  int main(int argc, char* argv[])
  
  {
  
      // initalize ffmpeg
  
      av_register_all();
  
  
  
      // set up image scaler
  
      // (in-width, in-height, in-format, out-width, out-height, out-format, scaling-method, 0, 0, 0)
  
      imgctx = sws_getContext(WIDTH, HEIGHT, PIX_FMT_MONOWHITE,
  
                              WIDTH, HEIGHT, PIX_FMT_YUV420P,
  
                              SWS_FAST_BILINEAR, NULL, NULL, NULL);
  
  
  
      // set up encoder presets
  
      x264_param_t param;
  
      x264_param_default_preset(&amp;param, "ultrafast", "zerolatency");
  
  
  
      param.i_threads = 3;
  
      param.i_width = WIDTH;
  
      param.i_height = HEIGHT;
  
      param.i_fps_num = FPS;
  
      param.i_fps_den = 1;
  
      param.i_keyint_max = FPS;
  
      param.b_intra_refresh = 0;
  
      param.rc.i_bitrate = BITRATE;
  
      param.b_repeat_headers = 1; // whether to repeat headers or write just once
  
      param.b_annexb = 1;         // place start codes (1) or sizes (0)
  
  
  
      // initalize
  
      x264_param_apply_profile(&amp;param, "high");
  
      encoder = x264_encoder_open(&amp;param);
  
  
  
      // at this point, x264_encoder_headers can be used, but it has had no effect
  
  
  
      // set up streaming context. a lot of error handling has been ommitted
  
      // for brevity, but this should be pretty standard.
  
      avctx = avformat_alloc_context();
  
      struct AVOutputFormat* fmt = av_guess_format("rtp", NULL, NULL);
  
      avctx->oformat = fmt;
  
  
  
      snprintf(avctx->filename, sizeof(avctx->filename), "rtp://%s:%d", RTP_ADDRESS, RTP_PORT);
  
      if (url_fopen(&amp;avctx->pb, avctx->filename, URL_WRONLY) &lt; 0)
  
      {
  
          perror("url_fopen failed");
  
          return 1;
  
      }
  
      struct AVStream* stream = av_new_stream(avctx, 1);
  
  
  
      // initalize codec
  
      AVCodecContext* c = stream->codec;
  
      c->codec_id = CODEC_ID_H264;
  
      c->codec_type = AVMEDIA_TYPE_VIDEO;
  
      c->flags = CODEC_FLAG_GLOBAL_HEADER;
  
      c->width = WIDTH;
  
      c->height = HEIGHT;
  
      c->time_base.den = FPS;
  
      c->time_base.num = 1;
  
      c->gop_size = FPS;
  
      c->bit_rate = BITRATE;
  
      avctx->flags = AVFMT_FLAG_RTP_HINT;
  
  
  
      // write the header
  
      av_write_header(avctx);
  
  
  
      // make some frames
  
      for (int frame = 0; frame &lt; 10000; frame++)
  
      {
  
          // create a sample moving frame
  
          x264_picture_t* pic = (x264_picture_t*) malloc(sizeof(x264_picture_t));
  
          create_sample_picture(pic);
  
  
  
          // encode the frame
  
          x264_nal_t* nals;
  
          int num_nals = encode_frame(pic, &amp;nals);
  
  
  
          if (num_nals &lt; 0)
  
              printf("invalid frame size: %d\n", num_nals);
  
  
  
          // send out NALs
  
          for (int i = 0; i &lt; num_nals; i++)
  
          {
  
              stream_frame(nals[i].p_payload, nals[i].i_payload);
  
          }
  
  
  
          // free up resources
  
          x264_picture_clean(pic);
  
          free(pic);
  
  
  
          // stream at approx 30 fps
  
          printf("frame %d\n", frame);
  
          usleep(33333);
  
      }
  
  
  
      return 0;
  
  }

  This test shows black lines on a white background that
  should move smoothly to the left. It has been written for ffmpeg 0.6.5
  but the problem can be reproduced on 0.8 and 0.10 (from what I've tested so far). I've taken some shortcuts in error handling to make this example as short as
  possible while still showing the problem, so please excuse some of the
  nasty code. I should also note that while an SDP is not used here, I
  have tried using that already with similar results. The test can be
  compiled with :

  gcc -g -std=gnu99 streamtest.c -lswscale -lavformat -lx264 -lm -lpthread -o streamtest

  It can be played with gtreamer directly :

  gst-launch udpsrc port=49990 ! application/x-rtp,payload=96,clock-rate=90000 ! rtph264depay ! decodebin ! xvimagesink

  You should immediately notice the stuttering. One common "fix" I've
  seen all over the Internet is to add sync=false to the pipeline :

  gst-launch udpsrc port=49990 ! application/x-rtp,payload=96,clock-rate=90000 ! rtph264depay ! decodebin ! xvimagesink sync=false

  This causes playback to be smooth (and near-realtime), but is a
  non-solution and only works with gstreamer. I'd like to fix the
  problem at the source. I've been able to stream with near-identical
  parameters using raw ffmpeg and haven't had any issues :

  ffmpeg -re -i sample.mp4 -vcodec libx264 -vpre ultrafast -vpre baseline -b 400000 -an -f rtp rtp://127.0.0.1:49990 -an

  So clearly I'm doing something wrong. But what is it ?

• encoding XDCAM MXF with FFMPEG

  9 octobre 2013, par magingax

  Trying to encode XDCAM HD422 MXF with FFMPEG
  But can't know specific setting for encoder/format/mux
  Anyone can show me sample code or give some advice for that ?