Enhancement: Create Audio and Video Derivatives with FFmpeg Only if Necessary

[danloveg]

Current Behavior

The createAudioDerivative and createVideoDerivative methods in the QubitDigitalObject class process audio and video files with FFmpeg even if the master files are in the correct format. This is an issue when ingesting large amounts of video and audio, since FFmpeg can take a long time to re-encode files (especially large video files).

For example, video reference derivatives are created in this format:

• .mp4 container
• h264 video
• yuv420p pixel format
• aac audio
• 44.1 kHz audio sample rate

But, if the master video file is already in this format, then FFmpeg is still used to re-encode all streams, which is inefficient.

Expected Behavior

AtoM should skip re-encoding audio/video streams with FFmpeg if the streams are already encoded correctly.

Possible Solution

My organization (National Centre for Truth and Reconciliation) has a working fix in our custom version of AtoM which I am willing to adapt to merge into qa/2.x.

Basically, it does this:

• Check if ffprobe is available.
• Use ffprobe to analyze streams.
• If the video is already in the correct format, copy it.
• If the video is partially in the correct format, construct a minimal FFmpeg command that encodes only the streams that need re-encoding.
• If the video does not match any of the correct parameters, then do a full re-encode.

These changes make it much quicker to get video and audio into AtoM when they are in the proper format already.

Context and Notes

An example command for when only the audio is in the wrong format is this:

ffmpeg -y -i <INPUT> -c:v copy -c:a aac -ar 44100 <OUTPUT> 2>&1

The -c:v copy instruction is used to tell FFmpeg to copy the video. This is much faster than re-encoding with libx264.

Version used

AtoM 2.8.2

Operating System and version

No response

Default installation culture

No response

PHP version

PHP 7.4

Contact details

No response

[anvit]

Hi @danloveg, thank you for reporting this issue! We would really appreciate a PR for the fix if you do have the capacity to create one!

Just a heads up, we're fairly close finalizing the 2.9 release so the fix would be for the next release.

[danloveg]

Hi @danloveg, thank you for reporting this issue! We would really appreciate a PR for the fix if you do have the capacity to create one!

Just a heads up, we're fairly close finalizing the 2.9 release so the fix would be for the next release.

Sounds great, we'll be making a pull request in the next couple of weeks or so, so keep an eye out for that! Totally fine that this would be in the release following 2.9. Should I still have the pull request target qa/2.x (once it's ready)?

[anvit]

Hi @danloveg, thank you for reporting this issue! We would really appreciate a PR for the fix if you do have the capacity to create one!
Just a heads up, we're fairly close finalizing the 2.9 release so the fix would be for the next release.

Sounds great, we'll be making a pull request in the next couple of weeks or so, so keep an eye out for that! Totally fine that this would be in the release following 2.9. Should I still have the pull request target qa/2.x (once it's ready)?

Yes! qa/2.x is the development branch with the most up to date changes, and we always create PR's off it.

[danloveg]

I've just opened #1926 to address this issue