Commit 5e57424d authored by Philip Gladstone's avatar Philip Gladstone
Browse files

Fix the WAIT_FEED problem. It turns out that when you open up an FFM

file and seek to an FFM packet, then it is important that the packet
found has a frame header within it. If not, then terrible things happen.
This fixes the problem.

Originally committed as revision 513 to svn://svn.ffmpeg.org/ffmpeg/trunk
parent 9c80daf1
......@@ -301,6 +301,7 @@ static int ffm_read_data(AVFormatContext *s,
if (len == 0) {
if (url_ftell(pb) == ffm->file_size)
url_fseek(pb, ffm->packet_size, SEEK_SET);
retry_read:
get_be16(pb); /* PACKET_ID */
fill_size = get_be16(pb);
ffm->pts = get_be64(pb);
......@@ -310,7 +311,18 @@ static int ffm_read_data(AVFormatContext *s,
/* if first packet or resynchronization packet, we must
handle it specifically */
if (ffm->first_packet || (frame_offset & 0x8000)) {
if (!frame_offset) {
/* This packet has no frame headers in it */
if (url_ftell(pb) >= ffm->packet_size * 3) {
url_fseek(pb, -ffm->packet_size * 2, SEEK_CUR);
goto retry_read;
}
/* This is bad, we cannot find a valid frame header */
return 0;
}
ffm->first_packet = 0;
if ((frame_offset & 0x7ffff) < FFM_HEADER_SIZE)
abort();
ffm->packet_ptr = ffm->packet + (frame_offset & 0x7fff) - FFM_HEADER_SIZE;
if (!first)
break;
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment