Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Lynne <dev@lynne.ee>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/9] avcodec/opus_rc: Remove write-only waste from OpusRangeCoder
Date: Sat, 8 Oct 2022 05:25:50 +0200 (CEST)
Message-ID: <NDpc9wq--3-2@lynne.ee> (raw)
In-Reply-To: <GV1P250MB0737F6A03249BF948291E39F8F5F9@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>

Oct 7, 2022, 22:20 by andreas.rheinhardt@outlook.com:

> Write-only since e7d977b446194649aa30f2aacc6c17bce7aeb90b
> (and local to ff_opus_rc_enc_end() before that).
>
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
> ---
>  libavcodec/opus_rc.c | 2 --
>  libavcodec/opus_rc.h | 3 ---
>  2 files changed, 5 deletions(-)
>
> diff --git a/libavcodec/opus_rc.c b/libavcodec/opus_rc.c
> index c432eb90c9..2061418e52 100644
> --- a/libavcodec/opus_rc.c
> +++ b/libavcodec/opus_rc.c
> @@ -383,8 +383,6 @@ void ff_opus_rc_enc_end(OpusRangeCoder *rc, uint8_t *dst, int size)
>  rng_bytes = rc->rng_cur - rc->buf;
>  memcpy(dst, rc->buf, rng_bytes);
>  
> -    rc->waste = size*8 - (rc->rb.bytes*8 + rc->rb.cachelen) - rng_bytes*8;
> -
>  /* Put the rawbits part, if any */
>  if (rc->rb.bytes || rc->rb.cachelen) {
>  int i, lap;
> diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
> index 627f83229e..1b3cb93a15 100644
> --- a/libavcodec/opus_rc.h
> +++ b/libavcodec/opus_rc.h
> @@ -49,9 +49,6 @@ typedef struct OpusRangeCoder {
>  uint8_t *rng_cur;                      /* Current range coded byte */
>  int ext;                               /* Awaiting propagation */
>  int rem;                               /* Carryout flag */
> -
> -    /* Encoding stats */
> -    int waste;
>  } OpusRangeCoder;
>

Not really to patch 1. The purpose of the waste field was to know how many
bits were spare and usable to put stuff like encoder settings into. It's only a
small field, compilers probably eliminate it anyway, and it's useful for debugging,
just leave it there for now. It's not something I'd argue about, so if you'd really like
to get rid of it, do tell.

LGTM to patches 2-6. Whatever for the opusenc_psy file, I have a rewrite
I need to finish at some point.

Definite NAK to patch 7. The RC system is very easy to read and well-organized.
I'd like to keep it that way than hunt for spare bytes that any LTO trivially removes.
I'd accept a patch that changes the encoder array to heap allocated one (better yet
a framepool) if you'd still like to save on the struct size.

LGTM to patches 8-9.
_______________________________________________
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".

      parent reply	other threads:[~2022-10-08  3:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 20:20 Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 2/9] avcodec/opusenc_psy: Remove unused function parameter Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 3/9] avcodec/opusenc_psy: Remove unused/write-only context members Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 4/9] avcodec/opus: Use prefix for defines Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 5/9] avcodec/opus_rc: Don't duplicate define Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 6/9] avcodec/opus_pvq: Don't build ppp_pvq_search_c when unused Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 7/9] avcodec/opus_rc: Split de/encoder-only parts off OpusRangeContext Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 8/9] avcodec/opus: Rename opus.c->opus_celt.c, opus_celt.c->opusdec_celt.c Andreas Rheinhardt
2022-10-07 20:25 ` [FFmpeg-devel] [PATCH 9/9] avcodec/opus_pvq: Avoid indirection when possible Andreas Rheinhardt
2022-10-08  3:25 ` Lynne [this message]

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=NDpc9wq--3-2@lynne.ee \
    --to=dev@lynne.ee \
    --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