<p dir="ltr">On 1 Apr 2013 07:57, "Brad O'Hearne" <<a href="mailto:brado@bighillsoftware.com">brado@bighillsoftware.com</a>> wrote:<br>
> I suppose my thought is this -- instead of requiring the frame rate to calculate the next DTS/PTS, why is it that given both the DTS and PTS and the duration, it needs the frame rate to calculate the next DTS/PTS? Frame rate doesn't seem necessary with that info -- doesn't DTS/PTS + duration allow the next DTS/PTS to be calculated, essentially realizing whatever frame rate is taking place?</p>

<p dir="ltr">Video encoding is all about legacy standards, legacy players, legacy devices. Some support predefined frame rate, some allow choosing an arbitrary frame rate, others allow even choosing duration per frame.</p>

<p dir="ltr">If you can verify that your expected player accepts time-base.den = 1000, go for that as it gives you higher flexibility. On the other hand, 23.976 frames/s enjoys a bit wider support.</p>
<p dir="ltr">Between these two extremes lay your options.</p>
<p dir="ltr">And remember, frame rate /duration may be set per stream or per container, and in many different ways. Not necessarily changes to the way you time-code your video, require changes for the audio stream.</p>
<p dir="ltr">BR,<br>
Alex</p>