[FFmpeg-trac] #6682(undetermined:new): hstack repeats input frames

[FFmpeg]

#6682: hstack repeats input frames
-------------------------------------+-------------------------------------
             Reporter:  damonmaria   |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  hstack       |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by damonmaria):

 OK. I can confirm using setpts solves the problem:
 {{{
 ffmpeg -i 2017-08-31T220000-1.mp4 -i 2017-08-31T220000-2.mp4
 -filter_complex
 "[0:v]setpts=N/(4*TB)[a];[1:v]setpts=N/(4*TB)[b];[a][b]hstack=[v]" -map
 "[v]" -t 10 /Users/damon/Downloads/cmd-line-hstack-2/filename%03d.jpg
 }}}
 The produces frames without skipping and when using the null muxer does
 not give any "non monotonically increasing dts" warnings.

 The problem is this breaks my use-case. The camera these 2 videos were
 originally dumped from is an AXIS Q3708:
 https://www.axis.com/global/en/products/axis-q3708-pve The camera has 3
 sensors in it that when hstack'ed together produce the 180º image. Each
 sensor produces it's own RTSP stream so I need to **sync** and combine the
 streams in my client. The reason I'm trying to use ffmpeg in the first
 place (rather than OpenCV's VideoCapture) is that I was hoping ffmpeg
 would do this syncing for me. If I just open the streams and combine them
 myself and the network causes slightly different start times then my
 images are misaligned. I have used Wireshark to sniff the RTCP packets and
 can see the camera is correctly sending NTP time in the Sender Report. I
 presume by using setpts that timing info is replaced and different start
 times or dropped frames would cause mis-matched frames?

 I understand this have moved from a bug report to a more general ffmpeg
 question. I'm happy to move this over to Stackoverflow if that's a better
 place.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6682#comment:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker