On Fri, Feb 20, 2015 at 07:00:48PM +0100, Michael Niedermayer wrote:
> On Fri, Feb 20, 2015 at 04:04:52PM +, Kevin Wheatley wrote:
> > On Fri, Feb 20, 2015 at 11:36 AM, Michael Niedermayer
> > wrote:
> > > applied the case for DNxHD, for the more general case, please
> > > explain which case(
On Fri, Feb 20, 2015 at 04:04:52PM +, Kevin Wheatley wrote:
> On Fri, Feb 20, 2015 at 11:36 AM, Michael Niedermayer
> wrote:
> > applied the case for DNxHD, for the more general case, please
> > explain which case(s) and software need them, and how to reproduce
> > that
>
> My experience and
On Fri, Feb 20, 2015 at 11:36 AM, Michael Niedermayer wrote:
> applied the case for DNxHD, for the more general case, please
> explain which case(s) and software need them, and how to reproduce
> that
My experience and by the looks of things other people using
libquicktime have seen issues with F
On Mon, Feb 16, 2015 at 10:49:52AM +, Kevin Wheatley wrote:
> ffmpeg and qtdump could not decode pasp/colr atoms in the files made by
> ffmpeg,
> when outputting DNxHD due to the incorrect padding placement. Now we add the
> padding in the correct place, we also always add padding for Final Cu
ffmpeg and qtdump could not decode pasp/colr atoms in the files made by ffmpeg,
when outputting DNxHD due to the incorrect padding placement. Now we add the
padding in the correct place, we also always add padding for Final Cut
compatibility.
Tidy up FATE changes due to padding changes.
Kevin
Fro