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".
next prev parent 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