Recherche avancée

Sur d’autres sites (3442)

• avcodec/nvenc : include nvEncodeAPI v7 SDK header

  27 août 2016, par Timo Rothenpieler

  avcodec/nvenc : include nvEncodeAPI v7 SDK header
  As Nvidia has put the most recent Video Codec SDK behind a double
  
  registration wall, of which one needs manual approval of a lenghty
  
  application, bundling this header saves everyone trying to use NVENC
  
  from that headache.
  The header is still MIT licensed and thus fine to bundle with ffmpeg.
  Not bundling this header would get ffmpeg stuck at SDK v6, which is
  
  still freely available, holding back future development of the NVENC
  
  encoder.
  

  • [DH] compat/nvenc/nvEncodeAPI.h
  • [DH] configure
  • [DH] libavcodec/nvenc.h
  • [DH] tests/ref/fate/source

• FFMpeg(Android) av_read_frame or avcodec_decode_video2 returning same colour

  5 décembre 2012, par Cehm

  I've been experimenting FFMpeg for the past 2 weeks and I'm having a bit of trouble...
  First I've been working with a Galaxy S3, which worked super fine, gave me the best pictures ever but I recently switched to a Galaxy NEXUS which gave me a bunch of problems...

  What I'm doing : I just extract frame from a video

  How I'm doing :

  while(av_read_frame(gFormatCtx, &packet)>=0)
  
          {
  
              // Is this a packet from the video stream?
  
              if(packet.stream_index==videoStream)
  
              {
  
                  // Decode video frame
  
                  avcodec_decode_video2(gVideoCodecCtx, pFrame, &frameFinished, &packet);
  
                  // Did we get a video frame?
  
                  if(frameFinished)
  
                  {//and so on... But our problem is already here...

  Ok, now pFrame is holding a YUV representation of my frame... So, in order to check what I'm getting from the avcodec_decode_video2(...) function I'm just writing pFrame to a file so I can see it with any YUV reader on the web.

  char yuvFileName[100];
  
  sprintf(yuvFileName,"/storage/sdcard0/yuv%d.yuv",index);
  
  FILE* fp = fopen(yuvFileName, "wb");
  
  int y;
  
  // Write pixel data
  
  for(y=0; yheight; y++)
  
  {
  
      fwrite(pFrame->data[0]+y*pFrame->linesize[0], 1, gVideoCodecCtx->width, fp);    
  
  }
  
  for(y=0; yheight/2; y++)
  
  {
  
      fwrite(pFrame->data[1]+y*pFrame->linesize[1], 1, gVideoCodecCtx->width/2, fp);
  
  }
  
  for(y=0; yheight/2; y++)
  
  {
  
      fwrite(pFrame->data[2]+y*pFrame->linesize[2], 1, gVideoCodecCtx->width/2, fp);
  
  }
  
  fclose(fp);

  Ok so Here I now have my result on a file store @ /storage/sdcard0/blabla.YUV on my Galaxy Nexus root memory.

  But If I open the file with (for example XnView, which is meant to display YUV type properly) I only see Dark green on the picture.

  What bothers me is that everything worked properly on Galaxy S3 but something failed on GNexus...

  So here's my question : Why doesn't it work on Galaxy Nexus ?

  Compatibility problem between Gnexus and armeabiv7 ?

  I don't know !

  Regards,
  Cehm

• Prevent suspend event when streaming video via HTML video tag

  24 septembre 2014, par jasongullickson

  I seem to be having the opposite problem of most people who are streaming video using the HTML video tag ; I’m saturating the client with data.

  When playing a long video served via ffserver (webm container) everything works great but eventually the browser (Chrome in this case) will begin throwing "suspend" events. After a number of these ( 50-100), a "stalled" event will fire and playback will stop.

  I believe the problem is that once Chrome has buffered a certain amount of video it goes into "suspend" and stops downloading more data. I’ve tested this theory by throttling the speed at which video data is delivered, and if I keep the delivered frame rate close to the playback rate, I can prevent this from happening, but of course deliberately holding back server performance isn’t ideal.

  What I’m looking for is either a way to suppress this "suspend" behavior altogether, or alternatively a way to respond to the event that prevents the eventual "stalled" state.

  Presumably the browser at some point exits the "suspend" state and begins requesting data again, but I haven’t actually observed this occurring. I’m using a chain of mpeg2 -> ffmpeg -> ffserver to stream the video so if the browser is attempting to resume loading data I don’t see the request in my application. I could use a proxy or a sniffer to watch for the traffic but I would expect that maybe there is an ffserver log that can tell me the same thing ? In any event if it’s attempting to resume the download it’s failing, and there’s no indication server-side that there’s a reason for the request to fail (in fact I can pull up the same video feed from ffserver and see it playing correctly).

  So I feel like I’ve isolated this to a client-side playback issue, and one where the browser is voluntarily giving up on loading the data, but I’m not sure how to convince it to "not do that", or at least attempt to resume when it runs the buffer dry.