GStreamer Has An Exciting 2019 Planned With Some Big Features

[phoronix]

Phoronix: GStreamer Has An Exciting 2019 Planned With Some Big Features

Tim-Philipp Müller once again presented at FOSDEM in Brussels about the current GStreamer release and a bit of what they have planned for moving forward. This multimedia framework continues to evolve and is quite exciting with everything they have in store...

http://www.phoronix.com/scan.php?page=news_item&px=GStreamer-2019-Plans

[Michael_S]

I would argue the best feature might be the SRT (Secure Reliable Transport). Netflix, Youtube, Amazon streaming, and a lot of other big enterprise streaming services use their own proprietary protocol that can adjust video quality in a low latency way automatically based on bandwidth. From what I understand - could be wrong - SRT makes an open source standard for this.

Up until now, this was a way Netflix, Youtube, and Amazon offered a flat out better end user experience with video streaming than things like MediaGoblin and federated video services. Your Netflix video starts all but instantly at a low quality and then the image sharpens until you're getting the full quality, and if something slows down bandwidth it adjusts automatically. You rarely get dead pauses while the stream buffers. You might notice occasional drops in image quality but it's less irritating than a pause. When you stream from MediaGoblin the only way to get an instant start and the most reliable connection possible without pauses for buffering is for the MediaGoblin owner to host low quality videos. I think this GStreamer enhancement fixes that.

(Edit: (tpm) below corrects me on what SRT does, I had it wrong.)

[tildearrow]

Typo?

There is also exploration around scaleable streams,

[(tpm)]

I would argue the best feature might be the SRT (Secure Reliable Transport). Netflix, Youtube, Amazon streaming, and a lot of other big enterprise streaming services use their own proprietary protocol that can adjust video quality in a low latency way automatically based on bandwidth. From what I understand - could be wrong - SRT makes an open source standard for this.

Up until now, this was a way Netflix, Youtube, and Amazon offered a flat out better end user experience with video streaming than things like MediaGoblin and federated video services. Your Netflix video starts all but instantly at a low quality and then the image sharpens until you're getting the full quality, and if something slows down bandwidth it adjusts automatically. You rarely get dead pauses while the stream buffers. You might notice occasional drops in image quality but it's less irritating than a pause. When you stream from MediaGoblin the only way to get an instant start and the most reliable connection possible without pauses for buffering is for the MediaGoblin owner to host low quality videos. I think this GStreamer enhancement fixes that.

SRT is a protocol that would usually used by a capture/contribution source (think: camera that captures + encodes a live stream at an event) to upload a stream to a transcoding/distribution server which will then take it and process it for distribution (e.g. encode it at different resolutions and bitrates and split it into chunks and make it available via http via DASH/HLS for example; or generate an MPEG-TS stream for broadcast). In those cases you want to make sure that you keep streaming even if the network link throughput is a bit flaky (reliable links with guaranteed bandwidth can be very very expensive).

What Netflix, YouTube, Amazon streaming and other video on demand services use is usually one of various adaptive streaming protocols like DASH/HLS. They basically encode the same movie/video multiple times in different bitrates and resolutions, and chop up the video into 10 second chunks (or somesuch). The video player can then start downloading 10-second chunks of video and for each chunk it will measure the bandwidth and decide if it wants to try a higher-resolution/bitrate chunk next time or if it needs to downgrade because the network is too slow. That's why you tend to start with low resolution video and after a few seconds it gets sharper once it has detected that you have enough bandwidth.

GStreamer supports this as well, and in fact many clients you find in set-top boxes or 'sticks' are based on GStreamer. It's got nothing to do with SRT though. Adaptive streaming is designed for scalability, serving thousands if not millions of people at the same time via battletested http data serving infrastructure. SRT is a 1:1 link and not really meant for serving video to end users, it's better suited as part of a production/transcoding pipeline.

I don't know how MediaGoblin streams data, so can't comment on that, but if there are problems I'm sure it could be improved.

[Michael_S]

(tpm) thanks for explaining. I was thinking of the technology you describe as DASH/HLS, I misunderstood the overview of SRT to mean that.

I haven't played with MediaGoblin in a few years. When I did, I don't think it had anything like DASH/HLS integrated. I thought an open source version of that feature hadn't been implemented yet. I played with MediaGoblin as it was for a month or two and then just gave up and upgraded my home wireless and ran cat5e in a few places to make streaming work better.

[andrei_me]

(tpm) thanks for explaining

You got the answer from the man itself, Tim-Philipp Müller