[FFmpeg-devel] TR-03 implementation

[Michael Niedermayer]

Hi

On Thu, Nov 10, 2016 at 08:33:12PM +0000, Rostislav Pehlivanov wrote:
> On 10 November 2016 at 19:44, Éloi Bail <eloi.bail at savoirfairelinux.com>
> 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 what the SMPTE will adopt to start working on it.
> >
> > Radio Canada/CBC, a major Canadian broadcaster, wants to make FFmpeg
> > compatible with TR-03 and SMTPE future standard.
> >
> > Video pixel format is defined in RFC4175 (4.3. Payload Data) for YCbCr
> > format video. According to the discussion we had on #ffmpeg-devel
> > yesterday, lots of those pixel formats are not supported in FFmpeg.
> > These pixel formats are designed to group together all the samples of a
> > pixel group.
> >
> >
> Conversions and the formats already exist in another repository:
> https://github.com/kierank/ffmpeg-sdi

why have these changes not been submitted to ffmpeg-devel ?
These changes from a very quick look, look clean


[...]

> Don't try to help. Don't waste your or our time getting the existing
> conversions mainlined. Actually don't waste anyone's time at all. FFmpeg
> CANNOT support TR03.
> RFC4175 requires the ability to process huge amounts of packets which
> exceeds a gigabit per second. Let's do some math: since the packet sizes
> are 1475 bytes, this equates to around 200 000 packets per second for
> 1080i25. At which point the network stack built into most operating systems
> starts to fail and drop packets due to its inefficiency. Kernel bypassing
> is needed to do this properly in realtime. Only FreeBSD has the kernel
> bypassing framework complete in the kernel. For other OSes you need to use
> an out of tree third party kernel module. And not to mention that ffmpeg's
> RTP demuxer doesn't work all too well at all and will probably bottleneck
> the hell out of everything.

everything at some point couldnt be done easily.

I remember how decoding mp3 audio in realtime in software was
considered hard
and how decoding mpeg-2 in realtime impossible, still shortly after
that, there were software players that could do it.
I remember how people said breaking that old analouge videocrypt
requires speialized hardware (FPGAs) and be only crap quality and is
impossible oterwise.
Well i wrote my own code to decrypt it on my own average computer
back then in similar (bad) quality and color

also computers get faster every year, something impossible today
without specialized hw and kernel will be possible tomorrow

also whatever the resolution and framerate that can be supported today
the same code will do better on tomorrows hardware and kernel



> 
> So no. TR03 cannot fit into FFmpeg unless you use uselessly low resolutions
> and framerates and break everything RTP could do. No amount of "BUT I NEED
> THIS!!!11!1!!" will help you to even get kernel bypassing into mainline.
> And no amount of "BUT I NEED THIS!!!1!1!!!" will help you to rewrite the
> entire bloody ffmpeg RTP demuxer and break the few things it can do just to
> support TR03.
> 

> If you make up some bad TR03 implementation and try to post it here I will
> NAK the living hell out of it. So don't even think about it.

Noone should want a bad implementation.
We should write or merge a good implementation.
And if it cannot be done in the API or architecture then we should
fix or improve it.
If we dont want to do it, we should not stop others from doing it

But above all, lets NOT send people away, lets work together to solve
problems and make the implementation the way we prefer it. Be that
more on the fast side or more on the clean side or a compromise or ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161111/226d049d/attachment.sig>