[rtmpdump] patch: Stream does not start with requested frame, ignoring data
hyc at highlandsun.com
Sat Apr 9 19:39:41 CEST 2011
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.
More information about the rtmpdump