What export workflow gets the best results for uploading?

I've been using Davinci Resolve about 2 years now, I love the software and own the studio version. One piece I feel I have not mastered yet is the best export settings.

I work on a Mac and I feel like I've gotten my exported footage to look almost identical to my timeline, which is great! Files I export look great to me, however when uploading to popular social media networks I feel the quality drops significantly. Colors look less saturated and sometimes I get big issues with artifacts and pixelation of my footage.

So my question is, what is your workflow for uploading to YouTube, Facebook and/or Instagram?

I'd love to know your settings and tricks used for each of the popular social media networks (YouTube, Facebook, Instagram, Vimeo)
- Resolution of video based on where it's being uploaded
- Format
- Codec
- Frame rate
- Quality
- Keyframes
- Encoding Profiel
- ETC.

Also, is anyone using other software platforms to further render before uploading? Examples would exporting from DR, then opening in Quicktime and exporting a QT file at 720p for best Instagram quality. Or using Handbrake to re-render a DNxHR file from Davinci Resolve.

Thanks for any input you have!

So my question is, what is your workflow for uploading to YouTube, Facebook and/or Instagram?

Standard Rec.709 export using Cineform and encode using x264 or x265, mostly 4k with a bitrate of about 40Mbps for H.264 or more than half of that for H.265.

in case of youtube uploads, recoding to VP9 by an external helper tool may even produce better results, because that's the main delivery format of youtube for most clients and cascaded recoding within the same family or type of codec is usually producing slightly better results. i would therefore also suggest to utilize a DCT based codec, like DNxHR or ProRes, instead of the wavelet based cineform as intermediate export format from resolve. but the actual differences caused by this alternative workflow are usually negligible small.

in case of youtube uploads, recoding to VP9 by an external helper tool may even produce better results, because that's the main delivery format of youtube for most clients and cascaded recoding within the same family or type of codec is usually producing slightly better results. i would therefore also suggest to utilize a DCT based codec, like DNxHR or ProRes, instead of the wavelet based cineform as intermediate export format from resolve. but the actual differences caused by this alternative workflow are usually negligible small.

I believe it when someone can demonstrate there is a difference.

I believe it when someone can demonstrate there is a difference.

how about this quick proof:

Code: Select all

TESTFILE=crowd_run_1080p50.y4m

ffmpeg -i $TESTFILE -v quiet -an -c:v prores -f matroska - | ffmpeg -i pipe: -v quiet -c:v libx264 -b:v 15M -f matroska - | ffmpeg -i pipe: -v quiet -c:v vp9 -b:v 2M -f matroska - | ffmpeg -i pipe: -i $TESTFILE -filter_complex "psnr" -f null - 2>&1 | grep PSNR
...
PSNR y:25.065664 u:33.289557 v:33.644779 average:27.489370 min:26.468325 max:35.922846

ffmpeg -i $TESTFILE -v quiet -an -c:v prores -f matroska - | ffmpeg -i pipe: -v quiet -c:v vp9 -b:v 15M -f matroska - | ffmpeg -i pipe: -v quiet -c:v vp9 -b:v 2M -f matroska - | ffmpeg -i pipe: -i $TESTFILE -filter_complex "psnr" -f null - 2>&1 | grep PSNR
...
PSNR y:25.102801 u:33.266273 v:33.606510 average:27.517907 min:26.422427 max:35.937598


as already mentioned before, the differences are usually negligible small -- but this is at least a more rational way do find out and verify suitable workflows...

I believe it when someone can demonstrate there is a difference.

how about this quick proof:

Code: Select all

TESTFILE=crowd_run_1080p50.y4m

ffmpeg -i $TESTFILE -v quiet -an -c:v prores -f matroska - | ffmpeg -i pipe: -v quiet -c:v libx264 -b:v 15M -f matroska - | ffmpeg -i pipe: -v quiet -c:v vp9 -b:v 2M -f matroska - | ffmpeg -i pipe: -i $TESTFILE -filter_complex "psnr" -f null - 2>&1 | grep PSNR
...
PSNR y:25.065664 u:33.289557 v:33.644779 average:27.489370 min:26.468325 max:35.922846

ffmpeg -i $TESTFILE -v quiet -an -c:v prores -f matroska - | ffmpeg -i pipe: -v quiet -c:v vp9 -b:v 15M -f matroska - | ffmpeg -i pipe: -v quiet -c:v vp9 -b:v 2M -f matroska - | ffmpeg -i pipe: -i $TESTFILE -filter_complex "psnr" -f null - 2>&1 | grep PSNR
...
PSNR y:25.102801 u:33.266273 v:33.606510 average:27.517907 min:26.422427 max:35.937598


as already mentioned before, the differences are usually negligible small -- but this is at least a more rational way do find out and verify suitable workflows...

That script only proves that a 15Mb/s VP9 is better quality than a 15Mb/s H.264 video. That is true of course, it would also be the case with H.265.

But it does not prove that using a VP9 video against an equal quality H.264 video will give a better result if it is re-encoded to VP9 because the source was already VP9. It would be interesting to run the script and change libx264 with libx265. If the PSNR results are equal (or better) than the VP9 results it would prove your proposition to be untrue.

Yep, it proves nothing.

Try uploading HD 50mbit x264 and VP9 encoded video to YT. Then download YT VP9s for both and measure PSNR against sources (and against some ProRes starting source). I'm almost sure it all will give basically same result.

how about this quick proof...

That script only proves that a 15Mb/s VP9 is better quality than a 15Mb/s H.264 video. That is true of course, it would also be the case with H.265.

well -- it's very hard to compensate this aspect in a fair manner, because you can hardly specify, how to highly compressed sources should look 'equally'. sure, if you choose really high bandwidth settings for upload, you will see much smaller differences. but for this kind of demonstrations it's even necessary, that the images already show the typical artifacts of one particular compression method, to reveal the effects of cascaded compression and the consequences of mixing different compression techniques.

using more advanced metrics could also help to make this a little bit more obvious.

here are the numbers for SSIM:

Code: Select all

SSIM Y:0.674036 (4.868302) U:0.823102 (7.522781) V:0.840604 (7.975231) All:0.752945 (6.072056)
SSIM Y:0.676602 (4.902633) U:0.824068 (7.546561) V:0.841258 (7.993093) All:0.754633 (6.101837)


i don't have a libvmaf enabled version of ffmpeg on my machine, to report this kind of metrics too.

well -- it's very hard to compensate this aspect in a fair manner, because you can hardly specify, how to highly compressed sources should look 'equally'.

I agree, that is true.

However Andrews proposed method should put the whole proposition to the test.

Try uploading HD 50mbit x264 and VP9 encoded video to YT. Then download YT VP9s for both and measure PSNR against sources (and against some ProRes starting source). I'm almost sure it all will give basically same result.

sorry -- but i personally will never sign the youtube EULA!
(and i have access to my own severs for this kind of services...)

but you could do it yourself...

but you could do it yourself...

I know but I don't think it is going to make any difference.

but you could do it yourself...

I know but I don't think it is going to make any difference.

hmm -- i don't think, it's always necessary to reinvent the wheel every day again -- so it's perfectly reasonable, if you don't waste your efforts on practical experiments, but read some useful books instead, because cascading behavior in video compression is already a well researched field.