rtmpdump and "no frame" error

[blousefet]

Hi everyone,

I managed to write a perl script to launch rtmpdump perfectly...
It works as a charm and allows me to schedule download for some livestreams.
Typical command would be :
/usr/local/bin/rtmpdump -r rtmpe://rtmpstreamwebsite.com -a typicalApp -f flashVer -W swfUrl --live -C AMFconnectparams -y playpath -o flvfile

Most of the time (say 90%), my downloaded streams are playable through vlc and when not through mplayer which seems more tolerant with errors.
However, sometimes the stream wont be playable at all without a clue of what's wrong in it...
vlc/mplayer/ffmpeg tells me "no frame".

Typical output in that case :
[h264 @ ???] no frame!
Last message repeated 38 times

Sometimes its playable even though but I would get this :
[flv @ ???] Stream discovered after head already parsed
Truncating packet of size 13574511 to 12471295

Now, i test the file by running an ffmpeg -i command which will tell me instantly if the stream will not be playable.

I then launch GetFlv (that I purchased) to download the same stream. The resulting flv is playable with no problem.
I know that rtmpdump dumps the stream as it downloads it ... (or am I wrong ?).
So what's the problem ? is there something I need to do to avoid these streams not to be unplayable ? How can I manage to play corrupted downloaded streams ?

Thanks for help

[blousefet]

No answers ... but I found something interesting about this cases..;

Once i read output for command rtmpdump, it shows this annoying message :
WARNING: Received FLV packet before play()! Ignoring.

Then i had the idea to try to toggle debug mode on rtmpdump, and saw that problems :

DEBUG2: RTMP_ReadPacket: fd=332
DEBUG2:   0000:  05 00 00 00 00 00 2d 09  01 00 00 00               ......-.....      
DEBUG2:   0000:  17 00 00 00 00 01 4d 00  1f ff e1 00 19 67 4d 40   ......M......gM@  
DEBUG2:   0010:  1f 96 54 05 01 ed 80 a8  40 00 00 03 00 40 00 00   ..T.....@....@..  
DEBUG2:   0020:  05 27 68 48 9a 80 01 00  04 68 ce 35 20            .'hH.....h.5      
WARNING: Received FLV packet before play()! Ignoring.

And then again :

DEBUG2: RTMP_ReadPacket: fd=332
DEBUG2:   0000:  05 00 00 00 00 00 02 09  01 00 00 00               ............      
DEBUG2:   0000:  57 00                                              W.                
DEBUG: ignoring too small video packet: size: 2

could it be the reason for my problem ?

[chap]

example url video

[blousefet]

as you can see the rtmpdump command, it's a live stream (webcam).

[blousefet]

Another point is that when I edit the flv stream using an HEX editor :
- a valid FLV stream shows "onMetaData" tag and other tags at the beginning of the file (ASCII)
- a invalid/corrupted FLV stream won't show that tag

... to be continued ...

[blousefet]

In fact, the previous point is false.
This night, I recorded a stream which had FLV info tags dumped by rtmpdump. That allows ffmpeg to show codec infos. But still, the stream isn't playable.
It shows one frame (or none) and then "no frame" when using vlc, mplayer or ffplay.
There are SRS errors too being reported by mplayer.

weird...


FYI, the stream showed well using adobe flashplayer or getflv on my notebook.

This week-end, I will try to compile rtmpdump with more DEBUG info (defining _DEBUG in .h). Then I'll try to catch a "no frame" stream.
It seems that this behaviour is dependant on the hardware/software used to produce the live stream.

However, obviously, getflv or flash players are more tolerant to stream errors. Getflv dumps the same livestream without frame errors. Sure, Getflv is a commercial and gets its value to perform that.


Is there someone that is interested to work with me on that ?
I'm willing to contribute to rtmpdump effort if allowed by the project.

It's seems rtmpdump won't wait for a valid keyframe to download the livestream. If you use "-k" option with "-v" it has no consequences because "-k" needs that you resume a download (and seeks for a keyframe already downloaded in the file being resumed. Am I wrong ?

[blousefet]

Hi every one who discover this thread with the problem...

I found a solution that needs to be tested over and over.
The solution is to suspress that unsuccessful attempt to subscribe to the stream. Although it was reported as an error, the stream was beginning to be delivered by the server.
As I thought under circonstances (very fast response from the server), rtmpdump droped the first packets, which led to a corrupted dump.

If this works for 2/3 days, I'll work as a patch (an option to allow to bypass FCSubscribe method call for livestreams). If you want to perform the same workaround I've been testing, look for this to comment :

else if (r->Link.lFlags & RTMP_LF_LIVE)
  SendFCSubscribe(r, &r->Link.playpath);

But, anyway, it seems to work for my problem, so use carefully...

[blousefet]

Hi everyone,

After the first day of tests, this workaround only suppresses the FCSubscribe error to the stream.

I managed to understand another thing using the debug info and it seems like it solves most of immediate "no frames" error. But, for some streams, I get AVC Nal errors which leads to the same case.

The other problem I noticed was linked to my previous observation. The stream was beginning before Play.

I discovered that NetStream.Play.Reset, for that FMS version, was leading to the stream being sent prior to NetStream.Play.Start. So I patched rtmp.c in librtmp like this :
... line 2325:
static const AVal av_NetStream_Play_Reset = AVC("NetStream.Play.Reset");

... line 2503:
else if (AVMATCH(&code, &av_NetStream_Play_Start)
|| AVMATCH(&code, &av_NetStream_Play_Reset)
|| AVMATCH(&code, &av_NetStream_Play_PublishNotify))


Now I've got to figure out why this damn streams have AVC Nal size errors... and the stream is playable for 1 to 3 sec.


Hope this helps those who have the same problems...

blousefet

[blousefet]

Still trying to avoid those "no frames" error...
Do someone knows a good FLV editor showing structure so that I can understand what's wrong in the stream downloaded ?

For the moment, 90% of my "no frames" error are solved by the change I've done to rtmp.c in librtmp.
For the last 10%, I figured out that source is somewhat problematic : when I look at the stream using a flash player, the video seems to idle sometimes. But, the flash player is able to play it and getflv is able to play the same stream downloaded at the same time...

I will try to ffplay the getflv downloaded file and compare it the one I've downloaded.

Next episode tonight (lol)

[blousefet]

Hi everyone,

I managed to have almost 95% of my streams being correct after I commented out lines in librtmp/rtmp.c relatives to ignoring short size video/audio packets.

For the last 5%, I assume the stream is corrupted.

For what I see, I need to test the packet against ffmpeg library if I want the packet not to be dumped and corrupting the FLV file created.

So I will try for the next days to fork rtmpdump source code in order to perform that.

Help welcome...

See you