Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#5846 closed bug (fixed)

Playing avi video broken

Reported by: X512 Owned by: dlmcpaul
Priority: normal Milestone: R1
Component: Audio & Video/Codecs Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by stippi)

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

Attachments (1)

aviVideoBug.png (104.6 KB ) - added by X512 14 years ago.

Download all attachments as: .zip

Change History (23)

by X512, 14 years ago

Attachment: aviVideoBug.png added

comment:1 by stippi, 14 years ago

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?

in reply to:  1 comment:2 by X512, 14 years ago

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.

comment:3 by stippi, 14 years ago

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?

in reply to:  3 comment:4 by X512, 14 years ago

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.

comment:5 by stippi, 14 years ago

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

in reply to:  5 comment:6 by X512, 14 years ago

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.

comment:7 by X512, 14 years ago

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

comment:8 by X512, 14 years ago

Version: R1/DevelopmentR1/alpha2

comment:9 by mmadia, 14 years ago

Would you retest this with a nightly image?

comment:10 by X512, 13 years ago

The same problem in hrev38712.

comment:11 by diver, 13 years ago

Also reproducible in hrev38797 in vbox.

comment:12 by stippi, 13 years ago

Blocking: 6376 added

comment:12 by stippi, 13 years ago

Blocking: 6376 removed
Owner: changed from nobody to dlmcpaul
Status: newassigned

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.

comment:13 by stippi, 13 years ago

Description: modified (diff)
Summary: Playing avi video brokenSIMD color space conversion does not handle all color spaces correctly.

comment:14 by stippi, 13 years ago

BTW, both test videos I have are 320x240.

comment:15 by dlmcpaul, 13 years ago

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.

comment:16 by dlmcpaul, 13 years ago

Owner: changed from dlmcpaul to stippi
Summary: SIMD color space conversion does not handle all color spaces correctly.Playing avi video broken

in reply to:  15 comment:17 by dlmcpaul, 13 years ago

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.

comment:18 by dlmcpaul, 13 years ago

Owner: changed from stippi to dlmcpaul

comment:19 by stippi, 13 years ago

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.

comment:20 by dlmcpaul, 13 years ago

Resolution: fixed
Status: assignedclosed

should be fixed in hrev39913

comment:21 by diver, 13 years ago

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

Note: See TracTickets for help on using tickets.