Recherche avancée

Sur d’autres sites (4727)

• Writing H.264 RTP stream data to a container file

  2 avril 2018, par Kamal

  In a call, I receive RTP packets (h264 payload). I am trying to depacketize it and write it to a container file like mkv or mp4 using ffmpeg. However the output file is not playing. I am following below steps, please let me know whats wrong here.

  1. Got RTP packet
  2. Removed RTP header 12 bytes
  3. Read one more byte and calculated F, NRI & Type value. Type value comes to 1 most of the time, sometime it is 5 also.
  4. Since type is in between 1 & 23, it is of type single NAL unit.
  5. Allocates a buffer say BUF.
  6. Writes first 3 byte as 0x00 0x00 0x01.
  7. Then copy from video payload + 1 offset (since we have read 1 byte as described in point #3) to BUF
  8. Use this BUF to prepare avpacket and write this to output file using AV_Write_* API of ffmpeg. This part I have done correctly as it works fine for me in case of vp8 codec.
  9. Get the output file.
  10. However this file is not playing in ffmpeg.

  Please let me know of my approach is correct.

  I have observed sometimes group of packets coming with marker bit as 0, with same RTP timestamp. Do I need to concatenate such group of packets and write as single NALU, or each packet I should write as single NALU to output file.

• Make video frames from a livestream identifiable across multiple clients

  23 septembre 2016, par mschwaig

  I need to distribute a video stream from a live source to several clients with the additional requirement that each frame is identifiable across all clients.

  I have already done research into the topic, and I have arrived at a possible solution that I can share. My solution seems suboptimal and this is my first experience of working with video streams, so I want to see if somebody knows a better way.

  The reason why I need to be able to identify specific frames within the video stream is that the streaming clients need to be able to talk about the time differences between events each of them identifies in their video stream.

  A little clarifying example

  I want to enable the following interaction :

  • Two client applications Dewey and Stevie connect to the streaming server
  • Dewey displays the stream and Stevie saves it to disk
  • Dewey identifies a specific video frame that is of interest to Stevie, so he wants to tell Stevie about it
  • Dewey extracts some identifying information from the video frame and sends it to Stevie
  • Stevie uses the identifying information to extract the same frame from the copy of the livestream he is currently saving

  Dewey cannot send the frame to Stevie directly, because Malcolm and Reese also want to tell him about specific video frames and Stevie is interested in the time difference between their findings.

  Suggested solution

  The solution that I found was using ffserver to broadcast a RTP stream and use the timestamps from the RTCP packets to identify frames. These timestamps are normally used to synchronize audio and video, and not to provide a shared timeline across several clients, which is why I am skeptical this is the best way to solve my problem.

  It also seems beneficial to have frame numbers, like an increasing counter of frames instead of arbitrary timestamps which increase by some perhaps varying offset as for my application I also have to reference neighboring frames and it seems easier to compute time differences from frame numbers, than the other way around.

• Revision 9f79259e54 : adapt the adjustment limit for rate correction factor in RTC mode Rate correcti

  13 novembre 2014, par Yaowu Xu

  Changed Paths :
   Modify /vp9/encoder/vp9_ratectrl.c

  
  
  adapt the adjustment limit for rate correction factor in RTC mode

  Rate correction factor is used to correct the estimated rate for any
  given quantizer, and feeds into rate control for quantizer selection.
  We make use of the actual bits used to calculate this rate correction
  factor with an adjustment limit to prevent over-adjustment.

  This commit adapts the adjustment limit to the difference between the
  estimated bits and the actual bits, allows the adjustment limit to vary
  between 0.125 (when estimate is close to actual) and 0.625 (when there
  is >10X factor off between estimated and actual bits). By doing this,
  the commit appears to have largely corrected two observed issues :
  1. Adjustment is too slow when the actual bits used is way off from
  estimate due to the small adjustment limit.
  2. Extreme oscillating quantizer choices due to the feedback loop.

  Change-Id : I4ee148d2c9d26d173b6c48011313ddb07ce2d7d6