Sur d’autres sites (7897)

• Muxing in audio to gstreamer RTMP stream kills both video and Audio

  1er avril 2015, par Adam

  I need some genius help here - I’m trying to set up a live stream for my upcoming wedding... and I have it ALMOST working - audio seems to be the problem.

  This is my setup

  • Raspberry Pi Model B+
  • Logitech C920 (with onboard h264 encoding that I am utilising)
  • on-camera (C920) microphone
  • USB wifi to iPhone 4G connection
  • gstreamer1.0
  • Amazon EC2 Wowza RTMP server

  I have it all set up, but as soon as I mux in the audio, the streams wont play by any player.

  What Works :
  - my gstreamer pipeline WITHOUT the audio muxed in
  - Wowza receives a consistent stream, no failures
  - The various Flash players / iOS / Android and VLC all play back the video

  What doesnt :
  - enabling audio in the mux (using the pipeline below)
  - BUT gstreamer doesnt complain
  - BUT Wowza receives a consistent stream, no failures
  - The various flash players fail to play both Audio and Video. some just display the first video frame
  - VLC plays 1 video frame, and about 100ms of audio, then stops

  Ideally I’d like the muxed audio/video FLV stored on the SD card too in case the network goes down - but if the ’tee’ needs to be sacrificed to make it work, so be it.

  This is my current FAILING pipeline - I assume there’s something really stupid in it because I know practically nothing about gstreamer.... The first frame loads in all the players (except iOS.. which never shows anything)

  # set camera resolution to 720p, and the data format to H264 (alternatives are YUV and JPG)
  
  v4l2-ctl --device=/dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=1
  
  # set the frame rate
  
  v4l2-ctl --device=/dev/video0 --set-parm=10
  
  
  
  gst-launch-1.0 -v -e uvch264src initial-bitrate=300000 average-bitrate=300000 device=/dev/video0 name=src auto-start=true src.vidsrc \
  
                  ! queue \
  
                  ! video/x-h264,width=1280,height=720,framerate=10/1 \
  
                  ! h264parse \
  
                  ! flvmux streamable=true name=mux \
  
                  ! queue \
  
                  ! tee name=t \
  
                  ! queue \
  
                  ! filesink location=/home/pi/wedding.flv t. \
  
                  ! queue \
  
                  ! rtmpsink location='rtmp://wowzaserver/live/wedding live=1' >>/home/pi/wedding.log 2>&1

  Some of the things I can’t really afford to change at this late stage are the encapsulation (FLV) and wowza RTMP because I’ve built everything around that...

  Please Help !! Thanks !

  UPDATE

  Given that I am also saving the FLV file, I have found that if I use ffmpeg to send that FLV file (using audio copy, video copy) to the RTMP server, everything works (but obviously its not live) ! So I am now starting to believe this is a problem with the way Gstreamer encapsulates RTMP - and by putting ffmpeg in the middle it fixes it... but it’s not live of course.
  Is it possible to pipe my output to ffmpeg and using ffmpeg’s RTMP ?

• 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

• AAC encoder : Extensive improvements

  11 octobre 2015, par Claudio Freire

  AAC encoder : Extensive improvements
  This finalizes merging of the work in the patches in ticket #2686.
  Improvements to twoloop and RC logic are extensive.
  The non-exhaustive list of twoloop improvments includes :
  
   - Tweaks to distortion limits on the RD optimization phase of twoloop
  
   - Deeper search in twoloop
  
   - PNS information marking to let twoloop decide when to use it
  
     (turned out having the decision made separately wasn’t working)
  
   - Tonal band detection and priorization
  
   - Better band energy conservation rules
  
   - Strict hole avoidance
  For rate control :
  
   - Use psymodel’s bit allocation to allow proper use of the bit
  
     reservoir. Don’t work against the bit reservoir by moving lambda
  
     in the opposite direction when psymodel decides to allocate more/less
  
     bits to a frame.
  
   - Retry the encode if the effective rate lies outside a reasonable
  
     margin of psymodel’s allocation or the selected ABR.
  
   - Log average lambda at the end. Useful info for everyone, but especially
  
     for tuning of the various encoder constants that relate to lambda
  
     feedback.
  Psy :
  
   - Do not apply lowpass with a FIR filter, instead just let the coder
  
     zero bands above the cutoff. The FIR filter induces group delay,
  
     and while zeroing bands causes ripple, it’s lost in the quantization
  
     noise.
  
   - Experimental VBR bit allocation code
  
   - Tweak automatic lowpass filter threshold to maximize audio bandwidth
  
     at all bitrates while still providing acceptable, stable quality.
  I/S :
  
   - Phase decision fixes. Unrelated to #2686, but the bugs only surfaced
  
     when the merge was finalized. Measure I/S band energy accounting for
  
     phase, and prevent I/S and M/S from being applied both.
  PNS :
  
   - Avoid marking short bands with PNS when they’re part of a window
  
     group in which there’s a large variation of energy from one window
  
     to the next. PNS can’t preserve those and the effect is extremely
  
     noticeable.
  M/S :
  
   - Implement BMLD protection similar to the specified in
  
     ISO-IEC/13818:7-2003, Appendix C Section 6.1. Since M/S decision
  
     doesn’t conform to section 6.1, a different method had to be
  
     implemented, but should provide equivalent protection.
  
   - Move the decision logic closer to the method specified in
  
     ISO-IEC/13818:7-2003, Appendix C Section 6.1. Specifically,
  
     make sure M/S needs less bits than dual stereo.
  
   - Don’t apply M/S in bands that are using I/S
  Now, this of course needed adjustments in the compare targets and
  
  fuzz factors of the AAC encoder’s fate tests, but if wondering why
  
  the targets go up (more distortion), consider the previous coder
  
  was using too many bits on LF content (far more than required by
  
  psy), and thus those signals will now be more distorted, not less.
  The extra distortion isn’t audible though, I carried extensive
  
  ABX testing to make sure.
  A very similar patch was also extensively tested by Kamendo2 in
  
  the context of #2686.
  

  • [DH] Changelog
  • [DH] libavcodec/aac.h
  • [DH] libavcodec/aaccoder.c
  • [DH] libavcodec/aaccoder_trellis.h
  • [DH] libavcodec/aaccoder_twoloop.h
  • [DH] libavcodec/aacenc.c
  • [DH] libavcodec/aacenc.h
  • [DH] libavcodec/aacenc_is.c
  • [DH] libavcodec/aacenc_is.h
  • [DH] libavcodec/aacenc_pred.c
  • [DH] libavcodec/aacenc_quantization.h
  • [DH] libavcodec/aacenc_utils.h
  • [DH] libavcodec/aacpsy.c
  • [DH] libavcodec/mathops.h
  • [DH] libavcodec/mips/aaccoder_mips.c
  • [DH] libavcodec/psymodel.c
  • [DH] libavcodec/psymodel.h
  • [DH] tests/fate/aac.mak