From patchwork Fri Apr 24 15:20:40 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: vectronic X-Patchwork-Id: 19217 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 76C2144B689 for ; Fri, 24 Apr 2020 18:21:00 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5268468C117; Fri, 24 Apr 2020 18:21:00 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A7DD568B372 for ; Fri, 24 Apr 2020 18:20:53 +0300 (EEST) Received: by mail-wm1-f68.google.com with SMTP id y24so11250897wma.4 for ; Fri, 24 Apr 2020 08:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=oXcb6NoHocqk/nQCuyGMm4lvypw6ZgtysZhRlaS1E4o=; b=uK25KbTVMbuM81ChXSWzsagAiaFi9nBmVEAhdEFl+SdOV3lvhEX344Vp+nkaPpLPWt SNCirpZNIJRy18tWVoiC05c6mzY8PsRHFkLnjhVwdjxHtIPWePFbh9Y3r+6neDGe69re rP0oKD2ixVLAwHLgkH2/KOt6YWLti+OLp1V7F7wYzFv1b03HMbLWlhvSifk9td7St9Vw Lo+Yw3ZUahdyiav2XX0duKR8gwdTg88NCFoFRfw57AN9E7UgGw4k1xaYr+5nl3NXFlNb S1eciuWOrEnkTwrKZFZ8W1LmaToQxLXgt7qb7htuLesiLRSWB+9UPBDczN7RoNsjXRSw HjYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=oXcb6NoHocqk/nQCuyGMm4lvypw6ZgtysZhRlaS1E4o=; b=nmDMEJfyuZmY6eOPbOsyezQQ6j4NL0u9b3nKI2jn2avmsFj1/57o5iShuJzRDsh/Bh kz3o/Hc8LamtbuSZN85v+CiPa3taMwlqWd3+aapTQ5O8T1pQyQq1t4JhbaqqbR9meDSQ /Y/NdrUIMjdw9o/JzsxRvGILidpYj7FktvLsaX15bNQeC8oOJwwzquRCqc7VOeg7M/xS qITt1O5IYWJ6lhsnVkEB2GEQvQ7o6U1ffLaUWqCn4SfPiv3ijHtKFHnpUak10rA7yqE7 bi7mDkXGKisyrRjQz3/U0Y2NRuECP0OtUn6h56yJxbYuZcJOsNdyWFh3lqu5g+/CCfqC s8/Q== X-Gm-Message-State: AGi0PuZ57y+bG+LEL4afJVSevpFNEEs70rpUF3QQyVw0Oa5FSlV+AAM8 QpRZj7e6oGxQrR06uFXIaOSruWqAyew= X-Google-Smtp-Source: APiQypKwgHGVpOakGCdLe7DBM5tgx5f+rWEQ4RGSkHf2NykG0gIRUunLFjNONK74Osa0Zug0D06M4A== X-Received: by 2002:a7b:c4c7:: with SMTP id g7mr10337765wmk.97.1587741652786; Fri, 24 Apr 2020 08:20:52 -0700 (PDT) Received: from mechagodzilla.chapatronic.net (cpc76904-dals22-2-0-cust471.20-2.cable.virginm.net. [81.106.45.216]) by smtp.gmail.com with ESMTPSA id l15sm3131661wmi.48.2020.04.24.08.20.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2020 08:20:52 -0700 (PDT) From: vectronic To: ffmpeg-devel@ffmpeg.org Date: Fri, 24 Apr 2020 16:20:40 +0100 Message-Id: <20200424152042.29383-1-hello.vectronic@gmail.com> X-Mailer: git-send-email 2.24.2 (Apple Git-127) MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 0/2] fix for seeking in HLS with TS/FMP4 media X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: vectronic Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" I am resubmitting a patch which fixes the following two tickets: https://trac.ffmpeg.org/ticket/7359 https://trac.ffmpeg.org/ticket/7485 The patch consists of 2 parts. The first is necessary to fix the case of HLS seeking when the HLS package consists of ts files. The second fixes HLS seeking when the HLS package consists of fmp4 files. Note that the first can be applied without the second, and HLS seeking with fmp4 files will remain broken, but in a different manner. The first patch works because it relies on correct behaviour implemented in mpegts.c, the second patch mirrors this behaviour in mov.c. The issues can be demonstrated as follows: ./ffmpeg -ss 3 -i http://vectronic.io/hls_seek_issue/ts/in.m3u8 -t 2 out.mp4 ./ffmpeg -ss 3 -i http://vectronic.io/hls_seek_issue/fmp4/in.m3u8 -t 2 out.mp4 These both produce zero duration output files. With the first patch applied, the ts example produces a 2 second output file as expected. However the fmp4 example results in a conversion error. With the second patch applied, both the ts and fmp4 examples produce 2 second output files as expected. Patch 1: Change to logic in hls.c for seeking After performing a rough seek in hls.c hls_read_seek() to the nearest segment, the logic for hls_read_packet() was to discard packets until a DTS after the accurate seek point is discovered. This was done even if AVSEEK_FLAG_ANY was not specified in the initial seek request. The patch changes this so that if AVSEEK_FLAG_ANY has not been specified, it will instead return the first keyframe discovered after the rough seek point. Patch 2: Change to logic in mov.c for reading packets after an HLS seek Within hls.c when hls_read_seek() is called it resets the stream position as follows: /* Reset the pos, to let the mpegts demuxer know we've seeked. */ pls->pb.pos = 0; There is support for this in the mpegts handle_packets() code to check if the position has been reset and clear out any PES packets: if (avio_tell(s->pb) != ts->last_pos) { int i; av_log(ts->stream, AV_LOG_TRACE, "Skipping after seek\n"); /* seek detected, flush pes buffer */ This behaviour needed to be mirrored in the mov demuxer. In mov.c it now detects if the pos has been reset in mov_read_packet(). It clears fragments and indexes and searches for the next root i.e. the next fragment via mov_switch_root(). vectronic (2): avformat hls fix to seek logic avformat mov fix to detect if stream position has been reset libavformat/hls.c | 8 +++++--- libavformat/mov.c | 36 +++++++++++++++++++++++++++++++++--- 2 files changed, 38 insertions(+), 6 deletions(-)