From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 66A2F4C2C2 for ; Thu, 31 Jul 2025 14:19:30 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 5DB4168CA01; Thu, 31 Jul 2025 17:19:25 +0300 (EEST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id E4EA968B77F for ; Thu, 31 Jul 2025 17:19:17 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 38665438EB for ; Thu, 31 Jul 2025 14:19:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1753971557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FkBjQ8SI2jD1iMWsqi/w3oMbMJPPedqgbmmXAUlSGvY=; b=OYnJkwWUZzIGyHnro4i7PFRxt6l+zG26/XdwouPQ9FgSCUfOqXEHHbsMyM1iw7qj8t9ImW r/Ejl2IpgdYuRUMJ4iLDf75M/QxmEe7YQM80H2UgesW2Y4uK2ZmTLgmooEnc1upVU5f7OD wcKg+3TZJ1Us7pEPlfLfY7+XDhBzjSKt1pXkvFpr59xLO97jGau+SNbBUgdH9ddGf8Mn1a ipFCbw+hGYb6mr1Krc17gwG6imx19xlfmui03k8f7yEJLqoAQew2Ofxq2fkWcZd5lRiytB AqeaIzmaMqqYXYxCLNO4dosK3q9lwWbi13UV+EjbnHLB0vEKqhD0HjKEJ0cF9g== Date: Thu, 31 Jul 2025 16:19:14 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250731141914.GS29660@pb2> References: MIME-Version: 1.0 In-Reply-To: X-GND-State: clean X-GND-Score: -85 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddutddutdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdduhedmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpedutedvhfduuedugedufefghefhvedvgffgffekhfdvgfdvtefftdejkeehteefheenucfkphepgedurdeiiedrieehrddujeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieehrddujeeipdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH] libopenmpt: fix seeking X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 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 Content-Type: multipart/mixed; boundary="===============0879495130336226278==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0879495130336226278== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PS6pHot/8phYoQaP" Content-Disposition: inline --PS6pHot/8phYoQaP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Mon, Jul 28, 2025 at 07:58:18AM +0500, kimapr via ffmpeg-devel wrote: > This patch fixes strange seeking behavior i have observed in mpv when usi= ng the libopenmpt demuxer, caused by mismatch in position state between the= demuxer and underlying libopenmpt library.=A0 Not setting the presentation= timestamp field of the AVPacket caused it to be guessed by libavformat, bu= t the guess didn't take seeking into account, so after seeking libopenmpt p= roduced packets at the new seeked position but they were then presented as = if they belong to the old position!=A0 A quick check for this behavior is t= o open a tracker tracker module that is, for example 2 minutes and a few se= conds long in mpv, and then press "up" 2 times (which would seek 2 minutes = forward): buggy demuxer causes mpv to exit immediately after seek because o= f an EOF,=A0 with non-buggy demuxer mpv will play the last few seconds of t= he song and then exit. >=20 > I found the bug when writing my own demuxer for an obscure audio format (= which i'm not quite sure if i should submit too) as i was using the libopen= mpt one as a reference and copied the bug too.=A0 Testing was done on 6.1.1= , but libopenmpt demuxer's code didn't really change since then so it shoul= d be relevant for the latest one too (unless the default value for pkt->pts= changed to take seeking into account), and either way it makes more sense = to expose information that is very much available to the demuxer rather tha= n leave it to be guessed. > libopenmpt.c | 3 +++ > 1 file changed, 3 insertions(+) > fd581b2b26ac22fc5bdcac053c98d9b541052fb2 0001-libopenmpt-fix-seeking.pat= ch > From 451691febac466cee37d9b836228e30c53813d60 Mon Sep 17 00:00:00 2001 > From: Kimapr > Date: Mon, 28 Jul 2025 06:32:27 +0500 > Subject: [PATCH] libopenmpt: fix seeking >=20 > --- > libavformat/libopenmpt.c | 3 +++ > 1 file changed, 3 insertions(+) while your email contains quite some details, the commit message of just "libopenmpt: fix seeking" is too terse >=20 > diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c > index c270a60cb2..d383d65ad8 100644 > --- a/libavformat/libopenmpt.c > +++ b/libavformat/libopenmpt.c > @@ -171,6 +171,8 @@ static int read_packet_openmpt(AVFormatContext *s, AV= Packet *pkt) > if ((ret =3D av_new_packet(pkt, AUDIO_PKT_SIZE)) < 0) > return ret; > =20 > + double pos =3D openmpt_module_get_position_seconds(openmpt->module); is there any possibility of a "unknown" "position" ? if not its fine otherwise a check may be needed to handle that > + > switch (openmpt->ch_layout.nb_channels) { > case 1: > ret =3D openmpt_module_read_float_mono(openmpt->module, openmpt-= >sample_rate, > @@ -195,6 +197,7 @@ static int read_packet_openmpt(AVFormatContext *s, AV= Packet *pkt) > } > =20 > pkt->size =3D ret * (openmpt->ch_layout.nb_channels * 4); > + pkt->pts =3D llrint(pos * AV_TIME_BASE); is it possible that this exceeds the int64_t range ? if so these out of range values should probably be replaced by AV_NOPTS_VAL= UE thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus --PS6pHot/8phYoQaP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaIt7XwAKCRBhHseHBAsP q7BxAJ4id/ywAHOIBCzcdc4xUfGnCwECAACffRbW7WzP2M3tCsqa+NO1M3RQa3M= =9ZMe -----END PGP SIGNATURE----- --PS6pHot/8phYoQaP-- --===============0879495130336226278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============0879495130336226278==--