[mythtv] HDTV patches

John Patrick Poet john at BlueSkyTours.com
Thu May 20 02:50:02 EDT 2004


I am running Fedora Core 2 Test 3, with a 2.6.6 Kernel, then new 
"official" 2.6.6 HD-2000 (pcHDTV) drivers, and all of Daniel's patches 
listed below.  Everything seems to be working very well for me.

Daniel,

Thanks for making XvMC acceleration an option in the playback setup -- 
at least I assume that was you.  With my 2.8 GHz HT P4, I still get 
better playback without enabling XvMC. 

The debugging output from mythbackend is a bit messy.  Unless you want 
me to do some more testing, can you tell me how to disable that output?

Thanks,

John


Daniel Thor Kristjansson wrote:

> The whole set of the latest patches is available here:
>  http://www.mrl.nyu.edu/~danielk/mythtv/all-patches-v1.tbz
>
>When I apply all of them, I do it in this order: xvmc-deinterlace,
>xvmc-idct, hdtv-signalcheck, hdtv-recorder, xvmc-efficiency. Of the
>non-patch files, XvMCSurfaceTypes.h is required for xvmc-idct, and the
>rest are used by the recorder patch; they all go in libs/libmythtv.
>
>*
>
>The signal check patch is fairly simple, I made two changes to the
>last version, one is to support both inputs throughout, and the
>other is to use v4l2 if available. The second change is for the new
>2.6.6 pcHDTV drivers, but it doesn't break the old driver since it does
>not support v4l2.
>
>*
>
>The idct patch is a little more complicated. First, it adds
>XvMCSurfaceTypes.h which descripes a XvMC port. XvMCSurfaceTypes.h also
>includes a couple find functions that let you locate a surface that
>supports the chroma, mpeg version, idct/mv, resolution and subsurface
>resolution. One locates a surface on a particular port that
>XvMCSurfaceTypes.h describes and the other is a static function that
>looks at a range of ports you specify on a particular display and
>adaptor. These find functions let you simplify VideoOutputXvMC::Init().
>I've also changed this function so it does also tries to find an IDCT
>capable surface first on a particular display and then try to find an MC
>capable surface. The old code didn't care which it got, so in practice
>it always got an MC only capable surface.
>
>I've added a method to VideoOutputXvMC called hasIDCTAcceleration()
>which tells the caller if the XvMC surface supports IDCT Acceleration.
>This lets NuppelVideoPlayer tell the AvFormatDecoder what kind of pixel
>format to use. This is done in InitVideo() right after
>VideoOutputXvMC::Init() is called.
>
>AvFormatDecoder in turn has a method called SetPixelFormat() which
>associates a pixel format with the video codecs in it's codec context.
>It also has a function that returns this pixelformat when given the
>context. This function is passed to the encoder when an XvMC decoder is
>created so that when it begins decoding the stream it will be told to
>use whatever pixelformat was specified by SetPixelFormat() when the XvMC
>surface was created (The XvMC surface is created after the avdecoder,
>but before te avdecoder calls getFormat(). The other small change I made
>was to use the ffmpeg defines for the error_concealment and idct_algo
>for clarity, to remove the setting of rate_emu, which doesn't do
>anything, and add the setting of enc->error_rate with a comment. Setting
>enc->error_rate to a higher value will allow broken streams to play, but
>adds junk to correct streams, when the recording patches are more
>complete I should be able to detect broken streams and set this
>accordingly.
>
>*
>
>I'll describe the other patches in later e-mails. But I'll note
>that xvmc-deinterlace is a poor man's deinterlacer which may reduce
>playback quality and hdtv-recorder is still experimental and produces a
>lot of printf noise.
>
>-- Daniel
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>  
>



More information about the mythtv-dev mailing list