On 15-04-2020 10:39 pm, Michael Niedermayer wrote:
On Wed, Apr 15, 2020 at 05:29:06PM +0530, Gyan Doshi wrote:
On 15-04-2020 05:03 pm, Michael Niedermayer wrote:
On Wed, Apr 15, 2020 at 10:55:47AM +0530, Gyan Doshi wrote:
On 15-04-2020 01:33 am, Michael Niedermayer wrote:
On Tue, Apr 14, 2020 at 02:48:47PM +0530, Gyan Doshi wrote:
For inputs from demuxers with AVFMT_TS_DISCONT flag,
the existing condition,
delta < -1LL*dts_delta_threshold*AV_TIME_BASE
is rendered superflous due to the fixed threshold in
pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)
This prevents users from setting a high threshold to
avoid discontinuity correction due to errant timestamps.
Now, the maximum of the two thresholds is used.
fate-mpeg4-resolution-change call changed to preserve existing
timestamp correction by ffmpeg.c
---
Tested with multiple satellite MPEG-TS inputs.
fftools/ffmpeg.c | 2 +-
tests/fate/mpeg4.mak | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
breaks:
./ffmpeg -i 'concat:angels.mpg|angels.mpg' -vsync 0 file.avi
...
frame= 24 fps=0.0 q=12.5 Lsize= 215kB time=00:00:07.50 bitrate=
234.7kbits/s speed=75.5x
video:84kB audio:110kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 10.697786%
vs.
...
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 219,
current: 86; changing to 220. This may result in incorrect timestamps in the
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 220,
current: 87; changing to 221. This may result in incorrect timestamps in the
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 221,
current: 88; changing to 222. This may result in incorrect timestamps in the
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 222,
current: 89; changing to 223. This may result in incorrect timestamps in the
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 223,
current: 90; changing to 224. This may result in incorrect timestamps in the
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 224,
current: 91; changing to 225. This may result in incorrect timestamps in the
output file.
[mpeg4 @ 0x5601cac87540] Invalid pts (72) <= last (83)
Video encoding failed
Yes, if the input includes a mid-stream dts reset of gap less than the
default value of dts_delta_threshold then timestamps won't be made
continuous. Default value is 10 seconds but till now it wasn't enforced for
negative jumps, so your command worked. With this change, user will have to
set it manually if they expect smaller jumps.
Negative jumps should always be a discontinuity more or less.
What are you trying to fix exactly ?
is this about bitstream errors in the timestamps ?
Yes. This is when there's a backward jump in one of the streams due to
corruption in the input and that leads to a new ts_offset. This new offset
when applied to other streams with error-free timestamps leads to async as
well as muxing errors due to (now) increased interval in the muxing queue.
dts_delta_threshold (in combination with filtering) should allow to prevent
these offset adjustments at the cost of filtering out or adjusting a few
packets, but the existing check prevents that by making 'delta <
-1LL*dts_delta_threshold*AV_TIME_BASE' irrelevant . With this patch, the
user can set a threshold and avoid unwanted offset adjustments due to
negative jumps.
iam still not sure we talk about the same thing
if there is corruption in the timestamp field then on average
the timestamp delta will be large and a threshold will not work
in seperating that reliably from discontinuities.
to detect / filter such issues looking at more than just the next
timestamp would be needed
as in
5,6,7,79861 you dont know if this is
5,6,7,79861,79862,79863
or
5,6,7,79861,9,10,
without seeing the next values
Right. So I'm talking about scenarios where the user *knows* that the
input is supposed to be
85006,85007,85008,85009,...95443,0,1,2,3,4,5...
but is received as
85006,85007,24104,85009...95443,0,1,2,14131,4,5...
Without this patch, user can set a threshold to ignore 2,14131 but not
85007,24104.
Gyan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
