[mythtv] Updated patch for directshow filters with MythTV (for CoreAVC)

[Alan Nisota]

Andrew Lyon wrote:
> On 2/16/07, Alan Nisota <alannisota at gmail.com> wrote:
>> Andrew Lyon wrote:
>> > On 2/15/07, Alan Nisota <alannisota at gmail.com> wrote:
>> >> Andrew Lyon wrote:
>> >> > The colour issue remains, "vertical, colour/chroma ghosting" is 
>> a good
>> >> > description, alan do you see the same on the other sample I sent?
>> >> I've been unable to see any chroma problems so far (but I haven't 
>> had a
>> >> chance to look at the new sample I got from you).  However, I saw 
>> this
>> >> on the Doom9 forum:
>> >>
>> >>     Has anybody tried setting the output color space to RGB32? I 
>> want to
>> >>     use it because there are problems with the color range in YUV 
>> modes
>> >>     on NVidia cards (16-235 instead of 0-255). The reason I need 
>> this is
>> >>     because the Fix VMR9 color range is not working when DirectVobSub
>> >>     (or any other postprocessing) is used.
>> >>
>> >> I'm not too familiar with the output formats, but we are using I420
>> >> which is a 12bit format like the other YUV modes.  If this is the
>> >> problem it would explain why I haven't seen the issue on the samples
>> >> I've looked at.  You can try to fix it via:
>> >> mythregistercodec -r ~/.mythtv/registry -k
>> >> "HKCU\\Software\\CoreCodec\\CoreAVC Pro\\VMR9Fix" -v "1"
>> >>
>> >> It may or may not work though.  Currently we can only set string 
>> values
>> >> for registry keys, and this would normally be a DWORD.  If it doesn't
>> >> help, I'll put together a patch to allow setting the type.  It may be
>> >> that I'm barking up the wrong tree here, too.
>> >
>> > Tried it, no change.
>> Ok, one last msg, then I need to go to bed:
>> This crude hack fixes the color problem for me, so it does show that it
>> is an alignment issue:
>> in avformatdecoder.cpp:
>>     avctx->get_buffer(avctx, picture);
>>     ret = DS_VideoDecoder_DecodeInternal(dshowdec, buf, len, 0, (char
>> *)picture->data[0]);
>> //    printf("\tret: %d\n", ret);
>> //    frm->type    = FF_BUFFER_TYPE_USER;
>> +    memmove(picture->data[0] + 1440*1088 + 1440 * 1088 / 4,
>> picture->data[0] + 1440*1080 + 1440*1080 / 4, 1440*1080 / 4);
>> +    memmove(picture->data[0] + 1440*1088, picture->data[0] + 1440*1080,
>> 1440*1080 / 4);
>>     *got_picture_ptr = 1;
>>
>>
>> Note that I hardcoded the resolution so it'll only work for this one
>> case, but it fixes the color offset on the samples I have.  Now that I
>> know what is wrong, I'll clean it up so the res isn't hardcoded and add
>> it to my patch tommorow.
>> If one of you UK folks could verify it is ok, that would be helpful.
>> I'll roll up all the patches I've posted and create a new CoreAVC patch
>> from them.
>>
>>
>>
>
> Tested with UK BBC HD, image is perfect, playback is a little jittery
> at times and cpu load is higher, I assume because of the extra
> calculation added to correct the colours/alignment... I will get a
> faster cpu if necessary.
Not sure if you need a faster CPU, but not for this specific reason.  I 
just posted version 1.3 of the patch.  It resolves all issues I know 
about, as well as fixing the resolution issue in a no-overhead manner.  
There is other stuff in here besides patches I've posted to the list, 
but I've been using it with good success so far.  I don't have any other 
changes in my queue, so this'll probably be my last update to the patch 
for a while unless I missed something, or someone has a specific request.
Note that the code as it is now should support any DirectShow codec that 
works with mplayer, and is no longer limited to CoreAVC.  Of course I 
haven't tested it, as ffmpeg does a pretty good job with everything 
besides h264.