[FFmpeg-devel] [PATCH] ffm packet synchronization lost

[Steve Webster]

This message is a resubmission, because I didn't submit correctly the 
first time. The patch is in-lined and an explanation follows afterwards.

Thanks,
Steve

Index: libavformat/ffm.c
===================================================================
--- libavformat/ffm.c	(revision 11463)
+++ libavformat/ffm.c	(working copy)
@@ -359,7 +359,8 @@
                  return -1;
              /* if first packet or resynchronization packet, we must
                 handle it specifically */
-            if (ffm->first_packet || (frame_offset & 0x8000)) {
+            if (ffm->first_packet || (frame_offset & 0x8000)
+                || (ffm->read_state == READ_HEADER && frame_offset && frame_offset - FFM_HEADER_SIZE != size)) {
                  if (!frame_offset) {
                      /* This packet has no frame headers in it */
                      if (url_ftell(pb) >= ffm->packet_size * 3) {
@@ -367,6 +368,8 @@
                          goto retry_read;
                      }
                      /* This is bad, we cannot find a valid frame header */
+                    ffm->packet_end = ffm->packet;
+                    ffm->packet_ptr = ffm->packet;
                      return 0;
                  }
                  ffm->first_packet = 0;

On Tue, 8 Jan 2008, Steve Webster wrote:

> Greetings,
>
> I have written an application that encodes synthesized video and provides it 
> to ffserver in a similar manner to ffmpeg. However, I've noticed 
> synchronization errors while reading ffm data. I've attached a patch to 
> address these issues, and I'm looking for feedback.
>
> One issue occurs when reading the first header, when encountering a frame 
> that does not include an offset in the initial packets. A frame header can 
> not be found, and the ffm_read_data returns 0. However, the FFMContext 
> pointers are not reset, so the ffm_read_data succeeds on a subsequent read, 
> regardless of whether the header is next to be read. I've reset the 
> FFMContext pointers upon this case, which appears to handle this case.
>
> The other issue is a loss of synchronization when ffserver is under load. 
> Essentially, the size to be read does not align with the next header, as 
> indicated between a mismatch of offset and size. I've spent days trying to 
> understand why synchronization can be lost, so I'm hoping someone here will 
> have some insight into the root cause. My patch only addresses the symptom, 
> by trapping and recovering from the loss of synchronization.
>
> Thanks,
> Steve