[FFmpeg-trac] #8620(avdevice:new): Fundamental bug in DirectShow capture - wrong timestamps

[FFmpeg]

#8620: Fundamental bug in DirectShow capture - wrong timestamps
-------------------------------------+------------------------------------
             Reporter:  Davis        |                     Type:  defect
               Status:  new          |                 Priority:  critical
            Component:  avdevice     |                  Version:  4.2
             Keywords:  dshow_pin.c  |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+------------------------------------
 Summary of the bug:
 File dshow_pin.c contains lines:
 {{{#!c
     if (devtype == VideoDevice) {
         /* PTS from video devices is unreliable. */
         IReferenceClock_GetTime(clock, &curtime);
     } else {
         IMediaSample_GetTime(sample, &curtime, &dummy);
 }}}
 As we can see for video stream this code uses current reference clock as
 PTS for video sample, while for audio sample it uses correct stream start
 time as PTS.
 I do not know why developer thought that "PTS from video devices is
 unreliable" but nowadays my experience makes me sure that we should use
 sample stream start time as PTS for all types of streams.
 I patched this code, tested and it works fine this way:
 {{{#!c
 if (0 /*devtype == VideoDevice*/) {
 }}}

 You can see good and wrong timestamps using this run:
 {{{
 % ffmpeg -v verbose -debug_ts -f dshow -pixel_format yuyv422 -video_size
 1920x1080 -framerate 30 -i "video=Logitech BRIO:audio=Микрофон (Logitech
 BRIO)" -y d:\Transcoding\manualCapture.mp4 >
 d:\Transcoding\manualCapture.log 2>&1
 }}}

 Look at "dshow passing through packet of type video" lines:
 {{{
 dshow passing through packet of type video size  4147200 timestamp
 63723140000 orig timestamp 63723136716 graph timestamp 63723140000 diff
 3284 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63723470000 orig timestamp 63723470049 graph timestamp 63723470000 diff
 -49 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63723790000 orig timestamp 63723803382 graph timestamp 63723790000 diff
 -13382 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63724260000 orig timestamp 63724136715 graph timestamp 63724260000 diff
 123285 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63724580000 orig timestamp 63724470048 graph timestamp 63724580000 diff
 109952 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63724900000 orig timestamp 63724803381 graph timestamp 63724900000 diff
 96619 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63725220000 orig timestamp 63725136714 graph timestamp 63725220000 diff
 83286 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63725540000 orig timestamp 63725470047 graph timestamp 63725540000 diff
 69953 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63725860000 orig timestamp 63725803380 graph timestamp 63725860000 diff
 56620 Logitech BRIO
 dshow passing through packet of type video size  4147200 timestamp
 63726180000 orig timestamp 63726136713 graph timestamp 63726180000 diff
 43287 Logitech BRIO
 }}}
 Good stream times timestamps are "orig timestamp"
 Bad currently used are "timestamp".
 While diffs between "orig timestamps" are perfectly 333333 (as we have 30
 fps) diffs between "timestamps" varies which is not surprising me.

 FFmpeg itself usually successfully synchronizes such streams but for those
 who uses libavdevice internally this defect adds unnecessary difficulties.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8620>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker