Interlacing for photo-jpeg movie

Question

I originally posted this in the compressor forum. Forgive me for posting again here - I had no response at all on the compressor forum...
I'm encoding a DV movie into photo-jpeg. I chose this codec as I believe it provides more accurate frames, rather than the keyframe technology in stuff like h.264, or sorenson etc. I am writing music to picture and accurate sync is essential. (feel free to correct me if my format choice is wrong!). The movie needs to frame sync perfectly (if this is possible from a DV source?) with Logic Pro's timeline.
On export there is an option to "de-interlace source". As I'm viewing the footage on my computer monitor I checked this option in the belief a de-interlaced movie would produce better results. With the option checked the burned-in-timecode looks blurred. When paused the frame number looks like a combination of the current frame and the previous frame - so for eg if I pause the movie at the 18th frame the bitc display looks like a number 18 over the top of 17. Indeed the "weirdness" reminds me of the sort of effect one gets when viewing interlaced footage on a progressive scan screen.
If I render the movie ~without~ the option of "de-interlace source" checked, all looks sharp and as it should be.
I am currently encoding my movies without the option checked.
does anyone know what is going on here?
(I'm wondering if that option just needs to be checked when the source is already de-interlaced?)
TIA

Answer 1

Edit: Go ahead and read this, but it occurs to me that this is neither a Compressor nor an FCP question. This is what Logic people deal with every day. Ask on the Logic forum what works best for those purposes.
When I say DV I don't mean digital video. My video is
delivered on DV tapes from a TV production company.
(for some reason they wont provide any other format).
I use FCP to capture and then export the movie to use
in Logic to create sync music.
Are you only doing this to create a visual for music production? i.e. this video won't be used in the end product? If so it really doesn't matter what format you use, and it sounds as though there's no real place for FCP in this beyond capturing the video.
Are you sure DV is all keyframes?
I'm sure, and I'm pretty sure that Colin is sure.
What I do know is that DV is not the best of
formats where sound sync is absolutely crucial
DV has no inherent sync problems. There are sync problems that can some up with poor practices in capturing, but it DV is in sync when it starts out in FCP it will stay that way.
I'm working in PAL 25fps for the record - but of
course your info equally applies. In my case I
obviously can't stipulate the shooting formats used
(shot on digibeta for broadcast).
My main question though is just what does
"de-interlace source" check-option in the export pane
in QT for motion-jpeg codec mean? Do I check it when
my source footage is de-interlaced, or when I want to
produce a de-interlaced file?
You would use it to produce de-interlaced output, which is irrelevant in your situation and should be ignored. De-interlacing is only called for when moving to final distribution format, and when that format will only be seen on web or computer screens.
My problem is described in my original post regarding
the BITC frame numbers looking "doubled up". Its like
the previous frame gets superimposed on top of the
current one.
It's VITC - but DV doesn't use VITC.
In any case, it's relevant to know where your window burn came from. Is it burned into the tape you receive, or are you using TC Generator or Reader in FCP?
What it indicates is a time code offset by one field (half a frame). It may also indicate that there are fields which are not only in the wrong order but in the wrong frame. If your tape has hard cuts in it, park at one of those and see if you get half the lines of the outgoing shot and half of the incoming one. That would indicate such a problem.
Most likely it's just a problem with whatever device did the window burn. If it's a problem for your work, ask them to fix it.
If this is a reference tape, most likely there was an analog transfer from DBeta, with one or both of these issues introduced there.
Is there relevant DV timecode on the tape itself? If so you should probably use that and ignore the window burn.
I am wondering its a field order thing. There is a
de-interlace process going on and instead of
combining field 1 and field 2 of frame5 say, it
combines field 2 of frame 4 with field 1 of frame 5.
Another possibility is that there was a standards conversion in the chain, which would spread some source fields over two frames. Did the program originate in NTSC?
I can post examples of the issue if the problem needs
to be "seen". With "de-interlaced source" checked I
get a more blurred result with messed up BITC.
Don't do the deinterlacing, you'll confuse yourself more. At best you'll cover up a problem which may really be a problem. You don't need deinterlacing.
The Animation or None codec
create movie files that are too big and unwieldily.
This is why I've been using photo-jpeg. I'm not sure
how the Motion-jpeg A or B codecs you mention work -
any info would be useful.
You also likely have no use for any of these codecs. Most of them will actually degrade from DV somewhat. Don't fix what ain't broke. For your purposes DV is the native format you have to work with. Everything will work best if you keep it that way.
I need my movie to be as undemanding on CPU ~and~
disk as possible, while supplying true frames. Logic
needs every clock cycle and disk bandwidth it can
get! Picture quality is less important - I can always
look at the DV stuff if I need too.
Others with Logic experience will have other suggestions. If you need to see every field for timing you will need an interlaced signal and an interlaced display, which pretty much leaves you using standard PAL. Might as well be standard PAL DV. If the machine can't hack that there are other formats to consider including even MPEG-1 or -2.