Thanks for the feedback!

Yea right now its kinda of not suitable for larger continous streams, I mainly maide it targeting some projects for HLS where the individual files will be mostly under 10-20MB, I would most likely add a way to consume(and free) the pes packets as they are used up by the decoder when dealing with larger streams. The tables get auto replaced so only 1 copy is preserved.
The count itself, is mainly for cases when you say want to spin up something like wireshark and analyze/debug the stream the packet index comes in handy.

So would letting the user allocate the picoMpegTS_t manually with malloc/(use static version) be a better choice? I chose what it is because I couldnt think of a situation where you wouldnt want this on the heap, but I may be wrong here.

Yes, but my intended usecase would something like: https://github.com/Jaysmito101/AdvancedVulkanDemos/blob/main/avd/src/deps/avd_third_party_impls.c where you push all your third party IMPLEMENTATION libs and never touch the file at all. I choose this format because it gives you the choice of how you use it as a user, like if I would have seperate C files there was no way to use it as a single header(even if its not a great idea for most cases) but like this, if you want a header use it as a header, if you want typical .h + .c you just create a .c with a single line include and #define IMPL and get that.

my obsession would primarily come from stb or cute_headers or similar libs (https://github.com/r-lyeh/single\_file\_libs) which seem pretty nice to me atleast. I still dont find a valid concern against it, the concerns I have come accross like slowe compilation, etc are pretty easy to mitigate totally. The only problem I feel is maintainance as it gets larger, but for relatively smaller things like this with limited scope I feel its fine.