ffmpeg start time offset question

[Sven Stauber]

Hi,

We currently are encountering the following problem, explained by example:

$ ffprobe test.mov

[...]

Duration: 00:39:20.20, start: -1.661066, bitrate: 4934 kb/s

    Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 130 kb/s (default)

    Metadata:

      creation_time   : 2014-09-22 14:03:35

      handler_name    : Core Media Data Handler

    Stream #0:1(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, smpte170m), 702x576, 4727 kb/s, SAR 59:54 DAR 767:576, 24.99 fps, 25 tbr, 25k tbn, 50 tbc (default)

    Metadata:

      creation_time   : 2014-09-22 14:03:35

      handler_name    : Core Media Data Handler

The interesting point if the start offset mentioned in the first line ("start: -1.661066"). If I understand correctly, this means that a player shall begin playback at time position 1.661066 (instead of the beginning of the video file) - at least, this seems to be the behaviour.

When we transcode this file, e.g. by $ ffmpeg -i test.mov test.mp4, we get the following ffprobe output:

 Duration: 00:39:22.72, start: 0.023220, bitrate: 2206 kb/s

    Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 702x576 [SAR 59:54 DAR 767:576], 2073 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)

    Metadata:

      handler_name    : VideoHandler

    Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 128 kb/s (default)

    Metadata:

      handler_name    : SoundHandler

So the duration of the video is now longer (39:20:20 vs 39.22:72).

The problem: When having both a presenter and presentation track with different values for "start", the videos are not in sync anymore after being transcoded.

We are currently investigating this problem. 

Has anyone seen or even solved this?

Best,

Sven

[Lars Kiesow]

Hi Sven,
another value that has changed is the FPS and it seems like during the
conversion, the assumed value for the FPS has changed. At least if you
take the input duration (+ offsets) and just change the fps count you
would end up with the resulting output length. But that only might
cause a very slight async over time.

For the different start values (presenter/presentation) you might want
to try the -copyts option:

-copyts
Do not process input timestamps, but keep their values without
trying to sanitize them. In particular, do not remove the initial
start time offset value.

Note that, depending on the vsync option or on specific muxer
processing (e.g. in case the format option avoid_negative_ts is
enabled) the output timestamps may mismatch with the input
timestamps even when this option is selected.

Regards,
Lars

[Rüdiger Rolf]

Hi Sven,

what are you using to record these files? If I look at our files the delay is usually not that large. I always thought that these delays were based on certain conditions during the start of the recording (Devices ready, GOP structure of a running encoder, etc).

And depending on the recording setup that you have I would expect that you do not have the same startup delay on both devices? So the source files would be already synchronous?
From what I see in your example the converted file is about 2s longer at the beginning, so the not usable frames could be restored. Why shouldn't this happen to the second file too? Is the second video only the duration of the shorter video or what was the expected recording duration?

So you could look to improve the recording setup first.

Regards
Rüdiger

Am 26.09.14 11:41, schrieb Sven Stauber:

--
You received this message because you are subscribed to the Google Groups "Matterhorn Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to matterhorn-use...@opencast.org.
To post to this group, send email to matterho...@opencast.org.
Visit this group at http://groups.google.com/a/opencast.org/group/matterhorn-users/.

-- 
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: rr...@uni-osnabrueck.de
Internet: www.virtuos.uni-osnabrueck.de

[Sven Stauber]

Hi, 

For the different start values (presenter/presentation) you might want 

to try the -copyts option [...]

Thanks, Lars. This does help to get the same initial start time in the new file. Unfortunately, this doesn't entirely solve the problem when doing more complicated processing as, for example, WOH composite. 

In the optimum case, we would manage to set the start time to zero by trimming the file to the start time, e.g. omitting all frames that come before the initial start time. Likely, this could be achieved by using the option -ss <initial_start_time> as output option. The bad thing is, that I cannot set this in encoding profiles since <initial_start_time> is not available (or is it?).

Do you accidentally know another magic ffmpeg option that enforces this (setting start to 0 and omit all frame before start) behaviour?

what are you using to record these files? If I look at our files the delay is usually not that large. I always thought that these delays were based on certain conditions during the start of the recording (Devices ready, GOP structure of a running encoder, etc). 

We are using our proprietary capture agent with capture devices from Epiphan and Blackmagic. No idea what causes the QuickTime library (it is a Mac-based capture agent) to set this initial start time thing.

 And depending on the recording setup that you have I would expect that you do not have the same startup delay on both devices? So the source files would be already synchronous? 
From what I see in your example the converted file is about 2s longer at the beginning, so the not usable frames could be restored. Why shouldn't this happen to the second file too? Is the second video only the duration of the shorter video or what was the expected recording duration?

We do not necessarily use the same capture devices for both input sources. The recording of the both inputs also does not necessary start at the exactly same time. We have a WOH that fixes this during Matterhorn post processing. 

So you could look to improve the recording setup first.

The recording setups are not entirely under our control -> this is not a shortterm option. 

Thanks for your answers!

Best,

Sven

[Lars Kiesow]

Hi Sven,
my guess is that you just need to seek to 00:00:00 while keeping the
original timestamps. I've tried that with one file and it seems to work:

ffprobe xy.mp4
[...]
Duration: 00:00:40.00, start: -5.000000, bitrate: 1 kb/s

ffmpeg -copyts -ss 0 -i xy.mp4 out.mp4
[...]

ffprobe out.mp4
[...]
Duration: 00:00:35.00, start: 0.000000, bitrate: 3 kb/s

Can you try that?

Btw, you might notice that 'm using -ss as input option. In newer
FFmpeg version -ss is both fast and accurate if possible, meaning that
it will use bitstream seeking to get as close as possible and the start
to use the decoded video if you don't do a bitstream copy (or turned it
off manually).

In general, with newer FFmpeg versions there is (almost) no reason to
use the slow seeking anymore.

Regards,
Lars

[Rüdiger Rolf]

Hi Sven.

> The recording setups are not entirely under our control -> this is not
> a shortterm option.

I though so already.

The reason for the different start delays is probably that the encoder
is already running and at a certain time you start to write the pipeline
with the encoded files into a file. For audio you probably start to
record it immediately. But for the video this might be in the middle of
a GOP. So you write the incomplete data for the first frames to a file
but you could not display them because of the missing keyframe. This
would be at least my theory.

So based on this theory, I would guess that you would need to cut away
the beginning of both files. If you cut away at least the maximum
keyframe interval of your codec (plus the delay that one of the video
might have during the recording) and reencode the video they both should
be in sync again.

Regards
Rüdiger