h265 Support

B

Bensam123

Member
Yup, it's been asked for before and it's been quite awhile since this has been announced. Does anyone have any idea of when Twitch is going to support this (I couldn't find anything by googling around) and is OBS ready for this as well? I heard musing of html5 support on Twitch instead of the Flash player, which is about time, I don't know if that includes h265 though.

Obviously Twitch has to support it first before it'll go anywhere, but it would be nice to hear about this from time to time.
 
The answer has still not changed: As long as RTMP (and thus FLV) is the transmission protocol used to stream from clients up to distribution servers, the video format will need to be h264 (since the FLV container does not support any other formats, officially). Twitch using an HTML5 player has nothing to do with that -- video files are transcoded to HLS on the server, which is why server -> viewer HTML5 video is a possibility. But right now, streamer -> server video transmission is still only RTMP pretty much everywhere you look. RTMP/FLV requires h264 video. Until that changes, streaming will always use h264 video.
 
Last edited:
Yup, we will all use DDR3 till people change to DDR4 systems, got that already... So you haven't heard anything about Twitch switching to h265 anytime soon?

I mentioned html5 as it's a stepping stone towards better quality content, which may include other changes to the back end.
 
Bensam123 said:
So you haven't heard anything about Twitch switching to h265 anytime soon?
Click to expand...

No, I haven't heard anything about that, but I don't think you're getting it. What would they switch to in terms of protocol for streamers to upload their livestreams to Twitch? The problem lies in how Twitch gets the video content FROM STREAMERS, not how they deliver video TO VIEWERS. To my knowledge, RTMP is currently the best way for streamers to upload their video streams to Twitch. Once Twitch gets the video, they can convert it to whatever they want and deliver it to viewers however they want. If they want to transcode the h264 video to h265, I guess they can do that if they want? It wouldn't affect streamers, only viewers. Twitch has no other way to get video from streamers other than RTMP, and they have not given any indication that they are working on changing that.
 
If you spent any time reading that page, you would see that it is describing options for h265 playback from the server to viewers, not live uploading of video from streamers to the server.

Many streaming services are in regular contact with OBS, including Twitch and YouTube. If they tell us that they are somehow adding support for some magical transmission protocol that lets streamers livestream video encoded in h265 format from their computers up to their servers, then sure, support will be added. But thus far, no such magical protocol has materialized to my knowledge, and no services have contacted OBS to talk about supporting it.
 
Your bedside manner definitely has something to be desired to say the least, but thanks for answering my question.

I'm not entirely certain how what a content production server that streams to a client differs from a client that streams to a content production server. Both can be transcoded and I've used relay media server to do just that before. I was under the impression the current limitation is Twitch support as they don't support anything other then RTMP. There are plenty of other formats based around HTTP and nothing stopping the streamer from encoding in such a format besides the software. Those were listed on the page I linked.

They appear to be discussing a similar topic here and using RTSP instead as well: http://stackoverflow.com/questions/28097665/ffmpeg-how-can-i-send-a-h-265-encoded-stream-to-wowza
 
Sorry, I just get very annoyed when people constantly ask about h265 as if it's going to be the savior of the universe when it's not even possible to use it for livestreaming via software encoding due to the extreme CPU load, and hardware encoding isn't even really widely available outside of beta access to the nVidia hardware encoders and we don't know what its performance will ultimately be like. When I see people get excited about h265, it strikes me as people just getting excited about how 265 is "one better" than 264 and ignore all of the other complications that come along with it.

My enthusiasm for h265 in livestreaming is heavily tampered by its impracticality for livestreaming outside of hardware encoders (assuming hardware encoders are up to the task), the lack of support (or even interest in support) from pretty much any streaming service provider, and the fact that, to be honest, h264 works and looks fine still, and will be the industry standard for quite a while, even after h265 becomes more mature.
 
I've seen the benchmarks and probably read the same articles you have. CPU utilization being 'up' to the point where it can't be done in realtime by most modern processors is a case by case basis (OCL and cluster support will definitely change that). Obviously depending on what is being encoded determines the CPU workload, res/fps/content. Those are all growing pains that first require support before they can be ironed out and dealt with though. It's definitely worth getting excited about though, it does half the bitrate usage a lot of the time. That's a big deal and why people are so excited.

So going back to the RTMP thing, why can't people stream in HTTP to say Twitch if they supported it? I was under the impression those were all other formats for streaming listed on Wowza that could be used to streaming. It may not be what Twitch currently supports, but they are other valid formats. MPEG-DASH or Adobe HLS over HTTP for instance... The one post I quoted was using RTSP (which seems to be quite old).


And yeah, I understand asking too much about h265... I haven't seen anything recently about it which is why I asked.
 
It's definitely worth getting excited about though, it does half the bitrate usage a lot of the time.
Click to expand...

I agree that such stats are exciting, but for now it's only reasonable for VOD usage like normal non-live YouTube videos.

why can't people stream in HTTP to say Twitch if they supported it?
Click to expand...

HLS and DASH (both HTTP-based streaming methods) are specifically designed to work like this: The server hosts video (the video lives on the server's hard drive somewhere), a user who wants to watch the video sends a request for it, and the server sends to down. So the person receiving the data has to initiate the request, and the server that sends the video has to support receiving HTTP requests. That model doesn't work if you're a streamer trying to send data up to the server rather than download from the server, since it would require the server to request video from the user rather than the user pushing video data, and then the user would have to have their computer configured to serve HTTP, which often isn't the case without setting up things like port forwarding on a network.

RTMP servers are instead set to listen for connections, and users can then initiate and push data without the server requesting it. Then it can also respond to other user requests for the video and pass it along to them, often without even needing to transcode, which is why raw RTMP has such low delay compared to HLS.

As for RSTP, I admit that I'm not very familiar with it (I do know it's an older technology), but from what I understand, it's designed for different purposes than the kind of streaming we're used to with Twitch.
 
Hypothetically speaking, why wouldn't that work? It just requires the user send a request to the server to request data from the user. One extra step, but it doesn't seem impossible. That's no different then any other sort of handshake online and wouldn't really require all that much extra work to initiate. Same with HTTP hosting, only reason no one is setup for it is because it hasn't really been done on the user end (we're all setup for RTMP right now).

Then it can also respond to other user requests for the video and pass it along to them, often without even needing to transcode, which is why raw RTMP has such low delay compared to HLS.
Click to expand...

If we're talking about a push vs pull model, instead of added delay of dealing with the container itself, how would that differ? I assume HTTP streams can be relayed as well as RTMP streams.


Obviously if no one supports this, it wont work, just curious why such a model wouldn't work. I assume streaming services like Wowza are already setup to relay HTTP streams. This will probably just turn into a bunch of finger pointing (whose job is it to start support of such a thing? chicken and egg), which is why it probably wont ever happen, but why wouldn't it be able to?

Adobe doesn't seem like they're thrilled to continue pushing RTMP forward and traditionally Adobe support sucks, so why stick with it if there are alternatives (albeit different)?
 
It just requires the user send a request to the server to request data from the user. One extra step, but it doesn't seem impossible.
Click to expand...

The problem is that you are telling the server to send an HTTP request, not a constant connection with a handshake. Basically, it means that the user's computer would need to be set up to run as an HTTP server. Sure, OBS could come bundled with an HTTP server, but then there's the issue of routing: you need to set up your router to forward requests on port 80 to your computer, and make sure you don't have a firewall on your computer that will block such requests. Already we have rocketed far beyond the technical capabilities of your standard user.

If we're talking about a push vs pull model, instead of added delay of dealing with the container itself, how would that differ? I assume HTTP streams can be relayed as well as RTMP streams.
Click to expand...

Sort of? I don't really know how one might go about it, and it would require the server to just "accept" the .ts chunks that it's downloading and put them into its own version of the m3u8 playlist. Streaming services are usually pretty picky with how they chunk their .ts files for HLS streams, so I would be surprised if a streaming service wouldn't want to transcode to its own format again. Perhaps it's theoretically possible delay could be reduced that way, but I don't think it's practical in any way, personally.

I assume streaming services like Wowza are already setup to relay HTTP streams.
Click to expand...

Small correction: they are set up to serve streams over HTTP. They have to either have video files to send down already, or transcode from a livestream into a format that can be delivered via HTTP. There is no "relaying" of HTTP livestreams because there is no way to send your stream to a distribution server over HTTP, as we have already been discussing.
 
dodgepong said:
The problem is that you are telling the server to send an HTTP request, not a constant connection with a handshake. Basically, it means that the user's computer would need to be set up to run as an HTTP server. Sure, OBS could come bundled with an HTTP server, but then there's the issue of routing: you need to set up your router to forward requests on port 80 to your computer, and make sure you don't have a firewall on your computer that will block such requests. Already we have rocketed far beyond the technical capabilities of your standard user.
Click to expand...

UPNP, putting that aside, it isn't always that complicated, sometimes it just works, especially if you use a different port, which could be done. Obviously a little bit more would have to be done here then simply setting up a ghetto web server. A standardized method to form a handshake would be a great place to start. I think you're making this more complicated then it seems. A lot of games allow you to host your own servers and they usually work in a very similar manner.

Sort of? I don't really know how one might go about it, and it would require the server to just "accept" the .ts chunks that it's downloading and put them into its own version of the m3u8 playlist. Streaming services are usually pretty picky with how they chunk their .ts files for HLS streams, so I would be surprised if a streaming service wouldn't want to transcode to its own format again. Perhaps it's theoretically possible delay could be reduced that way, but I don't think it's practical in any way, personally.
Click to expand...

Another thing a standard could define. You don't necessarily need to make new stuff either, just make sure everyone is on the same page. As I mentioned before, this probably wont happen due to finger pointing (which seems to be happening here already), but based on everything you said, something like this is very much possible.

I think OBS definitely has enough clout where they could present such a solution and youtube and/or twitch may consider adopting depending on how it works. Right now there aren't any other solutions so no one is going to adept something that doesn't exist.
 
Hmm, just writing a new protocol and making standards wont make anyone switch. I remember the guy that told us twitch would switch to webrtc in 3 months and OBS will be unusable by then. That was a year or two ago.

Probably 99% of computers are not able to encode a video with a useful resolution for streaming with the H265 codec at the moment, at least to what I read about it and saw in tests. Hardware encoders are not available yet, at least not in large numbers and even then it will still take some time. Only the newest graphics chips support hardware decoding of h265 for example and it uses a lot of CPU power. In theory, you might even be able to test h265 using the ffmpeg output of obs-mp, not totally sure.

As soon as we reach a point in which h265 can be encoded and decoded just fine by a big number of people (similar to h264 a few years ago) everyone will switch to it. Back in 2009 I streamed with vp6 at maybe 480p and it nearly ate my whole CPU.
I just checked, work on h264 started in 2001, first version was ready in 2003 and we all use it since, maybe 2008/2009 decoding wise? :D
 
Well some people actually can use h265 encoding. Running a 5820K i7 @4,5GHz, one of the strongest CPUs on the market for desktop systems, GTX 970 (will be replaced by 980Ti soon or maybe later for something with more steam under the hood). I dont mind going for hardware encoding etc (and can also provide PCI-lanes to it if needed, 8x should be enough). A second PC with same speccs or even higher amount of cores/threads (hi@Xeon CPU) is also possible and i would able to squeeze anything out of it.
Streaming was always about nerdy guys pushing the limits of hardware, bandwith and software. We should have access to the newest technology even if brings only a minor advantage and requires a powerful enthusiast-grade rig.
So why dont just come up with some testing, 1 server per continent, to push the limits and also gain expirience?
As an early adopter i agree to play the beta-tester role for free and providing feedback and data, so why not in this case?
h265 IS the future, and we have the power to decide when it goes public.
We have so many people with overkill systems just sitting around waiting for any possible improvement for the current situation and nothing goes forward. Not everyone is capable of pushing the development personally in the early stage, but a small amount of people is enough there. We can take the second stage right now, just give us something...
 
You're welcome to do that, but the OBS developers will be busy with other improvements to the program that are much more important in the near-term. Developing a protocol for h265 streaming from encoder to distributor is way, way outside the scope of OBS development.
 
Well h265 will give better quality at the same bitrate than x264. The cost: raw power needed to encode it as a streamer and the same goes for the playback.
Right now with anything going for multithreading and slapping as many cores as possible on anything, i expected this to have the highest priority here. Specially for twitch, cause they have pretty harsh bandwith restrictions - so everything that can improve the quality with the given bitrate would be welcome.
I know my rig beats 95% of all systems used for streaming, but with this kind of raw power i would love to actually test it in public, not just do some strange benchmarks (thats the only thing possible right now).
 
Since you belong to the 1% I mentioned, streaming WAS a thing for nerds, but if you regularly help the OBS users you will very very very fast learn that its maybe 2% of all streamers that are "nerds" and max 25% of those nerds have a processor like you. So thats less than 1% of all streamers in my opinion, 5% is a bit high maybe.

OBS is a streaming software that has to support what the services demand and use, that is rtmp at the moment. Focus in development is on bringing OBS-MP to have all necessary functions and features, good stability and if possible it should be easy to use. The development team is also pretty small I would say and there are far more important things that have to be added at the moment. (qs, nvenc, transitions, deinterlacing for example)

If OBS(MP) gets to a state where its bug free and feature complete, then (assuming one of the developers is even interested) one could look into working on h265. Apart of the protocol to deliver the stream it would also need a server software that can work with that protocol and a webplayer that can play the stream. Have fun writing all that.
 
Well i`m not into programming stuff, i`m more the audio and pc/hardware guy, not everyone can understand the code behind all this stuff (working myself into scripts and nginx etc just because i need it, not because i`m really interested).
I expected some sort of collaboration between the development teams behind software like OBS, Xsplit and the teams providing the service and servers, names like Twitch, Hitbox, Cybergame/Goodgame (russian teams specially) and Youtube (just because a) they want to push streaming on youtube and b) because they are well known for pushing and adapting new stuff before other VOD/streaming platforms do it). And specially Twitch and Youtube have a shit ton of money and manpower to push a project like this and provide you guys with all the needed infrastructure so you can work on the code and get everything you need to test it on servers provided by other teams.

I know that my CPU is kinda overkill even for a streamer but i`m following the streaming community for a while now - mostly we had nerds here with good hardware and great connections who started all this stuff. x264 took a bit too long for my taste, it was ready and waiting, but became big after a couple of years - thats a long time in the modern age.
So i expected h265 to hit like a truck right now, pushing on all fronts and forcing the development (thats where people like me jump in to test it and give feedback, specially on rare and new hardware like DX12-ready OS&GPUs, DDR4 and powerful CPUs). Thats how i became a hardware enthusiast. And all of us just sitting here waiting for the software to push our rigs to the limit :-)

Since streaming is hard limited by bandwith, the encoder here is really important, any performance gain at the same bitrate is worth it. Specially in my case where i have this rig but i`m limited by 6mbit/s upload, so i have a personal interest in making my stream look great with maximum 4000kbps before i actually get fibre or VDSL or before twitch raises the bandwith limits.
 
You really expect a paid software to work together with an open source project that is its direct competitor?
Or a service like twitch that is a direct competitor of hitbox should work with hitbox? I really had to laugh out loud.

Google (youtube) even has their own codecs, not sure if they are that interested in h265. In the end we can talk on and on but it wont change a thing. Talk to Twitch and Youtube with their manpower and money and ask them to work on h265.
There is nothing more to say from the OBS side atm.
 
You must log in or register to reply here.
Back
Top