Single pink line at top of frame when enabling post processor.

[GoogleCodeExporter]

Hi People,

I'm not sure if you have seen this, but we are having an issue where we enable 
the post processor, and set either DEBLOCK or DEMACROBLOCK "on" and the top of 
the frame becomes a single line of pink.

If the post processor is disabled, then there is no issue (the correct line is 
displayed).  We are building the code and using the provided library.

We haven't yet tried reproducing with the ivfdec tool.

Thanks

Martin

Original issue reported on code.google.com by martinli...@gmail.com on 5 Nov 2010 at 7:36

[GoogleCodeExporter]

Hello,

We have a little bit more information to report, which may assist with locating 
it;
Win32 build => pink line. (all 1s we presume)
OSX build => green line. (all 0s we presume)

Cheers

Martin

Original comment by martinli...@gmail.com on 9 Nov 2010 at 2:30

[GoogleCodeExporter]

I haven't been able to reproduce this. Can you try to reproduce this with 
vpxdec? Which version are you running?

Original comment by jkoles...@google.com on 9 Nov 2010 at 1:35

[GoogleCodeExporter]

Hello,

I've been able to mask the problem successfully, by adding the following lines 
to 

        vp8_yv12_extend_frame_borders_ptr(&oci->post_proc_buffer);

To the postproc.c file, vp8_post_proc_frame function, 

   "if (flags & VP8D_DEMACROBLOCK)" and     
   "else if (flags & VP8D_DEBLOCK)" blocks.

I have a strong suspicion that it has to do with the media we are using which 
is 32 x 32 pixels (or multiples thereof).

The top of the CHANGELOG reads; 2010-10-28 v0.9.5 "Aylesbury"

Thanks

Martin

Original comment by martinli...@gmail.com on 10 Nov 2010 at 2:05

[GoogleCodeExporter]

Do you mean *NOT* a multiple of 32x32? Can you provide a sample clip (can be 
just a few frames) or at a minimum, the exact resolution which is displaying 
this problem?

Original comment by jkoles...@google.com on 10 Nov 2010 at 1:47

[GoogleCodeExporter]

Pretty much all the video we do is a multiple of 16 in both width and height. 
The media in question is a multiple of 32.  We've tried a HD 720p frame size 
and a 32x32 pixel clip.  Both exhibit the same problem.  We build our own vpx 
libs, but the one downloaded had the same issue.

Let me know how you want any frames packaged and I'll do that. 

Thanks 

Martin

Original comment by martinli...@gmail.com on 11 Nov 2010 at 12:40

[GoogleCodeExporter]

if you can send a .webm or .ivf file that shows the problem, that should be 
enough to get me started. If this is an application that doesn't deal with 
files, you can also give us a "raw" file by writing the data you pass to 
vpx_codec_decode() to a file -- for each frame, write a 4 byte little endian 
int with the length of that frame's data, followed by the data.

just to be clear, I'm looking for the compressed data, not the 
decoded/postprocessed image. I'm want to reproduce with vpxdec.

Original comment by jkoles...@google.com on 11 Nov 2010 at 1:29

[GoogleCodeExporter]

Hi,

I've almost achieved what you asked for; 
1 file per frame;
File Format:
[2 bytes] junk
[4 bytes] size (little endian)
[1 byte] junk
[VPx frame data]

I hope this helps.

Cheers

Martin

Original comment by martinli...@gmail.com on 12 Nov 2010 at 3:50

Attachments:

• vpx.zip

[GoogleCodeExporter]

Hello,

I was wondering if there was any further forwards motion on this issue.

Thanks

Martin

Original comment by martinli...@gmail.com on 23 Nov 2010 at 6:43

[GoogleCodeExporter]

I haven't been able to reproduce this on osx or linux. I converted the data you 
sent me into something that vpxdec can process and have attached it to this 
bug. Please confirm your can reproduce on your systems with this input file and 
the vpxdec tool and then I'll give you some additional tests to try.

Original comment by jkoles...@google.com on 23 Nov 2010 at 7:06

Attachments:

• postproc-bug.raw

[GoogleCodeExporter]

Hello,

I downloaded the windows code via this link;

http://code.google.com/p/webm/downloads/detail?name=vpx-vp8-debug-src-x86-win32m
t-vs8-v0.9.5.zip&can=2&q=

I built all the libraries and then grabbed vpxdec.exe

I ran it with the following arguments;

vpxdec.exe --i420 --postproc --deblock --demacroblock-level=16 
--output=test_%2.raw postproc-bug.raw

The file it produced I imported into Irfanview, as a raw file, no header, 32x32 
pixels, interpreted as at YUV 4:2:0 image.  It produced no line.

Not satisfied with this, I tried another series of frames encoded from a movie 
trailer.  Same effect; however we noticed pink lines appearing at the sides of 
the image (not solid, only shades).

Having a series of interleaved frames with the post processor on and post 
processor off - we were examining the difference, and realised that the post 
processor was not a post processor at all, but rather a post smudging filter 
that removes detail.  Upon realisation of this, and testing with demacroblock 
set to 1 - we noticed that it didn't improve the video quality - like it has 
done previously with the VP6 codec - it simply made it worse.

Our solution is as follows; Turn off the smudging filter, remove code kludges 
and mark the problem as "not an issue" and leave it.

Thanks

Martin

Original comment by martinli...@gmail.com on 24 Nov 2010 at 4:36

[GoogleCodeExporter]

Original comment by jkoles...@google.com on 1 Mar 2011 at 1:27

• Changed state: Invalid