Opened 12 years ago

Closed 12 years ago

#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 by Maxim Dounin, 12 years ago

Status: newaccepted

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 by Martin Fjordvald, 12 years ago

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 by Martin Fjordvald, 12 years ago

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 by Maxim Dounin, 12 years ago

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 by Martin Fjordvald, 12 years ago

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 by Maxim Dounin, 12 years ago

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 by Martin Fjordvald, 12 years ago

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

In 4821/nginx:

(The changeset message doesn't reference this ticket)

comment:9 by Maxim Dounin, 12 years ago

Resolution: fixed
Status: acceptedclosed

Patch committed, thanks for report and testing.

Note: See TracTickets for help on using tickets.