On Thu, 24 Mar 2016 18:14:03 +0100
Michael Niedermayer wrote:
> On Thu, Mar 24, 2016 at 06:03:49PM +0100, Michael Niedermayer wrote:
> > On Thu, Mar 24, 2016 at 03:34:58PM +0100, wm4 wrote:
> > > On Wed, 23 Mar 2016 18:31:56 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Wed, Mar 2
On Thu, Mar 24, 2016 at 06:03:49PM +0100, Michael Niedermayer wrote:
> On Thu, Mar 24, 2016 at 03:34:58PM +0100, wm4 wrote:
> > On Wed, 23 Mar 2016 18:31:56 +0100
> > Michael Niedermayer wrote:
> >
> > > On Wed, Mar 23, 2016 at 02:02:12PM +0100, wm4 wrote:
> > > > This is a bit messy, mainly due
On Thu, Mar 24, 2016 at 03:34:58PM +0100, wm4 wrote:
> On Wed, 23 Mar 2016 18:31:56 +0100
> Michael Niedermayer wrote:
>
> > On Wed, Mar 23, 2016 at 02:02:12PM +0100, wm4 wrote:
> > > This is a bit messy, mainly due to timestamp handling.
> > >
> > > decode_video() relied on the fact that it cou
On Wed, 23 Mar 2016 18:31:56 +0100
Michael Niedermayer wrote:
> On Wed, Mar 23, 2016 at 02:02:12PM +0100, wm4 wrote:
> > This is a bit messy, mainly due to timestamp handling.
> >
> > decode_video() relied on the fact that it could set dts on a flush/drain
> > packet. This is not possible with t
On Wed, Mar 23, 2016 at 02:02:12PM +0100, wm4 wrote:
> This is a bit messy, mainly due to timestamp handling.
>
> decode_video() relied on the fact that it could set dts on a flush/drain
> packet. This is not possible with the old API, and won't be. (I think
> doing this was very questionable with
This is a bit messy, mainly due to timestamp handling.
decode_video() relied on the fact that it could set dts on a flush/drain
packet. This is not possible with the old API, and won't be. (I think
doing this was very questionable with the old API. Flush packets should
not contain any information;
