Recherche avancée

Sur d’autres sites (4919)

• VideoJS for HLS streaming not working on iOS

  13 février 2024, par Aames

  I have a website where I stream audio using HLS (m3u8 playlist + ts files).
I use VideoJS 8.3.0 to handle the stream in the frontend side.
The streaming works in all devices (PC, Android, Mac) except in iOS where it works intermittently and often it blocks.

  


  Here is my videojs initialization :

  


  player = videojs('stream-id', {
            controls: false, autoplay: true, preload: 'auto',
            html5: {
               vhs: {overrideNative: false},
               nativeAudioTracks: true
           }
        });

...

player.src({ type: 'application/x-mpegURL', src: 'https://.../master.m3u8' });



  


  And these are the headers of the m3u8 file :

  


  #EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-PROGRAM-DATE-TIME:2024-02-13T09:00:00Z
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-DISCONTINUITY
#EXTINF:10.007800,
master0.ts
#EXTINF:7.214989,
master1.ts
....


  


  I use ffmpeg to create the playlist from mp3 files :

  


  ffmpeg -i inputFileName -c:a aac -b:a 128k -ac 2 -f hls -hls_time 10 -preset ultrafast -map 0:a -flags -global_header -hls_list_size 0 -hls_flags append_list outputFileName



  


  Am I doing something wrong ? Any help would be appreciated
Thanks

  


  I tried this solution : Videojs HLS m3u8 files are not playing in iOS devices and safari browser but it does not work for me

  


• get error ffmpeg when running wdio-video-reporter in jenkins and centos

  31 janvier 2024, par Ferawati Hartanti Pratiwi

  i got this error when i run wdio-video-reporter on jenkins and the OS is centos 8

  


  


  2024-01-31T17:54:56.047Z ERROR @wdio/config:ConfigParser: Failed loading configuration file:


  


  file :///var/data/jenkins-slave/workspace/QE_Playground/web-testing-pr-only/test/support/wdio.conf.chrome.js :
undefined
Could not find ffmpeg executable, tried "/var/data/jenkins-slave/workspace/QE_Playground/web-testing-pr-only/node_modules/@ffmpeg-installer/linux-x64/ffmpeg",
"/var/data/jenkins-slave/workspace/QE_Playground/web-testing-pr-only/node_modules/@ffmpeg-installer/ffmpeg/node_modules/@ffmpeg-installer/linux-x64/ffmpeg"
and
"/var/data/jenkins-slave/workspace/QE_Playground/web-testing-pr-only/node_modules/@ffmpeg-installer/linux-x64/ffmpeg"

  


  


  this is my jenkins env

  


    environment {
    PATH = "/usr/bin/ffmpeg:$PATH"
  }


  


  this is my wdio config

  


    ffmpegPath: '/usr/bin/ffmpeg',
  capabilities: [
    {
      maxInstances: parseInt(process.env.MAX_INSTANCES, 10) || 3,
      specs: [
        `${process.cwd()}/test/**_${folder}/features/**/*.feature`,
      ],
      browserName: 'chrome',
      'goog:chromeOptions': browserOptions,
      acceptInsecureCerts: true,
    },
  ],


  


• avformat/rtsp : Send mode=record instead of mode=receive in Transport header

  15 janvier 2024, par Paul Orlyk

  avformat/rtsp : Send mode=record instead of mode=receive in Transport header
  Fixes server compatibility issues with rtspclientsink GStreamer plugin.
  >From specification :
  
  RFC 7826 "Real-Time Streaming Protocol Version 2.0" (https://datatracker.ietf.org/doc/html/rfc7826), section 18.54 :
  
     mode : The mode parameter indicates the methods to be supported for
  
           this session.  The currently defined valid value is "PLAY".  If
  
           not provided, the default is "PLAY".  The "RECORD" value was
  
           defined in RFC 2326 ; in this specification, it is unspecified
  
           but reserved.  RECORD and other values may be specified in the
  
           future.
  
  RFC 2326 "Real Time Streaming Protocol (RTSP)" (https://datatracker.ietf.org/doc/html/rfc2326), section 12.39 :
  
     mode :
  
            The mode parameter indicates the methods to be supported for
  
            this session. Valid values are PLAY and RECORD. If not
  
            provided, the default is PLAY.
  mode=receive was always like this, from the initial commit 'a8ad6ffa rtsp : Add listen mode'.
  For comparison, Wowza was used to push RTSP stream to. Both GStreamer and FFmpeg had no issues.
  
  Here is the capture of Wowza responding to SETUP request :
  
  200 OK
  
  CSeq : 3
  
  Server : Wowza Streaming Engine 4.8.26+4 build20231212155517
  
  Cache-Control : no-cache
  
  Expires : Mon, 15 Jan 2024 19:40:31 GMT
  
  Transport : RTP/AVP/UDP ;unicast ;client_port=11640-11641 ;mode=record ;source=172.17.0.2 ;server_port=6976-6977
  
  Date : Mon, 15 Jan 2024 19:40:31 GMT
  
  Session : 1401457689 ;timeout=60
  Test setup :
  
      Server : ffmpeg -loglevel trace -y -rtsp_flags listen -i rtsp ://0.0.0.0:30800/live.stream t.mp4
  
      FFmpeg client : ffmpeg -re -i "Big Buck Bunny - FULL HD 30FPS.mp4" -c:v libx264 -f rtsp rtsp ://127.0.0.1:30800/live.stream
  
      GStreamer client : gst-launch-1.0 videotestsrc is-live=true pattern=smpte ! queue ! videorate ! videoscale ! video/x-raw,width=640,height=360,framerate=60/1 ! timeoverlay font-desc="Sans, 84" halignment=center valignment=center ! queue ! videoconvert ! tee name=t t. ! x264enc bitrate=9000 pass=cbr speed-preset=ultrafast byte-stream=false key-int-max=15 threads=1 ! video/x-h264,profile=baseline ! queue ! rsink. audiotestsrc ! voaacenc ! queue ! rsink. t. ! queue ! autovideosink rtspclientsink name=rsink location=rtsp ://localhost:30800/live.stream
  Test results :
  
  modified FFmpeg client -> stock server : ok
  
  stock FFmpeg client    -> modified server : ok
  
  modified FFmpeg client -> modified server : ok
  
  GStreamer client       -> modified server : ok
  Signed-off-by : Paul Orlyk <paul.orlyk@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/rtspdec.c