[FFmpeg-devel] TR-03 implementation

[Rostislav Pehlivanov]

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
Explaining what pixel packing formats are to us is like preaching to the
choir.


> A solution would be to repack the samples into a compatible format, eg.
> planar. Repacking samples seems not to be an appropriate solution
> because it has an impact on performance, specially dealing with high
> resolution uncompressed streams.
>
> 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.
>

This paragraph almost made me vomit and use swear words in this email. We
don't need more broadcasting shit in ffmpeg.


>
> Could you tell us if our contribution would make sense and eventually
> advise us on the best way to address that ?
>
>
Sure:

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.

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.

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
cost you your sanity.


Now, the best advice I can give you is to talk to kierank privately on IRC
about TR03 since I know he had to deal with it.. Or to make your own
implementation up since the conversions I linked above are LGPL'd and you
could use them.