#194 closed defect (fixed)

mp4 streaming module breaks embedded text data

Reported by: Dan Rossi Owned by: somebody
Priority: minor Milestone: 1.3.6
Component: nginx-module Version: 1.3.x
Keywords: Cc:
uname -a:
nginx -V: 1.3.2


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


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

public function onTextData(obj:Object):void


trace("ontextdata", obj);


Change History (9)

comment:1 Changed 21 months ago by Maxim Dounin

  • Status changed from new to accepted

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
                    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.

comment:2 Changed 21 months ago by 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.

comment:3 Changed 21 months ago by 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.

comment:4 Changed 21 months ago by 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.

comment:5 Changed 21 months ago by 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?

comment:6 Changed 21 months ago by 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.

comment:7 Changed 21 months ago by 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.

comment:8 Changed 21 months ago by sync

In 4821/nginx:

(The changeset message doesn't reference this ticket)

comment:9 Changed 21 months ago by Maxim Dounin

  • Resolution set to fixed
  • Status changed from accepted to closed

Patch committed, thanks for report and testing.

Note: See TracTickets for help on using tickets.