Opened 4 years ago

Closed 4 years ago

#194 closed defect (fixed)

mp4 streaming module breaks embedded text data

Reported by: electroteque@… 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 4 years ago by mdounin

  • 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 4 years ago by nofearroxo@…

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 4 years ago by nofearroxo@…

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 4 years ago by mdounin

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 4 years ago by nofearroxo@…

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 4 years ago by mdounin

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 4 years ago by nofearroxo@…

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 4 years ago by sync

In 4821/nginx:

(The changeset message doesn't reference this ticket)

comment:9 Changed 4 years ago by mdounin

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