UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Platform: 7647.84.0

Steps to reproduce the problem:
The PPB_VideoEncoder (0.2) "Encode" call "stalls" for certain bitrates when encoding into H.264/baseline. Background: we have built a PNaCl plugin that successfully encodes H.264 and VP8 video from a given pixel buffer. We are using an x86-64 Chromebook (a Toshiba Chromebook 2 "CB35") - unsure if other types of x86 Chromebooks are affected. There is a general issue on ARM-based Chromebooks, which is seemingly related to a Linux driver issue (see  issue 551761 ) and as such, different to this issue.

Specifically, what we do: we invoke the PPB_VideoEncoder operations in a separate call, such as to avoid the ordering complexities of using asynchronous callbacks (from the Encode, GetBitstreamBuffer functions). For the first few frames (according to the number comes back from GetFramesRequired), we invoke Encode with a "dummy" callback that will never be invoked:

```
ppb_videoencoder_interface->Encode(
   encoder,
   video_frame,
   PP_FALSE,
   PP_MakeCompletionCallback(dummy_callback, NULL)
);

// proceed by passing the next frame to Encode
```
From the N-th (with N=GetFramesRequired()) frame onwards, we use:
```
ppb_videoencoder_interface->Encode(
   encoder,
   video_frame,
   PP_FALSE,
   PP_BlockUntilComplete()
);	

// proceed by fetching the bitstream buffer for this Encode call, then pass the next frame to Encode
```

What is the expected behavior?
Encode calls should eventually return when called after the first few frames were passed into the encoder.

What went wrong?
This works fine for software encoding (VP8) and in most cases for hardware encoding (H.264). We found that for a few bitrates that we pass into the Initialize call, Encode stalls when being invoked with the PP_BlockUntilComplete() callback. The differences in the bitrates can be fairly small, like we noticed it to stall for 5600000, but work fine for 6000000 and 4800000.

We thus believe this is a bug in PPB_VideoEncoder. 

Generally, the GetFramesRequired behavior is a bit awkward. I would prefer if could always be called with PP_BlockUntilComplete and return some status flag that indicates whether this Encode call has produced a bitstream buffer that can be fetched. 

Did this work before? Yes For some (most?) bitrates our implementation works fine, only for some bitrates, it stalls. 

Chrome version: 48.0.2564.116  Channel: stable
OS Version: 48.0.2564.116 (64-bit)
Flash Version: not sure, n/a