Recherche avancée

Sur d’autres sites (5816)

• 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 3606b78108 : Modified test for auto key frame detection. The existing test was triggering a

  16 avril 2015, par paulwilkins

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

  
  
  Modified test for auto key frame detection.

  The existing test was triggering a lot of false positives on some types
  of animated material with very plain backgrounds. These were triggering
  code designed to catch key frames in letter box format clips.

  This patch tightens up the criteria and imposes a minimum requirement
  on the % blocks coded intra in the first pass and the ratio between the
  % coded intra and the modified inter % after discounting neutral (flat)
  blocks that are coded equally well either way.

  On a particular problem animation clip this change eliminated a large
  number of false positives including some cases where the old code
  selected kf several times in a row. Marginal false negatives are less
  damaging typically to compression and in the problem clip there are now
  a couple of cases where "visual" scene cuts are ignored because of well
  correlated content across the scene cut.

  Replaced some magic numbers related to this with #defines and added
  explanatory comments.

  Change-Id : Ia3d304ac60eb7e4323e3817eaf83b4752cd63ecf

• AAC : Fix M/S stereo encoding

  3 mars 2015, par Claudio Freire

  AAC : Fix M/S stereo encoding
  This patch fixes a pointer arithmetic bug in adjust_frame_information that resulted in heavily corrupted audio when using M/S encoding. Also, a backup copy of untransformed coefficients has to be kept around or attempts at re-processing the frame (which happens when hevavily overspending bits during transients) will result in re-encoding of the coefficients and subsequent corruption of the resulting stream.
  A/B testing shows the bug as corrected, but still cannot prove that M/S coding is a win at least in numbers. Limited listening tests do show improvement on M/S encoded samples in lower bitrates, but they’re hidden among the other artifacts that remain to be corrected in the encoder.
  Some of the regressions flagged in the report do show poor stereo image (but not buggy), so M/S encoding is clearly not good enough yet to be defaulted to auto.
  In numbers, Patched against Unpatched, stereo_mode auto :
    Files : 114
  
    Bitrates : 6
  
    Tests : 683
    Serious Regressions : 0 (0%)
  
    Regressions : 0 (0%)
  
    Improvements : 227 (33%)
  
    Big improvements : 92 (13%)
  
    Worst regression - mybloodrusts.wv - 256k
  
      - StdDev : 28.61       pSNR : -0.43     maxdiff : 1372.00
  
    Best improvement - 60.wv - 384k
  
      - StdDev : -369.57     pSNR : 45.02     maxdiff : -13322.00
  
    Average          - StdDev : -80.56       pSNR : 2.49      maxdiff : -8858.00
  Patched against Unpatched stereo_mode ms_off shows no difference.
  Patched stereo_mode auto vs Unpatched stereo_mode ms_off shows a small average improvement, just not too significant :
    Serious Regressions : 0 (0%)
  
    Regressions : 10 (1%)
  
    Improvements : 45 (6%)
  
    Big improvements : 2 (0%)
  
    Worst regression - Illinois.wv - 256k
  
      - StdDev : 33.20       pSNR : -2.03     maxdiff : 477.00
  
    Best improvement - song_of_circomstances.flac - 384k
  
      - StdDev : -3.97       pSNR : 7.61      maxdiff : -826.00
  
    Average          - StdDev : -10.25       pSNR : 0.20      maxdiff : -281.00
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/aac.h
  • [DH] libavcodec/aaccoder.c
  • [DH] libavcodec/aacenc.c