On 01/14/2017 12:46 PM, John Stebbins wrote:
> On 01/14/2017 12:30 PM, John Stebbins wrote:
>> On 01/12/2017 10:51 PM, wm4 wrote:
>>> On Thu, 12 Jan 2017 10:33:28 -0700
>>> John Stebbins <[email protected]> wrote:
>>>
>>>> ---
>>>>  libavformat/dv.c | 7 ++++++-
>>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/libavformat/dv.c b/libavformat/dv.c
>>>> index d4e5180..3ff369b 100644
>>>> --- a/libavformat/dv.c
>>>> +++ b/libavformat/dv.c
>>>> @@ -484,10 +484,15 @@ static int dv_read_packet(AVFormatContext *s, 
>>>> AVPacket *pkt)
>>>>      size = avpriv_dv_get_packet(c->dv_demux, pkt);
>>>>  
>>>>      if (size < 0) {
>>>> +        int result;
>>>> +
>>>>          if (!c->dv_demux->sys)
>>>>              return AVERROR(EIO);
>>>>          size = c->dv_demux->sys->frame_size;
>>>> -        if (avio_read(s->pb, c->buf, size) <= 0)
>>>> +        result = avio_read(s->pb, c->buf, size);
>>>> +        if (result == AVERROR_EOF)
>>>> +            return result;
>>>> +        if (result <= 0)
>>>>              return AVERROR(EIO);
>>>>  
>>>>          size = avpriv_dv_produce_packet(c->dv_demux, pkt, c->buf, size);
>>> Why not just return the error code as-is?
>>>
>>> While I have my doubts whether it's useful, it's simpler and is what
>>> most other demuxers (probably) do.
>>>
>> Ok by me.  I was just making the minimal change to behaviour possible in 
>> case the current behaviour mattered to somebody.
>>
> After a closer look, is avio_read guaranteed to return AVERROR_EOF upon end 
> of input for all types of AVIOContext?  I
> see some code that explicitly checks for avio_read returning 0 and treating 
> that as EOF. I.e. how should I handle a
> return value of 0 from avio_read?
>

I forgot this was still pending.  I never got an answer to my last question 
above.  Do you all think wm4's suggestion is
sensible. His suggestion results in dv_read_packet returning 0 instead of EIO 
when avio_read returns 0. IMO, if this
change results in other issues, those issues should be fixed since they rely on 
broken behaviour, so my opinion is wm4's
suggestion is good.

-- 
John      GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to