The Softron playout applications can support a large number of codecs and formats. This can be very flexible if you are a producer that receive new content just a few seconds before putting them on air. But this can also be the source of stress for the cautious broadcaster.
Indeed, these files can present some particularities that may create issues when playing them:
- the file can be corrupted
- there can be some black frames, distorted video frames or distorted audio that was not noticed
- AV Sync issues
- the codec is supported by the playout application, but the way it is encoded make it very hard to decompress by the playout application, leading to drop frames, etc...
In order to make sure that these issues do not happen when the file is on air, try to follow the good practice rules as much as possible.
HOW are your files created ?
Nowadays, editors can create files from their editing solution, or it can have been recorded by a field recorder, or exported from the animation software, or encoded by an encoder. All these software can encode the file differently, and even if the same codec and format is chosen, the files will be different and thus may behave differently when played.
Choose the best codec for you
Some codecs, such as H.264, are nice because they do not use a lot of space, but there are many ways a H.264 can be encoded, with hundreds of settings. Some files (with longer GOPs for example) may be harder to decode by our playout applications, and thus use more resources until sometimes dropping frames. We try to test many different type of H.264, but it is impossible to test all.
So if you can afford it, try to avoid H264 and if your storage allows it (and storage is getting cheaper and cheaper), we would recommend sticking with a codec such as the Apple ProRes (LT) codec. It is not the lightest in terms of storage, but in terms of efficiency (it is quick and easy to encode and decode), it is unbeatable on the Mac. It is also the most reliable, we have almost never seen an issue with a ProRes file (except maybe with a corrupted audio track, but that was the audio).
The best solution: validate a way to create your files and stick to it!
To be sure not to run on a specific issue when a file plays, you should validate one single way to create your files. With one application, one setting, one format.
Run a few tests, create a few different settings and workflows, and:
- Of course first check the quality of the resulting file. If it looks bad, it is not worth ;-)
- Check the time it takes to encode a file. Make sure it is reasonable. If you end up with a setting that takes too long to encode, you will loose efficiency in your production.
- It should also be easy for all the persons that will need to give you videos.
Then try to play the different files in one of our playout applications (you can use a demo version for that) and check:
- That the files are shown as valid in the playlist. They will either not be accepted or be shown as "offline" if something is not supported.
- When you play the files, check if the output (Video and Audio) is correct. You can either use a real video output (AJA, Blackmagic-Design), or use the Direct Link with MovieRecorder
- When you play the files, open the "Logs window" (more info on this log window here) and check:
- that there are no logs shown saying that we could not decompress some frames, or frames were duplicated, etc...
- check the various gauges, and more importantly the "Reading" and "Decompression" gauges. The smaller they are, the easier it is for the application to decompress the frames. Try to choose a format and codec that is as light as possible to decompress
- Open the application "Activity Monitor" and check how much CPU is used to decompress. Again here, use as little CPU as possible
When you run these tests, test as much as possible in a "real life" situation with for example:
- The same Mac you will use. There can be different behaviour if you test on a Mac Pro than if you test on a Mac mini or MacBook Pro. For example with H.264, the Mac Pro does not have a hardware acceleration chip to decompress H.264, while other computer mostly do.
- The same type of storage. Obviously the behaviour will be different when reading from an SSD or from an Xsan, or a NAS, depending on the block size, and many other things
- The same type of video file. Don't test with color bars, use the same videos you will use. IT is easier to decompress a colour bar than other type of moving images.
- The same version of the playout application. We sometimes address issues with specific files, so make sure that the version you use for your tests is the same as the one used for the playout.
- The same type of video device. This is less important, and you could run tests with a "Virtual output", so you don't need to have a video device to play out. But there can be device specific issues, though it is quite rare...
- Audio is important too. Sometimes the audio is left on the side, but an audio track can create issues too, so again test with the same audio configuration.
Once you have validated that, make sure that everybody in the company follow the rules to create the files. This is the best way to make sure to have smooth playback in all cases.
If you receive files from other companies, check them!
If you receive files from other companies and you don't know how they were created, and if you can't have them go through your own workflow, you should at least validate the file with a demo version of one of our playout application.
If you don't have the time to check them
We know this happens in some last minute scenarios. Then, well just cross fingers. In most case it should play just fine...
What if some files don't play correctly in a Softron playout
If it does not play fine, try to play it with other playback applications such as VLC or QuickTime (X and/or 7). If it does not play with these applications either, then there is most probably an issue with the file. If it plays correctly in these applications, please contact the support and send us that file if it is not too large, and at least send the logs of the Softron application when you played it.