This week say another Digital Production PartnershipInteroperability Day. It was bigger and better than all the ones that went before. More importantly it seems that interoperability is going beyond simple video and audio and is including themetadata that is exchanged along with the file:

We’re seeing more device types being DPP-native. It’s no longer just transcoders and players – there are ingest devices, servers and QC tools that are all becoming DPP aware.

The work that’s going on within the Digital Production Partnership is attracting a room full of people that exceeds the borders of the UK. The topic is important enough for vendors to fly in from Europe and for multi-vendor testing to exercise the whole stack, not just the MXF layer. If you’re a follower of twitter, then a running commentary of the day is online and it makes interesting and very positive reading. Are we in good shape for the October file delivery deadline? Yes, I think so.

There is still work to do in the UK though. There was interesting discussion on the nature of the specifications and the fact that bitstream compliance does not 100% guarantee that everything will work. Vendors are forced to provide option switches that control behaviour depending on the context of the operation. AmberFin was willing to share a use case with the group. We made some DPP files. No-one found any errors in the file and they appeared to meet the specification. A layout server was able to play them, but there appeared to be an interesting behaviour when it came to queuing to Timecode and overlaying Timecode. It seems that the playout server was taking Timecode from two different places in the file – one mandatory and one optional. This makes perfect sense for the way in which the server was configured, but the fact that the optional Timecode was not in the file caused an error.

Well Bruce, I hear you say, why not put the optional Timecode in the file and make the server happy without having to change its configuration? This is indeed what we did via configuration of ourtranscoder BUT this may potentially be dangerous in a complex workflow. By inserting a frame-by-frame Timecode that is optional, we have now increased the chances of Timecode discontinuities downstream. Someone may edit the file next week, next month or next year. Because the optional Timecode is not looked at by all software devices, the edit may well create a discontinuity in the embedded Timecode that is not picked up until it reaches the playout server in a week, a month or a year. Worse still, the discontinuity may be localised to the end of the file and a 3 spot check would never pick it up.

This was a good topic of conversation amongst designers, specification writers and the operational staff who have to cope with these issues. It’s clear that the DPP’s delivery specification is a powerful interoperable tool for UK based file delivery. It’s also clear that as an industry we have to start looking at the behaviour rules of software so that we can make systems that have long term stability. It is not enough to have compliant bitstreams to guarantee system stability.

I continue to be proud to work with the DPP and as Andy Quested of the BBC pointed out – it must be working because staff in some of the post houses have enough time to create funny videos.

I am sure at NAB there will be lots of talk about future HEVC projects, but for me the real action is tangible changes in our business with files truly replacing tapes and the improved connectivity between business processes using assisted, unified QC to transfer trust between organisations. If you want to know about HEVC, then feel free to download our white paper, but if you prefer to recognise the importance of trust transfer between businesses then our UQC paper might be more interesting.

See you at NAB.

I hope you found this blog post interesting and helpful. If so, why not sign-up to receive notifications of new blog posts as they are published?