5 ms·

One of the sibling articles explains that part of the project involves trying to cut labor costs on covering massively multi-sited events: https://www.bbc.co.u

One of the sibling articles explains that part of the project involves trying to cut labor costs on covering massively multi-sited events: https://www.bbc.co.uk/rd/projects/nearly-live-production https://www.bbc.co.uk/rd/projects/nearly-live-production The idea is explicitly that you would run the equivalent of a TV control room on a web app that knows how to switch between video feeds (potentially from fixed cameras without human operators) and then can output video to... whoever is your audience. The "moving window" of near-live editorial decisions is pretty interesting as well, and seems geared towards giving non-professional editors a chance to fix mistakes.

decasia 8y ago
relevant TLDR: "Professional, live, multi-camera coverage isn’t practical for all events or venues at a large festival. For our research at Edinburgh Fringe Festival 2015, we experimented with placing three unmanned, static, ultra high definition cameras and two unmanned, static, high definition GoPro cameras around the circumference of the BBC venue. A lightweight video capture rig of this kind, delivering images to a cloud system, could allow a director to crop and cut between these shots in software, over the web and produce good quality coverage ‘nearly live’ at reduced cost."
- deleted 8y ago
  [deleted]
stephen_g 8y ago
How does a web app know how to switch between video feeds, or cameras know where to point? Maybe we're talking about different kinds of events, but there's actually a lot of creativity that goes into camera framing, movement, shot selection, timing of cuts, etc. to end up with something that's actually interesting to watch...
- decasia 8y ago
  Yeah on your second point; I used to do a bit of TV broadcast stuff and it was a marvelous technical world/system of its own. And it seems obvious that the BBC's proposal here is in some sense much more lo-fi than that. I think their proposal was that you could give up on being able to do camera framing and movement, but you would still maintain the ability to cut between shots at aesthetically pleasing moments. I could just about imagine that producing good results, with a relatively predictable performance and a decent technical director. But I think a system like this doesn't compete with professional video production. It competes with someone making a shaky cellphone video in a small venue -- a form of video which a lot of people seem to accept, these days. I could see the BBC's proposal being a step up from that (and a lot cheaper than a mobile TV studio setup).
- birdman3131 8y ago
  The app is not choosing. The operator/director is choosing. The thing is that you give yourself a buffer before broadcasting. "The user can pause the action at any point in time and seek back through the session to fine tune edit decisions using a visual representation of the programme timeline. On resuming, the play-head seeks forward to the end of the timeline. This functionality is made possible by ensuring the time shift window (DVR window) of the camera feed is infinite so that all live footage is recorded and can be randomly accessed by seeking. Once the operator has established a sufficient buffer of edit decisions, they can begin broadcasting them. [...] A research goal is to investigate how big the window of time should be between the broadcast play head and edit play head to ensure the operator has enough time to perform edits without feeling rushed and whilst keeping the programme as close to a live broadcast as possible. We call this the ‘near-live window’"
  - petetttt 8y ago
    More on building similar web apps here [1] and on getting a computer to play director here [2] 1 - https://www.bbc.co.uk/rd/blog/2017-07-compositing-mixing-video-browser https://www.bbc.co.uk/rd/blog/2017-07-compositing-mixing-vid... 2 - https://www.bbc.co.uk/rd/projects/ai-production https://www.bbc.co.uk/rd/projects/ai-production
- M2Ys4U 8y ago
  >Maybe we're talking about different kinds of events, but there's actually a lot of creativity that goes into camera framing, movement, shot selection, timing of cuts, etc. to end up with something that's actually interesting to watch... BBC R&D also has a project that's using AI and machine learning to investigate automating that work: https://www.bbc.co.uk/rd/projects/ai-production https://www.bbc.co.uk/rd/projects/ai-production
- kvm000 8y ago
  My company is heavily involved in this area... there is a migration underway from baseband (https://en.wikipedia.org/wiki/Serial_digital_interface https://en.wikipedia.org/wiki/Serial_digital_interface) to fully IP based infrastructure for routing and signal flow. With IP, it's usually a software defined network model, along with some IGMP components for controlling video flow. So the clients (software or control panels) would send a request to the routing orchestration system to request a route to send multicast flows (SMPTE 2110, separate multicast for video, audio streams, ancillary data) from a source to a destination, same as with a baseband router. With IP, the orchestration layer also drives the receiving device to join the multicast explicitly if it isn't IGMP based. This is our SDN orchestration; https://evertz.com/solutions/magnum https://evertz.com/solutions/magnum (we're hiring!)
  - kierank 8y ago
    Your employer amongst other dinosaur hardware manufacturers is also making this a nightmare to implement in software because of the tiny packet burst requirements (40us). My team will spend thousands of man hours and our servers will waste huge amounts of energy because power-saving can't be turned off in order to hit these crazy requirements. In 40 years time we'll be still having to comply with this nonsense because some manufacturers didn't want to update their FPGA designs. It's like fractional frame rates all over again. This is really where the broadcast industry lost its collective mind.
    - kvm000 8y ago
      We also do full systems purely in software at large scale, such as this one; https://evertz.com/resources/press/Discovery-Cloud-Oct2017.PDF https://evertz.com/resources/press/Discovery-Cloud-Oct2017.P... ... fully virtualized in AWS, not just for OTT but also full linear cable/sat broadcast channels. There are valid use cases for both hardware solutions where appropriate, and software solutions for other use cases. There are many low latency use cases where crazy requirements are still actual requirements.
      - kierank 8y ago

decasia 8y ago

relevant TLDR: "Professional, live, multi-camera coverage isn’t practical for all events or venues at a large festival. For our research at Edinburgh Fringe Festival 2015, we experimented with placing three unmanned, static, ultra high definition cameras and two unmanned, static, high definition GoPro cameras around the circumference of the BBC venue. A lightweight video capture rig of this kind, delivering images to a cloud system, could allow a director to crop and cut between these shots in software, over the web and produce good quality coverage ‘nearly live’ at reduced cost."

deleted 8y ago
[deleted]

stephen_g 8y ago

How does a web app know how to switch between video feeds, or cameras know where to point? Maybe we're talking about different kinds of events, but there's actually a lot of creativity that goes into camera framing, movement, shot selection, timing of cuts, etc. to end up with something that's actually interesting to watch...

decasia 8y ago
Yeah on your second point; I used to do a bit of TV broadcast stuff and it was a marvelous technical world/system of its own. And it seems obvious that the BBC's proposal here is in some sense much more lo-fi than that. I think their proposal was that you could give up on being able to do camera framing and movement, but you would still maintain the ability to cut between shots at aesthetically pleasing moments. I could just about imagine that producing good results, with a relatively predictable performance and a decent technical director. But I think a system like this doesn't compete with professional video production. It competes with someone making a shaky cellphone video in a small venue -- a form of video which a lot of people seem to accept, these days. I could see the BBC's proposal being a step up from that (and a lot cheaper than a mobile TV studio setup).
birdman3131 8y ago
The app is not choosing. The operator/director is choosing. The thing is that you give yourself a buffer before broadcasting. "The user can pause the action at any point in time and seek back through the session to fine tune edit decisions using a visual representation of the programme timeline. On resuming, the play-head seeks forward to the end of the timeline. This functionality is made possible by ensuring the time shift window (DVR window) of the camera feed is infinite so that all live footage is recorded and can be randomly accessed by seeking. Once the operator has established a sufficient buffer of edit decisions, they can begin broadcasting them. [...] A research goal is to investigate how big the window of time should be between the broadcast play head and edit play head to ensure the operator has enough time to perform edits without feeling rushed and whilst keeping the programme as close to a live broadcast as possible. We call this the ‘near-live window’"
- petetttt 8y ago
  More on building similar web apps here [1] and on getting a computer to play director here [2] 1 - https://www.bbc.co.uk/rd/blog/2017-07-compositing-mixing-video-browser https://www.bbc.co.uk/rd/blog/2017-07-compositing-mixing-vid... 2 - https://www.bbc.co.uk/rd/projects/ai-production https://www.bbc.co.uk/rd/projects/ai-production
M2Ys4U 8y ago
>Maybe we're talking about different kinds of events, but there's actually a lot of creativity that goes into camera framing, movement, shot selection, timing of cuts, etc. to end up with something that's actually interesting to watch... BBC R&D also has a project that's using AI and machine learning to investigate automating that work: https://www.bbc.co.uk/rd/projects/ai-production https://www.bbc.co.uk/rd/projects/ai-production
kvm000 8y ago
My company is heavily involved in this area... there is a migration underway from baseband (https://en.wikipedia.org/wiki/Serial_digital_interface https://en.wikipedia.org/wiki/Serial_digital_interface) to fully IP based infrastructure for routing and signal flow. With IP, it's usually a software defined network model, along with some IGMP components for controlling video flow. So the clients (software or control panels) would send a request to the routing orchestration system to request a route to send multicast flows (SMPTE 2110, separate multicast for video, audio streams, ancillary data) from a source to a destination, same as with a baseband router. With IP, the orchestration layer also drives the receiving device to join the multicast explicitly if it isn't IGMP based. This is our SDN orchestration; https://evertz.com/solutions/magnum https://evertz.com/solutions/magnum (we're hiring!)
- kierank 8y ago
  Your employer amongst other dinosaur hardware manufacturers is also making this a nightmare to implement in software because of the tiny packet burst requirements (40us). My team will spend thousands of man hours and our servers will waste huge amounts of energy because power-saving can't be turned off in order to hit these crazy requirements. In 40 years time we'll be still having to comply with this nonsense because some manufacturers didn't want to update their FPGA designs. It's like fractional frame rates all over again. This is really where the broadcast industry lost its collective mind.
  - kvm000 8y ago
    We also do full systems purely in software at large scale, such as this one; https://evertz.com/resources/press/Discovery-Cloud-Oct2017.PDF https://evertz.com/resources/press/Discovery-Cloud-Oct2017.P... ... fully virtualized in AWS, not just for OTT but also full linear cable/sat broadcast channels. There are valid use cases for both hardware solutions where appropriate, and software solutions for other use cases. There are many low latency use cases where crazy requirements are still actual requirements.
    - kierank 8y ago