On Thu, Jan 25, 2024 at 1:27 AM Tomas Härdin wrote:
> tor 2024-01-25 klockan 01:09 +0300 skrev Victor Luchitz:
> > In our case, the machine we're targeting (the Sega 32X) has only
> > 256KB
> > of RAM. Even more modern consoles such as XBOX or even PS3 didn't
mas Härdin wrote:
> ons 2024-01-24 klockan 11:50 +0300 skrev Victor Luchitz:
> > On Tue, Jan 23, 2024 at 8:44 PM Tomas Härdin wrote:
> > >
> > > Anyway, using -b:v 100k causes the encoder to effectively become
> > > stuck
> > > on the first frame,
You're right, this is actually a part that's not necessarily tied to bitrate
support, I'll move it to a separate patch.
On Wed, Jan 24, 2024 at 2:06 PM Anton Khirnov wrote:
> Quoting Victor Luchitz (2024-01-23 09:33:04)
> > Re-posting the patch as an attachment. Sor
On Tue, Jan 23, 2024 at 8:44 PM Tomas Härdin wrote:
> tis 2024-01-23 klockan 11:33 +0300 skrev Victor Luchitz:
> > Re-posting the patch as an attachment. Sorry for the inconvenience!
>
> Yep, this one applies and also passes FATE.
>
> I notice ffplay_buffer whines a lot w
Re-posting the patch as an attachment. Sorry for the inconvenience!
--
Best regards,
Victor Luchitz
0001-libavcodec-add-bit-rate-support-to-RoQ-video-encoder.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
ling
to apply the patch for you.
>
> /Tomas
> _______
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ff
I've just posted a new version of the patch that addresses most (if not
all) of the comments from previous reviews.
On Mon, Jan 22, 2024 at 10:10 PM Tomas Härdin wrote:
> mån 2024-01-22 klockan 21:32 +0300 skrev Victor Luchitz:
> > On Mon, Jan 22, 2024 at 4:57 PM Tomas
supplied -b
> 200k an no -b at all, is even more janky. The default is also
> ridiculously low..
>
> I know some encoders like libvpx allow specifying both quality (-crf)
> and bitrate at the same time
>
> /Tomas
> ___
> ff
t; I know some encoders like libvpx allow specifying both quality (-
> > > crf)
> > > and bitrate at the same time
> >
> > FWIW, it's possible for an encoder to individually override the
> > defaults
> > for fields like these. See e.g. x264_defaults in l
te between a user-supplied -b
> > 200k an no -b at all, is even more janky. The default is also
> > ridiculously low..
> >
> > I know some encoders like libvpx allow specifying both quality (-crf)
> > and bitrate at the same time
>
> FWIW, it's possible for an
o detect whether an option has been set
> explicitly? At the very least this behavior should be documented in
> doc/encoders.texi
>
Originally, the code just checked for bit_rate != AV_CODEC_DEFAULT_BITRATE,
which required including options_table.h, which in turn produced a bunch
of compilation w
11 matches
Mail list logo
