[rtmpdump] patch: Stream does not start with requested frame, ignoring data

[Howard Chu]

Peter Miller wrote:
> On Sat, 2011-04-09 at 02:45 -0700, Howard Chu wrote:
>> Peter Miller wrote:
>>> The server does send the expected packet type
>>> (r->m_read.initialFrameType == RTMP_PACKET_TYPE_VIDEO) but it does not
>>> send the expected packet size (r->m_read.nInitialFrameSize = 17957,
>>> nPacketLen = 592).  This causes it to fall into the code that expects a
>>> RTMP_PACKET_TYPE_FLASH_VIDEO frame.
>>
>> Then the server is lying to you about something. I don't believe your video
>> keyframe can be only 592 bytes, especially not if the actual last keyframe in
>> the file was 17KB.
>
> Something is definitely strange, however my browser manages to play it
> without difficulty.  However, that's what's happening, now the code has
> to cope.  Just got to figure out how.

Your browser doesn't stop playing in one session and resume again in a later 
session, so that's inconclusive.

As if I hadn't made it clear already, you need to understand WTF you're 
dealing with before you go munging the code. Unless you're dealing with a 
video of about 160x120 resolution, or the frame is all one color with no 
detail, I don't see how a keyframe can compress down to only ~500 bytes.

rtmpdump says the last keyframe it received was 17KB. That's a pretty 
reasonable size for a keyframe. It's of course possible that the last keyframe 
was a FlashVideo frame instead of a plain Video frame, and so the actual 
keyframe should be much smaller. But that's apparently not the situation here. 
Until you actually know what the situation is, it's inappropriate to be 
proposing anything in the way of a fix.

If you can reproduce this situation on demand, then it should be a simple 
matter to compare the data and see what correspondence exists, if any, between 
the data rtmpdump holds and the frame the server sent.