[FFmpeg-devel] TR-03 implementation

[Jan Ekstrom]

On Sun, Nov 13, 2016 at 9:48 AM, Carlos Fernandez Sanz
<carlos at 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