Re: [Pearg] times square 15 sec delay new years

[Lloyd W <[e-mail]>]

Watch a live televised event simultaneously both by direct broadcast on tv, and by livestream on internet video.

Notice which one lags, and by how much.

Lloyd Woof
[e-mail]

> On 7 Jan 2023, at 19:59, Jens Finkhaeuser <[e-mail]> wrote:
> 
> Hi all,
> 
> so this is *almost certainly* a regulatory rather than technical issue. Almost, because I have no way of knowing, but certainly, because it happened before.
> 
> 2004, during the superbowl half time show, Janet Jackson's wardrobe famously malfunctioned. At the time, whichever regulator is responsible for this kind of thing in the US, mandated that a transmission delay is introduced to allow broadcasters to hit a panic button and broadcast something else instead. That happened to be 15 seconds long. (There's some fuzzy memory over it existing before and being extended instead, but someone else will have to clear that up. I can't recall.)
> 
> When we did p2p live streaming for Joost back in 2008ish, we realized that for less popular content, we maybe couldn't get a stream initiated faster than that. Not being broadcasters, that worried us. Then some folk with broadcast experience in the company told us that, actually, broadcasting a stream faster might be problematic for this reason.
> 
> TL;DR is, yes, as an engineer you'd like to cut this out completely (and so would I). But the delay you witnessed may be things just working as intended.
> 
> Hope that helps,
> Jens
> 
> ------- Original Message -------
>> On Friday, January 6th, 2023 at 23:51, Dave Taht <[e-mail]> wrote:
>> 
>> 
>> 
> 
>> 
> 
>> On Fri, Jan 6, 2023 at 12:42 PM Dino Farinacci [e-mail] wrote:
>> 
> 
>> 
> 
>> 
> 
>>>> I was rather annoyed to be watching the Times Square new years eve celebrations on You Tube TV with a 15 second delay. That could have been avoided if multicast had been a part of the distribution technology. But I can understand why it wasn't.
>> 
> 
>> 
> 
>> I would point at that time delay being more related to various aspects
>> of my bête noir, bufferbloat, cropping up, be it in the transport
>> itself, or in the application. RTMP implementations, in particular,
>> are notoriously laggy. There are multiple other problems possibly in
>> that time delay related to encode, decode time. Also, for all we know,
>> some of that lag was for a censor on the stream.
>> 
> 
>> Actually investigating where those 15 seconds went would be
>> interesting - who to ask?
>> 
> 
>> Recently some congestion controlled webrtc optimizations for OBS and
>> twitch arrived from this fella:
>> https://www.linkedin.com/posts/sean-dubois_github-pionwebrtc-pure-go-implementation-activity-6956254392949825536-bdac/
>> 
> 
>> I really don't think that "multicast" could have helped until we
>> started to get rid of the other 14.9 sec built into the system here.
>> 
> 
>> --
>> This song goes out to all the folk that thought Stadia would work:
>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>> Dave Täht CEO, TekLibre, LLC
>> 
> 
>> --
>> Pearg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/pearg
> <publickey - [e-mail] - 0x5C345E9C.asc>