Jim Simon wrote:It's quite old and simple codec. Something like Daniel2 should be better/modern replacement (and sort of free now).
Seems like daniel2 is only working on Windows atm, but since lots of content creators are working on Mac this means transcoding again, which is time consuming and avoiding that is exactly the reason for the feature request.
You think HAP is old? The initial GitHub commit is from September 2012, that is not that old for an codec, and it is actively developed. Up to FullHD 30MBit one of the best alternatives on media servers is still MPEG2, now that is an old codec..
Jim Simon wrote:Saying this playing 4K is not that difficult today even with ProRes, Cineform etc ( you can do it from eg. NUC based tiny player). If you have problems it's because you may be using old and crappy QT engine on PC or your app/player is not really well written.
I agree that NUC and SBC became very powerful recently, but I strongly doubt that you can play four streams of 4k 150Mbit 60fps from it. Let alone doing geometry mapping, manipulate the output with effect engines and synchronise multiple machines. This would render systems like PandorasBox, Whatout, Resolume, D3 etc. kinda obsolete and overkill with their Xeon-CPU, nVidia M4000, SSD-Raids 10GB-LAN Workstations.
Jim Simon wrote:You may be happy as ffmpeg has added HAP encoder not long time ago.
I know about ffmpeg support for HAP, but first their implementation is visually inferior to the qt-plugin by the known "native" implementations and second I want to avoid transcoding, since it costs to much time in the usual fast paced live event situations, where you have last minute changes during rehearsals, or even during the show.
Chad Capeland wrote:I've been playing back video files at live events for 20 years.
Never heard of HAP. These days, it's always H.264. It always works flawlessly.
h264 is not meant to be a " live playback" codec, it is designed for small file size and consumer robustness. So yes you can play it back quite safely, but you don't want to stress your machine with decoding to many streams at once, and you definitely don't want h264 (or any other VBR, VFR Codec) to synchronise streams.
And don't even think about syncing multiple machines to frame synced playback via network.
I could easily continue the list of where and why h264 is not suitable in lots of todays show situations, like reverse playback, "randomly" jumping timecode, low latency play and pause of clips and so on. I think you could get my point.
In such demanding situations, you want constant bitrate codecs (like MPEG2, HAP, Image sequences) with reliable and predictable playback.
Chad Capeland wrote:Strange that in 2018 HAP still uses BC3 compression.
It works quite well.
Though there is a request for BC6 integration which the dev promised to consider.
But since HAP is not meant to be the cutting edge push boundaries codec but more the LTS plays reliable type, they are quite conservative with adding features that might break file backwards-compatibility which I think is very necessary for the target users.