> > You will never fit all the features of complex > > containers like MXF, MP4, TS (and for argument's sake XML) inside a > > generalised framework like FFmpeg. > > Maybe true but the reason is not that it cant be dont just that there are > features noone uses and noone needs. > I do know some video codec specs and there are bizare things in them that > arent worth the paper they are written on. > The features that are used or that people need, we must support IMO. >
No, it's not that people don't want the features, it's just that they can't be supported in an API that has been "designed" around AVI and assumed all formats follow the same paradigm. Like I said, dependent substreams in a different track can't be done. Also moving between frame attached closed captions to track-based closed captions and vice versa. How do I feed v210 into x264 directly without having to decode and do two extra memory copies? External libraries support much more advanced features of the container than trying to shoehorn it into a rigid API. And people here will have to just accept the compromise. I'm not even going to begin to touch the rest of your email with a bargepole. Kieran _______________________________________________ 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".
