Recherche avancée

Sur d’autres sites (15131)

• Using GStreamer to receive and send h264 video (from OBS)

  16 mars 2020, par Ivorius

  I’ve been trying to set up using GStreamer to get support for some input I can output from OBS.

  OBS : rtp_mpegts to udp ://localhost:5000

  http-launch 8080 webmmux streamable=true name=stream udpsrc uri=udp://localhost:5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T-ES, payload=(int)
  
  33" ! gstrtpjitterbuffer latency=200 ! application/x-rtp ! rtpmp2tdepay ! video/mpegts ! mpegtsdemux ! video/x-h264 ! queue ! decodebin ! vp8enc ! stream.   audiotestsrc ! vorbisenc ! stream.

  However, using this it seems to accept connections, but just closes them again after a while. Any clues on what I am doing wrong ? I am open to any format changes as long as they’re supported by OBS / ffmpeg.

  As a bonus, how do I add support for audio as well ?

  Background

  I’ve found https://github.com/sdroege/http-launch, which works well in displaying a GStreamer video over http:

  <video autoplay="autoplay" controls="">
  
      <source src="https://localhost:8080" type="video/mp4" codecs="avc1.4D401E, mp4a.40.2">
  
      You browser doesn't support element <code>video
  .
  
  
  
  
  

  I’ve managed to set up a pipeline where I can use a GStreamer source to pipe into a http-launch
  pipeline and display it on video :

  http-launch 8080 webmmux streamable=true name=stream udpsrc port=5000 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! mpegtsdemu
  
  x ! h264parse ! TIViddec2 ! videoconvert ! vp8enc ! stream.   audiotestsrc ! vorbisenc ! stream.
  
  
  
  gst-launch-1.0 -v videotestsrc ! videoconvert ! x264enc tune=zerolatency bitrate=500 speed-preset=superfast ! rtph264pay ! udpsink host=127.0.0.1 port=5000

  However, I don’t think OBS supports rpt over UDP. It uses ffmpeg to send these packets, which can stream rtp_mpegts. I’ve found some code snippets which claim to support the format, and stitch together the above pipeline.

• SIMD : Accelerate decoding of 16 bit FLAC

  19 février 2017, par Erik de Castro Lopo

  SIMD : Accelerate decoding of 16 bit FLAC
  This patch removes FLAC__lpc_restore_signal_16_intrin_sse2().
  It’s faster than C code, but not faster than MMX-accelerated
  
  ASM functions. It’s also slower than the new SSE4.1 functions
  
  that were added by the previous patch.
  
  So this function wasn’t very useful before, and now it’s
  
  even less useful. I don’t see a reason to keep it.
  Patch-from : lvqcl <lvqcl.mail@gmail.com>
  

  • [DH] src/libFLAC/include/private/lpc.h
  • [DH] src/libFLAC/lpc_intrin_sse41.c
  • [DH] src/libFLAC/stream_decoder.c

• flac : Fix channel order for mono files.

  28 juin 2014, par Erik de Castro Lopo

  flac : Fix channel order for mono files.
  * The default channel mask for mono files was 0x0001 (front left) but it
  
    makes more sense to use 0x0004 (front center) for such files.
  * Also FLAC will accept not only mono WAV files with 0x0001 mask, but also
  
    with 0x0002 (requested at https://sourceforge.net/p/flac/bugs/390/)
  
    and 0x0004 (e.g. SoX creates mono files with this mask).
  * The comment about channel support was updated.
  * The error message
  
       "Use —channel-map=none option to store channels in current order ; FLAC files
  
       must also be decoded with —channel-map=none to restore correct order."
  
    is misleading : FLAC never changes the order of channels.
  
    Decoding with this options also sets the channel mask of the resulting WAV
  
    file to 0. Without this option the mask is equal to the value of
  
    WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag.
  Patch-from : lvqcl <lvqcl.mail@gmail.com>
  

  • [DH] src/flac/decode.c
  • [DH] src/flac/encode.c