From: kimapr via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> To: ffmpeg-devel@ffmpeg.org Cc: kimapr <root@kimapr.net> Subject: Re: [FFmpeg-devel] FFmpeg 6.1.3 and 7.0.3 Date: Tue, 5 Aug 2025 19:17:27 +0500 Message-ID: <5ffb2a05-5506-4a3e-a7b0-f0cf234ddeb6@kimapr.net> (raw) In-Reply-To: <484f34d6-8e2b-4854-9266-cfbbc7ed6554@kimapr.net> [-- Attachment #1: Type: text/plain, Size: 988 bytes --] On 2025/08/05 01:02, kimapr via ffmpeg-devel wrote: > Hi! it would be nice if my bug fix > > avformat/libopenmpt: fix seeking weirdness > > was backported to 6.1.3 and 7.0.3 (dunno about 5.1.7 as i haven't checked > if libopenmpt even exists there). not sure how that would work from my side I just checked, and it seems that my patch can be backported as far back as 3.2 (it cannot be backported to 3.1 or earlier because libopenmpt demuxer does not exist there, 3.2 code is similar enough to today's code) On 5.0 and earlier there is a merge conflict because a line of code near my change had changed a little bit so here's a version of the patch with conflict solved for convenience, for later versions (including 5.1) just rebase ecef5f9e1f i haven't tested the patch on top of anything older than 6.1.1 so i don't know if the seeking problems exist there, but the patch shouldn't break anything either as it doesn't depend on any APIs that were changed between 3.2 and latest [-- Attachment #2: 0001-avformat-libopenmpt-fix-seeking-weirdness_ffmpeg_3.2-5.0.patch --] [-- Type: text/x-patch, Size: 2524 bytes --] From 3dc81264cf6e5190c69ae35c87e0c2547b36b29b Mon Sep 17 00:00:00 2001 From: Kimapr <root@kimapr.net> Date: Mon, 28 Jul 2025 06:32:27 +0500 Subject: [PATCH] avformat/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 | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c index 8006c085df..1ed48fa900 100644 --- a/libavformat/libopenmpt.c +++ b/libavformat/libopenmpt.c @@ -150,7 +150,8 @@ 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 >= 0 && openmpt->duration < ((double)INT64_MAX + 1) / AV_TIME_BASE) + 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); @@ -171,6 +172,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); + switch (openmpt->channels) { case 1: ret = openmpt_module_read_float_mono(openmpt->module, openmpt->sample_rate, @@ -196,6 +199,9 @@ static int read_packet_openmpt(AVFormatContext *s, AVPacket *pkt) pkt->size = ret * (openmpt->channels * 4); + if (pos >= 0 && pos < ((double)INT64_MAX + 1) / AV_TIME_BASE) + pkt->pts = llrint(pos * AV_TIME_BASE); + return 0; } @@ -212,6 +218,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".
prev parent reply other threads:[~2025-08-05 14:17 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-03-03 1:10 [FFmpeg-devel] FFmpeg 4.3.9 and 3.4.14 Michael Niedermayer 2025-03-12 13:17 ` Michael Niedermayer 2025-03-15 0:36 ` [FFmpeg-devel] FFmpeg 4.4.6 and 4.2.11 Michael Niedermayer 2025-05-17 15:03 ` Michael Niedermayer 2025-05-17 21:57 ` [FFmpeg-devel] FFmpeg 6.1.3 and 7.0.3 Michael Niedermayer 2025-08-04 14:40 ` Michael Niedermayer 2025-08-04 20:02 ` kimapr via ffmpeg-devel 2025-08-05 14:17 ` kimapr via ffmpeg-devel [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5ffb2a05-5506-4a3e-a7b0-f0cf234ddeb6@kimapr.net \ --to=ffmpeg-devel@ffmpeg.org \ --cc=root@kimapr.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git