[mythtv-users] XvMC and libmpeg2 to be dropped in 0.25

[Brian Wood]

On Tuesday, December 07, 2010 11:14:27 am Michael T. Dean wrote:
>   On 12/07/2010 09:31 AM, Brian Wood wrote:
> > On Monday, December 06, 2010 01:44:13 pm Michael T. Dean wrote:
> >> On 12/06/2010 03:26 PM, Nick Rout wrote:
> >>> yep. of course much of it will still work as a file or print
> >>> server too.
> >> 
> >> Or as a MythTV backend.
> >> 
> >> Dedicated backends don't need to be fast.  Only people who feel
> >> they need faster-than-real-time commercial detection or
> >> transcoding need fast backend systems (and, in truth, even they
> >> don't--they only need fast mythjobqueue systems, and can easily
> >> disable jobs on their slow backends).
> >> 
> >> My backend system can't even decode the video it records in real
> >> time--let alone play it back using Xv or OpenGL or VDPAU.
> >> 
> >> You only need frontends that have 21st-century video output.
> > 
> > The exception would be if you were using software encoding,
> 
> True.  My unsaid implication is that there's not really any good
> reason to use frame grabbers/software encoding in 2010.  :)
> 
> (Sure, those OC people who feel that they can better tweak the
> quality of their analog NTSC/PAL by using a software encoder which
> allows the application of filters and more control over the encoding
> options can continue to do so--but I think if they were to discover
> that the weak point in the chain is not the ivtv encoding options,
> but the NTSC/PAL, they might reconsider.  Regardless, someone who
> chooses to use an inefficient mechanism for recording TV will have
> to take responsibility for making such hardware available and
> figuring out what to do with the underpowered frontend systems they
> may have acquired. :)
> 
> >   but I
> > 
> > suspect not too many Myth users are doing this. ATSC and QAM
> > signals are already encoded, you just have to record the stream,
> > and capture devices with on-board mpeg2 encoding are pretty
> > reasonably priced these days.
> 
> True.
> 
> > Of course simple frame grabbers are really cheap (as opposed to
> > "reasonably priced"), but you wind up paying in CPU cycles and
> > kilowatts.
> 
> Yes.  And, really, if you do your shopping well, there's not much
> difference between "cheap" and "reasonably priced".


By "cheap" I mean sold by no-name vendors, with horrible (if any) 
documentation, non-existent support and with highly questionable Windows 
only software.

You can make such hardware work, once you determine the chipset(s) used, 
and figure out more about what you actually have purchased, but it's 
generally not a fun task.

OTOH "reasonably priced" gear is well (or at least better) documented, 
supported by a company you have at least heard of, and sells for a low 
price.

So I agree, you can find a "reasonably priced" unit for the same cost as 
a "cheap" one, if you shop well, as you pointed out.

Somewhere on the net is a wonderful pictorial listing of a lot of video 
capture cards, with info about what chipsets they use etc., but of 
course you may have to have bought the unit to be able to use that 
guide.