[FFmpeg-user] Help needed to work around incorrect DTS when capturing H264 from a Logitech C920

[Carl Eugen Hoyos]

Peter Rabbitson <rabbit+list <at> rabbit.us> writes:

> On 12/16/2014 10:33 AM, Carl Eugen Hoyos wrote:
> > Peter Rabbitson <rabbit+list <at> rabbit.us> writes:
> >
> >> a playback of the stream via `ffplay -i stdin.h264`
> >> seems to run faster.
> >
> > You can now use the input option "-r 30" to remux
> > this stream with "correct" timestamps.
> > (I am not sure if they will really be correct but
> > playback works fine here.)
> >
> > The output will never be perfect because you have
> > reception errors in your input stream.

You may have misunderstood this:
What I mean is: Your input stream contains errors 
(loss of data). If you remux this stream, the 
resulting file will also miss data, this is not 
allowed for all container types iirc.

> > Consider
> > using mpegts which allows such errors, I suspect
> > all other file types are invalid whenever such
> > errors occur.
> 
> Which brings me back to the question about ffplay - 
> how does it manage to compensate for (apparently) 
> perfect timing as long as I feed it STDIN 
> in special chunks at special times?

I don't understand this question.

> Basically - is there a way to take the h264 frames 
> as they come down from the camera, and force-set 
> the PTS based on a wallclock or something?

You can use the input option "-r" to overwrite 
timestamps.
Since this option is a very bad hack, it may not 
work for all input formats iirc.
It works fine for the stream you provided.

> Basically "the output will never be perfect" is 
> not something I am willing to settle for.

See above.

> I either want to find out what is causing it

You have reception errors.

The second problem is probably that FFmpeg is not 
able to read timestamps always correctly from 
h264 streams (this is the reason for the "-r" 
hack): This bug is known for a very long time 
and apparently very difficult to fix.

Carl Eugen