Recherche avancée

Sur d’autres sites (4452)

• Ffmpeg live streaming to Youtube - "Connect streaming software to start preview"

  10 septembre 2019, par Zoltan Fedor

  I have an rtsp feed (H.265) which I am trying to stream to YouTube Live, but whatever I do YouTube Studio just showing the waiting icon with "Connect streaming software to start preview".

  .sh file for streaming :

  VBR="1000k"
  
  FPS="30"
  
  QUAL="ultrafast"
  
  YOUTUBE_URL="rtmp://b.rtmp.youtube.com/live2"
  
  SOURCE="rtsp://qhatever.org:8555/whatever.sdp"      
  
  KEY="xxxx-xxxx-xxxx-xxxx"
  
  
  
  ~/ffmpeg-git-20190905-amd64-static/ffmpeg \
  
      -thread_queue_size 512 \
  
      -rtsp_transport tcp -i "$SOURCE" \
  
      -f lavfi -i anullsrc \
  
      -vcodec libx264 -pix_fmt yuvj420p -preset $QUAL -r $FPS -g $(($FPS * 2)) -b:v 2250k -minrate $VBR -maxrate 6000k -bufsize 6000k -keyint_min 60 \
  
      -acodec libmp3lame -ar 44100 -b:a 128k \
  
      -f flv "$YOUTUBE_URL/$KEY"

  Ffmpeg’s output :

  ffmpeg version N-49800-g2b66c757d6-static https://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2019 the FFmpeg developers
  
    built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  
    configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg
  
    libavutil      56. 35.100 / 56. 35.100
  
    libavcodec     58. 56.101 / 58. 56.101
  
    libavformat    58. 32.104 / 58. 32.104
  
    libavdevice    58.  9.100 / 58.  9.100
  
    libavfilter     7. 58.102 /  7. 58.102
  
    libswscale      5.  6.100 /  5.  6.100
  
    libswresample   3.  6.100 /  3.  6.100
  
    libpostproc    55.  6.100 / 55.  6.100
  
  Input #0, rtsp, from 'rtsp://whatever.org:8555/whatever.sdp':
  
    Metadata:
  
      title           : streamed by the Rtsp Server
  
      comment         : RTSP_STREAM_0
  
    Duration: N/A, start: 0.000000, bitrate: N/A
  
      Stream #0:0: Video: hevc (Main), yuvj420p(pc, bt709), 1920x1080, 30 fps, 30 tbr, 90k tbn, 30 tbc
  
      Stream #0:1: Data: none
  
  Input #1, lavfi, from 'anullsrc':
  
    Duration: N/A, start: 0.000000, bitrate: 705 kb/s
  
      Stream #1:0: Audio: pcm_u8, 44100 Hz, stereo, u8, 705 kb/s
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (hevc (native) -> h264 (libx264))
  
    Stream #1:0 -> #0:1 (pcm_u8 (native) -> mp3 (libmp3lame))
  
  Press [q] to stop, [?] for help
  
  [hevc @ 0x5fbfd80] Could not find ref with POC 4
  
  [libx264 @ 0x5fb9d80] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
  
  [libx264 @ 0x5fb9d80] profile Constrained Baseline, level 4.0, 4:2:0, 8-bit
  
  [libx264 @ 0x5fb9d80] 264 - core 157 r2969 d4099dd - H.264/MPEG-4 AVC codec - Copyleft 2003-2019 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=60 keyint_min=31 scenecut=0 intra_refresh=0 rc_lookahead=0 rc=abr mbtree=0 bitrate=2250 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=6000 vbv_bufsize=6000 nal_hrd=none filler=0 ip_ratio=1.40 aq=0
  
  Output #0, flv, to 'rtmp://b.rtmp.youtube.com/live2/xxxx-xxxx-xxxx-xxxx':
  
    Metadata:
  
      title           : streamed by the Rtsp Server
  
      comment         : RTSP_STREAM_0
  
      encoder         : Lavf58.32.104
  
      Stream #0:0: Video: h264 (libx264) ([7][0][0][0] / 0x0007), yuvj420p(pc, progressive), 1920x1080, q=-1--1, 2250 kb/s, 30 fps, 1k tbn, 30 tbc
  
      Metadata:
  
        encoder         : Lavc58.56.101 libx264
  
      Side data:
  
        cpb: bitrate max/min/avg: 6000000/0/2250000 buffer size: 6000000 vbv_delay: N/A
  
      Stream #0:1: Audio: mp3 (libmp3lame) ([2][0][0][0] / 0x0002), 44100 Hz, stereo, s16p, 128 kb/s
  
      Metadata:
  
        encoder         : Lavc58.56.101 libmp3lame
  
  frame= 522 fps=31 q=19.0 size=  8802Kb time=00:00:36:53 bitrate 2481.0kbits/s dup= drop=2 speed=1.01x

  Basically all looks good to me - still, in YouTube Studio only the waiting icon with the "Connect streaming software to start preview" message is visible, not video feed.

  Any ideas ?

• avformat/matroskadec : Introduce a "last known good" position

  17 mai 2019, par Andreas Rheinhardt

  avformat/matroskadec : Introduce a "last known good" position
  Currently, resyncing during reading packets works as follows :
  
  The current position is recorded, then a call to matroska_parse_cluster
  
  is made and if said call fails, the demuxer tries to resync from the
  
  earlier position. If the call doesn't fail, but also doesn't deliver a
  
  packet, then this is looped.
  There are two problems with this approach :
  
  1. The Matroska file format aims to be forward-compatible ; to achieve
  
  this, a demuxer should simply ignore and skip elements it doesn't
  
  know about. But it is not possible to reliably distinguish unknown
  
  elements from junk. If matroska_parse_cluster encounters an unknown
  
  element, it can therefore not simply error out ; instead it returns zero
  
  and the loop is iterated which includes an update of the position that
  
  is intended to be used in case of errors, i.e. the element that is
  
  skipped is not searched for level 1 element ids to resync to at all if
  
  later calls to matroska_parse_cluster return an error.
  
  Notice that in case that sync has been lost there can be a chain of
  
  several unknown/possibly junk elements before an error is detected.
  2. Even if a call to matroska_parse_cluster delivers a packet, this does
  
  not mean that everything is fine. E.g. it might be that some of the
  
  block's data is missing and that the data that was presumed to be from
  
  the block just read actually contains the beginning of the next element.
  
  This will only be apparent at the next call of matroska_read_packet,
  
  which uses the (false) end of the earlier block as resync position so
  
  that in the (not unlikely) case that the call to matroska_parse_cluster
  
  fails, the data believed to be part of the earlier block is not searched
  
  for a level 1 element to resync to.
  To counter this, a "last known good" position is introduced. When an
  
  element id that is known to be allowed at this position in the hierarchy
  
  (according to the syntax currently in use for parsing) is read and some
  
  further checks (regarding the length of the element and its containing
  
  master element) are passed, then the beginning of the current element is
  
  treated as a "good" position and recorded as such in the
  
  MatroskaDemuxContext. Because of 2., only the start of the element is
  
  treated as a "good" position, not the whole element. If an error occurs
  
  later during parsing of clusters, the resync process starts at the last
  
  known good position.
  Given that when the header is damaged the subsequent resync never skips over
  
  data and is therefore unaffected by both issues, the "last known good"
  
  concept is not used there.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskadec.c

• avformat/matroskadec : Improve check for level 1 duplicates

  17 mai 2019, par Andreas Rheinhardt

  avformat/matroskadec : Improve check for level 1 duplicates
  If a file uses unknown-length level 1 elements besides clusters and such
  
  elements are after the first cluster, then these elements will usually
  
  be parsed twice : Once during parsing of the file header and once when
  
  reading the file reaches the position where these elements are located.
  
  The second time the element is parsed leads to a "Duplicate element"
  
  error message. Known-length elements are not affected by this as they
  
  are skipped except during parsing the header.
  This commit fixes this by explicitly adding a check for whether the
  
  position of the element to be parsed is the same as the position of the
  
  already known level 1 element.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskadec.c