18 ms·

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 act

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 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago

decasia 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago