On 10 November 2016 at 19:44, Éloi Bail <eloi.b...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
