HD Online Player (ip Video Transcoding Live V5 18)
Laura N Gerard
I have a linux server (Apache) setup to stream video files through an html5 web player (Video.js) designed for Chrome and Firefox browsers. The file types I am dealing with are .mp4 (H.264), .mkv, and .wmv. The good news for me is that I can deal with mp4 and mkv natively, however I can't play wmv. Also, I have to deal with a lot of files, change periodically, and can be quite large.
After doing a lot of research and reading many times how you can't stream wmv directly, I came to the realization that I had two options. Either convert the file to a supported format or live transcode a file for use in the web player. Due to the amount of files and their size (and periodically changing) converting the file is simply not feasible. So I am stuck with live streaming/transcoding. I figured ffmpeg would be the way to go, but I have yet to figure out how to get ffmpeg to live stream into the html5 player.
Ffmpeg is not required to be used (was thinking of vlc as well), the html5 player is required. Completely converting then streaming isn't a viable option because file sizes can be too large and change periodically. What command/program can I use to stream the file for playback in the html player?
After trying a LOT of different ways, I finally came up with a workable solution. Posting here for anyone that may come across it in the future. The solution I ended up with is using HLS (live stream) which segments the file. Using the output .m3u8 file I then used it in video tag for my html5 player.
The following is what I used in ffmpeg. Note that I set the preset to ultrafast (because libx264 was very slow by what I've seen). I'm sure there are more efficient parameters to use with ffmpeg and I will definitely continue to do more testing, but this is confirmed as working:
Note for anyone who may come across this in the future: if you run into "file not supported error" when using the type x-mpegURL, then something is wrong with your source js. Make sure to have the hls.js (in my case videojs-contrib-hls.js) or it will throw the error. Took me a long time to figure out it wasn't the browser but the html js that was actually the issue.
I'm curious why this is. I'd love to be able to watch via the web player on devices that arent compatible with the app. I wish I weren't forced to transcode. I turn it up to 10 Mbps figuring it'll have to do less work, but it'll take 2 Mbps and transcode it up to 10...LOL not optimal.
If you set the quality to 10Mbps, and the bitrate of the video is less than that, it will just remux the video to a format the browser can play back. Browsers have limited format support. It will transcode MPEG1 to h.264 no matter what, but if you're playing back live tv or a recording from TVE, it will likely just remux the video.
Should the same thing apply for the iOS player? For example, if I set the video format to 8Mbps, and the original bitrate of the show (480i MPEG-2 from HDHR recording of an SD channel) is 2Mbps or so, I'm seeing the statistics show the bitrate as about 8Mbps, and the video as H.264 instead of MPEG-2?
Either you're wrong, or the bitrate shown by Stats is wrong. The Stats always shows whatever the transcode rate is set to (fluctuating up and down slightly as the video plays, but always averaging whatever the transcoder is set to).
if I set the video format to 8Mbps, and the original bitrate of the show (480i MPEG-2 from HDHR recording of an SD channel) is 2Mbps or so, I'm seeing the statistics show the bitrate as about 8Mbps, and the video as H.264 instead of MPEG-2
When using anything but Original Quality, the stream will be HLS which means it will be transcoded to h.264 to the correct bitrate, so for MPEG1, yes it will be. for h.264, it will only transcode if the original bitrate is above your quality setting, otherwise it will just remux.
I had channels dvr installed on a windows i5 3470 desktop, it worked pretty well, but I was able to get a good deal on the Nvidia Shield Pro, I am now running the DVR server on it, long story short, everything in network runs good, but very slow transcoding HDHR channels, it is set to Hardware transcoding and Linear deinterlacer, adaptive streaming is off, 720p 6mbps, when running the web player it is transcoding around .20x, any ideas? Or more info needed?
Just to follow up, the Shield Pro is hardwired, the TVE channels transcode and play fine over the web player and channels app on my phone when viewing remotely. It's only the HDHR channels that struggle to play when viewing remotely, both live and recorded. Everything seems to play fine when on the local network.
I have enabled the Old Transcoder in the experimental DVR settings which seems to have helped, I am now able to view HDHR channels via the Web player fairly reliably. Its transcoding 720p 6mbps at 1.05x. Is the Nvidia Shield Pro expected to have to use the Old Transcoder? Or is there something else I should try?
The web player doesnt give any errors, I just keep getting the white circle spinning, then it will work for a few seconds, then white circle spinning again. I have tried on Chrome and Edge browsers, I just submitted logs fadffd41-03be-44e4-9195-a81f06bbf866
After spending a few hours tinkering with it, the best results are setting the DVR to Hardware transcoder, Linear Deinterlacer, adaptive streaming off, 720p @ 6 mbps, and selecting the Old Transcoder, any deviation from these settings, (especially turning off the Old Transcoder) will cause unwatchable remote viewing of HDHR live TV and HDHR recordings.
After deleting the DVR server on the Shield and re-installing stable version 2020.09.14.2100 the transcoding problem still persists, both on the web player and while viewing on the Channels app on my samsung phone remotely. The only remedy is to turn on Old Transcoder, keep hardware transcoding and linear deinterlacer
When live streaming with Streamio without live transcoding, we recommend broadcasting at a resolution of 720p at 2500 kbps. The reason for not wanting to broadcast with too high a resolution and bitrate is that there is a risk that some viewers with poorer connectivity may receive a substandard broadcast that chops and buffers.
For viewers, the player will select the best stream suited for the device and connection being used. So the viewer on a fast connection will automatically see the best quality. In contrast, another viewer on a mediocre mobile connection will see a lower resolution without the broadcast chopping or buffering. If a higher resolution stream had been broadcast without live transcoding, viewers with poorer connections would probably have received a poorly performing broadcast.
Live transcoding is the service that takes an incoming video stream and transforms it to a number of other qualities. These are sometimes called ABR ladders or encoding ladders. Each stream in the encoding stage is divided into different segments (chunks), each segment usually lasting around 10 seconds.
Special thanks go to Christopher Kennedy, Staff Video Engineer at Crunchyroll/Ellation John Nichols, Principal Software Engineer at Xilinx, jni...@xilinx.com for their information on FFmpeg and reviewing this article.
Twitch, like many other live streaming services, receives live stream uploads in Real-Time Messaging Protocol (RTMP) from its broadcasters. RTMP is a protocol designed to stream video and audio on the Internet, and is mainly used for point to point communication. To then scale our live stream content to countless viewers, Twitch uses HTTP Live Streaming (HLS), an HTTP-based media streaming communications protocol that most video websites also use.
Within the live stream processing pipeline, the transcoder module is in charge of converting an incoming RTMP stream into the HLS format with multiple variants (e.g., 1080p, 720p, etc.). These variants have different bitrates so that viewers with different levels of download bandwidth are able to consume live video streams at the best possible quality for their connection.
FFmpeg ( ) is a popular open-source software project, designed to record, process and stream video and audio. It is widely deployed by cloud encoding services for file transcoding and can also be used for live stream transmuxing and transcoding.
Suppose we are receiving the most widely used video compression standard of H.264 in RTMP at 6mbps and 1080p60 (resolution of 1920 by 1080 with a frame rate of 60 frames per second). We want to generate 4 HLS variants of:
One solution is to run 4 independent instances of FFmpeg, each of them processing one variant. Here we set all of their Instantaneous Decoding Refresh (IDR) intervals to 2 seconds and turn off the scene change detection, thus allowing the output HLS segments of all variants are perfectly time aligned, which is required by the HLS standard.
hls_list_size is used to determine the maximum number of segments in the playlist (e.g., we can use 6 for live streaming or set it equal to 0 to have a playlist of all the segments). The segment duration (the optional hls_time flag) will be same as the IDR interval, in our case is 2 seconds.
Since H.264 is a lossy compression standard, transcoding will inevitably trigger video quality degradation. Moreover, encoding is a very computationally expensive process, particularly for high resolution and high frame rate video. Due to these two constraints, we would ideally like to transmux rather than transcode the highest variant from the source RTMP to save the computational power and preserve the video quality.
In the above example, if we want to transmux an input 1080p60 RTMP source to HLS, we can actually use the above commands without specifying a size or target FPS and specifying copy for the codecs (to avoid decoding and re-encoding the source):
b37509886e