Test decoder behavior when dropping frames

[GoogleCodeExporter]

I did a git pull on May 7 commit hash 58cf8bef86547811d531439ca3ff8392826b7871 ,
this version has something broken for iOS. It throws a bad access error at " 
ctx->yv12_frame_buffers.pbi[0]->decrypt_cb = ctx->decrypt_cb;" inside function 
vp8_decode. 

Original issue reported on code.google.com by shri...@bluejeansnet.com on 9 May 2014 at 4:17

[GoogleCodeExporter]

Original comment by renganat...@google.com on 15 May 2014 at 10:24

• Changed state: Assigned
• Added labels: Component-libvpx, Pri-2, Type-Bug

[GoogleCodeExporter]

Can you please share more information? How are you building the library? How 
are you using it? Do you have a complete stack trace? Is this for all files or 
just one?

Original comment by johannkoenig@google.com on 16 May 2014 at 4:20

[GoogleCodeExporter]

I just did a pull and I'm getting similar error. 
I've pasted a backtrace here: 
https://gist.github.com/roxlu/51eb0461643c3c738d25.

- I have an encoder and decoder. When I encode and send the frames using rtp 
over
wifi to the decoder, the decoder crashes. When I start my decoder first, then 
start the encoder on the same pc everything works fine (probably because the 
decoder receives -all- the packets, also the first one).
- I've tested the same decoder code on Mac and there it works fine.
- I'm sending data through RTP/VP8 over Wifi w/o packet recovery (so losing 
packet).
- Using this commit of libvpx e9ed051c83c1f6e9940c93fa853436c435e67b6d. 
- I've used these configure flags:  --as=yasm --disable-shared --enable-static 
--  disable-vp9. 
- Running Arch Linux 3.11.6-1-ARCH. 
- Compiled with gcc: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8.2/configure --prefix=/usr 
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man 
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ 
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared 
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch 
--enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl 
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default 
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu 
--disable-install-libiberty --disable-multilib --disable-libssp 
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 (GCC).

Hope this helps,
roxlu

Original comment by diederi...@gmail.com on 20 May 2014 at 7:53

[GoogleCodeExporter]

I just verified that this crash happens only when you pass any encoded data 
which is not a "golden/key" frame. Only after receiving a keyframe you can 
start passing any data into the decoder. On mac I get a correct error message 
that the bitstream can't be decoded; linux crashes.

Original comment by diederi...@gmail.com on 20 May 2014 at 8:46

[GoogleCodeExporter]

Absolutely, didn't get the chance to create a bug for this but I encountered 
the same error on iOS with Clang compiler.
Since then, I switched to bypassing the call to the encoder entirely until I 
have an i-frame coming.

Original comment by gbi.linp...@gmail.com on 2 Jul 2014 at 7:17

[GoogleCodeExporter]

You must re-initialize the decoder with a key frame. Seeking to non-key frames 
is not supported.

Original comment by johannkoenig@google.com on 6 Nov 2014 at 1:02

• Changed state: WontFix

[GoogleCodeExporter]

Bad things shouldn't happen if one does. This is similar to passing the decoder 
bad data...

Original comment by jz...@google.com on 6 Nov 2014 at 9:56

• Changed state: Assigned

[GoogleCodeExporter]

I'll look into adding a test which drops frames. That plus the fuzzer should 
expose some crashes. Not going to commit to fixing all the issues before 1.4 
though.

Original comment by johannkoenig@google.com on 6 Nov 2014 at 4:40

• Changed title: Test decoder behavior when dropping frames