On 27.08.2014, at 16:41, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
>
>> Currently no relevant codecs use 12 bits, which is
>> the reason why 9 and 10 bits exist as separate
>> formats while 12 bits does not.
>
> Do you believe that x264 code would have to be
> less efficient
Reimar Döffinger gmx.de> writes:
> Currently no relevant codecs use 12 bits, which is
> the reason why 9 and 10 bits exist as separate
> formats while 12 bits does not.
Do you believe that x264 code would have to be
less efficient than it is now if the 9 and 10
bit colourspaces would be remo
On 25.08.2014, at 19:33, Christophe Gisquet
wrote:
> Hi,
>
> 2014-08-25 6:41 GMT+02:00 Reimar Döffinger :
>> The colorspace is supposed to be authoritative.
>> If it says 16 bit, then showing it as 16 bit must work properly.
>> The only intention of bits_per_raw_sample is to indicate that there
Hi,
2014-08-25 6:41 GMT+02:00 Reimar Döffinger :
> The colorspace is supposed to be authoritative.
> If it says 16 bit, then showing it as 16 bit must work properly.
> The only intention of bits_per_raw_sample is to indicate that there is no
> point in storing some of the lower bits if you have t
On 25 August 2014 06:41:58 CEST, "Reimar Döffinger"
wrote:
>On 24.08.2014, at 14:02, Christophe Gisquet
> wrote:
>> Hi,
>>
>> I think a first point must be cleared, seeing your reaction to my
>> pnmdec comment. Here' are the opinions:
>> - Mine: bits_per_raw_sample should indicate the dynamics o
On 24.08.2014, at 14:02, Christophe Gisquet
wrote:
> Hi,
>
> I think a first point must be cleared, seeing your reaction to my
> pnmdec comment. Here' are the opinions:
> - Mine: bits_per_raw_sample should indicate the dynamics of the signal
> when it is different from the colorspace bitdepth
>
Christophe Gisquet gmail.com> writes:
> - ffmpeg's and yours (if I'm not mistaken): the signal
> bitdepth should always match the colorspace one, and
> bits_per_raw_sample should indicate the original bitdepth
I believe that my opinion is mostly irrelevant
but that FFmpeg's opinion is the onl
Hi,
I think a first point must be cleared, seeing your reaction to my
pnmdec comment. Here' are the opinions:
- Mine: bits_per_raw_sample should indicate the dynamics of the signal
when it is different from the colorspace bitdepth
- ffmpeg's and yours (if I'm not mistaken): the signal bitdepth sho
Christophe Gisquet gmail.com> writes:
>
> Hi,
>
> 2014-08-24 12:48 GMT+02:00 Carl Eugen Hoyos ag.or.at>:
> >> I think "[PATCH 2/5] pnmenc: use bits_per_raw_sample"
> >> is wrong then
> >
> > Definitely, I still wonder how you tested it.
>
> ljpeg 36bits from #2966 and having the actual
> bit
Hi,
2014-08-24 12:48 GMT+02:00 Carl Eugen Hoyos :
>> I think "[PATCH 2/5] pnmenc: use bits_per_raw_sample"
>> is wrong then
>
> Definitely, I still wonder how you tested it.
ljpeg 36bits from #2966 and having the actual bits_per_raw_sample value
What this situation underlines is that bits_per_ra
Carl Eugen Hoyos ag.or.at> writes:
> Attached patch fixes pnm encoding for me if
> bits_per_raw_sample is set to a value different
> from the pix_fmt's native value.
I should have mentioned that this was planned as
a [RFC] since I am not completely convinced we
want this but current git head
Christophe Gisquet gmail.com> writes:
> Otherwise, this shift would undo scaling performed
> elsewhere or actually remove bits from the actual
> value, which would be incorrect.
It would undo the shift done in the decoder because we
(luckily!!) do not have PIX_FMT_RGB12 and PIX_FMT_GRAY12
(a
Christophe Gisquet gmail.com> writes:
> > -if( avctx->bits_per_raw_sample )
> > +if ( avctx->bits_per_raw_sample
> > +&&
> > av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 > 7)
> > maxdepth = (1 << avctx->bits_per_raw_sample) - 1;
>
> So bit
Hi,
2014-08-24 12:13 GMT+02:00 Carl Eugen Hoyos :
[...]
> -if( avctx->bits_per_raw_sample )
> +if ( avctx->bits_per_raw_sample
> +&& av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 > 7)
> maxdepth = (1 << avctx->bits_per_raw_sample) - 1;
So bit
14 matches
Mail list logo
