On Sun, Dec 15, 2019 at 04:24:11PM +0100, Marton Balint wrote:
>
>
> On Sun, 15 Dec 2019, Michael Niedermayer wrote:
>
> >On Sun, Dec 15, 2019 at 01:52:52PM +0100, Marton Balint wrote:
> >>
> >>
> >>On Sun, 15 Dec 2019, Michael Niedermayer wrote:
> >>
> >>>On Sun, Dec 15, 2019 at 02:16:49AM +010
On Sun, 15 Dec 2019, Michael Niedermayer wrote:
On Sun, Dec 15, 2019 at 01:52:52PM +0100, Marton Balint wrote:
On Sun, 15 Dec 2019, Michael Niedermayer wrote:
On Sun, Dec 15, 2019 at 02:16:49AM +0100, Marton Balint wrote:
Unfortunately the ld() and st() operations store the variables in
On Sun, Dec 15, 2019 at 01:52:52PM +0100, Marton Balint wrote:
>
>
> On Sun, 15 Dec 2019, Michael Niedermayer wrote:
>
> >On Sun, Dec 15, 2019 at 02:16:49AM +0100, Marton Balint wrote:
> >>Unfortunately the ld() and st() operations store the variables in the AVExpr
> >>context and not in the par
On Sun, 15 Dec 2019, Michael Niedermayer wrote:
On Sun, Dec 15, 2019 at 02:16:49AM +0100, Marton Balint wrote:
Unfortunately the ld() and st() operations store the variables in the AVExpr
context and not in the parser in order to keep the stored values between
evaluations (which is a rarely(?
On Sun, Dec 15, 2019 at 02:16:49AM +0100, Marton Balint wrote:
> Unfortunately the ld() and st() operations store the variables in the AVExpr
> context and not in the parser in order to keep the stored values between
> evaluations (which is a rarely(?) used undocumented(?) feature of AVExpr).
>
>
On 15-12-2019 06:46 am, Marton Balint wrote:
Unfortunately the ld() and st() operations store the variables in the AVExpr
context and not in the parser in order to keep the stored values between
evaluations (which is a rarely(?) used undocumented(?) feature of AVExpr).
This causes data race is
