MP4(3)

💖 MP4ReadSampleFromEditTime — MP4 File Format Library, section 3 of the manuals 💖

okay bestie so you're deep in the MP4(3) library, and you want a sample by edit list time, not by plain old track time. This function is MP4ReadSampleFromEditTime, and she's here to serve. 🎀

---

✨ SYNTAX ✨

#include <mp4.h>

bool MP4ReadSampleFromEditTime(
     MP4FileHandle hFile,
     MP4TrackId trackId,
     MP4Timestamp editWhen,
     u_int8_t** ppBytes,
     u_int32_t* pNumBytes,
     MP4Timestamp* pStartTime = NULL,
     MP4Duration* pDuration = NULL,
     MP4Duration* pRenderingOffset = NULL,
     bool pIsSyncSample = NULL
);

like yes she takes nine arguments, she's high maintenance, and she deserves to be 💅

---

🌸 ARGUMENTS 🌸

• hFile — the mp4 file we're operating on, obvi. Tell her which file. 📁
• trackId — which track we're working with. Pick your girl. 🎵
• editWhen — which sample to read, expressed as a time on the edit list timeline. For the deets, go look at MP4GetSampleIdFromEditTime(). ⏰
• ppBytes — pointer to the pointer to the sample data. It's giving pointer-to-pointer energy. Scroll down to DESCRIPTION because this one has layers. 🫶
• pNumBytes — pointer to a variable that will hold the size in bytes of the sample. 📏
• pStartTime — if it's non-NULL, pointer to a variable that receives the starting timestamp for this sample. Caveat: that timestamp is in the track timescale. ⚠️
• pDuration — if it's non-NULL, pointer to a variable that receives the duration for this sample. Caveat: it's in track timescale units. ⚠️
• pRenderingOffset — if it's non-NULL, pointer to a variable that receives the rendering offset for this sample. Currently the only media type that needs this is MPEG video. Caveat: the offset is in track timescale units. 🎬
• pIsSyncSample — if it's non-NULL, pointer to a variable that receives the state of the sync/random access flag for this sample. ⚡

---

🔥 RETURN VALUES 🔥

• Success? true (1) — ate, no crumbs. ✅
• Error? false (0) — she's not mad, she's just disappointed. 😭

---

💜 DESCRIPTION 💜

MP4ReadSampleFromEditTime reads the sample that corresponds to a given time on the track edit list timeline, from the specified track. Then, typically, you'd decode that sample in whatever codec-dependent way your heart desires and render it appropriately. That's the whole vibe. ✨

Now. The argument ppBytes is the main character here, and she allows two possible approaches for buffering:

1. You do the buffering, bestie. If your calling application wants to handle its own buffering, it can set *ppBytes to the buffer it wishes to use. But then you are responsible for making sure that buffer is big enough to hold the sample. Figure out ahead of time how large the receiving buffer needs to be by using either MP4GetSampleSize() or MP4GetTrackMaxSampleSize(). No cap. 🧠
2. She buffers for you. If the value of *ppBytes is NULL, then an appropriately sized buffer gets automatically malloc'ed for the sample data, and *ppBytes gets set to that pointer. And guess what — your calling application is responsible for free'ing that memory. Don't leak, it's not cute. 🗑️

The last four arguments are pointers to variables that can receive optional sample information.

Typically, for audio, none of these are needed. MPEG audio like MP3 or AAC has a fixed sample duration and every sample can be accessed at random. Slay, simple. 🎧

For video, though? All of these optional values could be needed. MPEG video can be encoded at a variable frame rate, with only occasional random access points, and with "B frames" which cause the rendering (display) order of the video frames to differ from the storage/decoding order. Yes that's a lot. Yes it matters. 😤

Other media types fall somewhere between these two extremes. The spectrum is real. 🌈

---

👑 SEE ALSO 👑

MP4(3) · MP4ReadSample(3) · MP4GetSampleIdFromEditTime(3) · MP4ReadSampleFromTime(3)

---

and that's the page!! brought to you by Cisco Systems Inc., running Version 0.9 — go read the other ones too, they're all in the same friend group 🫶✨💖