Appears to only play first playlist of segments then stops

[ethernetweb]

Greetings Sergey,

First of all, I would like to say thank you for continuing this nginx module. Much appreciated.

The dash players I have tested with all "freeze" apparently after only playing the first playlist of segments.

This is the dev branch of dashif: http://ethernetweb.com/dashjs-test/live.html

This is a link to the mpd: http://ethernetweb.com:19360/dash/ethernetweb/index.mpd

Have tested with bit-dash: http://www.dash-player.com/demo/manifest-test/

Have tested with stable / master 1.6.0 dashif. dashif.org/reference/players/javascript/v1.6.0/samples/dash-if-reference-player/index.html?url=http://ethernetweb.com:19360/dash/ethernetweb/index.mpd

All result in the player stopping and the buffer reaching 0.

Thank you very much.

[misiek08]

Your mpd shows 404.

[ethernetweb]

@misiek08 Sorry, I ran it live for over a week. The ffmpeg process to encode to mpeg dash takes resources. I didn't figure that anyone was watching considering it took 15 days to get a response.

[misiek08]

Ok, if you will evaluate same thing again let us know. I set up notifications, so I'll see much faster.

[ethernetweb]

It's back online for testing.

Some more info.

nginx version: nginx/1.8.1 built by gcc 4.7.2 (Debian 4.7.2-5) built with OpenSSL 1.0.1e 11 Feb 2013 TLS SNI support enabled configure arguments: --prefix=/root/test2/n --add-module=../nginx-rtmp-module/

[misiek08]

Can you show rtmp config? Looks like segments are disappearing from playlist before player get info about them and it creates gap. If you then skip that fragment it plays without any problems for next few.

[ethernetweb]

user www-data;
worker_processes 1;
pid ./nginx.pid;

# If more than one worker process use this option
#rtmp_auto_push on;

events {
  worker_connections 1024;
#  multi_accept on;
}

http {
  server_tokens off;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  server {
    listen 19380;

    location /dash {
      root /tmp;
      add_header Access-Control-Allow-Origin *;
      add_header 'Content-Type' 'text/plain charset=UTF-8';
      add_header Cache-Control no-cache;
    }
  }
}

rtmp {
  server {
    listen 19370;

    application dash {
      live on;
      dash on;
      wait_video on;
      dash_nested on;
      dash_fragment 5s;
      dash_path /tmp/dash;
      allow publish 127.0.0.1;
      allow publish 192.99.9.221;
      allow publish 0.0.0.0;
      deny publish all;
    }
  }
}

http {
  server {
    listen 22000;

    location /stat {
      allow 192.99.9.221;
      allow 127.0.0.1;
      deny all;
      rtmp_stat all;
      rtmp_stat_stylesheet stat.xsl;
    }
  }

[misiek08]

Try setting

dash_playlist_length 2m;

in

application dash {

[ethernetweb]

(You will probably notice different ports. I'm running multiple versions and compiles for testing but all the configs are the same, excluding port numbers). So far, all tests provide same results.

[ethernetweb]

I set the playlist length variable in config. Same results.

[ethernetweb]

If I had to guess, I would say this is a problem with the calculations of this variable timeShiftBufferDepth="P0Y00M00DT0H03M26.50S"

[misiek08]

http://dashas.castlabs.com/demo/try.html only this player is playing it without problem. I'll look into it tomorrow (it's 2:47 my local time :) )

[ethernetweb]

Cheers. Sleep well. Thank you.

[misiek08]

MPD is missing publishTime attribute, I'll try if it's the reason tomorrow.

[ethernetweb]

I looked at several other manifests including static ones created with Bento4 and none of them contain the publishTime. The static ones play quite well in all platforms also.

[krombel]

@ethernetweb Just to mention: this module runs live. So a reference to static mpd's may be not target-aimed. Do you know "live"-mpd's that are running seamlessly?

@misiek08 Have you tried adding the publishTime-attribute? Did it help?

For reference: http://dashif.org/conformance.html says, that the Schematron validation fails.

[misiek08]

I made valid mpd on-the-fly with simple PHP script, but it fails in player too. Looks like nginx generates Dash 1, incorrect playlist. I'm trying to rewrite that playlist live into Dash 2 format by PHP. I'll let you know if I made it working.

[ethernetweb]

@misiek08 Thank you. I know enough c to make modifications to the module and probably make any necessary changes work. I look forward to your update.

[misiek08]

I tried several things and only that 1 player worked good. I even made longer playlist and other things, but just keeping duration below 5 seconds crashes every player.

I think 5s default buffer in every player is the real minimum and you should make own player or don't go below 5s.

[misiek08]

And I set proxy, cache and PHP script rewriting stuff on-the-fly, so I tested every variant and every time there was problem, where browser wasn't able to download playlist or chunk in time. So it was like buffer was getting down to 0 and player restarted after 10-15s and kept playing. After making smart proxy and making playlist longer I was able to play that stream for even 45-55s, but then buffer was dropping to 0 again and player died.

[ethernetweb]

That's odd.How much playing around did you do with the timeShiftBufferDepth variable?

[ethernetweb]

I've updated it to Dash2 compliance and am finding this:

Conformance test completed Segment timeline for type dynamic is not supported, only MPD will be tested.

[misiek08]

Now it doesn't start on any of players I have. I just added sar, publishTime and id attributes to make it compilant and .mpd was passing tests.

http://misiek08.mydevil.net/index.mpd here is your playlist, live update (it's a php script behind this url).

[ethernetweb]

Okay. Thank you for looking into it. I put the stream back up and checked out your link and tampered a bit, still without good results.

I believe it may be time to look for another avenue and abandon this module for live DASH streaming as it is too buggy and deprecated.

[misiek08]

It's funny, but HLS works great and you can use it. I'll look into MPD specification and examples to build playlist from scratch, because module serve a little outdated version. Maybe that's the problem, maybe the problem is bad chunking.

According to the module - there are forks like this where owners maintain updates and fact that module is built on nginx make it better than many alternatives. I heard about people switching to wowza, but I'm taking care of servers with that java shit and it's resource usage comparing to functionality is terrible.

[ethernetweb]

@misiek08 I do plan to still use the module for other rtmp and streaming functions. It is very happy in the resource usage department and has some nice features that work well and integrate with other platforms easily. I've hunted down as many of the forks as I could and checked the update times on specific .c files to see if anything in this area was fixed. Didn't have any luck there either.

Thank you again. Rewriting the entire chunk system to use $Number instead of $Time and attributing it to the startNumber="0" and duration="5" variables under the SegmentTemplate directive would likely be a good solution. My ability in C however, is not good enough to make these alterations.

[misiek08]

Why are you forced to MPD? Is there any possibility to switch to HLS?

I looked over the code and I won't make any patches for mpd in near future, because HLS works good and fixing mpd can take simply too long.

[ethernetweb]

In short, compatibility issues with mobile devices. HLS is Apple, DASH is Android. YouTube / Netflix use DASH. It is becoming the primary industry standard.

[sergey-dryabzhinsky]

You can try latest code from master branch. Some fixes with cleanup logic was done. And with onMetaData, HLS mpegts headers.

[sergey-dryabzhinsky]

Also at locations for HTTP dash/hls need to set open_file_cache off;

[ethernetweb]

@sergey-dryabzhinsky Thank you. I will download it today, check it out and inform of outcome.

[ethernetweb]

@sergey-dryabzhinsky I just recompiled with nginx-1.8.1 and the latest master repository with open_file_cache off - It still fails

dash.mediaplayer.debug.js:2483:13 [245889] Prior to making a request for time, NextFragmentRequestRule is aligning index handler's currentTime with bufferedRange.end. 350.68399999999997 was changed to 350.717

When it freezes, the dash-js player continues to throw this console.log (I hope this is helpful)