More than a decade ago when Mr Sony was developing what would become HDCam (with some small contribution from the previous 1" open-reel HDVRS analogue & digital formats) they realised that progressive video was the future but existing HD equipment (typically the BVM-D series monitors) couldn't lock to such a slow framerate (24/25/29.97 as opposed to 48/50/59.98 fields). The answer for progressively-sourced pictures was the Psf standard which makes progressive frames look like interlaced video. So as to make film people think that this was better than video they have a new name for a field - the segment. In fact Psf is interlaced video (but there is no movement between the fields) - it just shows that good old interlaced video is able to faithfully reproduce progressive pictures (but the reverse is not true as progressive video with the same frame-rate has only half the motion rendition as interlaced video).
So - let's dismiss a couple of misconceptions;
So - let's dismiss a couple of misconceptions;
- There is no difference between a Psf signal and an interlaced signal from a technical standpoint
- Sending 1080 pictures via Psf doesn't degrade them in the slightest - in fact if you're laying off 1080 to HDCamSR then anything below a 5800 (in 50/60P mode @880mBits) is recording Psf!
Now then - below are screen-grabs from my trusty WFM7120. The first shows the output from a Symphony NitrisDX BOB. The footage had come from a Sony EX3 cameras recorded at 35mBits 1080/25P onto Memory Stick and imported straight into a progressive timeline. The Avid plays back Psf which the Tek shows as 1080i (for the reasons discussed above). Laying this off to HDCamSR (a 5500 deck) gives a 25Psf recording on tape. The second screen shot is the Quicktime sample movie imported into a new 25P timeline - it just serves to comfirm that the BOB output is always Psf.
This last picture is the down-convert output of a Leitch X75 which is a great little get you out of trouble box (basically does everything->everything with a few extra tricks thrown in - profanity delay etc.) but it's not a multi-frame broadcast standards converter (like a Snell & Wilcox Ukon).
Although you can't see it from this screen-grab the SD output has had it's field-dominance changed and the quality of the video ain't great. This wouldn't be an issue for VHS/DVD review copy or if it was the pre-processed feed for web-conversion but it's not suitable for SD delivery.
For that the best option (short of a £20k Ukon!) is to use the SD-downconvert from the HDCamSR machine.
This last picture is the down-convert output of a Leitch X75 which is a great little get you out of trouble box (basically does everything->everything with a few extra tricks thrown in - profanity delay etc.) but it's not a multi-frame broadcast standards converter (like a Snell & Wilcox Ukon).
Although you can't see it from this screen-grab the SD output has had it's field-dominance changed and the quality of the video ain't great. This wouldn't be an issue for VHS/DVD review copy or if it was the pre-processed feed for web-conversion but it's not suitable for SD delivery.For that the best option (short of a £20k Ukon!) is to use the SD-downconvert from the HDCamSR machine.
2 comments:
Just wondering now. Granted, there's no difference between i/psf on the SDI cable ...
But I was under the impression that the SR deck will treat the incoming fields differently depending on the mode. Theoretically, reassembling and storing "25psf" frames as real progressive frames, rather than twice as many fields, should make for more effective compression ... or rather, less compression artefacts for the same data rate.
I've never tested this out though. If I'm right, then setting the deck to 25sF mode but inputting and recording genuine interlaced content would be a bad idea.
Hmmm - I don't know HDCamSR decks as well as I should, however, DigiBeta (which admittedly doesn't do long-GOP compression) builds the entire frame before it does the macroblock-derivation - it has to because the zig-zag encode (before the run-length stage) needs the whole frame built. Now then, I can't imagine that HDCam and/or SR would do it differently (remember - both systems, whether longGOP to i-frame-only have to do those initial stages) and so regardless of whether the frame had arrived over the SDi i/f as two segments (i.e. interlaced) or as a contiguous frame it'll be assembled into a frame for the first stage of the DCT stage.
Post a Comment