Opened 11 years ago
Closed 11 years ago
#194 closed defect (fixed)
mp4 streaming module breaks embedded text data
|Reported by:||Dan Rossi||Owned by:||somebody|
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
Change History (9)
comment:1 by , 11 years ago
|Status:||new → accepted|
comment:2 by , 11 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 , 11 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 , 11 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 , 11 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 , 11 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 , 11 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 , 11 years ago
(The changeset message doesn't reference this ticket)
comment:9 by , 11 years ago
|Status:||accepted → closed|
Patch committed, thanks for report and testing.
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:
I don't see any real reasons for this restriction, so probably it should be just removed if this fixes the problem in question.