NG
200Mbs for 8 cameras via low latency codecs doesn't sound great. That would be 25Mbs per camera - which is a bit on the low side unless you use Long GOP encoding, which will add a lot of latency. Or is the 2x100Mbs figure separate to the 8 camera circuits?
The BBC trialled 100Mbs PER CAMERA AVC Intra stuff for IP production, and I think SVT and NRK used similarly high bitrates for their London 2012 studios, which had individual cameras, and reverse vision feeds, fibred back to Stockholm and Oslo where the shows were cut. NBC use similar techniques for their Olympic Today Show broadcasts - and have done since at least Beijing 2008.
I'm not sure about the specifics. The article mentioned that they used dual 100Mbps pipes that were used for everything on their network. From the viewing perspective the cameras look compatible to the main studio feed when they do cross talks. One company, VideoLink*, uses the same camera as the the bureau requires a 10 Mbps connection to send the HD video back and their picture quality is pretty good - but CNBC's is better. So I don't think 15-20 Mbps is that far off especially when ENG and bonded cellular use the same rates.
There's a VERY big difference between the quality that is acceptable for actuality reports and that which you can put up with for long periods of time for main studio cameras. Bonded cellular circuits are almost always using Long GOP codecs so add seconds of latency. If you want lower latency you reduce the picture quality or increase the bitrate...
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain. You are usually broadcasting at a low bitrate using a LongGOP codec (H264 in the UK, MPEG2 on US OTA/Cable and H264/MPEG4 on satellite and some newer cable systems), often distributing at a mezzanine rate, and acquiring and post producing at a higher bitrate. The old rule of thumb was that the upstream bitrate should be twice the downstream - on a like-for-like basis (MPEG2 needs about twice H264, and LongGOP about half-Intra, but will have higher latency)
I thought for the Olympics NBC sent back the less prominent sports and had them produced back in Stamford (previous Studio 8H @ 30 Rock). Today and Nightly News had their own control room in Sochi and London.
Anyway sorry for getting off topic.
No - Today was cut at Rockefeller Plaza both for 2008 and 2012. Cameras were fibred back individually. I have colleagues who worked alongside the Today team on both shows. The only place the finished camera cut existed was New York...
noggin
Founding member
200Mbs for 8 cameras via low latency codecs doesn't sound great. That would be 25Mbs per camera - which is a bit on the low side unless you use Long GOP encoding, which will add a lot of latency. Or is the 2x100Mbs figure separate to the 8 camera circuits?
The BBC trialled 100Mbs PER CAMERA AVC Intra stuff for IP production, and I think SVT and NRK used similarly high bitrates for their London 2012 studios, which had individual cameras, and reverse vision feeds, fibred back to Stockholm and Oslo where the shows were cut. NBC use similar techniques for their Olympic Today Show broadcasts - and have done since at least Beijing 2008.
I'm not sure about the specifics. The article mentioned that they used dual 100Mbps pipes that were used for everything on their network. From the viewing perspective the cameras look compatible to the main studio feed when they do cross talks. One company, VideoLink*, uses the same camera as the the bureau requires a 10 Mbps connection to send the HD video back and their picture quality is pretty good - but CNBC's is better. So I don't think 15-20 Mbps is that far off especially when ENG and bonded cellular use the same rates.
There's a VERY big difference between the quality that is acceptable for actuality reports and that which you can put up with for long periods of time for main studio cameras. Bonded cellular circuits are almost always using Long GOP codecs so add seconds of latency. If you want lower latency you reduce the picture quality or increase the bitrate...
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain. You are usually broadcasting at a low bitrate using a LongGOP codec (H264 in the UK, MPEG2 on US OTA/Cable and H264/MPEG4 on satellite and some newer cable systems), often distributing at a mezzanine rate, and acquiring and post producing at a higher bitrate. The old rule of thumb was that the upstream bitrate should be twice the downstream - on a like-for-like basis (MPEG2 needs about twice H264, and LongGOP about half-Intra, but will have higher latency)
Quote:
I thought for the Olympics NBC sent back the less prominent sports and had them produced back in Stamford (previous Studio 8H @ 30 Rock). Today and Nightly News had their own control room in Sochi and London.
Anyway sorry for getting off topic.
No - Today was cut at Rockefeller Plaza both for 2008 and 2012. Cameras were fibred back individually. I have colleagues who worked alongside the Today team on both shows. The only place the finished camera cut existed was New York...
Last edited by noggin on 14 August 2015 9:49am
RK
200Mbs for 8 cameras via low latency codecs doesn't sound great. That would be 25Mbs per camera - which is a bit on the low side unless you use Long GOP encoding, which will add a lot of latency. Or is the 2x100Mbs figure separate to the 8 camera circuits?
The BBC trialled 100Mbs PER CAMERA AVC Intra stuff for IP production, and I think SVT and NRK used similarly high bitrates for their London 2012 studios, which had individual cameras, and reverse vision feeds, fibred back to Stockholm and Oslo where the shows were cut. NBC use similar techniques for their Olympic Today Show broadcasts - and have done since at least Beijing 2008.
I'm not sure about the specifics. The article mentioned that they used dual 100Mbps pipes that were used for everything on their network. From the viewing perspective the cameras look compatible to the main studio feed when they do cross talks. One company, VideoLink*, uses the same camera as the the bureau requires a 10 Mbps connection to send the HD video back and their picture quality is pretty good - but CNBC's is better. So I don't think 15-20 Mbps is that far off especially when ENG and bonded cellular use the same rates.
There's a VERY big difference between the quality that is acceptable for actuality reports and that which you can put up with for long periods of time for main studio cameras. Bonded cellular circuits are almost always using Long GOP codecs so add seconds of latency. If you want lower latency you reduce the picture quality or increase the bitrate...
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain. You are usually broadcasting at a low bitrate using a LongGOP codec (H264 in the UK, MPEG2 on US OTA/Cable and H264/MPEG4 on satellite and some newer cable systems), often distributing at a mezzanine rate, and acquiring and post producing at a higher bitrate. The old rule of thumb was that the upstream bitrate should be twice the downstream - on a like-for-like basis (MPEG2 needs about twice H264, and LongGOP about half-Intra, but will have higher latency)
I thought for the Olympics NBC sent back the less prominent sports and had them produced back in Stamford (previous Studio 8H @ 30 Rock). Today and Nightly News had their own control room in Sochi and London.
Anyway sorry for getting off topic.
No - Today was cut at Rockefeller Plaza both for 2008 and 2012. Cameras were fibred back individually. I have colleagues who worked alongside the Today team on both shows. The only place the finished camera cut existed was New York...
Thank you for your input.
I clearly have a lot more to learn. I'm learning this from an engineering system point of view.
200Mbs for 8 cameras via low latency codecs doesn't sound great. That would be 25Mbs per camera - which is a bit on the low side unless you use Long GOP encoding, which will add a lot of latency. Or is the 2x100Mbs figure separate to the 8 camera circuits?
The BBC trialled 100Mbs PER CAMERA AVC Intra stuff for IP production, and I think SVT and NRK used similarly high bitrates for their London 2012 studios, which had individual cameras, and reverse vision feeds, fibred back to Stockholm and Oslo where the shows were cut. NBC use similar techniques for their Olympic Today Show broadcasts - and have done since at least Beijing 2008.
I'm not sure about the specifics. The article mentioned that they used dual 100Mbps pipes that were used for everything on their network. From the viewing perspective the cameras look compatible to the main studio feed when they do cross talks. One company, VideoLink*, uses the same camera as the the bureau requires a 10 Mbps connection to send the HD video back and their picture quality is pretty good - but CNBC's is better. So I don't think 15-20 Mbps is that far off especially when ENG and bonded cellular use the same rates.
There's a VERY big difference between the quality that is acceptable for actuality reports and that which you can put up with for long periods of time for main studio cameras. Bonded cellular circuits are almost always using Long GOP codecs so add seconds of latency. If you want lower latency you reduce the picture quality or increase the bitrate...
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain. You are usually broadcasting at a low bitrate using a LongGOP codec (H264 in the UK, MPEG2 on US OTA/Cable and H264/MPEG4 on satellite and some newer cable systems), often distributing at a mezzanine rate, and acquiring and post producing at a higher bitrate. The old rule of thumb was that the upstream bitrate should be twice the downstream - on a like-for-like basis (MPEG2 needs about twice H264, and LongGOP about half-Intra, but will have higher latency)
Quote:
I thought for the Olympics NBC sent back the less prominent sports and had them produced back in Stamford (previous Studio 8H @ 30 Rock). Today and Nightly News had their own control room in Sochi and London.
Anyway sorry for getting off topic.
No - Today was cut at Rockefeller Plaza both for 2008 and 2012. Cameras were fibred back individually. I have colleagues who worked alongside the Today team on both shows. The only place the finished camera cut existed was New York...
Thank you for your input.
I clearly have a lot more to learn. I'm learning this from an engineering system point of view.
DE
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain.
Out of interest, what bitrate and latency do you think that the Newsday/ABR feed runs at?
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain.
Out of interest, what bitrate and latency do you think that the Newsday/ABR feed runs at?
NG
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain.
Out of interest, what bitrate and latency do you think that the Newsday/ABR feed runs at?
No idea. The Newsday/ABR studio is pretty undemanding content (no whizzing handhelds or jibs) - and as it is news I suspect it may be a bit less than non-News shows are supposed to use?
Would hope latency was less than 2" after a single encode/decode cycle if LongGOP is being used. LongGOP IP links I've used recently have been around 1.5" end-to-end (including talkback latency)
As it is a studio feed rather than individual camera feeds, a bit of latency is likely to be OK. (If you are fibreing multiple cameras to a remote location, you want low latency so that you can direct them remotely without delay)
On the other hand it could be using a nice, low-latency, Intra coding scheme like JPEG2000 or AVCi 100 just for fun
I know that JPEG2000 over MPLS fibre is popular in Scandinavia for OBs from fibre venues.
noggin
Founding member
You can't compare bitrates between circuits of different latencies. For instance the BBC's lowest bitrate for shooting LongGOP is currently 50Mbs (News are allowed to go to 35Mbs), with Intra at 100Mbs. This is because you have to allow for concatenation in your programme chain.
Out of interest, what bitrate and latency do you think that the Newsday/ABR feed runs at?
No idea. The Newsday/ABR studio is pretty undemanding content (no whizzing handhelds or jibs) - and as it is news I suspect it may be a bit less than non-News shows are supposed to use?
Would hope latency was less than 2" after a single encode/decode cycle if LongGOP is being used. LongGOP IP links I've used recently have been around 1.5" end-to-end (including talkback latency)
As it is a studio feed rather than individual camera feeds, a bit of latency is likely to be OK. (If you are fibreing multiple cameras to a remote location, you want low latency so that you can direct them remotely without delay)
On the other hand it could be using a nice, low-latency, Intra coding scheme like JPEG2000 or AVCi 100 just for fun
I know that JPEG2000 over MPLS fibre is popular in Scandinavia for OBs from fibre venues.
DE
While the studio isn't too strenous, packages are played out for ABR, with lower thirds overlayed, and you also get the "Hiroshima-London-Singapore-London" lives when Rico interviews. The main feed is a 20Mbit Vivx circuit with an Atem encoder, longgop h264. Latency appears from the SG end to be about 19 frames on the NTT and OBE kit (OBE seems to be about 1-3 frames faster), and about 25 frames on the Atem -- the Atem/Vyvx is more reliable though. Reverse comms is about 4 frames. This is significantly better than the old shaw tower line.
Talkback latency is fairly low, tricky to know for certain without spending some time measuring, but it's about 4 frames in Singapore's case (with most of it being network latency)
For what it's worth, it takes 20.5 seconds from a cut happening on the Singapore vision mixer to the same cut happening on the Starhub IP based CATV box. That's a transmission "buffer" of 500 frames, or 1 billion pixels, or 2.5GB (obviously with compression and resizing to 1440x1080 it's not lossless!)
BBC bureaus typically feed in over the internet from a combination of NTT HVE9100s (about 5 years old, we don't buy them any more), MVE5000s (a bit newer, and cheaper) and OBEs (best of both worlds). The main exceptions are Washington (a mix of NTT9100 and Vyvx), Moscow (ATM and some shockingly old coder), Beijing and Rio (Vyvx) and Singapore (Vyvx/9100). Bitrates range from 1.5mbit SD to 30Mbit HD, with a median about 6Mbit. These are talking heads though, only Singapore and Washington feed anything more complex.
Bitrates may seem low, but a typical package that's fed in via a store-and-forward method tends to come out at 5-6mbit - in HD (we use a constant-quality metric to determine bitrate, so it can vary -- bars compresses to 100kbit/second, but low-level night shots or shots of running water and trees takes far more. I dislike the EBU's dancing woods for this very reason, and when we determined the settings needed in the real world for HD we used a sample of real packages and drew pretty graphs before going "about there". News is a bit different to the rest of the world
Latency on the encode/decode side is about 12 frames regardless of bitrate, however FEC adds a lot on top of that -- in low bitrates cases latency can be up in the 45 frame area! Recently I've been testing two features of OBE -- sending traffic into two separate ISPs and routing to the same decoder, and sending traffic into one ISP, but sending it twice, and timeshifting by a couple of frames (to get over "bumps" when ISPs drop all traffic for x ms, rather than x packets), which has the benefit of increasing stability and decreasing latency in the real world. Decoders tend to get upset though.
I miss the analog world, when you had an 8MHz signal, and that was it. Until you compressed it to under 2Mhz for your LP VHS recordings!
Talkback latency is fairly low, tricky to know for certain without spending some time measuring, but it's about 4 frames in Singapore's case (with most of it being network latency)
For what it's worth, it takes 20.5 seconds from a cut happening on the Singapore vision mixer to the same cut happening on the Starhub IP based CATV box. That's a transmission "buffer" of 500 frames, or 1 billion pixels, or 2.5GB (obviously with compression and resizing to 1440x1080 it's not lossless!)
BBC bureaus typically feed in over the internet from a combination of NTT HVE9100s (about 5 years old, we don't buy them any more), MVE5000s (a bit newer, and cheaper) and OBEs (best of both worlds). The main exceptions are Washington (a mix of NTT9100 and Vyvx), Moscow (ATM and some shockingly old coder), Beijing and Rio (Vyvx) and Singapore (Vyvx/9100). Bitrates range from 1.5mbit SD to 30Mbit HD, with a median about 6Mbit. These are talking heads though, only Singapore and Washington feed anything more complex.
Bitrates may seem low, but a typical package that's fed in via a store-and-forward method tends to come out at 5-6mbit - in HD (we use a constant-quality metric to determine bitrate, so it can vary -- bars compresses to 100kbit/second, but low-level night shots or shots of running water and trees takes far more. I dislike the EBU's dancing woods for this very reason, and when we determined the settings needed in the real world for HD we used a sample of real packages and drew pretty graphs before going "about there". News is a bit different to the rest of the world
Latency on the encode/decode side is about 12 frames regardless of bitrate, however FEC adds a lot on top of that -- in low bitrates cases latency can be up in the 45 frame area! Recently I've been testing two features of OBE -- sending traffic into two separate ISPs and routing to the same decoder, and sending traffic into one ISP, but sending it twice, and timeshifting by a couple of frames (to get over "bumps" when ISPs drop all traffic for x ms, rather than x packets), which has the benefit of increasing stability and decreasing latency in the real world. Decoders tend to get upset though.
I miss the analog world, when you had an 8MHz signal, and that was it. Until you compressed it to under 2Mhz for your LP VHS recordings!
RK
I take it the Starhub your referring to is the consumer MVPD - so it takes about 20 seconds for the feed to get to London and back to Singapore?
Also out of curiosity why 1440x1080?
While the studio isn't too strenous, packages are played out for ABR, with lower thirds overlayed, and you also get the "Hiroshima-London-Singapore-London" lives when Rico interviews. The main feed is a 20Mbit Vivx circuit with an Atem encoder, longgop h264. Latency appears from the SG end to be about 19 frames on the NTT and OBE kit (OBE seems to be about 1-3 frames faster), and about 25 frames on the Atem -- the Atem/Vyvx is more reliable though. Reverse comms is about 4 frames. This is significantly better than the old shaw tower line.
Talkback latency is fairly low, tricky to know for certain without spending some time measuring, but it's about 4 frames in Singapore's case (with most of it being network latency)
For what it's worth, it takes 20.5 seconds from a cut happening on the Singapore vision mixer to the same cut happening on the Starhub IP based CATV box. That's a transmission "buffer" of 500 frames, or 1 billion pixels, or 2.5GB (obviously with compression and resizing to 1440x1080 it's not lossless!)
BBC bureaus typically feed in over the internet from a combination of NTT HVE9100s (about 5 years old, we don't buy them any more), MVE5000s (a bit newer, and cheaper) and OBEs (best of both worlds). The main exceptions are Washington (a mix of NTT9100 and Vyvx), Moscow (ATM and some shockingly old coder), Beijing and Rio (Vyvx) and Singapore (Vyvx/9100). Bitrates range from 1.5mbit SD to 30Mbit HD, with a median about 6Mbit. These are talking heads though, only Singapore and Washington feed anything more complex.
Bitrates may seem low, but a typical package that's fed in via a store-and-forward method tends to come out at 5-6mbit - in HD (we use a constant-quality metric to determine bitrate, so it can vary -- bars compresses to 100kbit/second, but low-level night shots or shots of running water and trees takes far more. I dislike the EBU's dancing woods for this very reason, and when we determined the settings needed in the real world for HD we used a sample of real packages and drew pretty graphs before going "about there". News is a bit different to the rest of the world
Latency on the encode/decode side is about 12 frames regardless of bitrate, however FEC adds a lot on top of that -- in low bitrates cases latency can be up in the 45 frame area! Recently I've been testing two features of OBE -- sending traffic into two separate ISPs and routing to the same decoder, and sending traffic into one ISP, but sending it twice, and timeshifting by a couple of frames (to get over "bumps" when ISPs drop all traffic for x ms, rather than x packets), which has the benefit of increasing stability and decreasing latency in the real world. Decoders tend to get upset though.
I miss the analog world, when you had an 8MHz signal, and that was it. Until you compressed it to under 2Mhz for your LP VHS recordings!
Talkback latency is fairly low, tricky to know for certain without spending some time measuring, but it's about 4 frames in Singapore's case (with most of it being network latency)
For what it's worth, it takes 20.5 seconds from a cut happening on the Singapore vision mixer to the same cut happening on the Starhub IP based CATV box. That's a transmission "buffer" of 500 frames, or 1 billion pixels, or 2.5GB (obviously with compression and resizing to 1440x1080 it's not lossless!)
BBC bureaus typically feed in over the internet from a combination of NTT HVE9100s (about 5 years old, we don't buy them any more), MVE5000s (a bit newer, and cheaper) and OBEs (best of both worlds). The main exceptions are Washington (a mix of NTT9100 and Vyvx), Moscow (ATM and some shockingly old coder), Beijing and Rio (Vyvx) and Singapore (Vyvx/9100). Bitrates range from 1.5mbit SD to 30Mbit HD, with a median about 6Mbit. These are talking heads though, only Singapore and Washington feed anything more complex.
Bitrates may seem low, but a typical package that's fed in via a store-and-forward method tends to come out at 5-6mbit - in HD (we use a constant-quality metric to determine bitrate, so it can vary -- bars compresses to 100kbit/second, but low-level night shots or shots of running water and trees takes far more. I dislike the EBU's dancing woods for this very reason, and when we determined the settings needed in the real world for HD we used a sample of real packages and drew pretty graphs before going "about there". News is a bit different to the rest of the world
Latency on the encode/decode side is about 12 frames regardless of bitrate, however FEC adds a lot on top of that -- in low bitrates cases latency can be up in the 45 frame area! Recently I've been testing two features of OBE -- sending traffic into two separate ISPs and routing to the same decoder, and sending traffic into one ISP, but sending it twice, and timeshifting by a couple of frames (to get over "bumps" when ISPs drop all traffic for x ms, rather than x packets), which has the benefit of increasing stability and decreasing latency in the real world. Decoders tend to get upset though.
I miss the analog world, when you had an 8MHz signal, and that was it. Until you compressed it to under 2Mhz for your LP VHS recordings!
I take it the Starhub your referring to is the consumer MVPD - so it takes about 20 seconds for the feed to get to London and back to Singapore?
Also out of curiosity why 1440x1080?
NG
Also out of curiosity why 1440x1080?
1440x1080 was used quite extensively in the early days of UK HD broadcasting, and was used by BBC HD channels until they started 3D trials. This was mainly because the main acquisition and delivery formats at the time were HD Cam and DVC Pro HD - both of which use 1440x1080 subsampling (in 50Hz - DVC Pro HD drops to 1280x1080 at 60Hz) Now the main delivery format for shows is either HD Cam SR or AVC Intra 100Mbs file - both of which are 1920x1080, and there are myriad acquisition codecs, but most of them are 1920x1080 (or higher)
BBC News is still using DVC Pro HD as its main in-house codec in W1, so all pre-recorded HD material that has been via the main Quantel servers will, I believe, be 1440x1080 subsampled. So that could be one reason (though the studio live content will still be 1920x1080)
Another issue is that many 3rd-party satellite operators will re-compress 1920x1080 feeds they receive to 1440x1080 or 1280x1080 to reduce the bandwidth required to broadcast them. (Many of the US satellite operators do this too...)
noggin
Founding member
Also out of curiosity why 1440x1080?
1440x1080 was used quite extensively in the early days of UK HD broadcasting, and was used by BBC HD channels until they started 3D trials. This was mainly because the main acquisition and delivery formats at the time were HD Cam and DVC Pro HD - both of which use 1440x1080 subsampling (in 50Hz - DVC Pro HD drops to 1280x1080 at 60Hz) Now the main delivery format for shows is either HD Cam SR or AVC Intra 100Mbs file - both of which are 1920x1080, and there are myriad acquisition codecs, but most of them are 1920x1080 (or higher)
BBC News is still using DVC Pro HD as its main in-house codec in W1, so all pre-recorded HD material that has been via the main Quantel servers will, I believe, be 1440x1080 subsampled. So that could be one reason (though the studio live content will still be 1920x1080)
Another issue is that many 3rd-party satellite operators will re-compress 1920x1080 feeds they receive to 1440x1080 or 1280x1080 to reduce the bandwidth required to broadcast them. (Many of the US satellite operators do this too...)
SC
scottishtv
Founding member
Hate to become a serial complainer, but I don't know why this London shot is always used to introduce reports - often with no over-the-shoulder graphics in use. Why can't it be centred?
Indeed, as soon as Newsday is over, Babita does a 'Here's our top UK headline for you' and intro into ABR. They use this much better shot - just seconds after Newsday has finished:
Maybe it's a Newsday house style or something. As you can tell, it bugs me a bit.
Indeed, as soon as Newsday is over, Babita does a 'Here's our top UK headline for you' and intro into ABR. They use this much better shot - just seconds after Newsday has finished:
Maybe it's a Newsday house style or something. As you can tell, it bugs me a bit.
IL
Someone mentioned that we're getting less of Rico's catchphrase "That's right Babita", we seem to be getting it on the paper review and a few times when we get a crossover story between the two cities. Something I liked about the old graphics, it allowed a story to be told from both places without much fuss as the two screens are there already and no need to switch backwards and forwards between the cities.
Someone also mentioned Babita took the lead on the blasts in China, not surprising really as she is very good at it, especially after seeing her during the day recently. Singapore is only a satellite bureau, the main operation is London and everything has to go through there so makes sense to have breaking news and contacts with experts or correspondents from London and Singapore can ask questions if they need to (which I have seen happen on a few occasions).
I think before the opening titles there should be a time check from London. Anyone notice how Rico seems to do s lot of the news reading now and Babita tends to only give a summary of other stories now? Also is the desk in Sinagpore a bit of a waste of space now as they've switched to standing up for the programmes? Not seen them sit down much!
Someone also mentioned Babita took the lead on the blasts in China, not surprising really as she is very good at it, especially after seeing her during the day recently. Singapore is only a satellite bureau, the main operation is London and everything has to go through there so makes sense to have breaking news and contacts with experts or correspondents from London and Singapore can ask questions if they need to (which I have seen happen on a few occasions).
I think before the opening titles there should be a time check from London. Anyone notice how Rico seems to do s lot of the news reading now and Babita tends to only give a summary of other stories now? Also is the desk in Sinagpore a bit of a waste of space now as they've switched to standing up for the programmes? Not seen them sit down much!
