Recherche avancée

Sur d’autres sites (10391)

• Revision 79199e465a : Reverting "Adds support for reading and writing 10/12-bit y4m" for now because o

  3 juillet 2014, par Dmitry Kovalev

  Changed Paths :
   Modify /test/md5_helper.h

  
   Modify /test/test-data.sha1

  
   Modify /test/test.mk

  
   Modify /test/video_source.h

  
   Delete /test/y4m_test.cc

  
   Modify /test/y4m_video_source.h

  
   Modify /tools_common.h

  
   Modify /vp9/vp9_iface_common.h

  
   Modify /vpx/src/vpx_image.c

  
   Modify /vpx/vpx_codec.h

  
   Modify /vpx/vpx_image.h

  
   Modify /vpxdec.c

  
   Modify /vpxenc.c

  
   Modify /y4menc.c

  
   Modify /y4menc.h

  
   Modify /y4minput.c

  
   Modify /y4minput.h

  
  
  Reverting "Adds support for reading and writing 10/12-bit y4m" for now because
  of Mac Build Failure.

  This reverts commit 82dc1332af4b16d3e4ad3c4358498820637b7add

  Change-Id : I824bf42bf47c7df6985c79e451d6af913030d374

• Revision 749e0c7b28 : Revert "Revert "Revert 3 patches from Hangyu to get Chrome to build :"" This rev

  28 juin 2014, par James Zern

  Changed Paths :
   Modify /test/user_priv_test.cc

  
   Modify /vp9/decoder/vp9_decoder.c

  
   Modify /vp9/decoder/vp9_dthread.h

  
   Modify /vp9/vp9_dx_iface.c

  
  
  Revert "Revert "Revert 3 patches from Hangyu to get Chrome to build :""

  This reverts commit b336356198b8ada50fbb59f04f11cefceaf5ff95.

  This causes a hang in :
  VP9/InvalidFileTest.ReturnCode/3

  the change to test/user_priv_test.cc remains with a minor update

  Change-Id : I4a8a272ca37ea329b0f413f0b1cd827a238bd9fd

• Fixing "RTP : dropping old packet received too late" in FFMPEG

  25 juin 2014, par user985030

  I have been using FFMPEG 0.6 for years with no problems and recently ported much of my code to 2.2 ; however, there is still a problem that I cannot resolve after fixing many of the deprecated functions. I am generating simulated video and then using RTSP to unicast this generated stream. The problem is that when I change the height and width of my video data, I basically recreate a new stream to send the subscribed client. The algorithm I used to do this in 0.6 worked like a charm, never had any problems. Now that I have upgraded, I get "RTP : dropping old packet received too late" as soon as I change my frame size. I think I have been dropping packets all along, but the new code is causing connection issues for me. The packets being dropped in the past were negligible and I really didn’t care if I missed them as long as the stream eventually corrected itself. Is there a flag that I can set to not drop these packets ? Or at least recover more quickly ? I believe that this has something to do with receiving packets out of order. There is a section of code that does a diff in FFMPEG in the rtpdec.c file in the function rtp_parts_one_packet. The only reference I found similar to my issue is here :

  http://en.it-usenet.org/thread/16949/6708/#post6707. Any tips would be greatly appreciated. In the meantime, I am just going to patch the FFMPEG code to not do the following check :

  if (diff < 0) {
  
  
  
  /* Packet older than the previously emitted one, drop */
  
  
  
  av_log(s->st ? s->st->codec : NULL,        AV_LOG_WARNING,
  
  
  
  "RTP: dropping old packet received too late\n");
  
  
  
  return -1;
  
  
  
  }

  By commenting out the above code, I am able to run my streaming application like I used to, but I have a feeling that I am not doing something correctly but I am not sure what it is. Thanks for any advice !