Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Paul B Mahol <onemda@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] avformat: add CRI USM demuxer
Date: Sun, 10 Sep 2023 14:29:07 +0200
Message-ID: <CAPYw7P7ntQro7F1GrOYZsqeXoBs+kuu5i3o8SFnf5xa_irj7og@mail.gmail.com> (raw)
In-Reply-To: <AS8P250MB0744E9E7E5ACDF3A7E6384848FF3A@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>

On Sun, Sep 10, 2023 at 2:18 PM Andreas Rheinhardt <
andreas.rheinhardt@outlook.com> wrote:

> Paul B Mahol:
> > On Sun, Sep 10, 2023 at 2:06 PM Andreas Rheinhardt <
> > andreas.rheinhardt@outlook.com> wrote:
> >
> >> Paul B Mahol:
> >>> On Sun, Sep 10, 2023 at 1:59 PM Andreas Rheinhardt <
> >>> andreas.rheinhardt@outlook.com> wrote:
> >>>
> >>>> Paul B Mahol:
> >>>>> On Wed, Sep 6, 2023 at 1:30 PM Andreas Rheinhardt <
> >>>>> andreas.rheinhardt@outlook.com> wrote:
> >>>>>
> >>>>>> Paul B Mahol:
> >>>>>>> On Wed, Sep 6, 2023 at 11:26 AM Andreas Rheinhardt <
> >>>>>>> andreas.rheinhardt@outlook.com> wrote:
> >>>>>>>
> >>>>>>>> Paul B Mahol:
> >>>>>>>>>
> >>>>>>>>> +    chunk_type = avio_rb32(pb);
> >>>>>>>>> +    chunk_size = avio_rb32(pb);
> >>>>>>>>
> >>>>>>>> You are not checking whether the chunk here exceeds its containing
> >>>>>> chunk.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> +    av_fast_malloc(&usm->header, &usm->header_size,
> >>>>>>>>> +                   chunk_size + AV_INPUT_BUFFER_PADDING_SIZE);
> >>>>>>>>> +    if (!usm->header)
> >>>>>>>>> +        return AVERROR(ENOMEM);
> >>>>>>>>
> >>>>>>>> The bytestream2 API does not rely on the buffer being padded at
> all.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> +    bytestream2_skip(&sgb, string_offset);
> >>>>>>>>
> >>>>>>>> This is unnecessary, because you seek with an absolute offset
> >> lateron
> >>>>>>>> anyway before using sgb.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> +        bytestream2_seek(&sgb, string_offset + offset,
> SEEK_SET);
> >>>>>>>>> +        while (bytestream2_get_bytes_left(&sgb) > 0) {
> >>>>>>>>> +            key[n] = bytestream2_get_byte(&sgb);
> >>>>>>>>> +            if (!key[n])
> >>>>>>>>> +                break;
> >>>>>>>>> +            if (n >= sizeof(key) - 1)
> >>>>>>>>> +                break;
> >>>>>>>>> +            n++;
> >>>>>>>>> +        }
> >>>>>>>>> +        key[n] = '\0';
> >>>>>>>>
> >>>>>>>> IMO this would be easier with strnlen(), avoiding sgb altogether.
> >>>>>>>> You would of course need to explicitly check that you are not
> >>>>>>>> overreading, but that is good practice anyway.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> +    chunk_start = avio_tell(pb);
> >>>>>>>>> +    avio_skip(pb, 1);
> >>>>>>>>> +    payload_offset = avio_r8(pb);
> >>>>>>>>> +    padding_size = avio_rb16(pb);
> >>>>>>>>> +    stream_index = avio_r8(pb);
> >>>>>>>>> +    avio_skip(pb, 2);
> >>>>>>>>> +    payload_type = avio_r8(pb);
> >>>>>>>>> +    frame_time = avio_rb32(pb);
> >>>>>>>>> +    frame_rate = avio_rb32(pb);
> >>>>>>>>> +    avio_skip(pb, 8);
> >>>>>>>>
> >>>>>>>> payload_offset and frame_time are set-but-unused; this might lead
> to
> >>>>>>>> compiler warnings.
> >>>>>>>>
> >>>>>>>>> +        if (usm->ch[is_audio][stream_index].used == 1) {
> >>>>>>>>> +            uint32_t pkt_size = chunk_size - (avio_tell(pb) -
> >>>>>>>> chunk_start);
> >>>>>>>>> +
> >>>>>>>>
> >>>>>>>> This is unnecessary: Unless we already had a read error, pkt_size
> is
> >>>>>>>> chunk_size - (1 + 1 + 2 + 1 + 2 + 1 + 4 + 4 + 8).
> >>>>>>>>
> >>>>>>>> (Notice that in case padding_size is > 0, it will be part of the
> >>>> packet
> >>>>>>>> with the current code; not sure if that is an issue.)
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> +
> >>>>>>>>> +    avio_skip(pb, padding_size);
> >>>>>>>>> +    avio_skip(pb, chunk_size - (avio_tell(pb) - chunk_start));
> >>>>>>>>> +
> >>>>>>>>
> >>>>>>>> Simpler to just use avio_seek(pb, chunk_start + chunk_size,
> >> SEEK_SET);
> >>>>>>>>
> >>>>>>>
> >>>>>>> But input might not be seekable.
> >>>>>>>
> >>>>>>
> >>>>>> And? You know that avio_skip(pb, offset) is just avio_seek(pb,
> offset,
> >>>>>> SEEK_CUR)?
> >>>>>>
> >>>>>
> >>>>> And? Do you know that SEEK_SET is different from SEEK_CUR with
> positive
> >>>>> argument.
> >>>>>
> >>>>
> >>>> You are using SEEK_CUR with -avio_tell(pb), which effectively makes it
> >>>> an absolute seek.
> >>>>
> >>>
> >>> Nope, I skip data only, not seeking backward ever.
> >>>
> >>
> >> avio_seek() internally translates any avio_seek() with SEEK_CUR to an
> >> absolute seek (as required by the seek callbacks) and does not care
> >> about whether it is seeking forward or backward.
> >>
> >
> > Irrelevant. Seeking needs enough cache to work on non-seekable input.
> >
>
> Given that avio_skip() is just a wrapper around avio_seek(), the
> behaviour will not change even when the input is non-seekable.
>

What you are trying to sell?

That seeking works with unseekable input?


>
> - Andreas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2023-09-10 12:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-05 21:37 Paul B Mahol
2023-09-06  9:27 ` Andreas Rheinhardt
2023-09-06  9:57   ` Paul B Mahol
2023-09-06 11:31     ` Andreas Rheinhardt
2023-09-06 12:01       ` Paul B Mahol
2023-09-10 12:00         ` Andreas Rheinhardt
2023-09-10 12:10           ` Paul B Mahol
2023-09-10 12:07             ` Andreas Rheinhardt
2023-09-10 12:15               ` Paul B Mahol
2023-09-10 12:19                 ` Andreas Rheinhardt
2023-09-10 12:29                   ` Paul B Mahol [this message]
2023-09-10 12:55                     ` Andreas Rheinhardt
2023-09-10 13:16                       ` Paul B Mahol
2023-09-10 13:14                         ` Andreas Rheinhardt
2023-09-10 13:24                           ` Paul B Mahol
2023-09-10 12:02 ` Paul B Mahol
2023-09-16 12:19   ` Paul B Mahol

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPYw7P7ntQro7F1GrOYZsqeXoBs+kuu5i3o8SFnf5xa_irj7og@mail.gmail.com \
    --to=onemda@gmail.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git