Improved media quality in Shotgun

With the release of 8.18, the Shotgun team is progressively rolling out some transcoding enhancements over the next couple of weeks that will improve your media experience in Shotgun.

We’re doing a number of things like increasing the default mp4 transcoding to 1080p, increasing the default thumbnail size, increasing the number of frames in the filmstrip, and adding blurred preview image where possible. We will also be halting the transcoding of WebM.

We hope you enjoy your improved media quality experience in Shotgun, but if for some reason these changes negatively impact your site, please contact


Hi @warren.trezevant!

That is great news! :slight_smile: Is it possible that you can share the exact specs or command-line parameters of the generated movies? We are doing some custom transcoding at our studio and I would like to compare the settings to determine if we could switch off custom transcoding completely.

Thanks in advance!


Of course!

For video we use the following ffmpeg params:
-vcodec libx264 -pix_fmt yuv420p -vf 'scale=trunc((a*oh)/2)*2:%{height}' -g 30 -vprofile high -bf 0 -crf 23

The height variable above is the minimum between 1080 and the source resolution (so we don’t upscale).

For audio the ffmpeg params are:
-strict experimental -acodec aac -ab 160k -ac 2


Hey @warren.trezevant, curious what this feature is?

Blurred versions derived from the original thumbnails that are quick and fast to display while we wait for the images to download. You can see some examples here:

The hashed values are also available through the API (as image_blur_hash), so if you have any of your own tools/applications that are using thumbnails, you can also display a blur if you like.


Hi @nelsonr!

I was wondering weither you at some point considered using -movflags +faststart for the transcoding to speed up movie playback on the Shotgun website? And if you decided against it, what where your reasons?

Thanks in advance!


To be honest, the only reason I didn’t use it is because I didn’t know about it. After reading about what it does, the only potential pitfall that I see to using it is that if it somehow causes problems playing back the media through a non-browser players (RV specifically) that are expecting the moov atom to be at the end of the file. I suspect it will probably be fine, but I will do some tests with RV to be sure and if it works there, I will propose to the team that we add this.

Cool! Curious to see how that develops. :slight_smile:

After looking into it, we are actually using the flag. The params above are just for encoding the audio and video streams. When we assemble them into the mp4 container we use the following:

ffmpeg -y -i #{audio_stream} -t #{duration} -i #{video_stream} -t #{duration} -c:a copy -c:v copy -vsync 2 -f mp4 -movflags +faststart #{dest_file}

That makes sense since the moov atom is a property of the container and not the codecs. Sorry, I should have thought of that sooner and looked there first!

Great! Faster movie playback for everyone! :partying_face:

1 Like