On Fri, Mar 09, 2018 at 08:56:56PM +0100, Jerome Martinez wrote:
> On 09/03/2018 18:30, Paul B Mahol wrote:
> >On 3/7/18, Jerome Martinez wrote:
> >>With some sources having specific pix_fmt (9/10/12/14 bit), the source
> >>is padded to 16-bit when the pix_fmt is not supported natively by the
> >>
On 09/03/2018 18:30, Paul B Mahol wrote:
On 3/7/18, Jerome Martinez wrote:
With some sources having specific pix_fmt (9/10/12/14 bit), the source
is padded to 16-bit when the pix_fmt is not supported natively by the
FFV1 encoder.
Nothing is lost ("cutting" to the source bitdepth permits to retr
On 3/7/18, Jerome Martinez wrote:
> With some sources having specific pix_fmt (9/10/12/14 bit), the source
> is padded to 16-bit when the pix_fmt is not supported natively by the
> FFV1 encoder.
> Nothing is lost ("cutting" to the source bitdepth permits to retrieve
> the exact source), but the so
With some sources having specific pix_fmt (9/10/12/14 bit), the source
is padded to 16-bit when the pix_fmt is not supported natively by the
FFV1 encoder.
Nothing is lost ("cutting" to the source bitdepth permits to retrieve
the exact source), but the source bitdepth is not indicated so it is no
