Where to sacrifice or compromise

[koliva]

Hi,

I want to illustrate my question with an example. This example is completely made up by me.

Imagine that you have a dedicated computer to encode movies with x264 and imagine that this computer is connected to a server via LAN and that server acting as a sort of webserver. So a client opens his webbrowser and asks for a certain video from server and server asks this from the dedicated pc. So, from then on everything is live streaming. Dedicated pc encodes the video and sends the encoded bitstream to server and server sends it to client over internet. This connection is not limited to the internet, could be LAN or wireless and so on. So we should think about a generalized solution. My question is, from what property of the raw video located in the dedicated pc would you sacrifice or compromise from so that the bitrate of the encoded bistream would meet the the bandwidth of the client (or the minimum bandwidth on the path).

For example:
1. Would you compromise from the quality a lot, or to what extend,
2. Would you also compromise from the resolution if you cannot achieve the target bitrate by 1.
3. Would you also think about applying filters like interlacing if you can not achieve the target bitrate by 1 and 2.

and so on.

The order could be changed but I would like to know from which property you start from compromising and to what extent.

Hope that I could explain my question.

Thanks in advance.

[foxyshadis]

Quality is more fine-grained, but H.264 quality only scales so far before dropping resolution would be better, thanks largely to the 4x4 and 8x8 transform. (HEVC and VP9 will scale further due to their larger transforms, but that's future and not important to you.) It also depends on how much motion is in your video; lower resolution makes finding motion vectors of fast-changing video like sports much faster, resulting in higher quality real-time video.

Don't forget frame skipping, too. You can always drop frames to lower the bitrate a little.

There aren't absolute answers for when to switch, since they depend on your setup, but changing resolution on the fly usually requires a reset along the entire chain and buffer flushing. So I'd say:

1. Quantizer
2. Softening/denoising
3. Drop frames
4. Resolution

And I'd swap 3 & 4 for really high motion. Softening is similar to lower resolution, anyway, but it's faster, easier, and doesn't save as much. The balance of when to start each and how much to overlap is the tricky bit, you obviously don't want to go all the way down to Q51 before you start filtering or dropping.

[turbojet]

I've thought about setting up something like this to share video throughout the house but encoder and server would be the same box. Because it's LAN bitrate wouldn't matter as long as the encoder sustains realtime. It would mainly be used for sports in this case my priorities might look like this over internet:

1. Resolution but only down to 1024x (lower starts to really reduce quality)
2. Quantizer (try to stay 22 or below)

Target 2-3 mbps avg at 1024x576. Would rather watch 1mbps at 576p then 720p.

With films/shows where details matter more:

1. Quantizer (try to stay 23 or below)
2. Resolution

Target 2-3 mbps at 1280x720. Would rather watch 1mbps at 720p then 576p.

Only filter I'd consider is deinterlacing and ivtc, 60i/p to 30p/24p would also be a must. During playback sharpen and deband.

IVTC during realtime would be tricky (nearly impossible for me) and I'll probably just get a homerun or another network capture card.

[Chetwood]

Why not put all movies on a NAS and watch the files without encoding on dedicated media players like the WDTV?

[turbojet]

If you are writing to me, that's what I do with DVD/BD to play on other computers but what to do when it's live tv?

OP seems to have bandwidth limits.

The situation here is related to OP but with TV. I have server on the ground floor that has multiple capture cards. I want to be able to watch and change channel on the server from up to 3 different computers from inside the house. As long as it's video it doesn't really have to be encoded, can handle 1080i, but source of the filmed stuff looks pretty bad with realtime ivtc (avisynth, madvr) so it's needs encoding or a better realtime ivtc algorithm. There are some programs that promise similar functionality but require going over the internet and encoded at very low bitrates with subpar encoders, and no ivtc.

Changing the channel is pretty straightforward but getting the video to the client has proven difficult.

[koliva]

...

Currently I am using x264 as the encoder. Since it is live stream, I can't predict what the content is. It can be an hour of no-motion content as well as high-motion content. As you may know, there is a VBV parameter to limit the bandwidth and I am using it in my project. However, in this task, I can't change it on the fly since it requires encoder restart as you mentioned. I think I can't change the resolution as well but I will investigate what I am allowed to change further down.

...

I can put the encoder into the server. That's no problem at all.
The input stream is not from TV. Actually what I wrote was just an example. My input content will have full progressive frames at different fps. That's why I use x264 with ultrafast preset. Whatever frame my encoder receives, it encodes it and sends it to the other side real time. Therefore, I am thinking of applying interlacing filter on the input video to reduce the resolution further down. Do you think that this make any sense or cause any problems? ivtc is also not an option for me because I have a receiver application at the client side which decodes and shows the incoming frames real time.

Thanks a lot for all the answers but let's keep discussing this.

[turbojet]

You don't have to combine the server, encoder. I was just explaining my situation. What bitrate limits are you under and what resolution were you planning on using?

The only time I've found interlacing useful is video sources targeted at DVD or hybrid sources targeted for CFR. Not sure what advantages there would be in interlacing progressive content, if any at all. If it's a proper progressive source ivtc shouldn't be needed but it's possible to do it near realtime with a very small delay, theoretically you only need 5 frames to ivtc 30 -> 24 fps.

[koliva]

You don't have to combine the server, encoder. I was just explaining my situation. What bitrate limits are you under and what resolution were you planning on using?

The only time I've found interlacing useful is video sources targeted at DVD or hybrid sources targeted for CFR. Not sure what advantages there would be in interlacing progressive content, if any at all. If it's a proper progressive source ivtc shouldn't be needed but it's possible to do it near realtime with a very small delay, theoretically you only need 5 frames to ivtc 30 -> 24 fps.

The best case is having 10Mbps. bandwidth limit while encoding full HD content. The worst case is transmitting it over internet which I think has about 1Mbps. I was planning to scale down the resolution in this case but it is not possible in my setup. See my other post: http://forum.doom9.org/showthread.php?t=168350

[raffriff42]

False assumption. You don't ever need to change resolution or maximum bit rate on the fly. These things should be set when the channel is opened - whether over a LAN or the Internet. In other words, your streaming server should have one URL per program for high bandwidth, another for low bandwidth, etc.

[foxyshadis]

False assumption. You don't ever need to change resolution or maximum bit rate on the fly. These things should be set when the channel is opened - whether over a LAN or the Internet. In other words, your streaming server should have one URL per program for high bandwidth, another for low bandwidth, etc.

Well, nobody supports H.264 SVC except teleconferencing, so it's more like you can't change resolution. But you can seamlessly switch.

Maximum bitrate certainly can change. What if you start having 10 mbps and a perfect picture, then you're suddenly cut down to 256k for some reason, like a dozen branch offices on fractional T1s suddenly connect and you don't have a CDN. What do you do, drop frames and encode at Q51 until the users get tired of seeing a sea of blocks and turn it off? Display an error that some minimum bandwidth is required?

This is why streaming servers have resolution flexibility built in. It still requires ending the stream, flushing the buffer, and restarting, but it's entirely hidden and a better experience than forcing the user to manually choose lower resolution, or worse, hoping they know it's there. This way the user always gets the best experience no matter what bandwidth they get.

[turbojet]

On demand encoding is ambitious, what advantage do you see in it compared to the very common encoding of low and high bitrate (riffraff42's idea) and stream it on demand?

Theoretically it's possible to change resolution with on demand encoding but there'd be a few second delay. When it's triggered, stop encode noting the last frame encoded, start a new encode at lower/higher resolution some frames before the last encoded. Any number of things could go wrong but with a lot of work could be a near flawless system.

10 mbit full hd would be fine
1 mbit hd might be a bit of a squeeze

[raffriff42]

@FoxyShadis,
>What if you start having 10 mbps and a perfect picture, then you're suddenly cut down to 256k for some reason
Ah, hadn't thought of that. Thank you.

>It still requires ending the stream, flushing the buffer, and restarting, but it's entirely hidden
This seems to happen when you change YouTube resolution on the fly - there is a rebuffering delay.
OP should perhaps be looking for a streaming server (http://en.wikipedia.org/wiki/List_of_streaming_media_systems#Servers), such as VideoLAN, if any can do this trick.

[koliva]

May I ask how you guys switch between two streams seamlessly? For example, the switch between two same movies but in different resolution.

[Blue_MiSfit]

Look into how HTTP Live Streaming (HLS) and similar systems like Smooth Streaming or HTTP Dynamic Streaming (HDS) work. They don't switch between encoding two streams, they encode many streams in parallel and split them up on I-Frame boundaries. These fragments are all made available to clients, along with a manifest file describing the relationships. The clients get to pick which stream to play (fragment by fragment) based on their own interpretation of available bandwidth. Each "layer" can have a different resolution and bitrate, and usually anywhere from 3 to 12 layers are encoded in parallel, ranging from ~240p to full 1080p.

This is, of course, computationally expensive relative to just encoding one stream. It's also a bit tricky, in the sense that all streams must be GOP aligned. Some very clever folks have devised methods to run all encodes share a single input / filter chain, and even a single lookahead. However, these are only available AFAIK on high end professional encoders like Elemental Live. These pro tools are also usually able to encode the elementary streams once, and fragment them into all of the aforementioned adaptive streaming formats in parallel if necessary.