[Red5] mp4 in flv container

[Eugen-Andrei Gavriloaie]

Exactly!!!

On 5/16/09, DJP <DJP at architectes.org> wrote:
> Yeah, and perhaps get rid of desync audio/video...
>> -----Message d'origine-----
>> De : red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] De la
>> part de Eugen-Andrei Gavriloaie
>> Envoyé : samedi 16 mai 2009 16:43
>> À : red5 at osflash.org
>> Objet : Re: [Red5] mp4 in flv container
>>
>> Forgot to tell that i read n tags at once, reaching about 128kB per
>> chunk. After that i put them on the network buffer and forgot about
>> them. This greatly improves performance
>> On 5/16/09, DJP <DJP at architectes.org> wrote:
>> > Hi,
>> >
>> >
>> >
>> > Thanks for sharing.
>> >
>> >
>> >
>> > I don’t understand all of your explanations, but I understand that
>> you
>> > managed to get mp4 streaming working in a flv file, is that it ? For
>> my
>> > information, what’s the difference with paulg streaming mp4 file (cf
>> > paulg_mp4 branch in the svn or this
>> > http://s1blue2.waltertak.com:15080/demos/ demo which apparently is
>> doing the
>> > job (I mean streaming mp4)) ?
>> >
>> >
>> >
>> > Thanks for your answer,
>> >
>> > DJP
>> >
>> >
>> >
>> > De : red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] De la
>> part
>> > de Gavriloaie Eugen-Andrei
>> > Envoyé : samedi 16 mai 2009 13:47
>> > À : red5 at osflash.org
>> > Objet : Re: [Red5] mp4 in flv container
>> >
>> >
>> >
>> > IS WORKING!!!
>> >
>> >
>> >
>> > Applied the explained strategy of feeding data with message type
>> 0x16.
>> > Perfect synchronization! I feed all the flv via message type 0x16. No
>> > initial message types 0x09 and 0x08 (A/V)
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On May 16, 2009, at 1:08 PM, Gavriloaie Eugen-Andrei wrote:
>> >
>> >
>> >
>> >
>> >
>> > Don't want to be ungrateful, but why the more in-depth technical
>> > questions/opinions are totally ignored around here? Am I posting to
>> the
>> > wrong forum? Or I just make an ass out of myself by reinventing the
>> > wheel.... In any cases, please give me a hint...
>> >
>> >
>> >
>> > Thank you
>> >
>> >
>> >
>> > P.S.
>> >
>> > This is the third time when I'm posting this kind of issues and no
>> answers .
>> > As usual...
>> >
>> >
>> >
>> > On May 15, 2009, at 11:56 PM, Gavriloaie Eugen-Andrei wrote:
>> >
>> >
>> >
>> >
>> >
>> > Hi,
>> >
>> >
>> >
>> > You are the best! I don't know how you managed to decrypt that rtmp
>> > handshake spaghetti... I'm very impressed! I took the liberty to
>> "borrow"
>> > the algorithm and put it in practice in my C++ implementation and it
>> really
>> > works. Now I can stream mp4 in flv container. I Also did some
>> investigations
>> > by myself and I like to share them with you. Here is what I've done:
>> >
>> >
>> >
>> > I've analyzed (with wireshark) the traffic between FMS 3.5 (win32)
>> and Adobe
>> > Flash Player (OSX Leopard) while streaming a flv containing mp4. Here
>> is
>> > what is happens:
>> >
>> >
>> >
>> >
>> > WS start
>> >
>> > WS end
>> >
>> > Type
>> >
>> > flv start
>> >
>> > flv end
>> >
>> > payload size
>> >
>> >
>> > 0107e
>> >
>> > 010b5
>> >
>> > V
>> >
>> > 110
>> >
>> > 0014B
>> >
>> > 0002C
>> >
>> >
>> > 010b6
>> >
>> > 010c5
>> >
>> > A
>> >
>> > 0014b
>> >
>> > 0015d
>> >
>> > 4
>> >
>> >
>> > 010c6
>> >
>> > 084dd
>> >
>> > V
>> >
>> > 0015e
>> >
>> > 7571
>> >
>> > 07405
>> >
>> >
>> > 084de
>> >
>> > 0851e
>> >
>> > A
>> >
>> > 07572
>> >
>> > 075b5
>> >
>> > 00035
>> >
>> >
>> > 0851f
>> >
>> > 1df56
>> >
>> > ?
>> >
>> > 075b6
>> >
>> > 1cfcc
>> >
>> > 15A17
>> >
>> >
>> > 1df57
>> >
>> > 3268b
>> >
>> > ?
>> >
>> > 1cfcd
>> >
>> > 316e5
>> >
>> > 14719
>> >
>> >
>> >
>> > WS start - wirshark dump start offset
>> >
>> > WS start - wirshark dump end offset
>> >
>> > Type - Audio(0x08), Video (0x09) or 0x16 (what is this!?!?!?)
>> >
>> > flv start - flv start offset
>> >
>> > flv end - flv end offset
>> >
>> > payload size - the size of the rtmp message payload
>> >
>> >
>> >
>> > Observations:
>> >
>> >
>> >
>> > 1. for A/V packets WS end-WS start > payload size. and flv end - flv
>> start >
>> > payload size. This is obvious because there is either flv or rtmp
>> format
>> > overhead
>> >
>> > 2. after those 4 A/V messages FMS does an interesting thing: it just
>> start
>> > to send HUGE chunks of data from flv WITHOUT and computation
>> whatsoever
>> > until the end of the stream. (no more timing issues :). As you can
>> see
>> > 15A17+ 075b6= 1cfcc. It just groups n tags from the flv and send them
>> over
>> > the network via RTMP protocol with message type 0x16
>> >
>> > 3. When the 0x16 message is sent, the data picked up from flv remains
>> > untouched (with the flv file format).
>> >
>> > 4. On the last flv tag of each bunch of tags send, the trailing
>> length is
>> > set to zero. By trailing length I understand this:
>> >
>> >
>> >
>> > flv tag format
>> >
>> > type, length, timestamp, reserved, payload, TRAILING LENGTH
>> >
>> >
>> >
>> > Right now I stream the flv frame by frame which is not pretty and I
>> have
>> > timing issues. On monday I'll blindly apply the FMS strategy of
>> sending big
>> > chunks of data.
>> >
>> >
>> >
>> > Contact me if you need further clarifications. I've sent this mail in
>> a
>> > hurry
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>