By:
Paul Pettit <p.t.pettit@sussex.ac.uk>
Multimedia Development
University of Sussex
h4.As requested, here are the encoding profiles we use:
h5.HQ presentation:
{noformat}
-threads 2 -i #{in.video.path} -strict experimental -f mp4 -threads 8
-codec:v libx264 -preset fast -profile:v baseline -crf 22 -r 25 -pix_fmt
yuv420p -codec:a aac -cutoff 11000 -ac 1 -b:a 48k -ar 22050 -movflags
faststart #{out.dir}/#{out.name}#{out.suffix}
{noformat}
h5.LQ presentation:
{noformat}
-threads 2 -i #{in.video.path} -strict experimental -threads 8 -f mp4
-codec:v libx264 -filter:v scale='trunc(oh*a/2)*2:360' -preset fast
-profile:v baseline -crf 22 -r 25 -pix_fmt yuv420p -codec:a aac -cutoff
11000 -ac 1 -b:a 48k -ar 22050 -movflags faststart
#{out.dir}/#{out.name}#{out.suffix}
{noformat}
As you can see, we use -crf (constant rate factor) instead of specifying a bitrate. this means we generally end up with pretty small files as there is not much motion in the majority of powerpoint slideshows. We scale to half the vertical resolution for the low quality version but leave the crf the same, so there are no more compression artifacts, just lower resolution.
Scale size is fixed here as we know that from galicaster we always get 720p video but for user uploaded files we use the original files frame size up to a max of 720p (scale='trunc(oh*a/2)*2:min(720,ih)') for HQ, and half the original frame size up to a max of 360p (scale='trunc(oh*a/2)*2:min(360,trunc(ih/4)*2)') for LQ. the extra maths is because widths and heights have to be divisible by 2 in h264.
Audio is mono'd and run through a 11kHz low pass filter as we are encoding at 22050Hz.
The faststart creates an index so streaming using the <video> tag works nicely on mobile.
The threads stuff (2 input, 8 output) is because on our 64 core worker machines we were running into default process limits in the OS (ffmpeg seems to use 1.5*cores as it's default thread count!). we have since fixed that so it might be worth increasing the threads, though after a certain amount you really don't gain much from extra threads anyway.
h5.HQ presenter:
{noformat}
-threads 2 -i #{in.video.path} -strict experimental -threads 8 -f mp4
-codec:v libx264 -filter:v yadif,hqdn3d,scale='trunc(oh*a/2)*2:480'
-preset fast -profile:v baseline -crf 21 -r 25 -pix_fmt yuv420p -codec:a
aac -cutoff 11000 -ac 1 -b:a 48k -ar 22050 -movflags faststart
#{out.dir}/#{out.name}#{out.suffix}
{noformat}
h5.LQ presenter:
{noformat}
-threads 2 -i #{in.video.path} -strict experimental -threads 8 -f mp4
-codec:v libx264 -filter:v yadif,hqdn3d,scale='trunc(oh*a/2)*2:240'
-preset fast -profile:v baseline -crf 21 -r 25 -pix_fmt yuv420p -codec:a
aac -cutoff 11000 -ac 1 -b:a 48k -ar 22050 -movflags faststart
#{out.dir}/#{out.name}#{out.suffix}
{noformat}
Very similar to presentation, but with the addition of deinterlace (yadif) and denoise (hqdn3d) filters. we tried using the hardwaredeinterlacing on the datapath capture cards but it doesn't seem to work too well so we do it here. the denoiser drastically shrinks file size, as most of our theatres are very poorly lit and the encoder has a hard time with noise. here we use 480p for HQ and 240p for LQ as our cameras are SD PAL resolution (user uploaded files get the same max 720p/360p as above).
Our galicaster recordings are typically 70-80MB for HQ presentation, 30-40MB for LQ presentation, and 10-20MB more for the presenter as they are less compressible even with the noise filter). i found frame rate didn't have a huge impact in file size so we left it at 25 so when people do play bits of video etc. it still looks nice (but at the cost of higher bitrates)
These files are served through http from download links in our VLE and the fairly heavily modified) engage player, rtmp (wowza) for the engage player, and http for the complete bodge of a html5 <video> fallback we hacked into engage player for mobile ;)
The 2 LQ videos and an mp3 are produced at the beginning of the workflow and published to engage straight away so if matterhorn core is playing ball we can get recordings published extremely quickly, then the workflow carries on to make the HQ versions and do the segmentation and OCR then the mediapackage is re-published.
We haven't done any analysis on which formats are most viewed/downloaded yet.
Hope that is helpful!
Thanks,
Paul.