The Semicolon Saga: Navigating Standards and Real-World Implementations in Broadcast Engineering 🚨 In broadcast engineering, even the tiniest details can cause massive headaches. Recently, I found myself deep in the weeds of one such issue: a missing semicolon in an SDP file from Ross Video's Ultrix platform caused a Blackmagic Design receiver 🎥 to misinterpret a 1080i50 stream as 1080p25, leading to a cropped and incorrect display. Not cool. After some serious troubleshooting 🛠️, I discovered that simply adding a semicolon at the end of the a=fmtp line in the SDP magically fixed everything. But hold up—it wasn’t just a quick fix; it sparked a deeper discussion about standards like SMPTE ST 2110 and our old friend, RFC 4566 📜. Curious to see how others handle this, I did a little digging 🕵️♂️. What did I find? A mixed bag of SDP examples from all over the internet—some with the semicolon, some without... Whether it's examples from brands like RIEDEL Communications 🎯 or various open-source implementations (GitHub projects & cie..), there seems to be no consistent approach. This inconsistency only highlights the grey area we're navigating when it comes to these standards. When I reached out to the pros at Ross Video, they confirmed that RFC 4566 requires semicolons to separate parameters, not necessarily end a line. But, and here’s the kicker, examples in different parts of the standard are inconsistent 🤷♂️—one shows a semicolon at the end, another doesn’t. This ambiguity leaves us in a tricky spot where device behavior can differ based on interpretation. Ross Video’s team acknowledged the dilemma: adding the semicolon might solve the problem with Blackmagic Design, but it could also break other workflows where the semicolon isn’t expected ⚖️. This is the balancing act we face in our industry—ensuring that standards are followed while being flexible enough to handle variations. This journey highlights the importance of open communication 🗣️ between engineers, manufacturers, and standards bodies to prevent minor inconsistencies from causing major issues. It also underscores the need for device flexibility to ensure smooth interoperability across the board. In the end, this experience is a powerful reminder that in our field, every character matters—sometimes even a single semicolon can make all the difference 💪. Hope all these industry players can find a common path forward... 🙂 But for now, it's on to the next big challenge: the Belgian local elections! 🇧🇪 At notélé, we're pushing the boundaries with a cutting-edge project fully based on ST 2110 for our debates and election night coverage. Exciting times ahead as we use and abuse this powerful standard to deliver top-notch broadcast experiences! #BroadcastEngineering #ST2110 #SMPTE2110 #SDP #RossVideo #BlackmagicDesign #RFC4566 #Interoperability #PrecisionMatters #EngineeringLife David Ross Blackmagic Design David MOSCA Robert Vander Meulen DigiNet
Open standards means being resilient to other interpretations of the standard. Who’s to blame here ? From my opinion: the receiver, always, as it has to accommodate various SDPs. It’s easy to be compatible with yourself (e.g.: <put any closed ecosystem here>).
Don’t forget that there’s also supposed to be a trailing space after the last semicolon on that a=fmt line. sdpoker (search. It’s on GitHub) is a great resource for checking compliance to “must” and “may” items in the SDP spec.
Well spotted, sir, and thanks for sharing.
Technical Director @ Notélé
2moSince several people have asked me for examples in private, I’m taking the liberty of doing a quick recap/addition in the comments: here are two examples of SDP retrieved via NMOS dynamically. The SDP from the SFP MUON (Riedel) works in a BMD receiver, while the other one only partially works (the interlace flag is not recognized). If you search online, you’ll find examples of SDP both with and without the semicolon (‘;’). It’s hard to navigate, both for manufacturers and clients. Maybe it's up to the manufacturers to handle both cases? 🙂