On Sun, Nov 13, 2016 at 9:48 AM, Carlos Fernandez Sanz <car...@ccextractor.org> wrote: > One of the reasons apparently for not merging the SCTE-35 patch; > better never include that in ffmpeg and have the professional use and > pay for other products even though an implementation that doesn't > break anything at that has been revised 14 times has been posted here. > > Reason not to merge? None, that just it "doesn't belong to FFmpeg". > And trying to merge it is not mature.
Hi, This is completely unrelated to this specific thread, so please take it up there in that thread (and reply to the following parts of this e-mail there, please). Although I remember that the issue with timestamps not being usable yet was one of the largest blockers? The whole thing of "should this be a 'codec' or should it be side data" is IMHO also not insignificant, but if I recall correctly the timestamp ordeal was one of the major reasons for this thing not yet being in. I can recall incorrectly, of course. So you can reply in that thread quoting me if you feel like something's incorrect that I've said. As for this thread, we have already pretty much agreed both on this ML and on IRC that Ros's reply was out of line. He has apologized. The point that people were trying to make is that for the person who is going to be implementing this, the actual pixel format part is the least of one's concerns (not insignificant, but definitely something that can be solved in "one place" with enough SIMD etc). The RTP input module being sub-optimal is the more major issues (among others) - together with the pure amount of data in general that would go through the network - which might require a rework on a much higher level of how the input framework works. And that generally tends to be a much higher hurdle to get over. If someone gets it done properly in the various areas, all the more power to them, but the scope of where the person will most probably have most of their issues should be noted if already known by someone who has done related work. Additionally, depending on the needs of a use case other alternatives (which tend to use parts of FFmpeg for specific things like decoding encoded video or encoding it) such as upipe can be a simpler place to start (due to base design assumptions being different than with libavformat f.ex.). What I most definitely am not seeing is people trying to push others to proprietary solutions. Best regards, Jan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
