Why do Live Recording requires higher Bitrate?

[iwod]

Would a 2 seconds delay help substantially lower the bitrate?

[poisondeathray]

Higher bitrate than what? In what context ?

e.g. If you record live at 1Mb/s , isn't that the same as offline at 1Mb/s ?

Doesn't 1Mb/s = 1Mb/s ?

[Filker]

It's quite obvious why real time requires higher bitrates, isn't it?
Same reason a good analog capture is made with a codec light on the cpu load and with a very high bitrate. You want to keep the highest quality with a time and processing power constraint. The less compression (higher bitrate) the less power and processing time you need.

For example fixed function encoders like intel's quicksync can get you the same quality as "software/cpu" x264 only at much higher bitrates.

For the interesting part of the question (if a 2 second delay (buffer?) would help) I don't know if codecs have that option implemented.

[Asmodian]

Would a 2 seconds delay help substantially lower the bitrate?

Well it depends on what you mean by "substantially" but I do know that going to zero latency mode in x264 vs modes with longer delays does give worse quality per bitrate. With a delay you give x264 a lot more information to work with.

There is a good section in the wiki (http://mewiki.project357.com/wiki/X264_Encoding_Suggestions) that gives advice on how tune for lower latency while hurting quality as little as possible.

Not sure about 2 vs 1 second delay etc. You might have to test. ;)

[iwod]

Arh. Sorry i forgot to explain. I was referring to Live TV Shows. I saw a discussion where when showing live Olympics Games some TV station had to shut off other channels in order for the game to show in 1080P Live. I think the Channel Bandwidth was close to 19Mbps. I never did such a high bitrate encoding, but i never have quality problem with x264 over 10Mbit 1080P. I was wondering why TV station needs such high bandwidth, and yet most of their shows looks worst even when they are not on Live. Which should give them time to have slower encode and much better quality.

Do TV station work with shows somehow differently to what we do?

[Filker]

Arh. Sorry i forgot to explain. I was referring to Live TV Shows. I saw a discussion where when showing live Olympics Games some TV station had to shut off other channels in order for the game to show in 1080P Live. I think the Channel Bandwidth was close to 19Mbps. I never did such a high bitrate encoding, but i never have quality problem with x264 over 10Mbit 1080P. I was wondering why TV station needs such high bandwidth, and yet most of their shows looks worst even when they are not on Live. Which should give them time to have slower encode and much better quality.

Do TV station work with shows somehow differently to what we do?

Well X264 is way better than what they're using :sly:

Must be related to bandwidth assigned to error correction too. I remember sd dvb-s mpeg2 with incredibly high bitrates and terrible quality. Even if today everything is digital there probably are decompress/recompress conversions from the source to what you get at home, and that conversion is done in realtime.

"most of their shows looks worst even when they are not on Live"
When they're Live they probably have less conversions as the source is captured in digital the same way they want to transmit it. Maybe recorded shows get their compression cranked up to economize server space.

[smok3]

From my expereince it is looslely like this:


live:

mixer > final encoder

non-live example:

mixer/camera codec (This one is usually the shitiest) > storage codec (codec1) > possible reediting (codec2) > possible grading (usually uncompressed) > storage codec > final encoder

or non-live, even worse example:

mixer/camera codec (This one is usually the shitiest) > storage codec (codec1) > possible reediting (codec2) > possible grading (usually uncompressed) > tape storage codec > hard subtitling > tape storage codec > storage codec > final encoder

---

camera codec , codec 1 & codec 2 are usually lightly compressed, but crap adds up quickly.

p.s. of course i'am not saying everyone is that retarded, just a real world example...

[kieranrk]

Arh. Sorry i forgot to explain. I was referring to Live TV Shows. I saw a discussion where when showing live Olympics Games some TV station had to shut off other channels in order for the game to show in 1080P Live. I think the Channel Bandwidth was close to 19Mbps. I never did such a high bitrate encoding, but i never have quality problem with x264 over 10Mbit 1080P. I was wondering why TV station needs such high bandwidth, and yet most of their shows looks worst even when they are not on Live. Which should give them time to have slower encode and much better quality.

Do TV station work with shows somehow differently to what we do?

I don't think any station used 1080p for sports. TV uses short keyframe intervals (probably 12-30 frames and 0.5-1 sec VBVs). Compare this to unrestricted VBV encodes with GOP lengths of 250 from x264.

[Asmodian]

I think you got it kieranrk, most sports are shown in 720p59.94 or 1080i59.94 so if they were broadcasting the Olympics in 1080p59.94 that would explain a big jump in bandwidth.

[kieranrk]

Some TV channels actually are using x264, aren't they?

Does anyone here know what kind of x264 settings are used by those TV channels?

I *think* OBE encodes the most channels now out of all the x264 broadcast users. Most are using settings equivalent to that between medium and slow. VBV and GOP lengths vary from 0.5 sec to 2 sec. There are a few places doing low latency interviewing with Intra-Refresh.

[Blue_MiSfit]

Who's using x264 for live broadcast encoding? I'm quite curious :)

[kieranrk]

Avail Media. Freebox (France). (Both in house) I think Freebox is biggest in terms of numbers of viewers but I might be wrong.

The largest OBE deployments are embargoed currently but will be announced before IBC. ifb (the co-creator of x262) uses x264 on SES-2.

[Blue_MiSfit]

Avail Media as in recently rebranded to Vubiquity? Interesting...

Thanks,
Derek

[Kurtnoise]

Freebox (France).
fyi, Freebox is the name of the stb...Free is the company name. ;)

[benwaggoner]

Also, sports content is particularly hard to encode. Lots of motion and detail, and shot at a fast shutter speed so little motion blur to help smooth things out. So lots more high frequency data to encode compared to typical 24p 1/48th second shutter TV/movie content.

[Dark Shikari]

Avail Media as in recently rebranded to Vubiquity? Interesting...

Avail Media was one of the earliest companies to sponsor x264 development and has used x264 as their main encoder since the beginning; around ~2005ish.

One of the stories I remember from them is they set up two televisions, one displaying a stream done by a hardware encoder vendor coming to pitch them, and one which was x264 (but they didn't say it was). The hardware encoder vendors watched as the -- very early! -- x264 trounced them, and left puzzled, wondering whose this mysterious encoder was.

[Dark Shikari]

Just typical x264 presets, plus the required VBV/keyframe interval settings for their business requirements and compatibility settings for various STBs.

They also use speedcontrol.

[Dark Shikari]

That can mean anything :p. Because there are ten presets available ;).It means "the slowest one they can get away with using on their encoding server". There's no special magic preset; you just pick the slowest one you can afford to use.

What do you mean with "speedcontrol"?I mean the Avail-developed speedcontrol patch.

[paradoxical]

What do you mean with "speedcontrol"?

http://x264dev.multimedia.cx/archives/34

Of course, broadcast has its own difficulties that make it much more of a challenge than ordinary offline encoding. For one, encoding has to run in realtime, quite a challenge when dealing with 1080i input. This is assisted by a patch written by Loren and improved by me, “speed control,” which automatically reconfigures x264′s settings on the fly to run at exactly the specified speed. It even communicates with the encoding/muxing frontend to know exactly how much time it really has left.

[paradoxical]

Why?

Why does it need to be real-time?

Because they are a broadcaster. Broadcasting has constraints that you seem to be oblivious to.

[detmek]

@jq963152
It seams that you really have no idea what you are talking about.
Delay has nothing to do with speed. If they stream video at 25fps their encoding server needs to encode at 25fps. How is one minute delay in streaming going to help them to go from preset fast to placebo which is 30x slower then former one? How can one minute delay compensate going from 25fps (assuming that is encoding speed of preset fast) encoding speed to 0.8fps encoding speed of preset placebo?
And the slowest one that they can afford depends on content and current encoding equipment.

[paradoxical]

Well, the --preset fast to --preset placebo example might have been a rather extreme example.

So just replace --preset placebo with --preset medium or whatever.

You need to run the numbers:

For a ~24 minute show at 30fps every 1 fps drop adds approximately 3 1/3% to the encoding time or around 45 seconds. So even a 1.5 fps drop means you've now added around 68 seconds to the encode time. Oops, there went that 1 minute buffer idea...

For a 90 minute movie at 24 fps every 1 fps drop adds around ~4.2% to the encoding time or around ~4 minutes.

Do you now see why your buffering idea makes no sense and that they need to be encoding in real time?

[drmpeg]

The difference between an offline encoder (like x264) and a real-time encoder is how the video to be encoded is presented to the encoder. It's a "pull" versus "push" scenario.

With an offline encoder, the video is pulled in (usually from some disk based file) and the encoder encodes frames as fast as it can. If the number of encoded frames per second is less than the frame rate of the video, then the encoder is running at less than real time. If the number of encoded frames per second is greater than the frame rate of the video, then the encoder is running at greater than real time. But the output (usually to some disk based file) is not for immediate play out. So it doesn't matter how fast (or slow) it's encoded. When the file is played out later, the decoder will be able sustain the frame rate.

With a real-time encoder, the video is pushed at the encoder from some interface (a PAL/NTSC analog to digital decoder, SD-SDI or HD-SDI) at the video frame rate. The encoder has to encode the frames as they come in from the interface, there is no flow control. You can buffer up frames for some look-ahead capability, but once you start encoding the frames, it has to be at the frame rate or faster. Otherwise, you'll drop (because you ran of memory) incoming video frames (and that's just not allowed in a broadcast environment).

If there's some output buffering (and remember, any output buffer adds to encode to decode latency), then you can take a little longer to encode some frames. For example, you can let B-frames take a little longer than real-time as long as you can make up the difference when I and P-frames are encoded. As long as the average encode rate is less than the incoming frame rate (and the output buffer doesn't under-run), you'll be okay.

Ron

[akupenguin]

For example, you can let B-frames take a little longer than real-time as long as you can make up the difference when I and P-frames are encoded.
Actually, B-frames are faster than P-frames.

[benwaggoner]

If there's some output buffering (and remember, any output buffer adds to encode to decode latency), then you can take a little longer to encode some frames. For example, you can let B-frames take a little longer than real-time as long as you can make up the difference when I and P-frames are encoded. As long as the average encode rate is less than the incoming frame rate (and the output buffer doesn't under-run), you'll be okay.
Plus, in x264 at least, the more frames you buffer the more threads you can use without having to use slices. With hardware with lots of cores, that can allow for higher quality presets to be used.

Low-latency encoding is a whole lot harder than just live encoding, since you can't spread encoding or rate control over a significant number of frames.

[drmpeg]

Actually, B-frames are faster than P-frames.

Depends on the architecture of the encoder hardware and what portion of the encode takes the most cycles. To be honest, I was thinking about a custom architecture that I worked on back in the early 1990's. It had a hardware VLC coding unit, so the number of bits per frame was not an issue. It was limited more by motion estimation and mode decision (so B-frames were the bottleneck).

I've kept this relic for nostalgic purposes. It's the daughter board portion of an in-house VME development system. The entire encoder used 8 or 9 chips to encode 720x480 or 720x576. Each chip has a whopping 2 Megabytes of DRAM connected to it.

http://www.w6rz.net/scorpio.jpg

Ron