Re: [FFmpeg-devel] [PATCH] libopenmpt: fix seeking

[kimapr via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

revised the patch, hopefully it's better now. i also fixed
another weirdness that i didn't fix in the original patch

On 2025/07/31 19:19, Michael Niedermayer wrote:

> while your email contains quite some details, the commit message of
> just "libopenmpt: fix seeking" is too terse

added some details!

> is there any possibility of a "unknown" "position" ?
> if not its fine otherwise a check may be needed to handle that

no idea. openmpt docs don't mention the possibility, and
besides like returning a NaN there isn't really much the API
can do to indicate such a condition

> is it possible that this exceeds the int64_t range ?
> if so these out of range values should probably be replaced by AV_NOPTS_VALUE

seems unlikely! i added a check anyway though (should also catch the
unknown position if it is indicated by a NaN). rather than replacing
the value with AV_NOPTS_VALUE i just don't set it. Is that good?

[-- Attachment #2: 0001-libopenmpt-fix-seeking-weirdness.patch --]
[-- Type: text/x-patch, Size: 2534 bytes --]

From d6418b665cc80a1680afee8259a242a42c0ed2ad Mon Sep 17 00:00:00 2001
From: Kimapr <kimapr.fr@gmail.com>
Date: Mon, 28 Jul 2025 06:32:27 +0500
Subject: [PATCH] libopenmpt: fix seeking weirdness

- proper pts for packets. leaving it blank leaves it up for guessing,
  but the guess doesn't take seeking into account, causing weirdness.

- clamp to 0 when seeking to negative ts. libopenmpt docs are unclear on
  this but not doing this causes an immediate EOF when seeking backwards
  to the beginning in mpv.

- only set song duration and packet pts when they are non-negative and
  in int64 range. NaNs count as out of range. this isn't a fix for any
  specific issue but might be helpful still, and shouldn't break
  anything.
---
 libavformat/libopenmpt.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 3ca59f506f..ab61000d0a 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -147,7 +147,10 @@ static int read_header_openmpt(AVFormatContext *s)
     if (!st)
         return AVERROR(ENOMEM);
     avpriv_set_pts_info(st, 64, 1, AV_TIME_BASE);
-    st->duration = llrint(openmpt->duration*AV_TIME_BASE);
+
+    if (openmpt->duration * AV_TIME_BASE <= INT64_MAX &&
+        openmpt->duration * AV_TIME_BASE >= 0)
+        st->duration = llrint(openmpt->duration*AV_TIME_BASE);
 
     st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
     st->codecpar->codec_id    = AV_NE(AV_CODEC_ID_PCM_F32BE, AV_CODEC_ID_PCM_F32LE);
@@ -170,6 +173,8 @@ static int read_packet_openmpt(AVFormatContext *s, AVPacket *pkt)
     if ((ret = av_new_packet(pkt, AUDIO_PKT_SIZE)) < 0)
         return ret;
 
+    double pos = openmpt_module_get_position_seconds(openmpt->module) * AV_TIME_BASE;
+
     switch (openmpt->ch_layout.nb_channels) {
     case 1:
         ret = openmpt_module_read_float_mono(openmpt->module, openmpt->sample_rate,
@@ -195,6 +200,9 @@ static int read_packet_openmpt(AVFormatContext *s, AVPacket *pkt)
 
     pkt->size = ret * (openmpt->ch_layout.nb_channels * 4);
 
+    if (pos >= 0 && pos <= INT64_MAX)
+        pkt->pts = llrint(pos);
+
     return 0;
 }
 
@@ -211,6 +219,8 @@ static int read_close_openmpt(AVFormatContext *s)
 static int read_seek_openmpt(AVFormatContext *s, int stream_idx, int64_t ts, int flags)
 {
     OpenMPTContext *openmpt = s->priv_data;
+    if (ts < 0)
+        ts = 0;
     openmpt_module_set_position_seconds(openmpt->module, (double)ts/AV_TIME_BASE);
     return 0;
 }
-- 
2.49.0


[-- Attachment #3: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".