Fred Eisele <[email protected]> added the comment:
In libavformat/ffmdec.c
ffm_read_packet(...)
The ffm is received and it appears that the header is defective.
line 395 : The header does not contain one of the expected stream indexes.
The following is dump of the header.
(gdb) p /x ffm->header
$31 = {0xf0, 0x61, 0x1d, 0xc1, 0x80, 0x64, 0x8, 0x20, 0x60, 0x18, 0x0, 0xd0,
0xc9, 0x51, 0x3f, 0x77, 0x0, 0x0, 0x0, 0x0}
The first byte is 0xf0 (128 as reported).
Subsequent executions of the function continue to use this defective header in
calls to ffm_is_avail_data.
The size reported in the broken header is 11845243.
The complete packet is smaller than that so ffserver becomes stuck in the loop.
So there are two bugs here.
1) ffserver gets stuck when a defective ffm header is sent where the length
reported in the header is greater than the actual size.
2) ffmpeg is providing a bad stream.
To check to see if ffmpeg is producing a bad ffm stream I fired up wireshark to
watch the socket but I only see the HTTP/GET with a payload?
____________________________________________________
FFmpeg issue tracker <[email protected]>
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue855>
____________________________________________________
