arut/nginx-rtmp-module

Audio-only HLS streams incompatible with numerous players

Opened this issue · 5 comments

leonnortje commented

We are creating live audio-only HLS streams using the nginx-rtmp module.

They work great in Safari (Mac and iOS). When we try to use them in VLC or from native iOS code (AVPlayer) they load the m3u8 manifest file and ts files, but audio playback either never starts (VLC) or only after a very long time (AVPlayer, 40 seconds plus)

Pushing the same stream via Wowza results in an audio-only HLS stream that works everywhere!

Our nginx config for incoming rtmp (/src) and outgoing (/hls):

application src {
  live on;
  exec_push /usr/local/bin/avconv -loglevel warning -i rtmp://localhost:80/src/$name
  -vn -c:a libfdk_aac -ab 56k -f flv -rtmp_live live rtmp://localhost:80/hls/$name_56k;
}

application hls {
  live on;
  hls on;
  hls_path /tmp/hls/;
  hls_fragment 5s;
  hls_playlist_length 20s;
  hls_fragment_slicing aligned;
  hls_fragment_naming timestamp;
}

We compared the Wowza and nginx-rtmp streams with avprobe:

  1. The nginx-rtmp output always includes an empty h264 video stream at stream index 0 despite pushing empty video with avconv. Is there any way to get rid of the video stream ? Under VLC we definitely see messages trying to play stream index 0 (video) and failing..
  2. The Wowza audio stream has a start_time=N/A value (which seems correct for a live stream) while the nginx-rtmp stream set this value, for example start_time=380.532000. Can we control this via our avconv command ?
  3. Wowza sets the audio stream fourcc tag to codec_tag=0x0000 while nxing-rtmp sets it to codec_tag=0x000f. Not sure which is correct but VLC seems to recognise both as AAC audio so i suspect the first two items may be the culprit..

For reference this is on nginx/1.4.6 (Ubuntu) built with the latest nginx-rtmp module and avconv version v12_dev0-1299-gb8d2630.

leonnortje commented

Apple's mediastreamvalidator has the following opinion of nginx-rtmp generated audio-only HLS:

WARNING: Video segment does not contain an IDR frame
--> Track ID 1

WARNING: Zero sample count
--> Track ID 1

Track ID: 1
 Video Codec: H.264 profile: (null)
 H.264 level: 0.0
 Video resolution: 0x0 pixels
 Video frame rate: 0.000 fps
Track ID: 2
 Audio Codec: AAC-HEv2
 Audio sample rate: 44100 Hz
 ACL: Stereo (L R)
 Average audio bitrate: 32.02 kbits/sec

Which makes it seem even more likely that the culprit is indeed the empty video stream. Current thinking is that some clients use the video stream to trigger actual playback waiting for the first IDR frame (which of course will never come). This would explain all the behaviour seen across different clients.

I see two possible routes to resolving this issue (inside this module at least):

  1. don't include a video track if none has been provided
  2. include an IDR frame with every segment

Of which removing the empty video track would certainly be preferable. Can anyone comment on the feasibility of this?

leonnortje commented

We worked around this issue by adding a valid x264 video track from a still image. Very sub-optimal as this adds significant overheads.

Audio-only streams produced by this module is incompatible with VLC, playing from iOS code with the AVPlayer component and various mobile browsers.

This module is not currently suitable for audio-only applications!

I feel the documentation should be updated to prominently state this to avoid others wasting as much time as we did.

Unfortunately we do not have the resources to fix this - if anyone working on this module would like to comment on a way to fix this that would be great?

rmens commented

Has this ever been fixed in this version?

JaniL commented

@rmens No, the issue still exists in 1.2.2