Wow, it got merged (the EDTS version). Nice and thanks!
( https://github.com/nginx/nginx/commit/7927071ee26ff6313301b744a90240dccbc836db https://github.com/nginx/nginx/commit/7927071ee26ff6313301b744a90240dccbc836db )

Thanks for filing the Firefox bug and following up with it, Roman.


I can move our live services over to the updated nginx once FF fixes the bug (and some time goes by).
(No worries, that’s probably about when ubuntu nginx version will get updated, hehe).

I haven’t seen timescales like 24 before here in the US (esp. w/ TV - but I believe very rare otherwise out here).
Glad you found a good solution.

I’m really looking forward to the new:
start_key_frame
directive!


You might find this hopefully amusing, but I gave a talk at Demuxed 2021 October 7th, titled:
"30,000 fps nginx - To Russia with Love”
while things were before the EDTS solution you all found and worked out.
(Video should hit YouTube by end of 2021).

Kind regards & gratefully!
- Tracey


> On Oct 20, 2021, at 8:32 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
>
> Hello!
>
> On Mon, Oct 04, 2021 at 03:41:47PM -0700, Tracey Jaquith wrote:
>
>> Hi Roman,
>>
>> OK, thanks!
>>
>> I’ve tested this on macosx & linux, so far with: chrome, safari, Firefox and iOS.
>>
>> However, I’m seeing Firefox is having alternate behavior where it plays video from the prior keyframe,
>> without audio, until it hits the desired start time in at least one video, though it’s not consistently doing this.
>> I suspect it’s the edit list — a nice solve for this.
>> I’ve had minor issues with edit lists in the past, for what that’s worth.
>
> Thanks for testing. Just for the record:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1735300
>
> Hopefully this will be eventually fixed.
>
> [...]
>
>> And deep apologies…
>>> Another problem is track delay
>>
>> I *should have* mentioned when I initially wrote in, that I was aware of the a/v sync slight slip
>> — and that in practice and running for over 3 months now, it hasn’t seemed to be any kind of issue.
>>
>> Assuming:
>> * the average (US TV) video might be 29.97 fps
>> * and thus timescale / duration of 30000 / 1001
>> * and that a typical max distance between keyframe GOPs w/ ffmpeg encoders and similar is 300 frames or about 10s
>>
>> Then:
>> * with a max of 10s between keyframes
>> * and 300 frames max would get “sped up” from 1001 => 1
>>
>> Then we’re looking at a maximum additional video frames duration of 1/100th of a second.
>>
>> (300 * 1001 / 30000) == 10.01
>>
>> (300 * 1 / 30000) == 0.01
>>
>> So the most the A/V sync could “drift” from those early added frames is 1/100th of a second,
>> where average might be 2-3x smaller than that.
>> In practice, it didn’t seem noticeable —
>> but I am quite impressed by your desire to minimize/eliminate that.
>> (In practice, from the broadcasters at least in the US, 1/100th of a second A/V slip is not uncommon).
>
> While it looks quite well with timescale 30000, it is not uncommon
> for video tracks to have timescale 25 or so. For example, the
> test video in the ticket linked above uses timescale 24. With
> such a timescale, resulting desync will be much more noticeable.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

-Tracey
@tracey_pooh
TV Architect https://archive.org/tv https://archive.org/tv





_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel