search

ut0mt8 / nginx-rtmp-module

NGINX-based Media Streaming Server
http://nginx-rtmp.blogspot.com
BSD 2-Clause "Simplified" License
86 stars 32 forks source link

DASH streams not working properly (dash.js/shaka player/rx player) #17

Closed z411 closed 5 years ago

z411 commented 5 years ago

Hello,

Thanks for your fork, it seems it's been a lot of work to fix the DASH issues upstream so I'm thankful for your work.

I tried your latest dev branch against nginx/1.14.1 and there are all kind of erratic behaviors with different players.

Shaka player doesn't start unless I revert the commit that changes availabilityStartTime because Shaka player seems to expect an UTC time. If not, it'll try to seek hours into the future and never start. That said, it will have short stalls on some browsers because it find some millisecond gaps in the stream (according to the log).

dash.js is weird because it sometimes will load properly, but other times will load with very big delay times (over 100 seconds). Sometimes it loads with 150s or even 200s of delay. Of course because the playlist is only 120s, the fragments don't exist so it doesn't play.

Have you experienced any of this issues? Is it a problem with my configuration?

I can provide logs. Here's one snapshot of the mpd: http://tv.bienvenidoainternet.org/snapshot.mpd

Thanks.

ut0mt8 commented 5 years ago

Hi,

I have to rebuild an demo env, because I've switch on another projects/work. Can you share your whole configuration ?

I got some problem with availabilityStartTime, but in the contrary I made this modification to allow shaka player to play (because is more strict then dash).

I have to refresh my memories :)

z411 commented 5 years ago

Hi, thanks for your reply.

Here's my full config: https://gist.github.com/z411/408fe71cec058f7328785d38dfc59ff6

Shaka doesn't work for me with your fork, but if I change ngx_libc_gmtime(start_time, &tm); to ngx_libc_gmtime(ctx->start_time.sec, &tm); in the file dash/ngx_rtmp_dash_module.c it works (Shaka needs availabilityStartTime to be in UTC time).

I've noticed that when segments are of the same length (6 secs) all players work perfectly. Here's a sample: https://tv.bienvenidoainternet.org/good.mpd

But if they are of different lengths, erratic behavior happens. Here's a sample: https://tv.bienvenidoainternet.org/bad.mpd

In this case dash.js sometimes works fine, but sometimes it tries to play with 150 secs of latency: firefox_2019-03-20_08-22-58

My playlist is only 120s of length so there's no fragment to play, so the player stalls.

Shaka plays fine but it starts seeking after a few segments with these messages: seamonkey_2019-03-20_08-25-30

Could this be an issue with timing in the mpd or should I report this to dash.js/Shaka?

ut0mt8 commented 5 years ago

Ah. Segment must be fixed size, specifically between representation. This is mandatory because if the player change representation in the middle of a stream (whatever player) will be lost. This is normal and by design. And by the way this is a quasi must to do fixed size chunk / constant bitrate to stream live.

ut0mt8 commented 5 years ago

That said in your mpd the only one representation, so even with variable chunk/bitrate it should work.

z411 commented 5 years ago

Thanks, yes. In dash.js official dynamic live mpd they have variable chunk size as well and it works fine: https://livesim.dashif.org/livesim/segtimeline_1/testpic_2s/Manifest.mpd

I think I'll ask in their issue tracker and report back.

ut0mt8 commented 5 years ago

Yep that could work, but it's a better option to do fixed size.

z411 commented 5 years ago

I reported the mentioned issue in dash.js' issue tracker and so far it seems it has problems with SegmentTimeline in general; it seems they're working on it so I'm assuming it's their issue for now. I'll be closing this, thank you for your response!