Hello,
I am a digital cinema engineering student working with new DCINE tech on my campus. We have a Dolby IMS3000 media block that supports H.264 for digital cinema, or "event" packages that consist of a DCP with H.264 encoded MXF image track files.
The MPEG 2 standard was used in the past - and not supported here in DCPomatic from other threads that I've seen. However, I am curious about the viability of introducing H.264 encoding support within DCPoMatic - how complex would this be to accomplish?
Dolby is currently the only entity that supports encoding/decoding this format through their CIneAsset software and the IMS systems. I would like to prompt conversation on this thread about utilizing this non-standard format in an open-source manner.
Thanks,
Andy
H.264 for Digital Cinema Support (Dolby)
Re: H.264 for Digital Cinema Support (Dolby)
It would probably depend on whether the supporting libraries we use (mainly asdcplib) support H264-encoded track files. If that support were present, or could easily be added, it would make life a lot easier.
The other question would be how widely-used these files are, since it may be a lot of work for something that very few users are interested in.
An example of one of these DCPs would be useful, if you have such a thing?
The other question would be how widely-used these files are, since it may be a lot of work for something that very few users are interested in.
An example of one of these DCPs would be useful, if you have such a thing?
Re: H.264 for Digital Cinema Support (Dolby)
There are some servers supporting alternative content codecs. I have rarely seen this being used actually within MXF containers. Very often these codecs are aimed at supporting live broadcasts and are based on common satellite/cable DVB codecs. The idea is e.g. to stream DVB over IP to these servers and let the server decode the live feed locally. The MXF file option may be used for replay/time shift presentations of the same content.
Honestly, I see little need to have this as an option in DCP-o-matic. For MPEG2, it was a practical option because there was a transition phase where e.g. advertising content was readily available in MPEG2, and only a rewrap was necessary. Also, the computational effort to create high-quality h.264 is not too far away from the effort to do J2K. The content created can then only be played back on very few servers supporting this very format.
I also think in general that it is not helpful to increase the codec varieties in digital cinema. We should all be glad that DCI managed to save digital cinema from codec hell.
- Carsten
Honestly, I see little need to have this as an option in DCP-o-matic. For MPEG2, it was a practical option because there was a transition phase where e.g. advertising content was readily available in MPEG2, and only a rewrap was necessary. Also, the computational effort to create high-quality h.264 is not too far away from the effort to do J2K. The content created can then only be played back on very few servers supporting this very format.
I also think in general that it is not helpful to increase the codec varieties in digital cinema. We should all be glad that DCI managed to save digital cinema from codec hell.
- Carsten