Demuxing incomplete packet

[sscobici]

I have a CAF file with the IMA4 codec, which is currently not supported.

I have some questions about how the demuxer should handle incomplete packets.
The IMA4 codec has a fixed number of 64 frames per packet. For mono audio, each frame is 4 bits, and the packet size is 34 bytes: 2 bytes for the preamble and 32 bytes for frame data.

The CAF file format can specify the total number of valid frames. For example, consider a file with a single 34-byte packet where the metadata indicates that only 5 frames are valid.

How should this packet be returned? Here are the options:

1. A buffer of 34 bytes with a duration of 5.
2. A buffer of 5 bytes (2 bytes for the preamble and 3 bytes for the frames) with a duration of 5.

Now, imagine it’s a stream, and the demuxer has only managed to read 3 bytes. Should the demuxer:

• Return this incomplete packet of 3 bytes and specify a duration of 5? ( it will be hard to calculate the actual duration in demuxer for 5 bytes)
• Report the end of the stream?
• Return a retry code (in case support for this scenario is added in the future)?

Should this behaviour be consistent across demuxers which support incomplete packets?

[pdeljanov]

A demuxer should always yield complete packets as they are muxed. In this case, it sounds like the IMA4 codec always produces/consumes 64 frame packets. Therefore, 64 frame packets should've been muxed into the file, thus, when demuxing you should yield packets containing those 64 frames.

Now, duration is a trickier because here the concept of gapless playback comes in. Yes, the encoded duration is always 64 frames, however, the container may signal that not all of those 64 frames are valid. In your example, the container indicated that only 5 are valid. This is where the trim_start and trim_end fields of Packet come into play. These indicate to the decoder how many samples to slice off the decoded buffer at the start and end.

Gapless playback in Symphonia can be enabled or disabled, so there's a fork in how a demuxer populates packet based on that option.

If gapless playback is not enabled:

• dur = 64
• trim_start = 0
• trim_end = 0

If gapless playback is enabled:

• dur = 5
• trim_start = 0
• trim_end = 59

Note that in both cases all 3 fields sum to the total encoded duration of 64.

For the demuxers and decoders that support gapless playback, this is the current behaviour.

---

In regards to the next part: If you encounter an end-of-file (EOF) condition before you finish reading a complete packet, then the expectation is to return an UnexpectedEof error. Only return None from next_packet when you know for certain the stream is done.

Hope this helps!