On Thu, Sep 21, 2017 at 6:25 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >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.
Ah, I would not have known that. Thank you! > 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. I cannot speak to the merits of the hardware, only that it is apparently well-used regardless of its merits (in that this particular issue I seek to resolve costs someone a lot of money, and that Microsoft resolved this issue in their filters, which suggests MS felt it worthwhile). DirecTV supposedly used their own header format because they could not wait for a standard to be determined, at least from what I've read. But... eh... I'm just trying to solve a problem. > 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). I agree. I would prefer not to sprinkle changes throughout something if I can avoid it. Unfortunately, unless someone with more of a background in this code can correct me, I don't see a way to avoid touching (if lightly) several modules. I view your recommendation to pass another argument to the existing function as potentially more damaging (if only slightly) than my approach. I still would need to alter code through several modules to either pass one argument or another, or to call one function or another. The logic in both cases is fairly equivalent. I can alter the original function, which would make it more difficult to untangle should one desire to revert to the original (not impossible, just kind of an annoyance), or have another function, which you could avoid calling, or stub out (#def?). In both cases, one is having to touch code in several places throughout the library to ensure either that the code is called the right way, or the right function is called. While I'd call this very light touching in either case, I'd still need to sprinkle changes in several modules. If this code were organized in a way where the configuration options were distributed to the various modules using the same structure, I could do a variation of what you propose where I'd alter that configuration structure with another value, and react to that. I'd wholeheartedly agree that it's the better approach (as I wouldn't need to touch much code at all). The piece that configures things would simply provide the structure, and the other bits would pass that structure into the function whose signature wouldn't even have to change. Then, yes, I wouldn't have to touch much, just something to inform the preferences structure of the new value, and the function itself. Unfortunately, this isn't the case. Each module seems to use a different structure, and would require touching in some fashion. If I'm already forced to touch a lot of code lightly, I would think it preferable to minimize the potential damage to the one function by writing another, than to both alter a lot of code (if lightly), and modify something we know is working perfectly well to accommodate this change. But, I'll approach it any way the team desires. I'm not as familiar with the rest of the code, so maybe my concern about configuring this stuff isn't well founded. Ultimately, I just want to solve this problem. - Trey _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel