HD content delivery questions

17 replies [Last post]
GG
Offline
Joined: Mar 16 2002

Hi guys, back after a long break.
I have a question that Alan R is most likely to know the answer to, but all suggestions welcome.
I’ve been working on a project for a while to deliver HD content to broadcasters. I can’t go into much detail but the general specifications are 13.5Mb/s H.264 Long GOP 4.2.0 8 bit. However I would prefer to deliver the content as 4.2.2 10 bit especially as 10 bit is more efficient and the source material will be 10 bit.
We are using Flipfactory to encode the video using Main Concept H.264 codec but it fails no matter what I try. Do any other broadcasters use Flipfactory to create 4.2.2 10 bit H.264? as I have had no luck at all, even Telestream have drawn a blank and have escalated the issues to the USA. Format Profile I’ve been mainly using is Hi10@L4.1
I can produce some great results with X264 and FFMPEG to MUX in the Audio but unfortunatly we can't use it.

I’ve tried to find the specs for the BBC HD-T distribution, but no joy yet. Anyone know? My Humax PVR encrypts the HD content so I can’t analyse the files.

Does anyone know of a link anywhere that will show detailed specs of files or streams that broadcasters deliver to customers?

Any help welcome,
Cheers,

Guido

BSOD - a truly unique Microsoft innovation!

DAVE M
Offline
Joined: May 17 1999

I've seen a document somewhere on line that specs the delivery expected by the Beeb but just to say that using the Humax to analyse what broadcasters are delivering to customers isn't necessarily the way to go as it's what THEY want delivered to THEM that you're after.

edit
http://www.bbc.co.uk/commissioning/tv/production/delivery/hd-production-delivery.shtml

any good?

GG
Offline
Joined: Mar 16 2002

Hi Dave, Yes this is true, but I was interested as to what the specs are of what is delivered to customers. We have bandwidth limitations which dictate a maximum bitrate of 13.5 or about 13Mb/s which with modern Encoders can produce very good results now. We already deliver SD content in MPEG2 at about 10Mb/s which is in my view not high enough, but we don't get any complaints.

Cheers

BSOD - a truly unique Microsoft innovation!

Duncan Craig
Offline
Joined: Nov 19 2008

'general specifications are 13.5Mb/s H.264 Long GOP 4.2.0 8 bit'
Where did you get these specs from?

Surely you should be delivering on a proper master (HDCAM etc), they deal with the transmission encoding.

Duncan.

GG
Offline
Joined: Mar 16 2002

Satellite delivery. We multiplex a Live feed in with an IP stream. No tapes involved. I should also point out it is news. So quality is very variable and could have been sourced from anywhere.

BSOD - a truly unique Microsoft innovation!

infocus
Offline
Joined: Jul 18 2003
GG wrote:
I’ve been working on a project for a while to deliver HD content to broadcasters. I can’t go into much detail but the general specifications are 13.5Mb/s H.264 Long GOP 4.2.0 8 bit. However I would prefer to deliver the content as 4.2.2 10 bit especially as 10 bit is more efficient and the source material will be 10 bit.

As a general point, then 10 bit can deliver advantages - but in most cases the bandwidth implications don't remotely justify the effort. In some cases if you double certain parameters (resolution, framerate etc) you don't need twice the bitrate for equivalent quality. (You can take advantage of redundancy.) 10 bit is not like that - the extra two bits have no correlation with the most significant 8 - so *for equivalent compression quality* - 10 bit needs 25% extra bitrate than 8 bit. Period.

So a 12.5Mbs 10 bit system is roughly equivalent to one of 10Mbs 8 bit. If you've only got 13.5Mbs to spare, I'd put it into better compressing 8 bits than even considering 10 - it's certainly not true that "10 bit is more efficient" - exactly the opposite.

The other thing to consider is that the extra bits tend to have little reason with most cameras, other than at the very top end because the noise level is greater than 8 bit resolution. In which case all that 10 bit is doing is more accurately conveying noise, whilst wasting bitrate!

Quote:
I’ve tried to find the specs for the BBC HD-T distribution, but no joy yet. Anyone know? My Humax PVR encrypts the HD content so I can’t analyse the files.

For distribution, Freeview HD is H264, 4:2:0 long-GOP, 1440x1080, and varies between 1080i/25 and 1080p/25. (Even within a programme.) The bitrate is variable, and dynamically allocated within the transmission mux between all the HD channels - so if fast action is being shown on one channel and something slower paced on another, the first channel will be allocated a far higher instantaneous bitrate than the latter.

A variable delay and buffers helps to even things out - longer the delay, the easier it becomes to have efficiencies - but it can bring problems in other ways. Most importantly, it's impossible to say that any given bitrate with a given coding system will give the same quality with two different encoders. So BBC HD may be able to manage with (say) 10 Mbs with their coders - but 10Mbs may look inadequate with a coder that isn't as good.

And an underlying problem is the one of concatenation - cascading coders and decoders through a transmission chain. So even if BBC HD distribution did get away with a max bitrate of 13.5Mbs, it's by no means certain that it would be anything like adequate to cascade chains of 13.5Mbs in each.

I think the only real answer is to ask potential customers what they're prepared to accept. I strongly suspect that it may well be not solely due to parametrs such as bitrate etc, but the metadata etc that is part of the wrapper.

It's issues like that why currently programmes only get accepted on HDCAM SR tape. Everybody feels that "tapeless" is the way of the future, but the more it gets looked into, the more complex the subject becomes. The bigger the organisation, the truer that statement is.

It's a central premise that whilst a given bitrate may give OK quality with one coder, it may not be enough with a dfifferent encoder - even if the same basic system specs. All coders are not equal.

Alan Roberts
Alan Roberts's picture
Offline
Joined: May 3 1999

Guido, the normal format for delivery of content to the broadcaster is either HDCAMSR or MPEG2 4:2:2 50Meg 10-bit. But you're trying to deliver into the output stream. For that, the only way you'll get any sensible answer is to ask the broadcaster. There's nothing any of us here can do to help.

Get my test cards document, and cards for 625, 525, 720 and 1080. Thanks to Gavin Gration for hosting them.
Camera settings documents are held by Daniel Browning and at the EBU
My book, 'Circles of Confusion' is available here.
Also EBU Tech.3335 tells how to test cameras, and R.118 tells how to use the results.

MAGLINK
Offline
Joined: Mar 8 2007

If it's a sat uplink that the specs will be a lot lower than delivery on HDcam etc.

Here are some specs for an HD sat uplink that may be of some use, talking to some sat engineers it seems that up to 18mbs will be the norm so your spec should be OK I would have thought. The difference between 10 and 8 bits will be irrelevant as if the uplink is only 8 bits that is all it will transmit.

You are best having a chat with the uplink engineer as they will be able to advise you what spec the uplink is and the best format to deliver on, personally I have shot AVC Intra 100 4.2.2 10 bit and DVCPro 50i and just fed with uplink direct via HD or SD/SDI, the sat encode should then sort it into the transmission format and change the bandwidth to suit the upload. Most trucks also have converters that will handle incoming video in all sorts of formats.

Info:

Satellite
Transponder: Channel : Uplink : Downlink: Video standard: Symbol Rate FEC
Aspect Ratio Modulation MPEG Encryption Audio
Talk-up
W3A @ 7 ̊ East
F01 H 14073.17 V 12573.17 H
HD 1080i/50 7.12 Msym/s 3⁄4 SD 16:9 True
9 MHz
DVBS2-8PSK (20% RO) Pilot On 4.2.0. MPEG 4
In the clear 2 pairs (4 Channels)

GG
Offline
Joined: Mar 16 2002

Hi Alan, Thanks for the reply. We are already providing content to boradcasters as MPEG2 files, however when we begin to roll out HD we will be providing H.264 for HD and eventually SD although SD will stay MPEG2 for the moment. I was trying to get a feel for what other broadcasters are doing. We have Satellite bandwidth that dictates what maximum bitrate we can use. I believe the 13Mb/s we have currently settled on as a good compromise is similar to what the BBC TX HD (DVB-T2).

Thanks Infocus for your reply also. But I've done exhaustive testing with 8 and 10 bit H.264 encoding and due to the better efficiency of encoding at 10 bit, files are actually smaller for the same quality than 8 bit. I've backed up these rather surprising results with data from Ateme, who are well respected within the video encoding business.
I though broadcasters were steering away from Thin raster because of the reduction in quality by down rezzing to 1440? I really want to keep away from 1440x1080.

I intend to keep with the same parameters, codec and if possible introduce the MOLE system so that numerous re-encodes will not introduce concatenation through out the Tx path. I’ve done many tests with X264 and Main Concept (the only 2 acceptable codecs for our purpose, although Flipfactory only supports Main Concept) and got very good results at 13Mb/s and kept a high PSNR. So I’m happy with the results. As I said before this is for News contribution not Programmes so it does not have to adhere to the same strict rules as Programmes, although I’m always trying to drive the quality up, which is partly the reason for asking some of the questions in my original post.

BSOD - a truly unique Microsoft innovation!

MAGLINK
Offline
Joined: Mar 8 2007

But surely the limitations are on the uplink and should not be relevant to the delivery file so dropping your bit rate down to the spec of the uplink may mean that you are not putting the best into it at the front end, I would have thought keeping to the recognised shooting / edit specs would be the best bet for delivery and that is certainly what I have been doing so far what happens after that at the uplink end of things should not dictate or lower your delivery spec.

I know that pro res LT (H264) tends to be the spec that a lot of news operations are using as a minimum and that is 10 bit mpeg4 4.2.2 at around 50mbs VBR.

GG
Offline
Joined: Mar 16 2002

Hi Gary,

Thanks, yes that is exactly correct.
However we are delivering files in this instance which we MUX with another stream before delivering to the uplink as an ASI stream, so they don't care about the content of our ASI signal as long as the PID's defining the services are all correctly configured.
The Cameras are a large variety of Panasonic P2 recording AVC-intra 100 for HD, editors and any linear paths that may be between the Camera and the final transmission system are likely to all be capable of 10bit so it makes a lot of sense to create the transmitted files as 10bit. There is also evidence to show that even if the original file is 8 bit, transmitting 10 bit will save bandwidth despite this sounding unlikely.

To add to your 2nd reply. Because we MUX the IP delivery with another signal there is a trade off within the available bandwidth. As you know news needs to be delivered as quickly as possible. If we delivered 100Mb/s files or even 50Mb/s files to clients over a shared 10Mb path it could take hours and we deliver 100’s of files every day. This is not acceptable, we need to deliver a high quality product in minutes not hours. 13Mb/s seems to be about the sweet spot, so we have chosen this compromise bit-rate which still delivers a high quality product.

BSOD - a truly unique Microsoft innovation!

MAGLINK
Offline
Joined: Mar 8 2007

Ah I see that makes more sense and 13mbs should be fine for news, P2 and news operation, hmm must be hitting the Sky then????:D

GG
Offline
Joined: Mar 16 2002

No not Sky, but they do take our content ;)

I've found some interesting stuff well hidden on the BBC website re DVB-T2, but still interested in any info people may have.

We will be running a trial soon so we will be getting feedback about quality. I'm mindful that even if we start distributing 4.2.0 8 bit I want to be sure we can go to 4.2.2 10bit in the future, also compatibility is important. Not all media players with play 4.2.2 or 10bit video correctly or at all. Actually most wont..
It is a minefield out there and I'm quite disappointed at how poorly implemented some "PRO" formats are implemented in very expensive video encoding solutions.
Most only support 10bit 4.2.2 as Intra fame which is no good at all if you are after a lower bitrate than 50Mb/s for distribution.

BSOD - a truly unique Microsoft innovation!

infocus
Offline
Joined: Jul 18 2003
GG wrote:
Thanks Infocus for your reply also. But I've done exhaustive testing with 8 and 10 bit H.264 encoding and due to the better efficiency of encoding at 10 bit, files are actually smaller for the same quality than 8 bit. I've backed up these rather surprising results with data from Ateme, who are well respected within the video encoding business.

I find this very hard to believe as I can't see any sensible mechanism by which it could be the case. It's perfectly true that efficiencies can happen when certain parameters are increased (1080p/50 theoretically not needing anything like twice the coded data rate of 1080i/25, for example) but it's pretty easy to see why that's the case - the extra data is highly correlated with the original, and that can be taken advantage of.

But the least significant bits of a 10 bit system aren't correlated with the most significant bits, so surely nothing like that can be happening here? Assuming your test results are correct, then all I can think of to explain it is that more than one variable is changing between the 8 and 10 bit encodes - something like the 10 bit encoding is using a more efficient engine than for 8 bit? In which case, it would be desirable to use that - but only encode to 8 bit!

Do you have a reference for what Ateme have to say?

Quote:
I though broadcasters were steering away from Thin raster because of the reduction in quality by down rezzing to 1440? I really want to keep away from 1440x1080.

It's a constantly changing scene, but I think it's currently a case of "if needs must" - at least for Freeview. The HD mux has a limited capacity for data, the options are have one less channel (unacceptable), increase the general compression, or reduce the horizontal resolution to 1440. The latter is (currently) seen as the least worst option. Maybe future coder efficiencies will allow for five 1920x1080 channels at equivalent quality levels?

If I understand correctly, you're compressing your pictures with software, then sending over the satellite in non-real time - so more of a file transfer than transmitting real time video? In which case, would a VBR bitrate encoding system have advantages? Allow for much higher than 13.5Mbs when the picture content demanded it for quality, but cut back at other times?

GG
Offline
Joined: Mar 16 2002

It appears that they have put this info online now: http://www.ateme.com/Why-does-10-bit-save-bandwidth.

Yes we are using softare. I’ll spare you the detail, but it has been quite a ride so far. As well as testing off the shelf encoding software like Flipfactory and Amberfin I have also written my own application based on X264 and other open source tools to create files at about 13Mb/s with different colour subsampling and bit depths. I spent a long time tweaking the countless parameters to get the desired results and have produced hundreds of files that we have been using for testing. Leading towards hopefully finding a file type produced with a modern codec that meets the criteria of being excellent quality within the constraints of the chosen bit rate and hopefully without the nasty solarising effect you often see with 8 bit video if we choose to go 10 bit.
H.264 has excellent support for 10 bit in the High422 and High-10 profile so it makes sense to explore that option.

BSOD - a truly unique Microsoft innovation!

GG
Offline
Joined: Mar 16 2002

Found some more bed time reading ;) : http://www.ateme.com/Why-4-2-2-10-bit-video-compression

BSOD - a truly unique Microsoft innovation!

infocus
Offline
Joined: Jul 18 2003
GG wrote:
It appears that they have put this info online now: http://www.ateme.com/Why-does-10-bit-save-bandwidth.

Thanks - I did do a bit of googling after my last post and also found these white papers as well - http://www.ateme.com/White-papers . The relevant one is about ten from the top. (Only had chance to skim it so far, must get on with something more productive now! ;) )

First impressions are that the more you find out, the more you realise there is to it.....! I do think that the advantages of 10 bit increase the more noise free the original. The problem with any discussions along these lines is that there are so many variables that it becomes so difficult to draw meaningful conclusions.

Quote:
H.264 has excellent support for 10 bit in the High422 and High-10 profile so it makes sense to explore that option.

Yes, and obviously there is no such thing as 10 bit MPEG2 - a 10 bit option was proposed (Part 8 of the specification), but dropped. If you want 10 bit, you have to go to H264 - MPEG2 implies 8 bit by definition.