[mythtv] Should mythtranscode be preserving closed-captioning data?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Thu Dec 8 16:06:24 EST 2005


    Date: Thu, 8 Dec 2005 03:50:35 -0500
    From: Isaac Richards <ijr at case.edu>

    CC data from the pvr-x50 isn't supported.  These are users list questions.

Er, ok.  So why is there a UI element mentioning it in mythtv-setup?
(And is that why setting it seems to have no effect?)  Is such support
contemplated at any point?  Is the blocker something internal to
mythtranscode, or is it that some included library from elsewhere that
handles MPEG4 (and that Myth doesn't modify) doesn't handle CC data?
(If so, I can attempt to see if such support might be added or if
I can otherwise enable it.)  It seems a shame that such useful,
computer-parseable data (which we need for our research purposes)
must be sacrificed if we'd also like to reduce the video size by
transcoding.

[And what's a good metric by which I can decide whether something is
appropriate for -dev?  I've been reluctant to post to -dev, but it
seems that questions about things that seem to be bugs belong where
developers are more likely to see them.  For example, should my bug
report about really low audio levels after transcoding stay on -users,
or should I redirect it to -dev?  How about the bug where the job
scheduler tries to put mythtranscode jobs on the SBE, but then
mythtranscode complains that it wasn't designed to run remotely, even
though it shares an NFS-mounted filesystem (hence not -really- remote
at all) and commflagging works just fine that way?  -users? -dev?
trac?  Neither of these have gotten any response and I'm concerned
that they will just sink invisibly out of sight forever, given the
traffic volume.  I'm really unclear where such things should be
reported/discussed/logged.  Tnx.]


More information about the mythtv-dev mailing list