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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo