<div dir="ltr"><div>On Sat, 19 Nov 2016 22:38:40 +1100, Jan Schmidt wrote:<br><br>
Hi!<br>
<br>
> What's happened here is that qtmux has used a timescale of 5000 when<br>
> muxing the 2nd time. The pts_time, dts_time and duration_time match<br>
> exactly if you divide the pts/dts/duration by 5000 instead of 10000. I<br>
> think what's happening is that you muxed the first time using caps of<br>
> fps=100/1, and so qtmux picked 10000 (100 Hz * 100) as a timescale. But,<br>
> I guess the mux only has 50Hz worth of captured frames in it - which<br>> makes qtdemux probably output caps with fps=50/1, and the 2nd mux<br>
> therefore picks a timescale of 5000 (50Hz * 100).<br><br></div>How can I setup timescale for qtmux or mp4mux <span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">through </span></span> splitmuxsink? I tried to use mp4mux and qtmux for splitmuxsink. Results are same.<br><div><br>
> I think the overflows are the only real problem here. Would you like to<br>
> file a bug and make available a couple of input chunk files plus the<br>
> resulting broken merge and I can take more of a look at that to figure<br>
> out what calculation is overflowing where?<br><br><a href="https://bugzilla.gnome.org/show_bug.cgi?id=774716">https://bugzilla.gnome.org/show_bug.cgi?id=774716</a><br></div></div>