HTTP Live Streaming

RSS for tag

Send audio and video over HTTP from an ordinary web server for playback on Mac, iOS, and tvOS devices using HTTP Live Streaming (HLS).

Posts under HTTP Live Streaming tag

84 Posts
Sort by:

Post

Replies

Boosts

Views

Activity

Putting the TS into tsrecompressor
I notice that precious few HTTP Live Streaming questions have gotten responses, let alone answers. But I'll be optimistic!I'd like to try streaming my own live video through the LL-HLS tools (currently prerelease 73), in multiple bitrates.I succeeded in following directions: I use tsrecompressor to generate "bip-bop" video and pass three compressed variations of that into three instances of mediastreamsegmenter, then out through three instances of ll-hls-origin-example.go. It works as promised, end-to-end. (Brief aside, for any who may stumble after me: it took me too long to realize that I should improve my knowledge of IP Multicasting and use the prescribed 224.0.0.50 address. I got nowhere trying to simply route familiar UDP unicast between my processes.)So far, so good. Now I want to supply my own video from an external feed. Not the generated "bip-bop" or any local capture devices.% tsrecompressor --help tsrecompressor: unrecognized option `--help' Read input MPEG-2 TS, recompress and write to output. Usage: tsrecompressor [options] where options are: -i | --input-file= : input file path (default is stdin) ... etc.That sounds fantastic — I'd love to feed tsrecompressor through stdin! But in what format? It doesn't say, and my first few dozen guesses came up cold.The man page for mediastreamsegmenter appears to point the way: The mediastreamsegmenter only accepts MPEG-2 Transport Streams as defined in ISO/IEC 14496-1 as input. The transport stream must contain H.264 (MPEG-4, part 10) video and AAC or MPEG audio. If AAC audio is used, it must have ADTS headers. H.264 video access units must use Access Unit Delimiter NALs, and must be in unique PES packets.Of course, that's mediastreamsegmenter and not tsrecompressor. But it's a start. So this is my best guess at the appropriate ffmpeg output. (Recall that I want to eventually pass a live stream into ffmpeg; for now I'm starting with an m4v file.)% ffmpeg -re -i infile.m4v \ -c:v h264_************ \ -c:a aac_at \ -f mpegts \ - | tsrecompressor -h -a \ -O 224.0.0.50:9121 \ -L 224.0.0.50:9123 \ -P 224.0.0.50:9125This ends abruptly after 9 frames.av_interleaved_write_frame(): Broken pipe Error writing trailer of pipe:: Broken pipe//My best results are when I change from H.264 to H.265:% ffmpeg -re -i infile.m4v \ -c:v hevc_************ \ -c:a aac_at \ -f mpegts \ - | tsrecompressor -h -a \ -O 224.0.0.50:9121 \ -L 224.0.0.50:9123 \ -P 224.0.0.50:9125Now it doesn't break the pipe. It keeps counting along, frame after frame. The VTEncoderXPCService starts up, and sampling of the tsrecompressor process shows both producer and consumer threads for audio recompression.But there's no output. There was output for the generated "bip-bop" video. Not for HEVC-TS via stdin. I'm not 100% certain yet but I see no indication of any UDP output from tsrecompressor. The three mediastreamsegmenter processes sit idle.Am I missing some tag, or something, in the input stream? Do I need to pay more attention to chunk sizes and frame offsets?Thanks, all, for any insight or experience.
7
0
1.8k
Aug ’23
-16832/CoreMediaErrorDomain Warning: restarting from end of live playlist
Hello Guys,Recently, I'm getting this kind of issue on the HLS live streaming content,The error detail is like belowerror -16832/CoreMediaErrorDomain Warning: restarting 12.494080s from end of live playlist; target duration 9s - stall danger for https://C4--147-21-8-0-24-8395.dfwlive-v1-c4p1-sponsored.dfw.vcdn.att-idns.net/Content/HLS.abre/Live/channel(CMTHD-8395.dfw.1080)/uc9zjusg758wyw3zmumhqyck92mpguti-ks7qcjbcm2aaaaaa-20191125T201851-197474271-114.vttAnyone know what this is? It seems make the picture frozen, or degrade the streaming quality. Sometimes end up restarting the playback.Thanks & regards.
2
2
1.7k
Jun ’23
HLS media playlist Captions and the DEFAULT attribute
When describing closed captions renditions through HLS master playlists, should a properly formed playlist with closed captions contain one closed caption rendition with the DEFAULT=YES attribute? I searched the HLS RFC and section 4.3.4.1 on EXT-X-MEDIA mentions that no more than one should contain the DEFAULT=YES attribute. I was hoping to find recommendations around whether with one or more EXT-X-MEDIA renditions in the same group, if it is required that one of them contain DEFAULT=YES.The media player I am using does not display closed captions if one of the closed captions renditions does not contain the DEFAULT=YES attribute and I am wondering if that is an issue with the player or an issue with a malformed HLS playlist. Note the lack of a DEFAULT=YES attribute in the example playlist below. Should this still be considered a valid playlist?#EXTM3U #EXT-X-VERSION:3 #EXT-X-INDEPENDENT-SEGMENTS #EXT-X-MEDIA:TYPE=CLOSED-CAPTIONS,GROUP-ID="CC",LANGUAGE="eng",NAME="English",INSTREAM-ID="CC1" #EXT-X-STREAM-INF:BANDWIDTH=2103200,AVERAGE-BANDWIDTH=2305600,CODECS="avc1.640029,mp4a.40.2",RESOLUTION=960x540,FRAME-RATE=30.000,CLOSED-CAPTIONS="CC" https://the.link.to.my.stream #EXT-X-STREAM-INF:BANDWIDTH=804760,AVERAGE-BANDWIDTH=875600,CODECS="avc1.640029,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=30.000,CLOSED-CAPTIONS="CC" https://the.link.to.my.stream #EXT-X-STREAM-INF:BANDWIDTH=1304160,AVERAGE-BANDWIDTH=1425600,CODECS="avc1.640029,mp4a.40.2",RESOLUTION=768x432,FRAME-RATE=30.000,CLOSED-CAPTIONS="CC" https://the.link.to.my.stream #EXT-X-STREAM-INF:BANDWIDTH=505120,AVERAGE-BANDWIDTH=545600,CODECS="avc1.640029,mp4a.40.2",RESOLUTION=480x270,FRAME-RATE=30.000,CLOSED-CAPTIONS="CC" https://the.link.to.my.stream #EXT-X-STREAM-INF:BANDWIDTH=3102000,AVERAGE-BANDWIDTH=3405600,CODECS="avc1.640029,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=30.000,CLOSED-CAPTIONS="CC" https://the.link.to.my.stream
1
0
3.9k
Sep ’23
mediastreamvalidator always signals 'unsupported sudo track codec' with AES sample encrypted streams
Hi,When I run mediastreamvalidator on HLS streams (produced by mediafilesegmenter), with SAMPLE-AES applied, the latest version always signals :Unsupported audio track codec: Unknown - As a 'MUST FIX' issue.This result occurs even when I run the validator against the FairPlayStreaming example content supplied with the developer SDK package.This seems to have been introduced in HTTPLiveStreamingTools version:Version 1.2(170524)It does not happen with tools version:Version 1.2(160525)Is this a bug in the tool? or a new requirement perhaps?Hopefully someone can help me out with this...
2
0
1.5k
Aug ’23