Open source SVC decoder

[Dust Signs]

Hi,

as I stumbled upon this on one of the JVT mailing lists and did not find a corresponding topic in here I thought I'll share this: http://sourceforge.net/projects/opensvcdecoder/
According to the post on the mailing list it's "50 times faster than the JSVM", but as Dark Shikari replied on the mailing list a comparison with a "real world" decoder would be more meaningful. I didn't find the time to test it yet - just opened the player.exe which looks quite old fashioned and is not very intuitive to use. Unfortunately I don't have the time right now to do some tests (maybe on the weekend), but maybe someone is interested in doing that in the mean time :).

Dust Signs

[Dark Shikari]

The code is really rather boring. Almost no assembly code, and that which exists is terribly-written intrinsics. Most of the decent code is ripped from really old versions of libavcodec.

It's going to be slow, folks.

[Dust Signs]

I just wanted to test the performance in my lunch break but i could not get even one file to display properly. I tried all of the sequences from here (http://ip.hhi.de/imagecom_G1/savce/MPEG-Verification-Test/SBC1.htm) and here (http://www.svc-analyzer.com/index.php?option=com_remository&Itemid=11&func=finishdown&id=9). As their player.exe is incapable of playing raw bit streams I tried several containers and (in order to be sure) different applications for muxing. The result: I achieved to open one of the files from the first link after muxing it into an MP4 container, but the picture being displayed had the wrong size, the wrong aspect ratio and was a mixture of green and grey blocks which looked nothing like they were supposed to look. Trying to play or even move the position slider resulted in an immediate crash, as did all the other video sequences.
So far I'm either using the invalid or old (maybe from during the standardization process) streams or the software itself is really incapable of decoding them. Either way, lunch break is over, so I have to get back to work. Maybe someone has got more time to investigate this but to me it does not look very promising...

Dust Signs

[benwaggoner]

If not this one, are there any other SVC decoders known to work reasonably well?

[Dark Shikari]

if not this one, are there any other svc decoders known to work reasonably well?JSVM perhaps ;)

[BeyondTheEyes]

Maybe someone has got more time to investigate this but to me it does not look very promising...
Dust Signs

I would recommend to have a look at the official SVC conformance bitstreams (http://wftp3.itu.int/av-arch/jvt-site/bitstream_exchange/SVC/) and not to some old broken bitstreams (i.e. not compliant to the published scalable extension of H.264/AVC (http://www.itu.int/rec/T-REC-H.264/en), a.k.a. SVC)...
as explained here (http://sourceforge.net/forum/forum.php?forum_id=967885).

[BeyondTheEyes]

The code is really rather boring. Almost no assembly code, and that which exists is terribly-written intrinsics.

Maybe this has something to do with the fact that this code is "automatically" generated using a dataflow-based description, following the MPEG Reconfigurable Video Coding framework...

[Dark Shikari]

Maybe this has something to do with the fact that this code is "automatically" generated using a dataflow-based description, following the MPEG Reconfigurable Video Coding framework...I doubt that, considering a large portion of the code is copy-pasted from libavcodec.

[BeyondTheEyes]

If not this one, are there any other SVC decoders known to work reasonably well?

I would not say "known", but other SVC decoder(s) do exist and yes, they do work reasonably well... ;-)

Among them, have you ever tried the Google Video Chat plugin from Vidyo (http://www.vidyo.com/)?

BTW, I would kindly suggest to have a look at DVB-SCENE 30 (http://cde.cerosmedia.com/1X4a167dfa1eab8557.cde) (June 2009) pages 10-11.

[BeyondTheEyes]

I doubt that, considering a large portion of the code is copy-pasted from libavcodec.

“[Luke:] I can’t believe it. [Yoda:] That is why you fail.”

[Dark Shikari]

“[Luke:] I can’t believe it. [Yoda:] That is why you fail.”Do I need to post the actual code here? Hell, one of the authors of the library admitted that they used copy-pasted libavcodec code.

But here's some easy ones:

int residual_block_cabac( CABACContext *c, unsigned char *state, short *coeffLevel, int non_zero_count_cache[], const int *scan_table, CABAC_NEIGH *neigh
, int cat , int n, int max_coeff, int *cbp, int offset )
{

int index[64];

int i, last;
int coeff_count = 0;
int abslevel1 = 1;
int abslevelgt1 = 0;
unsigned char *significant_coeff_ctx_base;
unsigned char *last_coeff_ctx_base;
unsigned char *abs_level_m1_ctx_base;


int left_cbp = neigh -> Cbp_a;
int top_cbp = neigh -> Cbp_b;


/* cat: 0 -> DC 16x16 n = 0
* 1 -> AC 16x16 n = luma4x4idx
* 2 -> Luma4x4 n = luma4x4idx
* 3 -> DC Chroma n = iCbCr
* 4 -> AC Chroma n = 4 * iCbCr + chroma4x4idx
* 5 -> Luma8x8 n = 4 * luma8x8idx
*/

/* read coded block flag */
if( cat != 5 ) {
if( get_cabac( c, &state[85 + get_cabac_cbf_ctx(non_zero_count_cache, cat, n,left_cbp, top_cbp ) ] ) == 0 ) {
if( cat == 1 || cat == 2 )
non_zero_count_cache[SCAN8(n)] = 0;
else if( cat == 4 )
non_zero_count_cache[SCAN8(16+n)] = 0;
return 0;
}
}

significant_coeff_ctx_base = state + significant_coeff_flag_offset[cat] + significant_coeff_flag_field_offset[0];

last_coeff_ctx_base = state + last_significant_coeff_flag_offset[cat] + last_significant_coeff_flag_field_offset[0];

abs_level_m1_ctx_base = state + coeff_abs_level_m1_offset[cat];



if( cat == 5 ) {
DECODE_SIGNIFICANCE(63, significant_coeff_flag_offset_8x8[last], last_coeff_flag_offset_8x8[last] );
} else {
DECODE_SIGNIFICANCE(max_coeff - 1, last, last );
}
if( last == max_coeff -1 ) {
index[coeff_count++] = last;
}

if( cat == 0 )
*cbp |= 0x100;
else if( cat == 1 || cat == 2 )
non_zero_count_cache[SCAN8(n)] = coeff_count;
else if( cat == 3 )
*cbp |= 0x40 << n;
else if( cat == 4 )
non_zero_count_cache[SCAN8(16 + n)] = coeff_count;
else {
non_zero_count_cache[SCAN8(n)] = non_zero_count_cache[SCAN8(n + 1)] =
non_zero_count_cache[SCAN8(n + 2)] = non_zero_count_cache[SCAN8(n + 3)] = coeff_count;
}

for( i = coeff_count - 1; i >= 0; i-- ) {
unsigned char *ctx = (abslevelgt1 != 0 ? 0 : 4 >abslevel1 ? abslevel1:4 ) + abs_level_m1_ctx_base;
short j = (short) scan_table[index[i] + offset] ;

if( get_cabac( c, ctx ) == 0 ) {
if( get_cabac_bypass( c ) ){
coeffLevel[j] = -1;
}else {
coeffLevel[j] = 1;
}

abslevel1++;
} else {
short coeff_abs = 2;
ctx = 5 + (4 > abslevelgt1 ? abslevelgt1: 4) + abs_level_m1_ctx_base;
while( coeff_abs < 15 && get_cabac( c, ctx ) ) {
coeff_abs++;
}

if( coeff_abs >= 15 ) {
short j = 0;
while( get_cabac_bypass( c ) ) {
coeff_abs += 1 << j;
j++;
}

while( j-- ) {
if( get_cabac_bypass( c ) )
coeff_abs += 1 << j ;
}
}


if( get_cabac_bypass( c ) )
coeffLevel[j] = - coeff_abs;
else
coeffLevel[j] = coeff_abs;

abslevelgt1++;
}
}

return 0;
}

This function is copied from libavcodec almost line-for-line, with one of the comments (the 0/1/2/3/4/5 comment) being character-for-character identical.

[BeyondTheEyes]

I doubt that, considering a large portion of the code is copy-pasted from libavcodec.

The term "this code" I was referring to is related to the very specific part of your post about the non "copy-pasted from libavcodec" part of their code. I fully agree that they should have paid more attention to GPL implications for the H.264/AVC base layer support, but regarding the SVC-related portions of their decoder, I believe that this does not come from libavcodec, or I missed something...

[Dark Shikari]

The term "this code" I was referring to is related to the very specific part of your post about the non "copy-pasted from libavcodec" part of their code. I fully agree that they should have paid more attention to GPL implications for the H.264/AVC base layer support, but regarding the SVC-related portions of their decoder, I believe that this does not come from libavcodec, or I missed something...Oh, of course.

There's no GPL implications anyways; the library itself is GPL anyways, so all they need to do is credit the source.

[Dust Signs]

I would recommend to have a look at the official SVC conformance bitstreams (http://wftp3.itu.int/av-arch/jvt-site/bitstream_exchange/SVC/) and not to some old broken bitstreams (i.e. not compliant to the published scalable extension of H.264/AVC (http://www.itu.int/rec/T-REC-H.264/en), a.k.a. SVC)...
as explained here (http://sourceforge.net/forum/forum.php?forum_id=967885).
I just tested some of these streams (muxed of course as raw streams are not supported) - same result (sequence shown here is SVCHMTS-2):http://img32.imageshack.us/img32/4351/svc.th.jpg (http://img32.imageshack.us/i/svc.jpg/)

Dust Signs

PS.: When typing in my browser with the player window open the spacebar does not work any more and the "decoded" picture is being drawn over the textbox in my browser - that's kind of odd :confused: :eek:
//EDIT: I just found out that the spacebar controls pause/play in the player and seems to be hooked globally which explains that -_-. Oh dear, I better get rid of that executable

[BeyondTheEyes]

I just tested some of these streams (muxed of course as raw streams are not supported) - same result (sequence shown here is SVCHMTS-2)

Bad choice! According to that table (http://opensvcdecoder.sourceforge.net/JVT-AB023.xls) (as explained here (http://sourceforge.net/forum/forum.php?forum_id=967885)), that particular conformance bitstream SVCHMTS-2 comes with specific features that are not yet supported by their decoder.

Oh dear, I better get rid of that executable

You may want to test that decoder with Mplayer instead, as explained here (http://sourceforge.net/apps/mediawiki/opensvcdecoder/index.php?title=Installation#Mplayer_installation).