mp4 embedded captions + pseudostreaming: captions stuck when seeking to unbuffered position

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Minimal example by user: 
http://blog.martinfjordvald.com/flowplayer/bugexample.html
2. Seek to unbuffered position: captions do not update anymore

What is the expected output? What do you see instead?
Expected: captions update when seeking to unbuffered position.
Instead: captions are stuck.

As this works in rtmp: Is this a technical restriction in the sense that mp4 
embedded captions do not work with pseudostreaming? Then we have to document 
it. Or is it a bug?

See also: http://flowplayer.org/forum/8/102564

Note: the track filtering code (albeit perfectly working) in the example is not 
needed to reproduce the problem (defaults to English track). Just mp4 embedded 
captions + pseudostreaming triggers the issue.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by blacktrashproduct on 9 Aug 2012 at 11:23

[GoogleCodeExporter]

confirming this an issue

Original comment by electrot...@gmail.com on 10 Aug 2012 at 8:29

[GoogleCodeExporter]

This relies on a textdata event on the stream, it looks like the pseudo server 
is breaking this after seeking. Will download the file to test. 

Original comment by electrot...@gmail.com on 10 Aug 2012 at 8:34

[GoogleCodeExporter]

thanks  I love Chi lol. 

If you request with this 

http://blog.martinfjordvald.com/flowplayer/01%20-%20Chii%20Awakens.mp4?start=101
8.828

it breaks the textdata event. 

I don't have server for testing pseudo videos, is there a way to put this video 
up on a pseudo server ? 

Original comment by electrot...@gmail.com on 10 Aug 2012 at 8:43

[GoogleCodeExporter]

confirming onTextData callbacks break .

http://flowplayer.org/plugins/flash/captions.html

the mp4 embedded example is dead, is it possible to be placed on the pseudo 
server ? The flv example is too short to properly test. 

Original comment by electrot...@gmail.com on 10 Aug 2012 at 8:58

[GoogleCodeExporter]

filed a bug report with nginx

http://trac.nginx.org/nginx/ticket/194

Original comment by electrot...@gmail.com on 10 Aug 2012 at 9:13

[GoogleCodeExporter]

The supplied nginx patch fixes the issue. So unless you want to detect lack of 
support for this and notify the user then you can close the issue. 

Original comment by NoFearR...@gmail.com on 10 Aug 2012 at 6:13

[GoogleCodeExporter]

Hi great confirming it works here. It would have to be documented somewhere I 
suppose but because the combination is unique and that patch is not available 
yet such documentation could be come outdated. 

Original comment by electrot...@gmail.com on 11 Aug 2012 at 6:38

[GoogleCodeExporter]

actually its not seeking properly now , please confirm if its working for you

Original comment by electrot...@gmail.com on 11 Aug 2012 at 6:40

[GoogleCodeExporter]

The guy commented on the ticket, he seems to suggest its an encoding issue ? I 
don't quite understand it sorry, he is expecting the textdata to be placed in 
the right portion of the file to seek correctly. 

Original comment by electrot...@gmail.com on 13 Aug 2012 at 2:08

[GoogleCodeExporter]

Is this still a problem ? 

Original comment by electrot...@gmail.com on 15 Aug 2012 at 4:45

[GoogleCodeExporter]

Is this still a problem ? 

Original comment by electrot...@gmail.com on 15 Aug 2012 at 4:45

[GoogleCodeExporter]

Finally got the problem figured out. The supplied patch did indeed remove the 
subtitle seeking to unbuffered position limitation. The slowness in seeking 
problem after that was due to the hinting being in the start of the file and 
not spread throughout the file, thus requiring the client to client to buffer a 
large part of the video to continue playback with subtitles in sync.

The solution is to make sure you hint your MP4 files properly by using the 
-tight parameter of MP4Box or whatever equivalent your software provides.

This issue can now finally be considered closed as my bug example shows this is 
now fast and working.

If I may offer a suggestion then I would document the interval hinting 
requirement in the captions module on the flow player site.

Original comment by NoFearR...@gmail.com on 16 Aug 2012 at 12:06

[GoogleCodeExporter]

Thanks a lot for digging deep.

As I'm in charge of the docs: Hinting is for RTP/RTSP, isn't it? -tight is for 
interleaving:

$ MP4Box -h general | fgrep -A 1 tight
 -tight               performs tight interleaving (sample based) of the file
                       * Note: reduces disk seek but increases file size

That's the one you have in mind?

Original comment by blacktrashproduct on 16 Aug 2012 at 6:42

[GoogleCodeExporter]

Yes I was unclear, the man entry just states that it does tight interleaving 
for both media tracks and hint tracks.

 -tight performs sample-based interleaving of media tracks and hint tracks. This should reduce disk seeks at server side  (depending  on  server  implementation)  but results in a bigger file.

Original comment by NoFearR...@gmail.com on 16 Aug 2012 at 11:42

[GoogleCodeExporter]

Thanks again. I think we all agree that we can close this now.

Original comment by blacktrashproduct on 16 Aug 2012 at 4:09

• Changed state: Done