Remuxing and Progressive Download

[sannies]

Hi Erankor, we need to support progressive download for old TV sets. There is no track selection on the device so the track selection needs to be done server side. While track selection works fine e.g.:

curl http://localhost/pd/tos/tracks/v0-a1/TOS_all.mp4 -o dl.mp4

correctly return the video and audio 1 / excludes audio track 0. In our environment It is unfortunately the case that the audio tracks are in separate files - there is no MP4 file that contains all audio tracks. Each audio is in it's own MP4 container.

So we tried multiuri / urlset:

curl http://localhost/pd/tos/TOS_,ITA,1400,.mp4.urlset -o dl.mp4

This downloads the Italian translation (TOS_ITA.mp4). When we switch position

curl http://localhost/pd/tos/TOS_,1400,ITA,.mp4.urlset -o dl.mp4

we retrieve video TOS_1400.mp4 only. Is this supposed to work? Or are we in uncharted territory? If it should work but doesn't could you point me to a starting point?

The tos directory looks like this:

-rw-r--r--  1 sannies  staff   118M 19 Dez 09:48 TOS_1400.mp4
-rw-r--r--  1 sannies  staff    11M 19 Dez 11:31 TOS_ENG.mp4
-rw-r--r--  1 sannies  staff    11M 19 Dez 11:30 TOS_ITA.mp4
-rw-r--r--@ 1 sannies  staff   141M 19 Dez 11:57 TOS_all.mp4

[erankor]

No, this is not supported. In general, progressive download is a second-class citizen in this module, many features that are supported with HLS/DASH are not supported with progressive download. Including - encryption, decryption, audio filtering, playlist, and multiple input files.

The only features that ARE supported (other than serving the file as-is, which can be done without any custom module...) -

1. Clipping - similarly to nginx's builtin mp4 module, but with a couple of advantages - support for clipping remote files & support for caching the MP4 metadata.
2. Track selection - only by editing the metadata - the output bitrate remains the same as the original MP4.

The main reason is that requests for MP4 files can be big, for example, consider a 2h long video with a high bitrate. In this case, a single request to the server may consume a significant amount of resources to complete. It is technically possible to implement something like that, of course, but this module was intended for outputting streaming protocols, and certain assumptions in its design do not hold for this case. It would probably take a significant effort to do it well, and for us, this was never important enough...