Opened 18 years ago
Closed 17 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)
Change History (33)
comment:1 Changed 18 years ago by
Milestone: | → unknown |
---|---|
Owner: | changed from Isaac Richards to danielk |
Priority: | major → minor |
Severity: | medium → low |
comment:2 Changed 18 years ago by
Milestone: | unknown → 0.21 |
---|---|
Summary: | 720x480 Playback Problems With Openchrome Driver → XVideo: Support padded YUV strides |
Type: | defect → task |
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.
comment:3 Changed 18 years ago by
Type: | task → patch |
---|
Trevor, please try the attached patch and report if it works for you.
If not, please attach a "mythfrontend -v playback" log.
Changed 18 years ago by
Attachment: | output.log added |
---|
mythfrontend -v playback log with patch applied
comment:4 Changed 18 years ago by
No dice - looks about the same but now there are lots of buffering pauses which were not there before.
comment:5 Changed 18 years ago by
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 18 years ago by
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 18 years ago by
(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 18 years ago by
Attachment: | 2171-filters-v2.patch added |
---|
ports adjust,kerneldeint and ivtc filters
comment:8 Changed 18 years ago by
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 18 years ago by
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}}
comment:11 Changed 18 years ago by
comment:12 Changed 18 years ago by
comment:14 Changed 18 years ago by
Summary: | XVideo: Support padded YUV strides → XVideo: Support padded YUV strides in all filters |
---|---|
Type: | patch → task |
comment:15 Changed 18 years ago by
Changed 18 years ago by
Attachment: | 2171-nvr.patch added |
---|
Possible fix for problem reported by "Gnome42" (untested)
comment:16 Changed 18 years ago by
(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 18 years ago by
(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 18 years ago by
comment:19 Changed 18 years ago by
comment:20 Changed 18 years ago by
comment:21 Changed 18 years ago by
(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 18 years ago by
Milestone: | 0.21 → 0.20 |
---|---|
Version: | head → 0.20 |
comment:23 Changed 18 years ago by
Type: | task → patch |
---|
comment:24 Changed 17 years ago by
Milestone: | 0.20 → 0.21 |
---|---|
Version: | 0.20 → head |
comment:25 Changed 17 years ago by
Milestone: | 0.21 → 0.20 |
---|---|
Version: | head → 0.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 17 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
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.