-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi,
Alvaro Lopez Ortega schreef: > On 10/12/2009, at 17:21, Stefan de Konink wrote: > >> Dome Charoenyost schreef: >>> Now i'm user nginx with h264 streaming module. and play by >>> flowplayer (with streaming plugin). I'm testing cherokee ans try >>> to hack handle_streaming.c for support seeking for mp4 (h264 >>> codec) but bad luck. someone working on this feature ? >> Yes, and everyone I try to volunteer to work on it mysteriously >> leaves after seeing what already has been done, and what is still >> open. >> >> For the record. We can (on the fly) make MP4 streamable, this code >> is not in trunk, but is available. But we cannot yet update the >> track atom, that is required for the seek. > > Stefan, could you please elaborate on where the problem lies? It'd be > enlightening for everybody (me included) who, at some point, took > over this task. In order to stream MP4 we need to have the MOOV atom at the beginning of the file, in the normal situation after for example encoding with FFmpeg a tool called qt-faststart can do this for you. This generates a new file and everything is moved. Because we want to stream any content, Cherokee is able to detect this MOOV atom and is able to generate a new MOOV atom on the fly, and places this in front of the stream after this operation a normal 'file based send' takes over. In order to seek in MP4 we actually generate a new file from that point on. There are several ways to do this, but we would prefer the way that doesn't require a seperate file to do so. This requires that we can skip to an 'arbritary' position in the file, stich a new MOOV in front of it *AND* because the the offset since the beginning changed, we have to update the 'track' atoms that point to the correct positions relative to the start of the track. [this part is the TODO, or better requires some debugging with an mpeg analyser] > A link to the code you did reference would also be appreciated (FTR). http://kinkrsoftware.nl/contrib/cherokee/cherokee_mp4_header.patch Probably will not apply on trunk anymore. But as reference it is good enough. Thus it is not really about testing, but about checking what things we are missing. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkshKBYACgkQYH1+F2Rqwn3p9ACdF5zoTixhjDT25juDiQJZvlZ7 lPIAoIB23Bhqrh/VHu6oQNLeyLj3uDNs =CXjS -----END PGP SIGNATURE----- _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
