[Red5] mp4 in flv container

[Gavriloaie Eugen-Andrei]

Check out www.rmpd.com on monday. I'll post an online demo after I  
apply the algorithm. Now I have my eyes as big as onions after  
counting endless series of bytes...

On May 16, 2009, at 12:08 AM, AMP Admin wrote:

> I don’t know what any of that means but I’ve been able to shove  
> mp4’s in flv’s using ffmpeg and lib264x.  the only problem is when  
> doing playlists it causes our player to hang for over 60 seconds  
> before starting.  It’s good for VOD but not webtv type apps.
>
> If whatever you said below can help me that would awesome… whatcha  
> think?
>
> From: red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] On  
> Behalf Of Gavriloaie Eugen-Andrei
> Sent: Friday, May 15, 2009 3:56 PM
> To: red5 at osflash.org
> Subject: [Red5] mp4 in flv container
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090516/89710e67/attachment-0001.html>