Hi,
In november, we wrote on the mailing list about implementing support for TR-03
in ffmpeg [1].
There were some doubts in the ffmpeg community about whether or not ffmpeg
could handle demuxing 3gbps of RTP input without significantly modifying the
RTP demuxer and/or doing kernel bypassing.
On Sun, Nov 13, 2016 at 9:48 AM, Carlos Fernandez Sanz
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
On Sat, Nov 12, 2016 at 8:17 PM, Ali KIZIL wrote:
> If someone wants to try, he can give a try, release a patch, it can be
> discussed in a discussion level. I really find saying such comments like "
> We don't need more broadcasting shit in ffmpeg." and "and it is why
> FFmpeg is full of bro
2016-11-11 0:24 GMT+03:00 Kieran Kunhya :
> >
> > sure, ffmpeg has support for many pixel formats and adding more
> > pixfmts is not a problem.
> >
> > my best answer would be to look at commits which add other pixel
> > formats and just follow how they were added to libswscale. make some
> > fate
2016-11-10 20:44 GMT+01:00 Éloi Bail :
> We would like to contribute to FFmpeg by adding the support of those pixel
> formats and thus make FFmpeg usable for the next generation of
> broadcasting products.
Sounds like a great idea to me.
Carl Eugen
___
Hi
On Thu, Nov 10, 2016 at 08:33:12PM +, Rostislav Pehlivanov wrote:
> On 10 November 2016 at 19:44, Éloi Bail
> wrote:
>
> > Hi all,
> >
> > Media broadcasters tend to move on carriage of live professional media
> > over IP. A group has been set up to recommend a standard for that, and
> >
On 10 November 2016 at 21:59, Michael Niedermayer
wrote:
> On Thu, Nov 10, 2016 at 08:33:12PM +, Rostislav Pehlivanov wrote:
> > On 10 November 2016 at 19:44, Éloi Bail
> > wrote:
> >
> > > Hi all,
> > >
> > > Media broadcasters tend to move on carriage of live professional media
> > > over
On Thu, Nov 10, 2016 at 08:33:12PM +, Rostislav Pehlivanov wrote:
> On 10 November 2016 at 19:44, Éloi Bail
> wrote:
>
> > Hi all,
> >
> > Media broadcasters tend to move on carriage of live professional media
> > over IP. A group has been set up to recommend a standard for that, and
> > they
>
> sure, ffmpeg has support for many pixel formats and adding more
> pixfmts is not a problem.
>
> my best answer would be to look at commits which add other pixel
> formats and just follow how they were added to libswscale. make some
> fate tests, and it should be done.
>
> hopefully you have tes
On Thu, 10 Nov 2016 14:44:44 -0500 (EST)
Éloi Bail wrote:
> We would like to contribute to FFmpeg by adding the support of those
> pixel formats and thus make FFmpeg usable for the next generation of
> broadcasting products.
>
> Could you tell us if our contribution would make sense and eventu
>
> The only thing which may fit would the UYVY 10bit format. But good luck
> getting the conversions adapted to libswscale. I certainly won't help you
> other than discourage you from doing it considering it is absolutely
> useless since absolutely nothing else uses that format and also it would
>
On 10 November 2016 at 19:44, Éloi Bail
wrote:
> Hi all,
>
> Media broadcasters tend to move on carriage of live professional media
> over IP. A group has been set up to recommend a standard for that, and
> they produced the TR-03. It is only a recommendation, but it should be
> close enough to w
Hello,
> We would like to contribute to FFmpeg by adding the support of those pixel
> formats and thus make FFmpeg usable for the next generation of
> broadcasting products.
>
So as someone who has been working on this for 6+ months this won't work,
the Gbit/s of data coming in over the network
13 matches
Mail list logo
