Michael Niedermayer (12023-08-04): > Everything is there for a reason. > Every part of mp4 has a use, still we extract the data and setup various > structs like AVStream, AVPacket, AVProgram and so on. > We do not return raw mp4/mov atoms > the seperation between programs in a stream of bits/bytes looses meaning > once the frames are in AVPackets with AVStream/AVProgram. > If there is more data in any framing that people want, theres a wide range > of ways to preserve and export that data. > OTOH outputting AAC in TS or AAC is other framing is painfull to handle > especially when it is muxed into something again. because it then needs > the right framing and even if it comes in as DAB framing and the output > wants DAB framing, it is unlikely everything in the framing will be correct > for the output. > The same is true for TS. I surely can take raw TS from 3 programs but if > i just take these and concatenate them into something that suppports TS > thats quite likely going to blow up somehow. > All this framing stuff should IMHO be "removed" on the demuxer side > usefull data be extracted and properly exported. And if anything > on the muxing side needs something similar it needed to rebuild it all. > > I may be missing something but i dont think the raw framing is too usefull > to the user.
I recommend you do what feels most simple, or most elegant, or most logical, whichever feels right. If somebody else, or you later, find a use for the framing, the code that removes it can be turned into code that extract information from it or reshape it. If and when that happens is the good time to figure out how to bring that information to the user, because that will be when what is necessary will be known. This is why the demands that you design a clean API first are absurd: at this point, you do not know exactly where this code is going, what kind of information or control you will need to expose. All this depends on which direction the codes takes, which in turns depends on you inspiration. And as the code progresses, the necessary API will emerge, and at one point it will be just a matter of thinking on it carefully to cut it cleanly. I suppose this is what the buzzword-living industry calls “agile programming”. But the industry cannot do it right because it needs return on investment quick. Only a real Libre Software project like FFmpeg can do that. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
