> There is the possibility that the field order was set incorrectly > by Cinelerra (it's happened in the past as I recall) and that you > were correcting it after the rendering.
I have had some cases where the y4m stream coming out of cinelerra either specifies the wrong field order in the y4m header or doesn't give any field order (that is, flags the stream as progressive). The most recent one of these was over the weekend. In this case the source was a non-commercial PAL DVD and the y4m stream header from cinelerra specified progressive frames - even through the frames were visually top-first and the DVD's MPEG stream flagged the frames as top-first. Using yuvcorrect was essential to ensure a watchable result. :) The other time I've seen a similar effect was with a non-commercial NTSC DVD used as the source. This was several years ago now, but my memory of that situation was that cinelerra made mjpegtools think the material was bottom-first when it was in fact top-first. Having said that, this particular work was done using a DV-format intermediate so the y4m stream wasn't coming from cinelerra. The DV intermediate was probably responsible for the bottom-first assumption by virtue of the DV format being (AFAIK) bottom first by definition. I think I resolved this particular issue using "-z t" to mpeg2enc, but I may also have used yuvcorrect instead - it's too long ago. Regards jonathan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
