XVideo: Support padded YUV strides in all filters

[anonymous]

I am running svn mythtv on a EPIA board (CN700 North Bridge) using a PVR-500 for captures. I am using the latest svn version of the openchrome drivers and using Xv output. When capturing video at 720x480 (or when playing dvds using the mythtv Internal player) the video plays back corrupted with red diagonal lines across the screen and a green bar at the bottom - I have a picture of it here - ​http:// www.trevorkramer.com/myth_corrupted.jpg - The same file plays fine in mplayer and xine. When capturing at 480x480 or several other settings it plays back fine in mythtv. Also - I can play back 720x480 content when using XvMC - it only happens when using Xv output in mythtv.

According to the openchrome developers this is caused by - "MythTV is not setting up the Xv image format according to the pitches and sizes it receives from the X server"

[danielk]

I've asked the OpenChrome? folks for clarification. This may not be fixable in 0.20 since libav needs to be made aware of the stride which may not map well to our order of XVideo init.

[danielk]

What needs to be done to support this is to add Y & U & V strides and offsets to VideoFrame? (frame.h) and use this to initialize the AVFrame picture in get_avf_buffer (avformatdecoder.cpp). The needed data is available in the XvImage? returned from XvShmCreateImage?() in VideoOutputXv::CreateShmImages?() (videoout_xv.cpp), this needs to be saved and passed along to VideoBuffers::CreateBuffers?() (videobuffers.cpp) which actually creates the VideoFrame? structures we use. Our YUV frame clearing construct and any other code where we assume a packed video YUV buffer need to be adjusted to use the needed offsets and strides.

[danielk]

Possible fix

[danielk]

Trevor, please try the attached patch and report if it works for you.

If not, please attach a "mythfrontend -v playback" log.

[tkramer@…]

mythfrontend -v playback log with patch applied

[tkramer@…]

No dice - looks about the same but now there are lots of buffering pauses which were not there before.

[danielk]

possible fix

[danielk]

Trevor, please try the new attached patch and report if it works for you.

We can probably make this faster, but if this doesn't get the colors right I've missed something else.. From looking at your log it looks like it was the U & V swap we're using for YV12 surfaces.

[tkramer@…]

This latest patch "2171-v2-alt.patch" works great. The only thing I'm seeing is when the osd is on the screen the colors get screwed up again and when the osd goes away it looks good again.

[danielk]

(In [10782]) Refs #2171. Fixes basic XVideo support to allow offset and stride padding.

I've ported the VideoOutputXv? and the OSD blend, plus 3 basic filters linearblend, onefield and bobdeint.

The remainder of the filters work a little differently and need some testing I can't do locally but should be ready soon. This doesn't break XVideo that worked before the fix, but VIA & some ATI users can't use these filters if they are using XV w/DMA, the workaround is to disable DMA.

[danielk]

ports adjust,kerneldeint and ivtc filters

[danielk]

I've attached a patch which ports the adjust, kerneldeint and ivtc filters.

The convert, crop, denoise3d, force, invert and quickdnr filters remain incompatible with VIA/ATI XVideo.

[Stuart Auchterlonie]

with and without 2171-filters-v2.patch applied I'm getting a SEGV changing inputs.

valgrind output

==11633== Invalid write of size 1
==11633==    at 0x401E3C5: memset (mc_replace_strmem.c:477)
==11633==    by 0x4743C6D: VideoBuffers::Clear(unsigned, int) (videobuffers.cpp:1318)
==11633==    by 0x4743CCD: VideoBuffers::Clear(int) (videobuffers.cpp:1326)
==11633==    by 0x4745FDF: VideoBuffers::CreateBuffers(int, int, std::vector<unsigned char*, std::allocator<unsigned char*> >, std::vector<YUVInfo, std::allocator<YUVInfo> >) (videobuffers.cpp:1151)
==11633==    by 0x47761BC: VideoOutputXv::CreateBuffers(VideoOutputSubType) (videoout_xv.cpp:1638)
==11633==    by 0x47787C9: VideoOutputXv::InitXVideo() (videoout_xv.cpp:886)
==11633==    by 0x4778DCA: VideoOutputXv::InitVideoBuffers(MythCodecID, bool, bool) (videoout_xv.cpp:718)
==11633==    by 0x477978A: VideoOutputXv::InitSetupBuffers() (videoout_xv.cpp:1124)
==11633==    by 0x477A9C3: VideoOutputXv::InputChanged(int, int, float, MythCodecID) (videoout_xv.cpp:228)
==11633==    by 0x469545D: NuppelVideoPlayer::ReinitVideo() (NuppelVideoPlayer.cpp:599)
==11633==    by 0x46959F4: NuppelVideoPlayer::SetVideoParams(int, int, double, int, float, FrameScanType) (NuppelVideoPlayer.cpp:876)
==11633==    by 0x46CB34C: AvFormatDecoder::InitVideoCodec(AVStream*, AVCodecContext*) (avformatdecoder.cpp:1006)
==11633==  Address 0x17545C40 is not stack'd, malloc'd or (recently) free'd

i'll attach gdb output & frontend --verbose channel,record logs. Excerpt from the gdb output. the result of print *vf within VideoBuffers::clear

$4 = {codec = FMT_YV12, buf = 0xa5569000 "", height = 576, width = 720, bpp = 12, size = 622080, frameNumber = 0, timecode = 0, priv = {0x0, 0x0, 0x0, 0x0}, qscale_table = 0x0, qstride = 0, interlaced_frame = -1, top_field_first = 1, repeat_pict = 0, forcekey = 0, pitches = {720, 360, 360}, offsets = {0, 414720, 518400}}

[Stuart Auchterlonie]

gdb backtrace of SEGV

[Stuart Auchterlonie]

mythfrontend --verbose channel,record

[danielk]

(In [10788]) Refs #2171. Fixes segfault reported by stuarta.

[danielk]

(In [10802]) Refs #2171. Ports adjust, kerneldeint, and ivtc filters to work with padded YUV strides, aka VIA XVideo w/DMA.

[danielk]

(In [10811]) Refs #2171. Fix BlendToYV12 to work with padded strides in YUV surfaces, the earlier change only made it work with padded offsets.

[Nigel]

(In [10833]) OS X compile fix. Refs #2171

[danielk]

(In [10841]) Refs #2171. Fixes non-Xv X11 display segfault reported by Nigel.

[danielk]

Possible fix for problem reported by "Gnome42" (untested)

[danielk]

(In [10845]) Refs #2171. Fix segfault reported by Gnome24. This was due to an uninitialized variable in VideoFrame?, this adds an init function for VideoFrame? to make it easier to avoid this mistake.

[danielk]

(In [10909]) Refs #2171. Some random fixes to directfb output, mostly to fix problems related to the padded YUV strides.

DirectFB is still pretty broken, but I don't want it to be more broken than before [10782]. This also makes DirectFB a little less verbose unless you pass "-v playback", thought it still prints about 25 lines per frame to the stdout/stderr.

[danielk]

(In [11382]) Refs #2171. Fix "quickdnr" filter so it works with padded YUV strides.

This leaves "convert", "crop", "denoise3d", and "force" left to be fixed.

The "invert" filter worked correctly already, and the rest were fixed before 0.20.

[danielk]

(In [11383]) Refs #2171. Fix "denoise3d" filter so it works with padded YUV strides.

[danielk]

(In [11384]) Refs #2171. Fix "crop" filter so it works with padded YUV strides.

This only leaves "convert", the "force" filter works as is.

[danielk]

(In [11389]) Refs #2171. Disable "convert" filter.

This filter is completely broken. It converts to and from 422P incorrectly, and overwrites memory whether you use padded strides or not.

In order to support any conversion which changes the size of the picture planes we need to change the filter API. Since we don't actually use this filter (all our filters work with 420P/YV12) I've just disabled it instead.

[danielk]

This has already been fixed in head, but anon changed the version and milestone to head and 0.21, I'm just changing it back..

[danielk]

No one has complained about the minor stride bugs remaining in the 0.20 fixes filters in almost a year, and it has been fixed in head for a long time.