Le 25 juin 09 à 12:50, Steven M. Schultz a écrit : >> Rats...my memory of the conversation was that TOP_FORWARD was >> necessary to correct DV of telecined video. > > And for a long time that was the prevailing method - but I ran into > problems back (3 or 4 years). > >> (I searched the >> mailing list archives, by asking Google for "TOP_FORWARD >> site:mail-archive.com", but couldn't find why TOP_FORWARD was >> harmful.) > > I took a quick look and saw bits/pieces of the threads but not parts > I was looking for. Try searching for yuvkineco and yuvcorrect > > I've got to get out the door and don't have time to do much more than > clear out the mailbox. > >> As an experiment, I tried running yuvkineco on video without >> doing TOP_FORWARD, and it was visibly worse.=A0 Maybe that's >> because yuvkineco is top-field-first only?=A0 It didn't seem to >> complain about being given bottom-field-first video. > > Hmmm, I thought yuvkineco would complain about the wrong field order > > >> The reverse-telecined videos I make with yuvkineco TOP_FORWARD >> look great to me...and I thought I was nitpicky about these >> things.=A0 :-) Have I been living a lie?=A0 What should I be doing? > > SHift the video one line up or down within the frame. This is MUCH > better (I think) than shifting the video 1/2 frame. Here's what I > wrote up about 3 years ago: > > #!/bin/sh > > N=rites > > # NOTE: lie and say it's a progressive stream instead of bottom > first. This > # hushes y4mscaler and we will tag the stream as top first > anyhow after > # shifting down 1 line. > # > # Take the first 479 lines of a frame and place them in the last 479 > lines > # of the output frame. This places 1 black line at the top and > converts the > # stream from bottom to top field first: > # y4mscaler -v 0 -I active=704x479+8+0 -O sar=src -O size=704x480 - > O align=BC > # > # OR > # > # If 720x486 input we can skip one top line and take the next 480 > lines: > # y4mscaler -v 0 -I active=704x480+8+1 -O sar=src -O size=704x480
my 2 cents: if I well remember (I didn't verify with the lastest version), TOP_FORWARD only shift luma (chroma was let in state) Same sort of concern here with y4mscaler if your file is 4:2:0 (or 4:1:1), the resulting chroma will be buggy with an odd crop Maybe the idea will be to convert it first to 4:4:4 before any process... (or y4mscaler still have automatisms to handle it?) bye (PS (not related to this thread): thanks to Bernhard Praschinger & Christian Ebert for their tips to compile y4mdenoise from SVN. But I didn't manage. I will wait for an official release to test it) Hervé ------------------------------------------------------------------------------ _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
