Yes HuffYUV is butter smooth for me but I’m using an PCIe SSD for my videos while editing at 4k so reading more data from disk isn’t a big deal. No i’m not using reduced sizes proxies. The lack of compression between frames seems to help although H264 wasn’t exactly slow on my tower either.
What are you trying to do with it? You don’t edit with it. You edit in whatever format it comes in, presumably H.264 if it comes from a camcorder, orpossibly even MPEG-2 or AVCHD. You then make a Huff YUV interpositive by exporting your edited master. You have to export the edited master to a file in order to upload it to YouTube. Why introduce another generatoin of lossy compression at this stage?
My question had nothing to do with uploading to youtube. It was purely about playback speed. I thought I recalled D_S saying before on another thread that playback with HuffYUV is snappy for him. I haven’t experienced that so I asked to confirm.
Whoops sorry for the disinformation regarding “standard” being visually lossless. I should have checked that.
To be fair to you, standard mode should still look really really good. It should hold up well for a few generations before falling apart. It shouldn’t look night-and-day worse than FFV1 provided it gets the bitrate it needs. But if pushed hard in color grading or something, then yes, the breakdown is visible faster. If you aren’t getting quality that good from standard mode, then maybe the codec implementation being used isn’t up to Apple standards, or something else in the configuration is choking it.
Also I went back and found it, uncompressed audio at 48khz(so wav PCM) could also help performance, I have noticed the waveform takes a while to build and am going to try that next project
1 Like
I don’t know what this means. If it’s not playing back at the correct speed the movement in the picture and the audio will give it away. Is that what you mean by “playback speed”?
He’s talking about in the shotcut UI, technically “preview speed” would be a more appropriate term, it’s not uncommon for this to be below realtime on slow systems or in complex edits even in big commercial products like adobe premier
So get a faster computer 
Yup. 
Although I don’t have a slow computer. Then again I was testing HuffYUV on a movie file that was over 2 hours. I don’t know if that makes a difference. When I dragged it in it took a long time for it to load and after that it also took a long time for it to load to the timeline. It plays fine after that unless I made any edits then it took a while to load again.
When you are working with HuffYUV, are you using the Shotcut preset or do you do your own HuffYUV exports with a different audio codec? The Shotcut HuffYUV preset uses FLAC audio. Maybe that’s making it run slower since it’s compressed lossless audio?
By the way, thanks for posting the link to that thread.
I just tested dragging the big HuffYUV movie file to Shotcut but with no audio track and it ran just as slow for me. So it isn’t FLAC. This is very curious because your description of your experience with HuffYUV is pretty much my experience with Ut Video. Ut for me runs unbelievably fast and smooth in Shotcut and I tested Ut with huge files that came out to almost half a terabyte. It’s pretty shocking to me how well it still runs with huge sized files. That’s why I’ve grown quite fond of Ut and have been experimenting a lot with it. This is the reason I am very disappointed that chris319 talked about finding color inaccuracies with it which I hope can be remedied ASAP. Have you tried Ut yet?
What happens if you play that HuffYUV file in another player?
You mean like a media player such as Potplayer or VLC? Perfectly fine. Maybe there are settings in Shotcut that would make a difference in the loading of HuffYUV files?
I generate my HuffYUV files with Tencoder which was generating 128bit 48khz AAC LC audio along side it, I plan to try using 48khz WAV instead next time, FLAC while great is probably causing more harm than good here as anything you gain by removing inter frame compression you throw away with very complex audio.
As a test, can you generate a HuffYUV file with Shotcut’s lossless preset and see if it runs any differently for you in Shotcut than HuffYUV files from Tencoder?
I can indeed, for refrence these are the 3 files(original, tencoder and then the one from shotcut) other than 29.97 vs 30fps and the audio being FLAC with the shotcut export everything looks the same.
Immediately on loading I can tell a difference between the tencoder and shotcut versions due to a massive increase in delay building the waveform.
However after that is complete playback is smooth again although I can imagine editing would be a touch bumpier as anything that caused the waveform to rebuild would take additional time. Furthermore tencoder has a “direct copy” option for audio which based on what mediaencoder is using must have been what I selected(I’d never actually pick AAC intentionally)
Could it be a disk performance issue? I keep my files on a PCIe NVMe SSD when editing.
1 Like
Thank you, @D_S. This description reflects my experience with the HuffYUV lossless preset in Shotcut. Following the long loading after both dragging the file to Shotcut and bringing the file down to the timeline, playback is just fine unless I make edits to it in the timeline. None of that is the case with Ut Video which runs just about as smoothly as any file can in Shotcut no matter the size of the Ut file. Ut Video is really something. Have you experimented with the Ut lossless preset in Shotcut?
Honestly no, and I probably won’t since I use Tencoder or Hybrid to process the media files before editing since I can feed them a batch of files and off they go. I haven’t had a new project(yet) to try UT video but will give it a try later this week when I have an audio mixer review and new microphone to review.
That is incorrect. Nothing passes through un-transcoded. You cannot even download your original. How do I know? Because, I used to work for a video streaming company and knowledgable about things like adaptive bitrate streaming over HTTP (DASH, HLS, etc.) In order to ensure that these streaming formats work correctly, they need to have a strict GOP and keyframe alignment between each bitrate/resolution. It is fundamental to how they operate, and nothing that is uploaded can be considered trustworthy.
Did you account for the fact that waveform data (technically, it is audio RMS data and a graph of that and not truly a waveform) is cached in a database only when completed? Maybe the one file has its data cached and the other does not.