Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/4] avcodec/get_bits: Avoid 2nd bitstream read in GET_VLC() if bits are known at build and small
Date: Tue, 31 Oct 2023 01:25:10 +0100
Message-ID: <20231031002510.GP3543730@pb2> (raw)
In-Reply-To: <AS8P250MB07445F7442F4618AB0C6AF108FA1A@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>


[-- Attachment #1.1: Type: text/plain, Size: 2151 bytes --]

On Mon, Oct 30, 2023 at 09:49:07PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
[...]

> > 
> > also i was wondering about a vlc reader thats entirely free of conditional
> > branches. Just a loop that in each iteration would step by 0-n symbols
> > forward and update a pointer to which table to use next
> 
> Doesn't this have the downside that short symbols need as many
> iterations as the longest one?

i dont think so but maybe iam thinking of something else

lets assume our main table is 10bits
so we read 10 bits look it up in the table and that tells us what there is
and lets assume these 10 bits contain 2 complete symbols and one partial

first we copy from the table a block into our symbol output list (that contains 2 symbols)
second we take a pointer from the table to the next table
    the incomplete can either now be handled in the next iteration or we
    could point back to the main 10bit table and only handle the
    2 complete in this iteration
third we move bits (10) and symbols output pointer (2) forward

now we go back to the start of the loop and continue handling the partial symbol
first we copy from the table a block into our symbol output list (that contains 0 symbols as our partial one still is unfinished)
second we take a pointer from the table to the next table
    this is the next table to decode the long symbol
third we move bits (10) and symbols output pointer (0) forward

now we go back to the start of the loop and continue handling the partial symbol
first we copy from the table a block into our symbol output list (that finally completes the long symbol so we output it)
second we take a pointer from the table to the next which is back at the main table
third we move bits (x) and symbols output pointer (1) forward


thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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-10-31  0:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24 15:04 [FFmpeg-devel] [PATCH 1/4] avcodec/magicyuv: Use a compile time constant for vlc_bits Michael Niedermayer
2023-10-24 15:04 ` [FFmpeg-devel] [PATCH 2/4] avcodec/get_bits: Avoid 2nd bitstream read in GET_VLC() if bits are known at build and small Michael Niedermayer
2023-10-27  3:10   ` Andreas Rheinhardt
2023-10-27 18:38     ` Michael Niedermayer
2023-10-30 20:49       ` Andreas Rheinhardt
2023-10-31  0:25         ` Michael Niedermayer [this message]
2023-10-24 15:04 ` [FFmpeg-devel] [PATCH 3/4] avcodec/get_bits: Implement get_vlc_multi() Michael Niedermayer
2023-10-24 15:04 ` [FFmpeg-devel] [PATCH 4/4] avcodec/magicyuv: Set UNCHECKED_BITSTREAM_READER Michael Niedermayer
2023-10-26 21:37 ` [FFmpeg-devel] [PATCH 1/4] avcodec/magicyuv: Use a compile time constant for vlc_bits Andreas Rheinhardt

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=20231031002510.GP3543730@pb2 \
    --to=michael@niedermayer.cc \
    --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