Playing avi video broken

[X512]

hrev36511 In some videos, the image doubles horizontally and has wrong colors if the native color space conversion is used in AVCodecDecoder. Using libswscale is slower but has the correct conversion. See USE_SWS_FOR_COLOR_SPACE_CONVERSION on line 43 of AVCodecDecoder.cpp

[stippi]

Maybe the alpha 1 release was not supporting your video hardware with overlays? In the MediaPlayer settings, there is a toggle if hardware overlays are to be used, does that change anything? Also, what video hardware do you own?

[X512]

Replying to stippi:

there is a toggle if hardware overlays are to be used, does that change anything?

No.

Also, what video hardware do you own?

nVidia GeForce 6600 LE.

[stippi]

Sounds like hardware that has overlay support in the driver. What happens if you launch a second MediaPlayer instance of the same video? Does the second video display correctly?

[X512]

Replying to stippi:

What happens if you launch a second MediaPlayer instance of the same video? Does the second video display correctly?

Second player plays video same as first.

[stippi]

I just see the potential for misunderstanding, did you have two players open for the same video at the same time?

[X512]

Replying to stippi:

I just see the potential for misunderstanding, did you have two players open for the same video at the same time?

I test with 1 player and 2 players at the same time. All tests have same result(see attached picture).

VLC playing video OK.

[X512]

R1/A2 has this bug too. Example of wrong playing video: ​http://www.traversaltech.com/files/ogd1_boot_vga.avi.

[mmadia]

Would you retest this with a ​nightly image?

[X512]

The same problem in hrev38712.

[diver]

Also reproducible in hrev38797 in vbox.

[stippi]

David, the bug is in the color space conversion code. If USE_SWS_FOR_COLOR_SPACE_CONVERSION is defined to 1 on line 43 of the AVCodecDecoder.cpp, then the video plays fine.

[stippi]

BTW, both test videos I have are 320x240.

[dlmcpaul]

An invalid colorspace is being passed to resolve_colorspace

Namely fContext.pix_fmt contains PIX_FMT_NONE

interestingly codecContext.pix_fmt does contain the correct colorspace

The SIMD colorspace converters are not being used.

[dlmcpaul]

Replying to dlmcpaul:

An invalid colorspace is being passed to resolve_colorspace

Namely fContext.pix_fmt contains PIX_FMT_NONE

interestingly codecContext.pix_fmt does contain the correct colorspace

The SIMD colorspace converters are not being used.

Hmm, a recompile fixed this. Now it seems the packed converters are being used when the format is planar.

[stippi]

I started looking into it and got caught up cleaning up the code versus looking at the actual problem. Of course cleaning it up I got a much better overview of what's actually there. I started removing all sorts of stuff which isn't actually implemented and just distracts from the bigger picture. Don't know if I committed that all, I believe not. A lot of stuff actually falls back to the C implementation and doesn't use SIMD at all. Then some stuff wrongly uses the NULL conversion which just does a memcpy(), while it should better do something. Some conversions are incorrectly implemented with a TODO in the code. I thought a good solution, since your code is so much faster when it works correctly, is to make sure no wrong conversions are used and for everything we don't support natively, use the swscale() codepath. For example also for the unaligned buffers, of which some are caught later in the code, i.e. *all* the checks need to be moved higher up in the code.

Unless I missed something, what you wrote in the comment above can't really be the reason for the problem, since the swscale() code paths also use fContext.pix_fmt, so it should not work then either. Those are my findings so far, I won't be looking into this until Monday at least.

[dlmcpaul]

should be fixed in hrev39913

[diver]

BTW, audio disappears after rewinding this (ogd1_boot_vga.avi) file. It comes back several seconds later.