GNOME Bugzilla – Bug 586873
PTS produced by gstffmpegmux are not DVD compatible
Last modified: 2009-06-26 18:23:08 UTC
Hello, PTS (presentation time stamp) produced by gstffmpegmux is not DVD compatible. Some of the MPEG produced cannot be played in regular DVDs players. This is caused because PTS for DVD have to be rounded to certain values. In order to fix this, a new element name called "ptsrounding" has been introduced that can be used when calling the muxer to make sure that the PTS are DVD compatible. Attached you have a proposed patch Regards, Jordi,
Created attachment 137330 [details] [review] Proposed patch
Several things wrong with the patch itself: * What's the unit of the property (nanoseconds ? milliseconds ? bananas per square foot ?) * allowing zero will result in big problems since you're using it as the denominator of a division * What rounding value should be used for the dvd case ? That being said... isn't the problem with the upstream encoders providing non-rounded timestamps ?
Also, do you have a reference for the feature? The only limitation I know of on PTS for DVD is that they need to be less than 0xffffffff, to match with the SCR that is duplicated as a 32-bit int in each NAV packet.
Edward, · The value of PTS is specified in units of the period of the system clock frequency divided by 300 (yielding 90 kHz). · Regarding allowing 0, you're right, the interval should start at 1. · In DVD case, the rounding value that I found that works is 300. Jan, No, unfortunately I have no documentation for this feature. I only have found that some software[1] do comment in their source code. As you know, there is little documentation of the MPEG/DVD. I found this value by experimentation. Jan, if you can point to some documentation I will appreciate it. Regards, Jordi, [1] http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#_j9QLhFEGhM/lxdvdrip/dvdauthor/0.6.12-2992alpha/dvdvob.c&q=dvdauthor%20%22Video%20PTS%20does%20not%20line%20up%20on%20a%20multiple%20of%20a%20field%22&l=56
I have been looking at the ffmpeg source code more closely and I have found that using the preload parameter I can fix this issue. Sorry about the confusion. I should look into this better. Regards, Jordi,