BBC London TV News

Yes, although it looks like a dead end corridor so probably not that wierd. Mind you, MHS has a corridor going right past the TV studio and at one point had office desks in the TV studio area, it's probably radio's turn

No Studio Managers in local radio of course, that's where the producer and broadcast assistants/phone operators sit

It might be that they'll be in that wing but a seperate newsroom. If not, I wonder how much integration of systems there'll be between London, Persia, Arabic and the main newsroom, it was always very difficult for London to access 'network' material and archive

I think the plan is that everything uses the same systems where possible in the new BH. Already a replacement audio playout system has been chosen to roll out across WS and network radio, and I would expect the same selection process is underway for video playout.


I know what you mean, but this was also a two way problem for WS. While we could pull content out of Jupiter fairly easily we had no way of ingesting it from BU, so it would involve sending the tapes across to SCAR or copying a huge DV file across Reith and crossing your fingers.

Though that particular limitation disappeared a while ago - anyone in the BBC (non-News in London, nations, regions, international bureaux etc.) can access broadcast quality news video on the London network news Jupiter system from their desktop these days. The bureaux around the world can now drop in archive and agency pictures available in London into their local edits using this system - reducing the number of packages fed with black holes that need re-editing in London after they've fed (or FTPed). (Though you need a fast enough network connection to download DV25 content - which is quite high bandwith)

Is DV25 considered "broadcast quality" in respect of news pictures then?

It's pretty much considered SD broadcast quality across the board these days - not just in News... (And it usually outperforms IB MPEG2 18Mbs Beta SX pretty effectively (which is what the BBC use for news in the nations)

Given that the DV25 formats DVCam or DVCPro are the standard ENG formats used by all UK news broadcasters (Sky, BBC network and English regions, ITN - though Sky are switching to XDCam EX I believe), and also the standard format used by most non-HD factual stuff these days, it kind of is. The bigger quality issue is the camera end - not the recording format. Z1s are in widespread use (shooting DV25 not HDV25) - but you can still tell them - but the decent DSRs are pretty good if properly set-up.

You wouldn't use it for high-end drama (though Doctors started out shooting with two DV25 camcorders ISTR before switching to DigiBeta, and now an HD format - not sure if DVCProHD 100 or HDCam) - though most single-camera drama is HD or Super 16 these days anyway...

You can shoot DV25 onto P2 and XDCam EX flash cards as well these days - it doesn't have to be tape...

DigiBeta has sort of died a death as an acquisition format in most SD areas - DV is deemed good enough for most situations, apart from the obvious (like shooting for Chroma key)
AIUI the Jupiter system doesn't keep DV25 native though - everything goes via SDI baseband in and out (apart from file transfer stuff?) and is compressed at MPEG2 33Mbs on-disc...

Things have moved on then, when I was at the BBC we could see Jupiter very slowly (and only on a PC running Windows 2000!) and we couldn't do anything with it other than persuade them to feed the stuff over in real time.

Didn't know there was SDI ingest and playout, although thinking about it there must be some way that SCAR gets the content in and SDI capture is the best way to do it.

I'm surprised about Jupiter not being DV native though. One of the great advantages of DV is that all the editing packages handle it natively and will cut/splice the raw bitstream without needing to decode/encode the footage, unless frames need to be rerendered due to a transition or burning in a graphic. So the bytes being read off the disk on the playout server are the same bytes that were laid down on tape in the camera. This is why DV does not degrade at every step, because it's not being decoded and re-encoded all the time, so maintains its original quality.

I think that most of the ingest and outgest ports are SDI - with only file-based possibly stuff going in differently (and being transcoded to 33Mbs MPEG2?). The Jupiter record/replay ports are, AIUI, just sources and destinations on a big SDI router, so any source on the router can be recorded on Jupiter, and any destination on the router can be fed from Jupiter. Given that relatively little material actually gets into the system from a physical tape, there aren't that many DV-native sources so going down the DV-native route would be tricky.

SNG trucks use sub-DV data rates (though they use long GOP MPEG2, and increasingly H264, for greater compression), and the main BBC internal lines infrastructure between regions and nations and London is now uncompressed SDI.

If you were feeding a DV tape from a sat truck you'd not be able to feed it DV Native without increasing your satellite budget hugely (I think News SNG trucks work at around 8Mbs or less MPEG2, and maybe <5Mbs with H264) Similarly feeding a DV tape from a DV machine in a nation or region would require SDTI (DV native over SDI) connectivity - which would make monitoring circuits a pain...



The downside is that if you are recording incoming feeds, DV25 is not really the best use of bitrate, and definitely to be avoided for multi-generation stuff, and you can't guarantee that you won't go down generations in a News environment. You can achieve significantly greater picture quality by using a longer GOP compression scheme, particularly if you aren't doing huge amounts of re-editing. If you are recording higher quality stuff (like turning around studio items to repeat) 33Mbs MPEG2 can be majorly better quality than DV25, and can stay native within the editing infrastructure too, apart from de- and re-coding at non-GOP edit points.

DV Native is great if you have a simple workflow :

DV25 rushes ingested locally (or pulled in off flash or hard drive increasingly), edited DV native, and dumped back to DV25 tape for playout. This may well be how edits happen in the field with News, where you have just a few DVCam tapes as sources, and a Firewire DV25 connected laptop running FCP or the Quantel DV field-software. This is likely to cease being DV25 native though as it will either be fed back via MPEG2/H264 SNG links, or store and forwarded in MPEG2 (or H264) and fed via satphone or broadband.

However if you have to mix and match between uncompressed SDI, native DV25 available locally, DV25 delivered SDI, MPEG2/H264 compressed SNG etc., then re-encoding the non-native DV25 stuff to DV25 is not a great solution, and there are better ones. This is much more likely to be the case with London stuff.

Ah. Davina lets you browse what video content is on Jupiter, via a web interface, but doesn't let you actually use Jupiter itself. It will either automatically copy content to network shared drives, such as folders on networked Avids or FCPs, or will copy to a folder that you can then download from to a removable hard drive, USB stick etc. to get content into a standalone edit. It even includes some software 525/60 to 625/50 conversion so that edits in the US, Japan etc. can use UK 50Hz material on Jupiter in their 60Hz edits. (Though this does mean it has gone 50->60->50 by the time it is shown in the UK - whereas if it had been dropped in in London it would be just 50Hz clean)

Which pretty much all of WS is. Download the raw footage from the camera (usually a Z1 or a VX2000) or Jupiter, edit in FCP or Premier and apply branding, export in DVPAL, save in a Topcat dropzone folder, create a new media asset page in Topcat, import the edit from the dropzone, fill in the metadata and hit publish. Assuming Flipfactory, Delta and the FTP gates are behaving then the footage ends up on the internet. And it usually looks pretty good online too, even though you are talking a total compression of around 500:1 from the uncompresed video via DV through to the flash codec.

The workflow isn't much different for the studios in Bush. Editied package is saved into the Fork ingest dropzone and can then be published for playout by the Mediadecks, remaining in DV format all the way. Over at Egton I'm 99% sure the ATV and PTV Dalet playout systems are native DV, with Carbon Coder used to transcode to and from DV as required.

Any of the bureaux that handle video usually don't have enough enough bandwidth back to London to transfer DV in real time. This isn't a hugh issue though as the packages don't get usually go over 10 minutes long, with a 10 minute package taking 45 minutes to transfer back at most. Media transcoders are being rolled out to these offices too, so anything destined for the web gets transcoded and uploaded locally avoiding the need to send any footage back to London. This improved the publishing time in one office recently by a factor of 10.

This must be the most jargon-filled thread in the world. I have no idea what's going on. Haha