[FFmpeg-devel] libavformat/subfile: Fix SEEK_CUR and SEEK_END seeking

Submitted by Andreas Rheinhardt on July 15, 2019, 5:48 p.m.

Details

Message ID 20190715174835.46772-1-andreas.rheinhardt@gmail.com
State Accepted
Commit de010d229a18fec9af0052af51615b0831945ae0
Headers show

Commit Message

Andreas Rheinhardt July 15, 2019, 5:48 p.m.
Up until now, when performing a SEEK_END seek, the subfile protocol
ignored the desired position (relative to EOF) and used the current
absolute offset in the input file instead.

And when performing a SEEK_CUR seek, the current position has been
ignored.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
---
Sorry for the noise of another email, but I just found out that SEEK_CUR
is buggy as well. This probably hasn't been detected earlier because
avio_seek translates SEEK_CUR to SEEK_SET internally.

 libavformat/subfile.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Michael Niedermayer July 17, 2019, 7:33 p.m.
On Mon, Jul 15, 2019 at 07:48:35PM +0200, Andreas Rheinhardt wrote:
> Up until now, when performing a SEEK_END seek, the subfile protocol
> ignored the desired position (relative to EOF) and used the current
> absolute offset in the input file instead.

I think this comment is only intended to be in the previous patch

[...]
Andreas Rheinhardt July 17, 2019, 7:45 p.m.
Michael Niedermayer:
> On Mon, Jul 15, 2019 at 07:48:35PM +0200, Andreas Rheinhardt wrote:
>> Up until now, when performing a SEEK_END seek, the subfile protocol
>> ignored the desired position (relative to EOF) and used the current
>> absolute offset in the input file instead.
> 
> I think this comment is only intended to be in the previous patch
> 
> [...]
No, the new patch supersedes the previous patch and therefore the
commit message explains what is wrong with SEEK_END as well as with
SEEK_CUR. Or do you want the changes to be split in two commits?

- Andreas
Michael Niedermayer July 18, 2019, 8:04 p.m.
On Wed, Jul 17, 2019 at 07:45:00PM +0000, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, Jul 15, 2019 at 07:48:35PM +0200, Andreas Rheinhardt wrote:
> >> Up until now, when performing a SEEK_END seek, the subfile protocol
> >> ignored the desired position (relative to EOF) and used the current
> >> absolute offset in the input file instead.
> > 
> > I think this comment is only intended to be in the previous patch
> > 
> > [...]
> No, the new patch supersedes the previous patch and therefore the
> commit message explains what is wrong with SEEK_END as well as with
> SEEK_CUR. Or do you want the changes to be split in two commits?

ahh, ok, sorry, i had looked at the code after locally applying
both which worked and caused the hunk to be not in the 2nd
so what i looked at was different from what you posted to the ML

[...]
Nicolas George July 19, 2019, 12:28 p.m.
Andreas Rheinhardt (12019-07-15):
> Up until now, when performing a SEEK_END seek, the subfile protocol
> ignored the desired position (relative to EOF) and used the current
> absolute offset in the input file instead.
> 
> And when performing a SEEK_CUR seek, the current position has been
> ignored.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
> ---
> Sorry for the noise of another email, but I just found out that SEEK_CUR
> is buggy as well. This probably hasn't been detected earlier because
> avio_seek translates SEEK_CUR to SEEK_SET internally.

I think this patch is necessary, and I intend to apply it.

But in the meantime, can you test if this patch:

https://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246765.html

does resolve the problem with concat: that made you look into it?

Regards,
Andreas Rheinhardt July 19, 2019, 4:30 p.m.
Nicolas George:
> Andreas Rheinhardt (12019-07-15):
>> Up until now, when performing a SEEK_END seek, the subfile protocol
>> ignored the desired position (relative to EOF) and used the current
>> absolute offset in the input file instead.
>>
>> And when performing a SEEK_CUR seek, the current position has been
>> ignored.
>>
>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
>> ---
>> Sorry for the noise of another email, but I just found out that SEEK_CUR
>> is buggy as well. This probably hasn't been detected earlier because
>> avio_seek translates SEEK_CUR to SEEK_SET internally.
> 
> I think this patch is necessary, and I intend to apply it.
> 
> But in the meantime, can you test if this patch:
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246765.html
> 
> does resolve the problem with concat: that made you look into it?
> 
> Regards,
> 
It does solve the seeking problem with concat and subfile, just as
fixing subfile alone does; also, applying both commits works fine, too.

- Andreas
Andreas Rheinhardt Aug. 8, 2019, 11:12 p.m.
Andreas Rheinhardt:
> Up until now, when performing a SEEK_END seek, the subfile protocol
> ignored the desired position (relative to EOF) and used the current
> absolute offset in the input file instead.
> 
> And when performing a SEEK_CUR seek, the current position has been
> ignored.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
> ---
Ping.

- Andreas
Nicolas George Aug. 13, 2019, 2:41 p.m.
Andreas Rheinhardt (12019-08-08):
> Ping.

I just pushed your patch and mine.

Regards,

Patch hide | download patch | download mbox

diff --git a/libavformat/subfile.c b/libavformat/subfile.c
index 2f162e0a34..5d8659c8c4 100644
--- a/libavformat/subfile.c
+++ b/libavformat/subfile.c
@@ -116,7 +116,7 @@  static int subfile_read(URLContext *h, unsigned char *buf, int size)
 static int64_t subfile_seek(URLContext *h, int64_t pos, int whence)
 {
     SubfileContext *c = h->priv_data;
-    int64_t new_pos = -1, end;
+    int64_t new_pos, end;
     int ret;
 
     if (whence == AVSEEK_SIZE || whence == SEEK_END) {
@@ -132,10 +132,10 @@  static int64_t subfile_seek(URLContext *h, int64_t pos, int whence)
         new_pos = c->start + pos;
         break;
     case SEEK_CUR:
-        new_pos += pos;
+        new_pos = c->pos + pos;
         break;
     case SEEK_END:
-        new_pos = end + c->pos;
+        new_pos = end + pos;
         break;
     }
     if (new_pos < c->start)