| Message ID | 20181009231026.21828-2-jeebjp@gmail.com |
|---|---|
| State | New |
| Headers |
Delivered-To: ffmpegpatchwork@gmail.com Received: by 2002:ab0:73d2:0:0:0:0:0 with SMTP id m18csp112684uaq; Tue, 9 Oct 2018 16:10:46 -0700 (PDT) X-Google-Smtp-Source: ACcGV62eB3CII2XDSUgicEUMKvdAZ6VpRNOz0PhVz4WvzQ2nH0db7jv5omgFLZNDtrO1LLHldVG3 X-Received: by 2002:a1c:9c84:: with SMTP id f126-v6mr3329400wme.8.1539126646265; Tue, 09 Oct 2018 16:10:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539126646; cv=none; d=google.com; s=arc-20160816; b=CzJJY9jAOVjJHfPouK2HCLjz96fh+8osue0TStr/PFb8f/SjRkepKZ4Uep3FD6hAiA lNtbGw1MP54+JxcfzegbvCT9IhrJRYpHrUyoX8+e3ilyc6+Koyh4X2IjsB/ha1uHnXRC l0HDyCCfWqa4fe4ZgFjicWSnDkeyS6KE4sSrcoBxuh3w1b6Zwf29jgcuTxwLGdNIJ4Ad Oo2brQmqMv9jPaD9BEyCTM48hn8N2/acwTpFHVMmec7rlGP1d0eHpub/fE6/WWfTV7PA 6MgJC992XbbluKn5febVTQnY02q5BjZlWNZa5xiQYEIGELeLrsuf0fxuwIxF3mz4qlN2 0IoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:mime-version:reply-to :list-subscribe:list-help:list-post:list-archive:list-unsubscribe :list-id:precedence:subject:references:in-reply-to:message-id:date :to:from:dkim-signature:delivered-to; bh=YDkBMt0pv61b89izy6+W9po9C/pobrGthKC2j4Q52tw=; b=KKPFgRbDZuhCnYfUUCe6uVtNajInGzZ+E5ULoJo/wIFHyatbe6L/K966DuXteNF+nR +lE42J726cFrnIiVFL6VA7iBuGvnhytK+CsXL0vhdvhhFncd4pV+/m+Pmq6HILHFOz5I g6CiWuj35c/E9KLhqZy3z2uAeYIuieZIvxJdmIB6t/cOIcwXJUUA34gUZOfRUX/MiBR8 ULmfgVblOSg/HGVfRWSiZ+cr1YqT/kdM0XP2rRxqdnB0Lr0gNRdmAL4AkRa1/h7qBwWE n7/BQe4Id/lKN9W3/5SlL2hkSNTYhpov8NbOGcQHYfeKRNSgAi5rhxblN43AJhkGq8AG E15g== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20161025 header.b="UYu/fg+4"; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id c71-v6si11033265wmd.172.2018.10.09.16.10.45; Tue, 09 Oct 2018 16:10:46 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20161025 header.b="UYu/fg+4"; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3D7A868A1D1; Wed, 10 Oct 2018 02:10:14 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1400F689D4B for <ffmpeg-devel@ffmpeg.org>; Wed, 10 Oct 2018 02:10:08 +0300 (EEST) Received: by mail-lj1-f196.google.com with SMTP id j4-v6so3099555ljc.12 for <ffmpeg-devel@ffmpeg.org>; Tue, 09 Oct 2018 16:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references; bh=ZhaUW5Twss3sW5Hc0HOXtaDch0uy7YYyGKFuVN1fKcs=; b=UYu/fg+4eEKgLcevjHJv3oHcZJ68Qp7Aq9Aa2UwZDvt37W1Rsiky5mY6VXgB7hiLLy vTkU3PZ5gokWm8/xDR6oH0xbzQiOToHv6MoAk6WRwOtzxc26NywA/B69L+PUPITXNfxy psizoOgJLkqT/xIOlyFtMRFZhy5VZdldPxw7DVXLjkDxtdoHqgCPb/1n7V20tvbToJ+a 93/SP1X+gskjx+iFCn+7eeMOpyzxq5wX0piPJ6LemDlXjfAXBMgiU4lTwre+ZFBtFYtk sP0GAL0nLE90galMgeDD6/9/cQYvMRj7a79QnpDVksq7vh+pa/9Z3iRwbA0qgCCuyTFe z1HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=ZhaUW5Twss3sW5Hc0HOXtaDch0uy7YYyGKFuVN1fKcs=; b=pRqKEOtUyhoU6WiI38RrRjKKeoAYSqUVzT/q5jcNkWhnyx+9nYqrERBGrXi56FwcmA lE/Z1iBM9MztPeM5Hx+ZsL//h+XvjUZo76PaKm3mQexgJK1T4brVdR4X7SfymvFmgjJG uxXiZ9l3WS7gHQukQcFSVAMCQR/T2sgzaiMDDRcIte9FOkJiueCJFS5+qto/YE3d2GvC izPLINstM0hylcemXq48yp3f8xpDrZEZ7EiKHvt9Is0yl5fqmo8E9EFt52xKziUPkeJ+ nNpsrEbICYdmvldmBwQ58fS0iCv+ZFDJ23ZTt4RJn3uHyI+7M0uFIfFHQkWd3hpuuDdK K/tQ== X-Gm-Message-State: ABuFfogRy2W9+rkb/gOIQhv74AImBhqx1PRAipNyVUANiWnLWseH9QRo /wQLwghBbrdYTPStaErDYt8Zg2cV X-Received: by 2002:a2e:3810:: with SMTP id f16-v6mr605170lja.77.1539126629240; Tue, 09 Oct 2018 16:10:29 -0700 (PDT) Received: from localhost.localdomain (91-159-194-103.elisa-laajakaista.fi. [91.159.194.103]) by smtp.gmail.com with ESMTPSA id r22-v6sm5151913ljr.27.2018.10.09.16.10.28 for <ffmpeg-devel@ffmpeg.org> (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 Oct 2018 16:10:28 -0700 (PDT) From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= <jeebjp@gmail.com> To: ffmpeg-devel@ffmpeg.org Date: Wed, 10 Oct 2018 02:10:26 +0300 Message-Id: <20181009231026.21828-2-jeebjp@gmail.com> X-Mailer: git-send-email 2.17.2 In-Reply-To: <20181009231026.21828-1-jeebjp@gmail.com> References: <20181009231026.21828-1-jeebjp@gmail.com> Subject: [FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <http://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <http://ffmpeg.org/pipermail/ffmpeg-devel/> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> |
Commit Message
Jan Ekström
Oct. 9, 2018, 11:10 p.m. UTC
As libavformat should at this point be handling general input timestamp discontinuities for us - such as with MPEG-TS - the amount of messages from this case should be small, and if it does start spamming messages, that would be a sign that either the input, or the discontinuity handling code itself is broken. In other words, printing this on the warning level makes more sense than staying silent on most verbosity levels. --- fftools/ffmpeg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: > As libavformat should at this point be handling general input > timestamp discontinuities for us - such as with MPEG-TS - the > amount of messages from this case should be small, and if it > does start spamming messages, that would be a sign that either > the input, or the discontinuity handling code itself is broken. libavformat handles the case where a timestamp wraps around that is goes beyond the maximum value. Thats not the only type of discontinuity. Is there some code i am missing or that i forgot about ? [...]
On Thu, 11 Oct 2018, Michael Niedermayer wrote: > On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: >> As libavformat should at this point be handling general input >> timestamp discontinuities for us - such as with MPEG-TS - the >> amount of messages from this case should be small, and if it >> does start spamming messages, that would be a sign that either >> the input, or the discontinuity handling code itself is broken. > > libavformat handles the case where a timestamp wraps around > that is goes beyond the maximum value. Thats not the only > type of discontinuity. Is there some code i am missing or that > i forgot about ? FWIW libavformat only handles wraparound _once_. Regards, Marton
On Thu, Oct 11, 2018 at 10:50 PM Marton Balint <cus@passwd.hu> wrote: > On Thu, 11 Oct 2018, Michael Niedermayer wrote: > > > On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: > >> As libavformat should at this point be handling general input > >> timestamp discontinuities for us - such as with MPEG-TS - the > >> amount of messages from this case should be small, and if it > >> does start spamming messages, that would be a sign that either > >> the input, or the discontinuity handling code itself is broken. > > > > libavformat handles the case where a timestamp wraps around > > that is goes beyond the maximum value. Thats not the only > > type of discontinuity. Is there some code i am missing or that > > i forgot about ? > > FWIW libavformat only handles wraparound _once_. > > Regards, > Marton Looking at update_wrap_reference and where it gets called from et al, it would seem like it should take care of multiple as it keeps updating the reference and applying wrap-around as required? Generally the one in ffmpeg.c seemed to only get hit when there was some sort of jump in the timestamps in addition to the wrap-arounds - or if the lavf wrap-around logic decided to go follow a teletext track with utterly broken timestamps as the reference. As for the comment, yes - lavf's wrap-around logic doesn't try to poke all sorts of discontinuities, but in my opinion the fact that "casual" discontinuities should no longer happen at this stage definitely makes logging that a discontinuity happened and that we tried to apply a new offset to all streams worth mentioning on a more normal verbosity level than "debug". Currently you will never, ever hear anything about this logic activating unless your verbosity level is ridiculously high. And as a general case, if the logic is working correctly this code should only fire once per discontinuity, not in an eternal loop. Best regards, Jan
On Thu, 11 Oct 2018, Jan Ekström wrote: > On Thu, Oct 11, 2018 at 10:50 PM Marton Balint <cus@passwd.hu> wrote: >> On Thu, 11 Oct 2018, Michael Niedermayer wrote: >> >> > On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: >> >> As libavformat should at this point be handling general input >> >> timestamp discontinuities for us - such as with MPEG-TS - the >> >> amount of messages from this case should be small, and if it >> >> does start spamming messages, that would be a sign that either >> >> the input, or the discontinuity handling code itself is broken. >> > >> > libavformat handles the case where a timestamp wraps around >> > that is goes beyond the maximum value. Thats not the only >> > type of discontinuity. Is there some code i am missing or that >> > i forgot about ? >> >> FWIW libavformat only handles wraparound _once_. >> >> Regards, >> Marton > > Looking at update_wrap_reference and where it gets called from et al, > it would seem like it should take care of multiple as it keeps > updating the reference and applying wrap-around as required? Timestamps are updated in wrap_timestamp and that only adds or substracts the wrap amount once, so it can't be right. > > Generally the one in ffmpeg.c seemed to only get hit when there was > some sort of jump in the timestamps in addition to the wrap-arounds - > or if the lavf wrap-around logic decided to go follow a teletext track > with utterly broken timestamps as the reference. > > As for the comment, yes - lavf's wrap-around logic doesn't try to poke > all sorts of discontinuities, but in my opinion the fact that "casual" > discontinuities should no longer happen at this stage definitely makes > logging that a discontinuity happened and that we tried to apply a new > offset to all streams worth mentioning on a more normal verbosity > level than "debug". Currently you will never, ever hear anything about > this logic activating unless your verbosity level is ridiculously > high. And as a general case, if the logic is working correctly this > code should only fire once per discontinuity, not in an eternal loop. Agreed. In fact there is another similar message with DEBUG level, that should be bumped as well at least to INFO. Regards, Marton
On Thu, Oct 11, 2018 at 09:50:22PM +0200, Marton Balint wrote: > > > On Thu, 11 Oct 2018, Michael Niedermayer wrote: > > >On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: > >>As libavformat should at this point be handling general input > >>timestamp discontinuities for us - such as with MPEG-TS - the > >>amount of messages from this case should be small, and if it > >>does start spamming messages, that would be a sign that either > >>the input, or the discontinuity handling code itself is broken. > > > >libavformat handles the case where a timestamp wraps around > >that is goes beyond the maximum value. Thats not the only > >type of discontinuity. Is there some code i am missing or that > >i forgot about ? > > FWIW libavformat only handles wraparound _once_. I think its more restrictive than this. If for example ths duration of a video is more then the full timestamp range (with just 1 wraparound) this will likely not work completely [...]
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index dfdee5100a..c20e998d86 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -4471,7 +4471,7 @@ static int process_input(int file_index) delta > 1LL*dts_delta_threshold*AV_TIME_BASE || pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)) { ifile->ts_offset -= delta; - av_log(NULL, AV_LOG_DEBUG, + av_log(NULL, AV_LOG_WARNING, "timestamp discontinuity for stream #%d:%d " "(id=%d, type=%s): %"PRId64", new offset= %"PRId64"\n", ist->file_index, ist->st->index, ist->st->id,