[mad-dev] mad_header_decode() and MAD_ERROR_BUFLEN
Sat, 17 Nov 2001 02:21:43 -0800
For non-mmap'ed input implementations, I have encountered a
situation where due to a truncated last frame, an infinite loop
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..
John Cooper firstname.lastname@example.org