But you are ignoring the fact that at very least 80% of the BBC programes are prerecorded so could be precompressed
No they couldn't, and I'll explain why not.
Video needs to be constant quality to look acceptable, which means more bits spent on fast moving scenes, and less bits on static scenes. This results in a variable bit rate stream.
Broadcasting however needs a constant symbol rate for modulation onto a carrier frequency. This is one of the reasons for grouping several channels together onto a mux, and using statistical multiplexing techniques to distribute bitrate fairly between the channels to achieve a constant group rate.
The only way this could all be done 'in advance' (and it would have to be at least a day before) is if all the channels in the statmux group were pre-recorded material, with no interruptions (advert breaks, news flashes, technical problems etc.).
This is impractical since, even if all the BBC channels were grouped together (no commercials) they would still have to allow for unexpected events, news flashes, last minute schedule changes etc. Indeed, alot of BBC programmes are indeed live anyway (for example 10 o'clock news, bbc breakfast, formula1, etc).
In the real world, things are a lot more complicated than your simplistic explanations.
Indeed, alot of BBC programmes are indeed live anyway (for example 10 o'clock news, bbc breakfast, formula1, etc).
Going back a LONG time now, the only two regular live programmes on BBC (ignoring news obviously) were Tomorrows World and Blue Peter.
This came to light when a particular top of the range Sony Betamax VCR wouldn't record those two specific programmes - all other programmes, both BBC and ITV, icluding live news programmes, recorded perfectly.
Back then we had plenty of contacts inside the BBC, including various technical guys - and when we asked them about it they all instantly said that they were the only live broadcasts.
I can't remember how it was resolved now (it's so long ago), but either the BBC cured whatever was causing the problem, or Sony brought out a modification for the VCR.
Video needs to be constant quality to look acceptable, which means more bits spent on fast moving scenes, and less bits on static scenes. This results in a variable bit rate stream.
Broadcasting however needs a constant symbol rate for modulation onto a carrier frequency. This is one of the reasons for grouping several channels together onto a mux, and using statistical multiplexing techniques to distribute bitrate fairly between the channels to achieve a constant group rate.
The only way this could all be done 'in advance' (and it would have to be at least a day before) is if all the channels in the statmux group were pre-recorded material, with no interruptions (advert breaks, news flashes, technical problems etc.).
This is impractical since, even if all the BBC channels were grouped together (no commercials) they would still have to allow for unexpected events, news flashes, last minute schedule changes etc. Indeed, alot of BBC programmes are indeed live anyway (for example 10 o'clock news, bbc breakfast, formula1, etc).
In the real world, things are a lot more complicated than your simplistic explanations.
Precompressing data has nothing at all to the data rate. So your argument is totally ireelevent.
Whether dats is compressed or not it is data. The datacan be tranmitted at the same data rate wether it is compressed or not. The network know's no different. It's just data.
There is no direct connection between Precompression and the data rate. They are two independent things. You are confused. You could if you chosse send the same Program Precompressed & Not Precompressed at the same data rate
But if you have a set amount of bandwidth, is there anything to stop you only using some of it? ie. Can't you set the maximum bandwidth to that of the live transmissions and then only use what you need for pre-compressed?
I don't see why in viewing terms switching from pre-compressed to live feed would need anything more than the displaying of one of the BBC's animated logos to smooth the fade in and out of pre-compressed vs live behind the scenes. So pre-compressed programme ends, BBC animated channel logo comes on and plays. New source selected behind scenes. Live feed starts at end of logo.
There is no direct connection between Precompression and the data rate. They are two independent things. You are confused. You could if you chosse send the same Program Precompressed & Not Precompressed at the same data rate
Yes, but the pre-compressed one would be good quality (like Luxe) and the live compressed one would be FAR worse than the current poor quality on BBC HD.
So they aren't 'un-related', they are entirely dependent on each other.
But if you have a set amount of bandwidth, is there anything to stop you only using some of it? ie. Can't you set the maximum bandwidth to that of the live transmissions and then only use what you need for pre-compressed?
I don't see why in viewing terms switching from pre-compressed to live feed would need anything more than the displaying of one of the BBC's animated logos to smooth the fade in and out of pre-compressed vs live behind the scenes. So pre-compressed programme ends, BBC animated channel logo comes on and plays. New source selected behind scenes. Live feed starts at end of logo.
You could do it that way, yes, its just that its not usually the best use of the available bandwidth, and that is what broadcasters are after.
The problem is that the live channels (such as sports) may need a lot of bits when there is fast action, but this need is bursty and unpredictable. Other times the sports channels bit rate requirements may be low (during lulls in the action, or during half-time discussion for example).
If the non-live channels (such as movies) were pre-compressed, they would need to limit their peak bitrate just in case the peak bitrate demand of the sports channels coincided with the peak of the movie channel.
This would lead to inefficient use of bandwidth when the difficult (peak) part of the movie coincided with the easy part of the sports - movie could have been coded with more quality at that point.
On the other hand, if the live sports channel had a very difficult part of the action to code, then even more bits could have been taken from the movie channel and allocated to the sports channel than was actually used, if the movie scene was easy to code at that point.
One solution could have been to encode the movie channel at a constant bitrate (CBR). But we know that leads to poor quality at fast-moving scenes, and quality that is too good in easy scenes (i.e. could have used less bits without the viewer noticing artefacts).
The other thing to consider is commercial considerations. Broadcasters generally make more money from live channels such as sports, and they really don't want the quality to suffer on those if they can help it. Borrowing bits from the easier-to-code channels (but only when they need to) is the way this is achieved.
It is a delicate balancing act, and making statmux fully live is generally a more efficient use of bandwidth overall than if the bitrate of some channels is already fixed.
There is no direct connection between Precompression and the data rate. They are two independent things. You are confused. You could if you chosse send the same Program Precompressed & Not Precompressed at the same data rate
The main problem I was trying to get across with offline pre-compression as opposed to live compression is, once the offline coding has been done, the bitrate cannot be changed. This is a problem if you want constant video quality across a group of channels (some of which will be carrying live content), and you also want to make the most efficient use of the limited bandwidth available.
What are you on about?, precompressing the data allows a much smaller data rate whilst maintaining the quality - as Luxe prove.
So it's entirely relevent.
But we are talking about transmited data. Its just data. You can transfer data. You are also confused between data rate and bandwidth. THey are not the same
The main problem I was trying to get across with offline pre-compression as opposed to live compression is, once the offline coding has been done, the bitrate cannot be changed. This is a problem if you want constant video quality across a group of channels (some of which will be carrying live content), and you also want to make the most efficient use of the limited bandwidth available.
The bitrate can be changed but the bandwidth will be coonstant. Precompressing saves them Bandwdth. Yes live dats will have a more variable bandwidth requirement and it will be pretty random. Yes the BBC could try agregating the channel to try to smooth it out but its unlikely to work well.
What I suspect is that this is all about try to cram HD into the inedequate amount of Bandwidth available on Terrestrial. It is always going to need serious compremises made unless and that what we are seeing on Freesat. The bandwidth the BBC are using is just not adequate but to get it on terrestrial they will have to squeeze it even further
If we are going to have HD it need to be HD and not something thats little better then SD.
Personally I think they should drop the idea of HD on terrestrial. THe bandwith is not there to do it justice. They could then tranmit proper HD on Freesat.
They have been putting out all sort of claims for HD. such as they will have rebuild sets etc because on HD you would see they are fake. Well not with what the BBC are cuurently puting out. No one would notice
It says 12-14mbps is the requirement for 1080i. BBC HD is now at 9.7.
It strikes me that things wont have changed that much in 6 months?
Psssh, that's those there Swiss- we Brits don't need that kind of quality:eek:! It's hard times don't you know, the BBC only have a budget of 2 billion pounds.
The bitrate can be changed but the bandwidth will be coonstant. Precompressing saves them Bandwdth. Yes live dats will have a more variable bandwidth requirement and it will be pretty random. Yes the BBC could try agregating the channel to try to smooth it out but its unlikely to work well.
What I suspect is that this is all about try to cram HD into the inedequate amount of Bandwidth available on Terrestrial. It is always going to need serious compremises made unless and that what we are seeing on Freesat. The bandwidth the BBC are using is just not adequate but to get it on terrestrial they will have to squeeze it even further
Or the BBC could just stop buying sub-optimal Thomson encoders and move to a better manufacturer?:rolleyes:
But we are talking about transmited data. Its just data. You can transfer data. You are also confused between data rate and bandwidth. THey are not the same
They are not the 'same' but they ARE directly (and exactly) related to each other - higher data rate, higher bandwidth required.
The only person confused in this thread appears to be you?.
It says 12-14mbps is the requirement for 1080i. BBC HD is now at 9.7.
It strikes me that things wont have changed that much in 6 months?
But statmuxed at 720p, 8 - 10 mbps is stated. As I prefer 720p/50fr to 1080i/25fr, I'd be delighted if the BBC switched to that and dropped the horrible interlaced broadcast format they currently use. Seems to me that this would be the sensible thing to do until 1080p/50 fr is available.
Or the BBC could just stop buying sub-optimal Thomson encoders and move to a better manufacturer?:rolleyes:
I'm not convinced that is the issue- I don't think we'll see the same problems on Freeview HD because it will be stat muxed, while the satelllite version will be stuck at too low a level. The BBC really need to come up with a sensible explanation as to why they are now wasting money on 6Mbps of bandwidth on satellite- I really hope the reason isn't as stupid as they are trying to make it equal with Freeview HD (which actually it won't be by my calculations)- as someone pointed out digital radio has higher bitrates on satellite than on freeview or DAB- so what is the problem the BBC HD on satellite having a higher bitrate? Of course it wouldn't be because of pressure from Freeview HD STB manufacturers who don't want to hear that HD channels on Freesat look better:rolleyes:...
Yes, but the pre-compressed one would be good quality (like Luxe) and the live compressed one would be FAR worse than the current poor quality on BBC HD.
So they aren't 'un-related', they are entirely dependent on each other.
The live compressed once would be as good as the compression engine and data rate used. THere is no reason why it world be any worse then now.
I'm not convinced that is the issue- I don't think we'll see the same problems on Freeview HD because it will be stat muxed, while the satelllite version will be stuck at too low a level. The BBC really need to come up with a sensible explanation as to why they are now wasting money on 6Mbps of bandwidth on satellite- I really hope the reason isn't as stupid as they are trying to make it equal with Freeview HD (which actually it won't be by my calculations)- as someone pointed out digital radio has higher bitrates on satellite than on freeview or DAB- so what is the problem the BBC HD on satellite having a higher bitrate? Of course it wouldn't be because of pressure from Freeview HD STB manufacturers who don't want to hear that HD channels on Freesat look better:rolleyes:...
I suspect that is the reason. THey are having to compress it down to unacctably poor levels so they can cram it onto Freeview
Well Monday 5ths "Criminal Justice" was the worst "HD" I've yet seen. There were crucial passages that were so blocky and unwatchable that I had to change to SD on BBC1 to see better.
I've been trying for months to get to post the BBC HD blogs but I never get the final verification email - but that now just seems to vent and get no reply.
Points of View is about to return, so I've emailed them and made a new complaint specifically citing Criminal Justice.
Well Monday 5ths "Criminal Justice" was the worst "HD" I've yet seen. There were crucial passages that were so blocky and unwatchable that I had to change to SD on BBC1 to see better.
I've been trying for months to get to post the BBC HD blogs but I never get the final verification email - but that now just seems to vent and get no reply.
Points of View is about to return, so I've emailed them and made a new complaint specifically citing Criminal Justice.
I would agree that the picture didn’t look like HD, but I didn’t have any trouble with blocking. Could your dish have become slightly out of alignment? All this rain can’t help!
I agree, it was awful. Occasionally the picture was in HD but then seemed to degrade when the background was dark or of an outside shot. I think it is down to dodgy camera work. Very disappointing, come on BBC get your act together!
Comments
But you are ignoring the fact that at very least 80% of the BBC programes are prerecorded so could be precompressed
Nothing to ignore, as they AREN'T pre-compressed - all broadcasters (apart from Luxe) compress live during broadcast.
Presumably there's a good reason for it?, particularly for channels Like Sky Movies HD, which would be even easier to pre-compress than BBC.
No they couldn't, and I'll explain why not.
Video needs to be constant quality to look acceptable, which means more bits spent on fast moving scenes, and less bits on static scenes. This results in a variable bit rate stream.
Broadcasting however needs a constant symbol rate for modulation onto a carrier frequency. This is one of the reasons for grouping several channels together onto a mux, and using statistical multiplexing techniques to distribute bitrate fairly between the channels to achieve a constant group rate.
The only way this could all be done 'in advance' (and it would have to be at least a day before) is if all the channels in the statmux group were pre-recorded material, with no interruptions (advert breaks, news flashes, technical problems etc.).
This is impractical since, even if all the BBC channels were grouped together (no commercials) they would still have to allow for unexpected events, news flashes, last minute schedule changes etc. Indeed, alot of BBC programmes are indeed live anyway (for example 10 o'clock news, bbc breakfast, formula1, etc).
In the real world, things are a lot more complicated than your simplistic explanations.
Going back a LONG time now, the only two regular live programmes on BBC (ignoring news obviously) were Tomorrows World and Blue Peter.
This came to light when a particular top of the range Sony Betamax VCR wouldn't record those two specific programmes - all other programmes, both BBC and ITV, icluding live news programmes, recorded perfectly.
Back then we had plenty of contacts inside the BBC, including various technical guys - and when we asked them about it they all instantly said that they were the only live broadcasts.
I can't remember how it was resolved now (it's so long ago), but either the BBC cured whatever was causing the problem, or Sony brought out a modification for the VCR.
Precompressing data has nothing at all to the data rate. So your argument is totally ireelevent.
Whether dats is compressed or not it is data. The datacan be tranmitted at the same data rate wether it is compressed or not. The network know's no different. It's just data.
What are you on about?, precompressing the data allows a much smaller data rate whilst maintaining the quality - as Luxe prove.
So it's entirely relevent.
I don't see why in viewing terms switching from pre-compressed to live feed would need anything more than the displaying of one of the BBC's animated logos to smooth the fade in and out of pre-compressed vs live behind the scenes. So pre-compressed programme ends, BBC animated channel logo comes on and plays. New source selected behind scenes. Live feed starts at end of logo.
Yes, but the pre-compressed one would be good quality (like Luxe) and the live compressed one would be FAR worse than the current poor quality on BBC HD.
So they aren't 'un-related', they are entirely dependent on each other.
You could do it that way, yes, its just that its not usually the best use of the available bandwidth, and that is what broadcasters are after.
The problem is that the live channels (such as sports) may need a lot of bits when there is fast action, but this need is bursty and unpredictable. Other times the sports channels bit rate requirements may be low (during lulls in the action, or during half-time discussion for example).
If the non-live channels (such as movies) were pre-compressed, they would need to limit their peak bitrate just in case the peak bitrate demand of the sports channels coincided with the peak of the movie channel.
This would lead to inefficient use of bandwidth when the difficult (peak) part of the movie coincided with the easy part of the sports - movie could have been coded with more quality at that point.
On the other hand, if the live sports channel had a very difficult part of the action to code, then even more bits could have been taken from the movie channel and allocated to the sports channel than was actually used, if the movie scene was easy to code at that point.
One solution could have been to encode the movie channel at a constant bitrate (CBR). But we know that leads to poor quality at fast-moving scenes, and quality that is too good in easy scenes (i.e. could have used less bits without the viewer noticing artefacts).
The other thing to consider is commercial considerations. Broadcasters generally make more money from live channels such as sports, and they really don't want the quality to suffer on those if they can help it. Borrowing bits from the easier-to-code channels (but only when they need to) is the way this is achieved.
It is a delicate balancing act, and making statmux fully live is generally a more efficient use of bandwidth overall than if the bitrate of some channels is already fixed.
The main problem I was trying to get across with offline pre-compression as opposed to live compression is, once the offline coding has been done, the bitrate cannot be changed. This is a problem if you want constant video quality across a group of channels (some of which will be carrying live content), and you also want to make the most efficient use of the limited bandwidth available.
But we are talking about transmited data. Its just data. You can transfer data. You are also confused between data rate and bandwidth. THey are not the same
The bitrate can be changed but the bandwidth will be coonstant. Precompressing saves them Bandwdth. Yes live dats will have a more variable bandwidth requirement and it will be pretty random. Yes the BBC could try agregating the channel to try to smooth it out but its unlikely to work well.
What I suspect is that this is all about try to cram HD into the inedequate amount of Bandwidth available on Terrestrial. It is always going to need serious compremises made unless and that what we are seeing on Freesat. The bandwidth the BBC are using is just not adequate but to get it on terrestrial they will have to squeeze it even further
If we are going to have HD it need to be HD and not something thats little better then SD.
Personally I think they should drop the idea of HD on terrestrial. THe bandwith is not there to do it justice. They could then tranmit proper HD on Freesat.
They have been putting out all sort of claims for HD. such as they will have rebuild sets etc because on HD you would see they are fake. Well not with what the BBC are cuurently puting out. No one would notice
Do you know what is the right recommended level currently then, and can you point me to it?
I'm referring to a document from March 2009 on the EBU site.
here: (see pages 17-18)
http://tech.ebu.ch/docs/events/abu09/abu_digital_broadcasting_symposium09_kouadio.pdf
It says 12-14mbps is the requirement for 1080i. BBC HD is now at 9.7.
It strikes me that things wont have changed that much in 6 months?
Or the BBC could just stop buying sub-optimal Thomson encoders and move to a better manufacturer?:rolleyes:
They are not the 'same' but they ARE directly (and exactly) related to each other - higher data rate, higher bandwidth required.
The only person confused in this thread appears to be you?.
But statmuxed at 720p, 8 - 10 mbps is stated. As I prefer 720p/50fr to 1080i/25fr, I'd be delighted if the BBC switched to that and dropped the horrible interlaced broadcast format they currently use. Seems to me that this would be the sensible thing to do until 1080p/50 fr is available.
The live compressed once would be as good as the compression engine and data rate used. THere is no reason why it world be any worse then now.
I suspect that is the reason. THey are having to compress it down to unacctably poor levels so they can cram it onto Freeview
I've been trying for months to get to post the BBC HD blogs but I never get the final verification email - but that now just seems to vent and get no reply.
Points of View is about to return, so I've emailed them and made a new complaint specifically citing Criminal Justice.
I would agree that the picture didn’t look like HD, but I didn’t have any trouble with blocking. Could your dish have become slightly out of alignment? All this rain can’t help!