[mad-dev] mad_header_decode() and MAD_ERROR_BUFLEN

[john cooper]

Hello,
    For non-mmap'ed input implementations, I have encountered a
situation where due to a truncated last frame, an infinite loop
occurs.

Where mad_header_decode() returning MAD_ERROR_BUFLEN is interpreted
as "need more input", my input caching routine continues to return
the unconsumed partial frame.  mad_header_decode() says that's not
enough and the process just goes on.

The complication I have here is my input routine is a random access
input cache routine and doesn't know an EOF has truly occurred until
input data is requested beyond the end of file.  Thus seeking N times
to a partial last frame (or any other frame) could happen.

One ugly hack I have found to avoid this is to increase the 8 byte
zero pad sufficiently to satisfy mad_header_decode()'s internal buffer
length validation.  Whereupon an attempt is made to seek beyond the
input length and an EOF can be detected.  Another approach is to
detect two MAD_ERROR_BUFLEN occurrences at the same address without
any other intervening repositioning of the input.  The latter is
arguably more safe, yet if mad_header_decode() had some way to
indicate how much input it was expecting for the current frame,
a cleaner solution is possible.  This calculation of N bytes exists
in the routine.  Stuffing this into a new stream structure member
would be one possibility..

Any suggestions?

Thanks,

-john

-- 
John Cooper   johncooper@tivo.com