[rtmpdump] Searching for key frames

fs ck fsckemail at gmail.com
Sat Jan 8 23:03:30 CET 2011


OK, I found there is a bug of some sort. Maybe FMS behavior has
changed as this was not happening to BBC iPlayer streams until
recently. (my previous post is probably worth ignoring as I think this
is the root cause)

Using latest r555 (although this happens with v2.3 in my tests also)
on ubuntu 10.10 amd64.

Here is how I can reproduce the problem:

I use get_iplayer using following cmd:
get_iplayer --modes=flashhigh 'bbc weather' -g --debug

I partially download the file to, say, 34 seconds into a 148 second
program by using 'ctrl-c'.

I now have an flv file
BBC_Weather-07_01_2011--b00x8cmb-default-flashhigh.partial.mp4.flv of
size 3683570 bytes. It got to "3403.710 kB / 34.920 sec (23.4%)"

I then re-run the same get_iplayer command
It says "Resuming download at: 3403.710 kB / 34.920 sec (23.4%)" which
is expected.

It then errors twice with "WARNING: Stream does not start with
requested frame, ignoring data..."

Then proceeds to download the resumed stream at the end of the partial flv file.

The problem is that the percent counter (and seconds counter) both
erroneously start from zero.

We then get problems when the rtmp stream is completed because
rtmpdump is still expecting the final 23.4%. It reports "14359.304 kB
/ 113.76 sec (76.4%)" but actually it has it all.

If I playback the file all the video is there but of course the player
gives loads of errors because the timestamps are wrong.

Basically the resume doesn't initialize the TS offset correctly for
the resumed frames. I cannot determine whether this is due to FMS
mis-reporting the TS or rtmpdump not setting it correctly.

Either way this causes havoc and endless retries in get_iplayer !!

Any help appreciated.

BTW: I have a full 60MB --debug trace if that helps - let me know if
you want it or just a portion of it.


More information about the rtmpdump mailing list