On Tue, Apr 25, 2017 at 6:58 PM, wm4 wrote:
> On Tue, 25 Apr 2017 17:29:10 +0700
> Muhammad Faiz wrote:
>
>> On Tue, Apr 25, 2017 at 4:09 PM, Hendrik Leppkes wrote:
>> > On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote:
>> >> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote:
>> >>> This is neede
On Tue, 25 Apr 2017 17:29:10 +0700
Muhammad Faiz wrote:
> On Tue, Apr 25, 2017 at 4:09 PM, Hendrik Leppkes wrote:
> > On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote:
> >> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote:
> >>> This is needed to get compatibility with the behavior before th
On Tue, Apr 25, 2017 at 4:09 PM, Hendrik Leppkes wrote:
> On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote:
>> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote:
>>> This is needed to get compatibility with the behavior before the
>>> recent decode.c restructuring merge, and fixes fate failures wit
On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote:
> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote:
>> This is needed to get compatibility with the behavior before the
>> recent decode.c restructuring merge, and fixes fate failures with
>> this:
>>
>> make fate-h264-attachment-631 THREADS=32
>>
On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote:
> This is needed to get compatibility with the behavior before the
> recent decode.c restructuring merge, and fixes fate failures with
> this:
>
> make fate-h264-attachment-631 THREADS=32
>
> For every 4 threads, a frame is dropped at the point at whic
