[FFmpeg-devel,V2,1/2] lavf/utils: fix error like "offset 0x1f85: partial file"

fix the issue like "offset 0x1f85: partial file" when demuxer mp4
from http/https/crypto

Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
 libavformat/utils.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

On Mon, Jan 14, 2019 at 5:09 PM Jun Zhao <mypopydev@gmail.com> wrote:
>
> fix the issue like "offset 0x1f85: partial file" when demuxer mp4
> from http/https/crypto
>
> Signed-off-by: Jun Zhao <mypopydev@gmail.com>
> ---
>  libavformat/utils.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 7afef54..92a0eb7 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2103,7 +2103,8 @@ void ff_configure_buffers_for_index(AVFormatContext *s, int64_t time_tolerance)
>                 "optimally without knowing the protocol\n");
>      }
>
> -    if (proto && !(strcmp(proto, "file") && strcmp(proto, "pipe") && strcmp(proto, "cache")))
> +    if (proto && !(strcmp(proto, "file") && strcmp(proto, "pipe") && strcmp(proto, "cache") &&
> +                   strcmp(proto, "https") && strcmp(proto, "http") && strcmp(proto, "crypto")))
>          return;
>
>      for (ist1 = 0; ist1 < s->nb_streams; ist1++) {

Isn't the entire point of this function to do stuff for network
streams,  like http?
If there is a bug in there, it should probably be fixed, and not just disabled?

- Hendrik

On Mon, Jan 14, 2019 at 5:32 PM Hendrik Leppkes <h.leppkes@gmail.com> wrote:
>
> On Mon, Jan 14, 2019 at 5:09 PM Jun Zhao <mypopydev@gmail.com> wrote:
> >
> > fix the issue like "offset 0x1f85: partial file" when demuxer mp4
> > from http/https/crypto
> >
> > Signed-off-by: Jun Zhao <mypopydev@gmail.com>
> > ---
> >  libavformat/utils.c |    3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 7afef54..92a0eb7 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -2103,7 +2103,8 @@ void ff_configure_buffers_for_index(AVFormatContext *s, int64_t time_tolerance)
> >                 "optimally without knowing the protocol\n");
> >      }
> >
> > -    if (proto && !(strcmp(proto, "file") && strcmp(proto, "pipe") && strcmp(proto, "cache")))
> > +    if (proto && !(strcmp(proto, "file") && strcmp(proto, "pipe") && strcmp(proto, "cache") &&
> > +                   strcmp(proto, "https") && strcmp(proto, "http") && strcmp(proto, "crypto")))
> >          return;
> >
> >      for (ist1 = 0; ist1 < s->nb_streams; ist1++) {
>
> Isn't the entire point of this function to do stuff for network
> streams,  like http?
> If there is a bug in there, it should probably be fixed, and not just disabled?
>

Apparently mov.c is also the only caller of this function, and http is
probably the only network protocol you're ever going to read a mov/mp4
file from, so if its disabled for those, might as well delete it. So
that should be given some careful thought.

- Hendrik

Hendrik Leppkes (12019-01-14):
>								 http is
> probably the only network protocol you're ever going to read a mov/mp4
> file from

Why? Generic file access like SFTP or Samba seem like good candidates
too.

Regards,

On Tue, Jan 15, 2019 at 12:44 AM Nicolas George <george@nsup.org> wrote:
>
> Hendrik Leppkes (12019-01-14):
> >                                                                http is
> > probably the only network protocol you're ever going to read a mov/mp4
> > file from
>
> Why? Generic file access like SFTP or Samba seem like good candidates
> too.
>
> Regards,
>
> --
Yes, by the way, I think this issue like:
https://stackoverflow.com/questions/50521677/ffplay-read-mp4-file-from-http-sever-report-error-stream-1-offset-0x1c33-par

And we don't need to reconfig the buffer when used http/https... and
the other network protocol if can't support seek action.