| Message ID | 20190715174835.46772-1-andreas.rheinhardt@gmail.com |
|---|---|
| State | Accepted |
| Commit | de010d229a18fec9af0052af51615b0831945ae0 |
| Headers | show |
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 [...]
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
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 [...]
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,
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: > 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
Andreas Rheinhardt (12019-08-08):
> Ping.
I just pushed your patch and mine.
Regards,
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)
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(-)