On Thu, Jan 5, 2012 at 9:42 AM, Jarod Wilson <jarod(a)wilsonet.com> wrote:
On Jan 5, 2012, at 10:17 AM, Richard Shaw wrote:
> On Thu, Jan 5, 2012 at 9:02 AM, Jarod Wilson <jarod(a)wilsonet.com> wrote:
>> On Jan 5, 2012, at 9:49 AM, Richard Shaw wrote:
>>> I think the biggest roadblock at this point is "v4l" where the
RHEL
>>> version is quite old, however, Hans[1] is trying to appeal to the RHEL
>>> QA gods to see if he can convince them.
>>
>> Hm. There's newer v4l-utils in EPEL... But no libv4l. Looks like its been
packaged to
>> have a private libv4l copy or some such thing. Was thinking that could be used,
but
>> maybe not.
>
> We may be able to, I just having figured out how to yet. When I try to
> use that version the transcode build fails because of missing headers
> which the new package does not provide. If someone knows a way around
> that then we may be back in business.
>
> Or do we just build transcode without v4l support?
For mythtv, I don't think its critical. The transcode bits are only used optionally,
and
they operate on already-recorded files, not directly on v4l devices. So you could
just build without v4l support and not miss out on much of anything, as far as mythtv
is concerned.
I tried doing a build without it but of course it fails because
libquicktime isn't available and libquicktime wants ffmpeg. I did a
build of libquicktime without ffmpeg but I'm not sure what we loose
with that. I'm thinking transcode without ffmpeg, even if possible,
would be pretty useless. So I guess that's the new roadblock. I know
Nicolas is working on it but his usual terse responses don't allow me
to see the big picture, hopefully he'll expound here.
Richard