Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-25 Thread Nicolas George
Le tridi 3 brumaire, an CCXXVI, Nicolas George a écrit : > As I said, I will try to find time to implement a correct workaround > tomorrow. Patch series posted. https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218482.html https://patchwork.ffmpeg.org/patch/5686/ Please confirm if it fixes

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom
On Tue, Oct 24, 2017 at 10:43 PM, James Almer wrote: > Maybe first ask what the workaround Nicolas mentioned is about? This was not meant to push anything on anyone. Just wanted to let him know what had been come up with elsewhere. > And preferably don't quote me on this

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Nicolas George
Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit : > You might be very true, but funny enough I just checked the AVIO > example doc/examples/avio_reading.c, and the read function there does > not seem to utilize AVERROR_EOF either :) . The examples are not exempt from mistakes. > Just for

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread James Almer
On 10/24/2017 4:37 PM, Jan Ekstrom wrote: > On Tue, Oct 24, 2017 at 10:17 PM, Nicolas George wrote: >> Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit : >> I do not consider this a public API change because 0 was never >> documented as a valid return value for a read_packet

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom
On Tue, Oct 24, 2017 at 10:17 PM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit : > I do not consider this a public API change because 0 was never > documented as a valid return value for a read_packet callback, while > AVERROR_EOF has been around

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Nicolas George
Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit : > The base idea was grasped rather quickly though, which seems to be > that all API clients utilizing their own IO seem to now require an > update to their code to return AVERROR_EOF if EOF was hit instead of > being able to return the number

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom
On Tue, Oct 24, 2017 at 9:18 PM, Jan Ekstrom wrote: > This is a public API change, and I'm not sure if we were planning on > this. I am not against the fact that zero is no longer implictly EOF, > but this might have been worth a bit more notice as this does indeed > break quite

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom
On Tue, Oct 24, 2017 at 8:57 PM, Nicolas George wrote: > Le duodi 2 brumaire, an CCXXVI, James Almer a écrit : >> https://trac.ffmpeg.org/ticket/6767 > > I do not see in this ticket anything that allows to reproduce the issue > without a huge amount of foreign code. > > Regards,

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Nicolas George
Le duodi 2 brumaire, an CCXXVI, James Almer a écrit : > https://trac.ffmpeg.org/ticket/6767 I do not see in this ticket anything that allows to reproduce the issue without a huge amount of foreign code. Regards, -- Nicolas George signature.asc Description: Digital signature

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-23 Thread Hendrik Leppkes
On Mon, Oct 23, 2017 at 3:22 PM, James Almer wrote: > On 10/23/2017 5:25 AM, Daniel Kučera wrote: >> 2017-10-21 13:36 GMT+02:00 Jan Ekstrom : >>> >>> This seems to have broken seeking and files ending. FLAC was >>> experienced yesterday but it seems like it's

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-23 Thread James Almer
On 10/23/2017 5:25 AM, Daniel Kučera wrote: > 2017-10-21 13:36 GMT+02:00 Jan Ekstrom : >> >> This seems to have broken seeking and files ending. FLAC was >> experienced yesterday but it seems like it's more general. This was >> reported on the mpv users' channel by sfan5, but I

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-23 Thread Daniel Kučera
2017-10-21 13:36 GMT+02:00 Jan Ekstrom : > > This seems to have broken seeking and files ending. FLAC was > experienced yesterday but it seems like it's more general. This was > reported on the mpv users' channel by sfan5, but I feel like this > might be more general than related

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-21 Thread Jan Ekstrom
On Tue, Oct 17, 2017 at 11:29 AM, Daniel Kucera wrote: > transfer_func variable passed to retry_transfer_wrapper > are h->prot->url_read and h->prot->url_write functions. > These need to return EOF or other error properly. > In case of returning >= 0, url_read/url_write

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-19 Thread Nicolas George
L'octidi 28 vendémiaire, an CCXXVI, Michael Niedermayer a écrit : > any reason why you dont apply it, if you think its correct ? Good question. Just did it. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-19 Thread Michael Niedermayer
On Thu, Oct 19, 2017 at 04:22:33PM +0200, Nicolas George wrote: > Le sextidi 26 vendémiaire, an CCXXVI, Michael Niedermayer a écrit : > > Seems to work, no more comments from me > > I think this is correct too. any reason why you dont apply it, if you think its correct ? [...] -- Michael

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-19 Thread Nicolas George
Le sextidi 26 vendémiaire, an CCXXVI, Michael Niedermayer a écrit : > Seems to work, no more comments from me I think this is correct too. Thanks to Daniel for the efforts. Regards, -- Nicolas George signature.asc Description: Digital signature

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-17 Thread Michael Niedermayer
On Tue, Oct 17, 2017 at 10:29:30AM +0200, Daniel Kucera wrote: > transfer_func variable passed to retry_transfer_wrapper > are h->prot->url_read and h->prot->url_write functions. > These need to return EOF or other error properly. > In case of returning >= 0, url_read/url_write is retried > until

[FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-17 Thread Daniel Kucera
transfer_func variable passed to retry_transfer_wrapper are h->prot->url_read and h->prot->url_write functions. These need to return EOF or other error properly. In case of returning >= 0, url_read/url_write is retried until error is returned. Signed-off-by: Daniel Kucera

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-16 Thread James Almer
On 10/16/2017 9:13 PM, Michael Niedermayer wrote: > On Mon, Oct 16, 2017 at 11:14:49AM +0200, Daniel Kucera wrote: >> transfer_func variable passed to retry_transfer_wrapper >> are h->prot->url_read and h->prot->url_write functions. >> These need to return EOF or other error properly. >> In case

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-16 Thread Michael Niedermayer
On Mon, Oct 16, 2017 at 11:14:49AM +0200, Daniel Kucera wrote: > transfer_func variable passed to retry_transfer_wrapper > are h->prot->url_read and h->prot->url_write functions. > These need to return EOF or other error properly. > In case of returning >= 0, url_read/url_write is retried > until