On Thu, 16 Mar 2006, Alec Robertson wrote:
Hi Alec -
> > ...which version of the software
>
> I'm using the svn version of cinelerra, and the cvs version of
> mjpegtools. I render my project from cinelerra (original footage is
Ah, ok. Good to know. I see also that you did indeed mention
'yuvdeinterlace' and not 'yuvdenoise'. Since I do not believe in
deinterlacing if the video is going to be viewed on a TV (interlaced
display) I saw 'yuvdenoise' where you mentioned 'yuvdeinterlace'.
Editorial aside: If the video is going to be watched
on a TV (which is an interlaced display) the the video should remain
interlaced. If the video is going to be displayed on a computer
screen then deinterlace at playback time. But that's just my
feelings/opinion ;)
I see that Stefan has mentioned there's a bug in yuvdeinterlace that
is causing your problems. IF the problem had been a "letter box"
effect (it was not clear from the original posting how big the
black bars were) I'd suspect the aspect ratio or framesize was being
created incorrectly.
> ntsc-dv in a quicktime-for-linux container) as a yuv4mpeg stream. The
> aspect ratio is set in cinelerra to be 4:3, but I see that "mplayer
> -identify" on the resulting yuv file gives me an aspect ratio of
> 1.36:1 and "head -n 1" gives:
> YUV4MPEG2 W720 H480 F30000:1001 Ib A10:11 C420jpeg
> Neither of these seem correct. I am seeing black bands of ~5 pixels
> on the top and bottom (ie "mplayer -vf crop=720:470" removes them).
Actually the only thing that's wrong is the Chroma tag - 'C420jpeg'
does not seem right for encoding to MPEG-2.
The problem is we don't know if the chroma siting is correct and
the tag ('C') is wrong (and the data actually is C420mpeg2) or if
the data needs to be resampled (using y4mscaler) from 420jpeg to
420mpeg2.
The 'A' tag (aspect) if FINE. Remember: that is the sample (pixel)
aspect ratio (SAR) _NOT_ the display aspect ratio (DAR). DV uses
Rec.601 pixels which for NTSC are 'narrow rectangles' with a 10:11
aspect.
MPlayer's slightly off - but 1.36 is quite close to 1.33. MPlayer
is printing the DAR and 1.36 is ~4/3 which is correct (unless your
video is anamorphic 16:9 ;)).
Hmmm, "470" is probably NOT a good size. IF the data is 4:2:0 you
should crop to a multiple of 4. Thus 472 would be a good value but
470 is bad.
Hmmm, but NTSC DV is 4:1:1 so something is converting to 4:2:0. Is
the stream coming out of Cinelerra that way? Without knowing where
the conversion from 4:1:1 to 4:2:0 is being done it's impossible
to say if it's being done correctly.
> This seems to be the case, as it also ignores the interlacing in batch
> rendering (fixed by a pipe through yuvcorrect). Is there a similar
> workaround for the aspect ratio?
Nothing needs to be done with the aspect. It's correct. The
problem you're seeing is a bug in yuvdeinterlace.
You can also use 'y4mscaler' to crop the data. IF the data really
is "420jpeg" then something like this, placed just before the
encoder (mpeg2enc) is what you need - it will crop and convert
at the same time:
y4mscaler -I active=720x472+0+4 -O sar=src -O size=720x480 -O chromass=420mpeg2
Good Luck.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mjpeg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
