V1U Additional "24A" Mode

[Steve Rolufs]

Haven't seen this mentioned heretofore, but the production HVR-V1U has an additional progressive scan mode not listed in the core manual, but detailed on an extra addendum sheet included in the box (may have been a last minute enhancement).

In addition to selectable 30p and 24p modes, there is an additional "24A" mode (also referred to as "24pSCNA" in long form).

Menu item (under CAMERA SET -> PROG.SCAN) is noted with "When 24A, a brief pause occurs btwn scenes (HDV1080i)".

The addendum sheet explains further: "Select to shoot 24 frames per second, which is the same as cinema films. When recording in HDV format, the phase of the 60i conversion is reset each time recording starts".

and:

"When recording in HDV format in [24A] mode, the time code does not progress correctly from scene to scene. When playing back those movies, a momentary pause will occur between scenes. In this case, you can copy the movies without the pause from your camcorder to a computer via an i.LINK cable and use them on the computer as normal movies."

Any thoughts on the purpose and/or benefit of this mode? Would the phase reset be to help ensure clean or easier pulldown of 24p frames from within the 1080i codec sequence? (with the pause and time code break a necessary evil?). Something else?

Thanks,

Steve R

[Steve Mullen]

I read this as, in non-24A mode the timecode follows 60i TC which means the next shot has a good chance of not starting with Frame A having a TC of :00. This means that a NLE that looks for Frame A by looking for :00 may identify the frame incorrectly. That screws-up editing in 24p.

Using TC -- assuming it is correct -- is the EZ way of working. Therefore, the software must find judder frames, which for a static shot may not work.

In 24A mode, the timecode is reset to a TC ending with :00 for each scene start. This makes most NLEs work fine. Why video playback should pause is because the :00 corresponds to an I frame. Wth JVC, the GOPs are closed, which frankly seems correct for any to be edited format. It's my understanding, that 1080i uses Open GOPs. Which means HOW a shot ends and HOW it starts are important. The new I frame likely means the decoder must do a total reset -- causing a 1/2-second pause.

The explanation is very poorly written!

[Marcus Marchesseault]

Perhaps this is a 24P format without judder frames?

[Steve Mullen]

Originally Posted by Marcus Marchesseault

Perhaps this is a 24P format without judder frames?

I think you may be correct or at least close, but what a bizarre explanation! And, it fits with my finding the A frames were aways :00. Earlier I assumed that I was just lucky.

"Select to shoot 24 frames per second, which is the same as cinema films."

To shoot 24p and record using pulldown "X" use this mode.


"When recording in HDV format, the phase of the 60i conversion is reset each time recording starts".

The pulldown must start fresh each time a shot begins.

and:

"When recording in HDV format in [24A] mode, the time code does not progress correctly from scene to scene."

The pulldown reset causes a TC break.


"When playing back those movies, a momentary pause will occur between scenes."

The delay is for 15 frames to accumulate in the decoder.


"In this case, you can copy the movies without the pause from your camcorder to a computer via an i.LINK cable and use them on the computer as normal movies."

Because the disk is doing seeks ahead of the decode, there is no wait.

Questions:

1) What is X?

2) What does the new shot's TC begin at? The next whole second?

3) Aren't some NLE's going to sense the TC break and abort?

4) Will this mode affect native capture which, for example, FCP already has problems performing?


I'm in the Malaysia airport at midnight so I'm not sure I'm can think well enough to think of a pulldown that has NO judder frames.

One can imagine 24 flagged frames (48 fields) with repeat frames (6 frames of 12 fields), but these would playback very strangly. Essentially a repeat frame after every 4 frames. Which makes 30p or 60i.

ABCDR ABCDR ABCDR ABCDR ABCDR ABCDR

[Thomas Smet]

Hopefully would that mean the frames could use a true progressive form of mpeg-2 encoding with a progressive style of chroma sampling? That might make that mode not work in other HDV devices but I wouldn't really care about that. There must be a really good reason why they added that mode. Progressive mpeg-2 also encodes a little bit better which may help reduce artifacts slightly.

[Marcus Marchesseault]

Correct me if I'm wrong, but wouldn't this feature technically take it out of the realm of HDV. I won't complain! Of course, I think NLE support will be critical and perhaps they have plans to implement something in Vegas. I doubt that it is doing a full encode of each frame, but rather that it is not doing a 60i conversion. Perhaps it is only encoding the 12 frames per GOP instead of the 30 fields needed to go to 60i? Intriguing...

[Ing Poh Hii]

Originally Posted by Marcus Marchesseault

Correct me if I'm wrong, but wouldn't this feature technically take it out of the realm of HDV. I won't complain! Of course, I think NLE support will be critical and perhaps they have plans to implement something in Vegas. I doubt that it is doing a full encode of each frame, but rather that it is not doing a 60i conversion. Perhaps it is only encoding the 12 frames per GOP instead of the 30 fields needed to go to 60i? Intriguing...

I have the same question, if Sony applies different mpeg encoding.. it won't be HDV anymore, perhaps DVCAM+ ?? or frame-based DVCPro ??

[Douglas Spotted Eagle]

Originally Posted by Marcus Marchesseault

Correct me if I'm wrong, but wouldn't this feature technically take it out of the realm of HDV. I won't complain! Of course, I think NLE support will be critical and perhaps they have plans to implement something in Vegas. I doubt that it is doing a full encode of each frame, but rather that it is not doing a 60i conversion. Perhaps it is only encoding the 12 frames per GOP instead of the 30 fields needed to go to 60i? Intriguing...

Technically, it arguably takes the discussion out of the realm of HDV, just like "ProHD" from JVC, 24F from Canon, etc. It's a moot discussion; it's still 25Mbps/long GOP, 384Kpbs audio, etc.

Sony Vegas already supports the appended/added A mode.
Hell would freeze over before Sony would implement DVCProHD in their camcorder products. Sony have spent millions upon millions developing their own formats, developing HDV/mpeg-based encoding, etc. It would be counter productive for them to step backwards in addition to paying for a codec developed by a tertiary competitor.

[Steve Mullen]

Originally Posted by Douglas Spotted Eagle

Sony Vegas already supports the appended/added A mode.

Since its implemented in Vegas and documented by Sony -- why not describe what Sony's documation fails to convey. What's SCNA?

And it what way is it "appended" verses "added?"

[Steve Mullen]

Originally Posted by Thomas Smet

Hopefully would that mean the frames could use a true progressive form of mpeg-2 encoding with a progressive style of chroma sampling?

I wondered about that too. But, I am certain it's still an interlace recording system and thus field-based.

1) I suspect the point of "SCNA" is an fast way to edit 24p native HDV. The key to this is a VERY simple way to know which frames are which. TC is the simplest way to ID frames. This, however, requires every shot to start with an I-frame and a :00 TC.

2) If a 60i HDV video (15-frame, Open GOP) shot always ended -- as I've previously assumed -- with a full GOP, then the next frame would always be both an I frame and have a TC of :00.

But, perhaps a shot can end with a Closed GOP that is shorter than 15-frames. This would mean the next shot would begin with an I frame, but not necessarily a :00 TC. Therefore, making TC a useless way of IDing frames.

3) Thus, the need to have a new 24p mode that forces both an I frame and a TC of :00 at the beginning of each shot.

4) This new mode could be used with the current 2:3 pulldown format. In this case it simply provides a very fast way of determining which frames in each GOP are the judder frames.

Or, it could support a "non-judder frame" mode that drops 6 frames for every 30. This could be done, as I posted earlier, by dropping every 5th frame:

IBBPbBPBBpBBPBb >> IBBPBPBBBBPB

Here the b and p frames are those dropped. However, this leads to dropping a P-frame and results in a series of four B-frames. Not good.

5) The following would work better:

IBBPbbPBBPbBPBBIBBPbbPBBPbBPBB

>>

IBBPPBBPBPBBIBBPPBBPBPBB

The bb frames are the ones dropped. Of every 30 frames only 24 remain.

The dropped frames are always TC -- :04, :05, :10, :19, :20, and :25. Note that both odd and even GOPs have the same dropped frames.

The playback pattern would be very weird, however!



>>>>>>>>>>>>>>>>>>>>>>>>>>>> UPDATE <<<<<<<<<<<<<<<<<<

6) The following 2:3 cadence should look much better:

IBbPBB PBbPBB PBbIBB PBbPBB PBbPBB

>>

IBPBB PBPBB PBIBB PBPBB PBPBB

The b frames are the ones dropped. Of every 30 frames only 24 remain.

The dropped frames are always TC -- :02, :08, :14 in the "odd" GOP and :05, :11 in the "even" GOP.

This changes the game: Now each shot must begin with a "odd" GOP plus an I-frame plus a :00 TC. Therefore, even if every shot always ends with a full 15-frame GOP (as I've assumed) that does not force the next GOP to be an odd GOP. It could be either an odd or even GOP. Hence the need for a new mode!


The advantages of a "no judder frames" mode are:

1) 6 frames can be dropped during capture leaving only the useful 24 to be stored to disk. The captured video really will be 23.97p.

2) A savings in disk space.

3) multi-stream RT playback is improved. When judder frames are in the native stream, the NLE must do the following for every GOP:

a) decode judder frame 1 and decode judder frame 2. Then combine the correct fields from both frames into a new frame. Cost = 2 frame decodes.

OR

b) decode the appropriate field in judder frame 1 and decode the appropriate field in judder frame 2. Then combine the two fields into a new frame. Cost = 2 field decodes = 1 frame decode.

NOW -- (a) costs 1 more frame decode than (b) so it reduces RT performance. Both (b) and the "no judder frames" mode are equal in cost since the desired frame must be decoded.

Therefore, if (b) can be done, there is no performance advantage to a "no judder frames" mode -- only a storage savings.

However, working with a pure 24p stream means the NLE playback engine doesn't need to be enhanced to deal with judder frames. This could be a big deal! Especially for Apple and Avid who I suspect don't want to change the inside of their NLE's.

A "no judder frames" mode would only require an update to the capture code.

[Steve Mullen]

Originally Posted by Steve Mullen

A "no judder frames" mode would only require an update to the capture code.

Actually, the mode might output only the 24p via i.LINK which makes the dropping not have to be done in the NLE.

I asume the video output from the camera still would use 2-3 pulldown.