>I think I've at least partially solved this problem. Over the weekend I
>tried encoding with the the "-z t" mpeg2enc option and the result was
>noticeably better when played back on the hardware player. mpeg2enc claimed
>the frame order of the incoming stream was bottom first, so the above option
>reversed the field order. Although some jerky motion remained (particularly
>in the movement of the background during panning) it was nowhere near as
>bad as it was before utilising this option.
By default, mpeg2enc gets the field order from the header of the input
stream. The "-z" option overrides that default. (This you already know
from reading the mpeg2enc manpage:
-z|--playback-field-orderb|t
This flag overrides the field-order specified in the interlacing tag of
the input stream header. (If you need this option, it indicates a prob-
lem in the capturing/encoding process where the temporal order of the
two fields in each frame has been mislabeled. The effect of this is
weird "juddering" when playing back the stream on a TV. Check the
mjpeg-howto for more information about interlacing problems.)
)
>I'm not entirely sure how or where the fields got reversed. The material
>was coming from a DV-encoded Quicktime file produced from a DVD by cinelerra
>as previously discussed. Grabbing frames from this Qt/DV file seemed to
>indicate that the field order was correct - there was no "backwards" motion
>when skipping through the fields. Perhaps the field order put into the
>Qt/DV file by cinelerra was wrong, or maybe lav2yuv was doing something
>funky - I haven't as yet had a chance to investigate furher.
DV is exclusively "bottom-field first" --- this is how it is defined in
the specification (IEC-61834-2, p.23 (first paragraph) and p.75 (Fig 26)).
lav2yuv is doing the right thing by emitting a "bottom-field first" header.
Check cinelerra --- see what it says about your video's field order. (If
it doesn't say anything, then you *know* it is broken.) The source DVD
is not necessarily bottom-field first (or even top-field first); if not,
cinelerra needs to account for that when it produces a DV file.
How did you do the "Grabbing frames from this Qt/DV file..."? How did you
step through the fields? (I'm quite jaded when it comes to video tools,
and hence doubt that some software actually let you do that.)
-matt m.
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
