if using PP_HARDWAREACCELERATION_NONE it just returns error -15 (PP_ERROR_RESOURCE_FAILED) to the first GetPictureDone callback.
If using PP_HARDWAREACCELERATION_WITHFALLBACK, then i get a picture like this: https://images.sshnuke.net/2016-02-27_00-27-07.png (it thinks there's only 1/4 of the macroblocks that there actually are ?, notice that the MV interpolated data from the bottom ones are also black, so its not like its just only showing 1/4 of the decoded image)
Here is the bitstream: https://files.sshnuke.net/goodstream.264 (4-byte length prefixed, not 0,0,0,1 prefixed, to convert it to that format so it can be played by mplayer or similar, use something like http://pastebin.com/dUkRN1zt)
And here's the slightly modified video_decode.cc i tried to play it: http://pastebin.com/YyNzmjgG (i am running as a ppapi .dll on windows as recommended in the debugging guidelines, so i can just use fopen to open d:/goodstream.264 (the file posted above) in order to get its contents)
The bitstream plays perfectly when using ffmpeg (even inside a chrome plugin as shown in the video itself), mplayer on the annex-b converted .264 file (using above utility), or even inside chrome when the annex-b converted .264 file is just packaged inside a .mp4 file ! (https://files.sshnuke.net/goodstream2-muxed.mp4)
Unfortunately ffmpeg inside nacl doesn't let me use video accelerated decoding which is what i'm trying to accomplish by using pp::VideoDecoder, so can anyone point me to what I'm doing wrong ?
(The bitstream was generated by NVENC Low-Latency high profile capture of my desktop)

Thanks in advance.

From your description, the software fallback implementation in Chrome (PP_HARDWAREACCELERATION_NONE) is initialized successfully but then fails to decode anything. The hardware implementation decodes successfully, but incorrectly.

the first NALUs in that bitstream are the SPS and then the PPS, then followed by frame data (not necessarily the first being an I-frame, ive tried skipping anything other than SPS/PPS untill the first I-frame, but that didn't change a thing).
the ffmpeg in nacl webports is able to decode the exact same bitstream perfectly with no extradata, just feeding it one NALU in an AVPacket at a time (annexb prefixed, just like im feeding pp::VideoDecoder), with CODEC_FLAG2_CHUNKS on (which is required for one-NALU-at-a-time decoding, instead of one-frame-at-a-time decoding)

Can you play the videos in Chrome (not using PPAPI or a plugin)? If Chrome can play them, then it might be a bug in the Pepper API.

As i've said in the first post, the same raw bitstream just boxed in mp4 plays fine when opened in chrome.