amazon-web-servicesvideoamazon-elastic-transcoder

Elastic Transcoder trimming time - accuracy problem


I'm trying to encode and trim a video to an exact in and out point but I've noticed that the output is lacking some precision.

For example, I know that my clip should start at 1.61s with a duration of 2.32s so I configure the pipeline job like so:

{
    PipelineId: ___,
    Input: {
        Key: ___,
        FrameRate: 'auto',
        Resolution: 'auto',
        AspectRatio: 'auto',
        Interlaced: 'auto',
        Container: 'auto',
        TimeSpan: { 
            StartTime: '00:00:01.610', 
            Duration: '00:00:02.320' 
        }
    },
    Outputs: [{
        Key: ___,
        PresetId: ___,
    }]
}

The output, though, has a duration of 2.36s and – it's hard to confirm – but the in-point seems to be a few frames early.

The input video is 100fps so when giving timing information to the precision of 1/100th second, I expect the precision of the in- and outpoints to not differ much. (Maybe one frame depending on the definition of where the time is in relation to the frame.)

I suspect it might be trimming from the nearest I-frame instead of the nearest actual frame. If so, is there any way to force it to trim at the intended positions?

For context, the videos are meant to be synced to other external data, which is why the in-point and duration is crucial to get correct.


Solution

  • After further investigation, I'm pretty sure what's going wrong. I generated a test video with burned-in time code and exported it in various formats. They were all trimmed correctly. So it isn't a general issue in Elastic Beanstalk since it works fine for those files.

    I then encoded the original video without cropping and I could see that the output file was considerably shorter. The original length was 6.90s, but the output was 6.12s. I then converted the same file using FFMPEG locally and its output was 6.08s.

    So it appears that the original video was encoded in a way that's (partly) incompatible with both Elastic Transcoder and FFMPEG. The original video is encoded using an ancient codec - Microsoft Video 1 - using an unknown encoder. I assume some property of it simply isn't read correctly any longer by modern tools.