Vittorio Giovara (12019-01-07):
> size_t represents a length
> so using it for video dimensions makes perfect sense.
size_t represents a system-dependent size of object in memory, not any
"length". There is no reason to have different resolution limi
On Sat, Jan 5, 2019 at 2:15 AM James Almer wrote:
> On 1/4/2019 10:08 AM, Vittorio Giovara wrote:
> > On Fri, Jan 4, 2019 at 12:22 PM Nicolas George wrote:
> >
> >> Rostislav Pehlivanov (12019-01-04):
> +typedef struct AVRegionOfInterest {
> +size_t self_size;
> +size_t to
>
> Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of
> Interest) data struct and bump version
>
> James Almer (12019-01-04):
> > We already did size_t for AVSphericalMapping and had to change them to
> > uint32_t.
> > size_t is not the correct typ
James Almer (12019-01-04):
> We already did size_t for AVSphericalMapping and had to change them to
> uint32_t.
> size_t is not the correct type at all, as video dimensions are not
> system dependent,
I fully agree with that.
> and it will generate the same issues we already
> e
On 1/4/2019 10:08 AM, Vittorio Giovara wrote:
> On Fri, Jan 4, 2019 at 12:22 PM Nicolas George wrote:
>
>> Rostislav Pehlivanov (12019-01-04):
+typedef struct AVRegionOfInterest {
+size_t self_size;
+size_t top;
+size_t bottom;
+size_t left;
+size
On Fri, 4 Jan 2019 at 20:44, Vittorio Giovara
wrote:
> On Fri, Jan 4, 2019 at 7:57 PM Rostislav Pehlivanov
> wrote:
>
> > On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara <
> vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
> > >
> > > > Vittori
On Fri, Jan 4, 2019 at 7:57 PM Rostislav Pehlivanov
wrote:
> On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara
> wrote:
>
> > On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
> >
> > > Vittorio Giovara (12019-01-04):
> > > > I personally disagree, what are coordinates within an AVFrame if not
>
On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara
wrote:
> On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
>
> > Vittorio Giovara (12019-01-04):
> > > I personally disagree, what are coordinates within an AVFrame if not
> the
> > > length/size of an object in memory?
> >
> > That would be an ar
On Fri, Jan 04, 2019 at 04:26:51PM +, Derek Buitenhuis wrote:
> On 04/01/2019 14:15, Nicolas George wrote:
> > Rostislav Pehlivanov (12019-01-04):
> >> Hence an AVRational is appropriate as you can have fractions between 0 and
> >> 1, the encoder can adjust it and it'll be agnostic.
> >
> > Ye
Steinar H. Gunderson (12019-01-04):
> Out of curiosity; if it's important to support as large resolutions
> as you can address in memory, what would you do with a 1bpp format
> on a 32-bit system, where one could easily store more than size_t pixels in
> memory?
It is not that important, and anywa
On Fri, Jan 04, 2019 at 05:28:03PM +0100, Vittorio Giovara wrote:
> size_t really seems the right choice here
Out of curiosity; if it's important to support as large resolutions
as you can address in memory, what would you do with a 1bpp format
on a 32-bit system, where one could easily store more
On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
> Vittorio Giovara (12019-01-04):
> > I personally disagree, what are coordinates within an AVFrame if not the
> > length/size of an object in memory?
>
> That would be an argument for making AVFrame.width and AVFrame.height
> size_t. But they
On 04/01/2019 14:15, Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
>> Hence an AVRational is appropriate as you can have fractions between 0 and
>> 1, the encoder can adjust it and it'll be agnostic.
>
> Yes, AVRational is fine. Producing warnings for an unexpected
> denominator woul
Rostislav Pehlivanov (12019-01-04):
> Hence an AVRational is appropriate as you can have fractions between 0 and
> 1, the encoder can adjust it and it'll be agnostic.
Yes, AVRational is fine. Producing warnings for an unexpected
denominator would be a bad idea.
Regards,
--
Nicolas George
si
On Fri, 4 Jan 2019 at 14:02, Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
> > Which are in pixels, not bytes.
>
> And plain int, not uint32_t.
>
> > This is an encoder-only interface for now. For vp9 the denum would be 255
> > for example. They would warn on out of range qdelta.
>
Rostislav Pehlivanov (12019-01-04):
> Which are in pixels, not bytes.
And plain int, not uint32_t.
> This is an encoder-only interface for now. For vp9 the denum would be 255
> for example. They would warn on out of range qdelta.
> I still don't get why this can't be an int.
"For now" is the key
Vittorio Giovara (12019-01-04):
> I personally disagree, what are coordinates within an AVFrame if not the
> length/size of an object in memory?
That would be an argument for making AVFrame.width and AVFrame.height
size_t. But they are not, and therefore these ROI values have no reason
to be eithe
On Fri, Jan 4, 2019 at 12:22 PM Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
> > > +typedef struct AVRegionOfInterest {
> > > +size_t self_size;
> > > +size_t top;
> > > +size_t bottom;
> > > +size_t left;
> > > +size_t right;
> > I'd still much rather have uint
On Fri, 4 Jan 2019 at 11:22, Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
> > > +typedef struct AVRegionOfInterest {
> > > +size_t self_size;
> > > +size_t top;
> > > +size_t bottom;
> > > +size_t left;
> > > +size_t right;
> > I'd still much rather have uints w
Rostislav Pehlivanov (12019-01-04):
> > +typedef struct AVRegionOfInterest {
> > +size_t self_size;
> > +size_t top;
> > +size_t bottom;
> > +size_t left;
> > +size_t right;
> I'd still much rather have uints with fixed sizes than these platform
> dependent types.
Guo, Yejun sa
On Thu, 3 Jan 2019 at 08:41, Guo, Yejun wrote:
> The encoders such as libx264 support different QPs offset for different
> MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
>
> Typical usage: After A
The encoders such as libx264 support different QPs offset for different MBs,
it makes possible for ROI-based encoding. It makes sense to add support
within ffmpeg to generate/accept ROI infos and pass into encoders.
Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
generates
22 matches
Mail list logo
