Opened 13 years ago

Closed 12 years ago

#2171 closed patch (wontfix)

XVideo: Support padded YUV strides in all filters

Reported by: anonymous Owned by: danielk
Priority: minor Milestone: 0.20
Component: mythtv Version: 0.20
Severity: low Keywords:
Cc: Ticket locked: no

Description

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"

Attachments (7)

2171-v1.patch (11.3 KB) - added by danielk 13 years ago.
Possible fix
output.log (17.7 KB) - added by tkramer@… 13 years ago.
mythfrontend -v playback log with patch applied
2171-v2.patch (16.5 KB) - added by danielk 13 years ago.
possible fix
2171-filters-v2.patch (13.6 KB) - added by danielk 13 years ago.
ports adjust,kerneldeint and ivtc filters
videobuffers-segv.txt (8.4 KB) - added by Stuart Auchterlonie 13 years ago.
gdb backtrace of SEGV
frontend.log (3.9 KB) - added by Stuart Auchterlonie 13 years ago.
mythfrontend --verbose channel,record
2171-nvr.patch (6.4 KB) - added by danielk 13 years ago.
Possible fix for problem reported by "Gnome42" (untested)

Download all attachments as: .zip

Change History (33)

comment:1 Changed 13 years ago by danielk

Milestone: unknown
Owner: changed from Isaac Richards to danielk
Priority: majorminor
Severity: mediumlow

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.

comment:2 Changed 13 years ago by danielk

Milestone: unknown0.21
Summary: 720x480 Playback Problems With Openchrome DriverXVideo: Support padded YUV strides
Type: defecttask

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.

Changed 13 years ago by danielk

Attachment: 2171-v1.patch added

Possible fix

comment:3 Changed 13 years ago by danielk

Type: taskpatch

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

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

Changed 13 years ago by tkramer@…

Attachment: output.log added

mythfrontend -v playback log with patch applied

comment:4 Changed 13 years ago by tkramer@…

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

Changed 13 years ago by danielk

Attachment: 2171-v2.patch added

possible fix

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by 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.

Changed 13 years ago by danielk

Attachment: 2171-filters-v2.patch added

ports adjust,kerneldeint and ivtc filters

comment:8 Changed 13 years ago by 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.

comment:9 Changed 13 years ago by 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}}

Changed 13 years ago by Stuart Auchterlonie

Attachment: videobuffers-segv.txt added

gdb backtrace of SEGV

Changed 13 years ago by Stuart Auchterlonie

Attachment: frontend.log added

mythfrontend --verbose channel,record

comment:10 Changed 13 years ago by danielk

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

comment:11 Changed 13 years ago by danielk

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

comment:12 Changed 13 years ago by 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.

comment:13 Changed 13 years ago by Nigel

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

comment:14 Changed 13 years ago by danielk

Summary: XVideo: Support padded YUV stridesXVideo: Support padded YUV strides in all filters
Type: patchtask

comment:15 Changed 13 years ago by danielk

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

Changed 13 years ago by danielk

Attachment: 2171-nvr.patch added

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

comment:16 Changed 13 years ago by 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.

comment:17 Changed 13 years ago by 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.

comment:18 Changed 13 years ago by 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.

comment:19 Changed 13 years ago by danielk

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

comment:20 Changed 13 years ago by 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.

comment:21 Changed 13 years ago by 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.

comment:22 Changed 13 years ago by danielk

Milestone: 0.210.20
Version: head0.20

comment:23 Changed 13 years ago by danielk

Type: taskpatch

comment:24 Changed 13 years ago by anonymous

Milestone: 0.200.21
Version: 0.20head

comment:25 Changed 13 years ago by danielk

Milestone: 0.210.20
Version: head0.20

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..

comment:26 Changed 12 years ago by danielk

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.