mp4 streaming module breaks embedded text data

[Dan Rossi]

The mp4 streaming module is breaking onTextData stream events from being dispatched once an offset has been requested. Please see here

​http://code.google.com/p/flowplayer-core/issues/detail?id=619
​http://blog.martinfjordvald.com/flowplayer/bugexample.html

If i request without the offset it will dispatch to a flash method onTextData.

public function onTextData(obj:Object):void

{

trace("ontextdata", obj);

}

[Maxim Dounin]

Thank you for report. As of now nginx's mp4 module only allows tracks with "avc1" or "mp4a" media types. Please try the following simple patch to see if it helps:

--- a/src/http/modules/ngx_http_mp4_module.c
+++ b/src/http/modules/ngx_http_mp4_module.c
@@ -1842,14 +1842,6 @@ ngx_http_mp4_read_stsd_atom(ngx_http_mp4
                    ngx_mp4_get_32value(stsd_atom->entries),
                    4, stsd_atom->media_name);
 
-    /* supported media format: "avc1" (H.264) and "mp4a" (MPEG-4/AAC) */
-
-    if (ngx_strncmp(stsd_atom->media_name, "avc1", 4) != 0
-        && ngx_strncmp(stsd_atom->media_name, "mp4a", 4) != 0)
-    {
-        return NGX_DECLINED;
-    }
-
     trak = ngx_mp4_last_trak(mp4);
 
     atom = &trak->stsd_atom_buf;

I don't see any real reasons for this restriction, so probably it should be just removed if this fixes the problem in question.

[Martin Fjordvald]

Original reporter here. I have updated my bug example and I can confirm that the supplied patch helps. The subtitles are no longer stuck when seeking to a non-buffered point in the file.

[Martin Fjordvald]

Correction. At the time of my previous comment my host had connectivity problems to Europe so I didn't pay much attention to the slowness of seeking, now with the connectivity fixed the seeking is still terribly slow. It seems that removing the restriction causes conditions that prevent seeking or make it extremely slow.

[Maxim Dounin]

Ok, I see, with the patch the "...?start=1000" response is about 117M instead of 43M before the change (full file is about 146M). Careful investigation shows that this is due to the fact that tx3g (subtitles) track resides in first 44 megabytes of the file (last chunk starts at 43172461), thus more or less preventing seeks. This looks like encoder problem.

[Martin Fjordvald]

Not sure I can change this in the encoder. The standard tools MP4Box and qtfaststart does not move the subtitles around, only the moov atom.

How should the subtitles be placed here in order to allow seeking?

[Maxim Dounin]

Subtitles track should be spread across the file, much like video/audio tracks. You may try demux / remux the file to see if it helps. MP4Box should be able to do this.

[Martin Fjordvald]

Okay, so sample based interleaving of the media tracks and hint tracks did the trick. MP4Box supports this through the -tight parameter.

I will make a note of this in the wiki so that this is documented and no one else is confused.

Your help was much appreciated Maxim.

[sync]

In 4821/nginx:

(The changeset message doesn't reference this ticket)

[Maxim Dounin]

Patch committed, thanks for report and testing.