[mythtv] mythmkmovie frames per second.

[Michael J. Pedersen]

On Mon, May 05, 2003 at 12:25:03AM +0200, Martin Moeller wrote:
> Hi Michael and others,
> 
>   The latest mythmkmovie is pretty great, but I currently have to make
> changes to it to get the correct cutlist:
> 
> I think in most European countries the recorded files are 25 fps (mine
> certainly are), so could you make this an option? Perhaps a binary
> toggle (29.97/25) if no other framerates are reported..?

This is a weakness that I knew of, and didn't address properly. Thank
you for pointing it out to me again, I'm adding it as a higher priority
to-do item, since (to me) it's a bug.

One thing I will ask of you, if you don't mind? Pick a recording (any
recording), and give me the output of the following command:

mencoder -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=1500 -oac mp3lame
-lameopts cbr:cbr=128:padding=0 -ss 0 -endpos 0.1 -o testing.avi
recordingfilename.nuv

I've found (what I feel) is a bug, either in mencoder or in the encoder
for MythTV which actually gives extra data. I need to adjust genBFrames
to account for PAL framerates.

> I also usually make a mkcopy file where I take out most of your hard
> work with optimiziing the files because the files end up *larger* than
> my previous MPEG4 files (even after cutlist removals) and thus cannot
> fit onto CD at all.. It seems to work pretty well with a few nags from
> mplayer (I don't plan on using them with any other player).

My bet on this is that it's turning the 25fps from PAL into the 29.97
for NTSC, and thus growing the files. Fixing for PAL should fix this
problem.

> It's simply '-ovc copy -oac copy' in stead. It works for me (and much
> better in 0.7 than the last version I tried, one of the very first
> ones). The Curses interface is functional, but a bit of polish/colours
> might be nice. Not a priority, of course :)
> Perhaps you would output the output named below the other information of
> the recording in question? Again, not super important, but I'm sure the
> less poweruserlike would prefer more feedback than 'O'.

I can definitely do that. My sole concern for it, though, is that the
screen is starting to get a bit full. Any suggestions on things I can
remove to allow for the output filename (mind you, I agree with putting
it in, I just need to shrink things a bit, somehow).

As for the colors: I've never given that much though. And I'm not sure
what I could do to improve things there. Simple monochrome seems almost
best for this particular script.

And yes, 0.7 is much better. If I were to show you what I actually
started this whole script with, you wouldn't believe the changes.
Basically, my original script was a set of mencoder command lines to
test out the question: Can this script be written? And would it be
useful (even to me)? The current revision came from about 4 lines of
mencoder commands stuck in a scripted file.

> Any particular reason than special characters like ' []{}' cannot be
> used, even if escaped? Convenience codewise?

Well, as to the why: The actual reason? My pattern was meant to include
simple, standard filesystem legal names. Adding in any non-normal
characters would easily create some ugly commands being executed by
perl, and I don't know that they would work, not without some extra
work.

Perhaps someday I'll revisit that, but for now, unless somebody sends in
a patch to allow it, I'm going to leave it as is. It keeps things
simpler.

> That's it from me for now. Great work so far ;)

Thank you very much. Glad to have something people can use out there :)

-- 
Michael J. Pedersen
My GnuPG KeyID: 4E724A60        My Public Key Available At: wwwkeys.pgp.net
My GnuPG Key Fingerprint: C31C 7E90 5992 9E5E 9A02 233D D8DD 985E 4E72 4A60
GnuPG available at http://www.gnupg.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20030504/b9fd88fb/attachment.bin