On Thu, Sep 21, 2017 at 11:54 PM, Joseph Van Riper <vanriper.t...@gmail.com> wrote: > > I would normally not want to request of an open source team a fast response > to something like this, but I sense some urgency to resolving this issue > for the folks who have asked me to look into it. I will feel compelled to > move forward with something by sometime next week... I just would prefer it > fit in with your recommendations to avoid wasting effort. >
You should know that some of the ffmpeg developers are at a conference this weekend, so reponses will possibly be reduced for the next few days. Generally (and definitely IMHO), writing non-standard files based on a proprietary specification for one specific piece of (apparently bad) hardware is not something we really enjoy around here. It often results in unmaintained and hard-to-test code, since correctness can only be verified with one specific piece of hardware, which may not even exist in the future anymore - even more so if its entangled in multiple components throughout the codebase. Keeping that in mind, the changes should be as self-contained and minimal as possible, anything that requires more logic in every caller that wants to create CC data seems like a bad idea already, and increases the maintenance burden. If there is only minimal differences in a header, perhaps the function should just have a flags parameter to change how it writes headers, or something like that, so that as much code as possible can be shared between alternate variants (within reason). - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
