Hi On Thu, Nov 10, 2016 at 08:33:12PM +0000, Rostislav Pehlivanov wrote: > 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
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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
