nginx-vod-module icon indicating copy to clipboard operation
nginx-vod-module copied to clipboard

Ran into multiple issues trying to migrate from .urlset to mapped mode

Open ugljesas opened this issue 2 years ago • 1 comments

I'm running nginx-vod-module 1.29 in alpine docker (3.14.2), on nginx version 1.20.1.

I've run into multiple issues using mapped + upstream mode to provide dash streaming services.

  1. It seems that for adaptive sets, if provided via JSON in mapped mode, some streams are corrupt.

Example: https://videobolt.wtf/api/dash/5f3bfc8891f80b2552512b4b/manifest.mpd The backend provides the following JSON:

{
    "sequences": [
        {
            "clips": [
                {
                    "type": "source",
                    "path": "/5f3bfd26c5ba1103e7989d1b"
                }
            ]
        },
        {
            "clips": [
                {
                    "type": "source",
                    "path": "/5f3bfd28c5ba1103e7989d1e"
                }
            ]
        },
        {
            "clips": [
                {
                    "type": "source",
                    "path": "/5f3bfd27c5ba1103e7989d1d"
                }
            ]
        },
        {
            "clips": [
                {
                    "type": "source",
                    "path": "/5f3bfd27c5ba1103e7989d1c"
                }
            ]
        }
    ]
}

This stream seems to be corrupt, playing it using ffplay and switching between streams gives the following error: top block unavailable for requested intra mode -1 [h264 @ 0x564c52437680] error while decoding MB 60 0, bytestream 173306 and shaka and other players show artifacts over the video. Creating the exact same manifest (minus exact urls) using urlset on: https://videobolt.wtf/api/dash/,5f3bfd26c5ba1103e7989d1b,5f3bfd27c5ba1103e7989d1c,5f3bfd28c5ba1103e7989d1e,5f3bfd27c5ba1103e7989d1d,.urlset/manifest.mpd (each request to backend returns a single sequence with the path in question) It plays just fine with shaka and ffplay.

Relevant conf:

vod_cache_buffer_size 8m;
vod_metadata_cache metadata_cache 8196m;
vod_response_cache response_cache 512m;
vod_performance_counters perf_counters;
vod_mode mapped;
vod_upstream_location /api_proxy;
vod_remote_upstream_location /s3;
vod_segment_duration                        2000;
vod_align_segments_to_key_frames on;
vod_manifest_segment_durations_mode accurate;
vod_segment_count_policy last_rounded;
vod_last_modified 'Sun, 19 Nov 2000 08:52:00 GMT';
vod_last_modified_types *;
vod_expires 100d;
vod_output_buffer_pool 4m 128;
vod_base_url https://videobolt.wtf;
location ~* /api_proxy/api/(hls|dash)/(.*)$ {
     internal;
     proxy_pass http://api/api/GET_STREAMING_JSON?q=$2;
}
location ~* /s3/(.*)$ {
  internal;
  proxy_pass http://storage/$1;
  proxy_http_version 1.1;
  proxy_set_header Connection "";
  proxy_set_header Authorization "";
  proxy_set_header Host videobolt-assets.s3.amazonaws.com;
}
location /api/dash/ {
  vod dash;
  vod_dash_manifest_format segmenttimeline;
}

Source assets:

https://videobolt-assets.s3.amazonaws.com/5f3bfd26c5ba1103e7989d1b
https://videobolt-assets.s3.amazonaws.com/5f3bfd27c5ba1103e7989d1c
https://videobolt-assets.s3.amazonaws.com/5f3bfd28c5ba1103e7989d1e
https://videobolt-assets.s3.amazonaws.com/5f3bfd27c5ba1103e7989d1d

They were all encoded with -force_key_frames expr:gte(t,n_forced*2) so they should align perfectly with the 2000 segment duration

  1. I was also looking to provide a custom segmentDuration in the JSON for the streams (depending on how they were encoded) and based on the output in the manifests it seemed to work for adaptive sets in all cases, but if a single sequence is returned it only worked if no default vod_segment_duration was set in the conf. If there is a default in the conf, it only works for adaptive sets and fallbacks to default with single stream. I can get around this since I can just set no default and always provide a value from the backend, but I thought it was worth reporting

Any input would be much appreciated

ugljesas avatar Oct 12 '21 10:10 ugljesas

I couldn't keep a broken version of this on our test environment for long, so I had to deploy a previous working version. When and if you have time to look into this @erankor I can set up an environment that reproduces this.

ugljesas avatar Oct 14 '21 12:10 ugljesas