I have a MythTV setup, currently running 0.18.1 with a frame-grabber
card, and have been a big fan of using NUVEXPORT to convert to MPEG2
for the creation of DVDs.
Before exporting, I've always manually edited the cutlist to tweak
commercial locations, and to verify that all the cutpoints are on a
KEYFRAME boundry. I've been under the impression that using KEYFRAME
boundries is necessary in order to maintain A/V sync throughout the
exported recording. But I have a few questions on this:
1) Is this still necessary, or am I doing a little extra needless work?
2) If it is necessary, what is the right procedure for cutting?
2.1) Is the KEYFRAME location important in regards to the beginning
of a cutpoint?
2.2) If 2.1 is YES, then should the frame used for 'Cut frames
after this frame' be the KEYFRAME, or the frame before the keyframe?
In other words, is it important for the KEYFRAME to be included in the
recording, or for it to be removed from the recording.
An example (assume no commflag is loaded for simplicity):
A) Enter Edit mode while watching an existing recording.
B) Seek to the beginning of a commercial break.
C) Manually seek to the nearest KEYFRAME.
D) ?? Should I seek one frame earlier?
E) 'Set Cutpoint Here, Cut frames after this frame'
F) Seek to the end of the commercial break.
G) Manually seek to the nearest KEYFRAME.
H) 'Set Cutpoint Here, Cut frames before this frame'
3) What about the first and last frame of the recording? Should
there be cutpoints at those locations, or can a cutpoint be
open-ended?
Example:
A) Enter Edit mode while watching an existing recording.
B) Seek 20 seconds into the recording.
C) 'Set Cutpoint Here, Cut frames before this frame'
4) I've noticed that Xine doesn't seem to understand the length of
the file... if I bring up the information text, the bar that shows the
% of the file is correct, but the time is wrong (i.e. it might show
that I'm 7 minutes into a 15 minute program, but I'm really 21 minutes
into a 45 minute program. I know that my NUVEXPORT version is a
little old (cvs20050221) but I don't see anything in the revision log
that looks likely to have fixed it. Is this currently expected
behavior? Or is there something wrong I need to figure out?
Thanks!
Ramon Redondo