Cedocida and anamorphic PAL

[SixdeeBee]

I use Premier CS3. The video production is anamorphic PAL (720 x 576) based on widescreen DV-cameras.

Working with the (latest) Cedocida codec, CS3 imports anamorphic files with a PAR of 1,067 and not, as required, with 1,42. Therefore in 16:9 productions those sources stay anamorphic => squeezed.

At time I use the MainConcept-DV-Codec which offers a 16:9 option to set the "widescreen flag" in the header of the output files.

Hopefully I did not have overseen a special setting to activate the widescreen flag in the menu of the Cedocida codec... but if not ... can I ask for that feature in a future version ? :)

SixdeeBee

[2Bdecided]

Ditto (or if it's there, please tell me where / how to access)

Cheers,
David.

[cedocida]

This (checkbox for setting the 16/9 flag in the DV encoded output) is allready implemented, but not released.
I did a quick test with the Trial Version of Premiere Pro CS3 but was not able to use cedocida for exporting the movie, as the codec was not in the list of AVI compressors. Did I missed something? What is your workflow?

[Blue_MiSfit]

Premiere's export engine is _dreadful_. An alternate workflow (what I do) is install debugmode frameserver, which can then be used to frameserve uncompressed YUY2 video into VirtualDub for encoding. It works well, and is pretty fast.

~MiSfit

[2Bdecided]

I'm just saving from VirtualDub and would like that checkbox in the cedocida config please!

Cheers,
David.

[SixdeeBee]

Thank you for the replies to my feature request.

@Cedocida

I get the same effect with CS3, the codec is hidden in the list of codecs (Microsoft AVI) while e.g. HuffYUV, Lagarith etc. appear. I only use HuffYUV 2.2.2 to export files in the YUY2 format yet. (Lagarith export fails with CS3 vers. 3.1.1)
The "pillarbox" effect seems not to be the result of exporting a clip, instead CS3 interprets 16:9 frames as "native" 4:3-fullscreen frames.

For testing DV codecs with anamorphic sources I used this simple way: (WinXP pro SP2)

1. I made a test file 1024x576.bmp with 1024 x 576 (square) pixels (e.g. alike FuBK) with > FML Test Card Maker <.

2. Render a YUY2-file with AVISynth (e.g. 10 seconds) and down resize horizontal to 720 pixels.

3. Let a host programme render the squeezed YUY2-clip to the DV-format.

4. Mark, if possible (MainConcept), the clip as 16:9 => my feature request for Cedocida codec ... :)

I use this simple script as "anamorphizer" for a 10sec clip:

#
# Generating an anamorphic PAL-DV-testcard clip, interlaced, BFF
#
ImageSource("X:\path\1024x576.bmp",start=1,end=500,fps=50.0)
#
ConvertToYUY2(interlaced=false)
#
GaussResize(720,576,p=50.0)
#
AssumeBFF(),SeparateFields().SelectEvery(4,0,3).Weave()
#

The host programme (VDub, AvsP) should encode with the actual
test-codec-candidate and its settings.

CS3 is set to > DV-PAL => Widescreen 48kHz.
After importing a Cedocida-rendered 1024x576.avi, the project field
(upper left field in the standard screen mask) shows:

1024x576.avi
Video, 720 x 576 (1,067)
... time ... 25.00 fps

The editor-monitor shows vertical stretched frames => 4:3-pillarboxed.
If I am not totally confused :rolleyes:, CS3 should show the frames in 16:9 when the WS-flag had been set while DV-encoding.

CS3 exports the frames in the same format as shown on the monitor.

I add the file 1024x576.png to this post. It is a 16:9 testcard which can be used as a source for the anamorphic DV-clip and for adjusting 16:9 monitors. The grid and circle are based on 1 pixel lines and discordant to 8x8 etc. canonical pixel arrays, therefore a "worst case" source for testing encoders and resizers.

@Blue_MiSfit

I agree ! :mad: It seems that there is more protectionism than reason build in those Adobe products!
Thank you for the hint about the debug mode frameserver. If I understand you correct, it has an influence to the file export but the PAR-problem results from the DV-file itself but good to know another way for exporting from CS3.
One of the bad behaviors is (for me...) that I cannot use the Lagarith codec. CS3 exports only the first frame of a sequence to a Lagarith encodet file. Of course this files are not readable and the Lagarith.dll creates an "Out of bonds" error and host programms crash ... and Win wants to telephone home ...:devil:


SixdeeBee

[WorBry]

1. I made a test file 1024x576.bmp with 1024 x 576 (square) pixels.......


Just a point. 1024 x 576 is the Image (display) AR for 16:9 anamorphic. The correct square pixel AR is 1048 x 576.

[SixdeeBee]

@WorBry

Thank you for the hint, yes I agree if one uses PAR 1,45 and BT-601-sources for upsizing 720 x 576. Then you get 1048 x 576 Pixels with 12 black rows on each side of the "visible" frames but DV unfortunately is not 100% ITU-BT-601 (rev. 5) compliant.

Premier (in standard mode) uses a PAR of 1,42 to scale up 720 x 576 (DV) to square 1024 x 576 pixels which is its "native" 16:9 format.
If you have BT-601 compliant PAL files lines consist of 8 (black) + 704 + 8 (black) hor. pixels. A visible line = 704 pixels last exactly 52 µs while DV has 720 visible pixels which last 53,33 µs.

(=> visible does not mean that any monitor shows all the rows, it means that they have picture content)

The problem is, that Premier scales with a PAR of 1,42 without black vertical rows, while TV-broadcast systems deliver exactly 52µs of visible line content and "fill-up" with black bars to get 720 pixels.
The testcard with 1024 hor. pixels therefore is intended for DV in connection with Premier or other editors, based on PAR = 1,42.

All that confusion would never have happened with a 100% ITU-BT-601 compliant DV system :mad:


SixdeeBee

[scharfis_brain]

DV is compliant to ITU-BT-601
as MPEG is.

But Adobe isn't conforming to IT-BT-601.
Look for other video related software like Sony Vegas, which is fully compatible to BT-601.
It offers 1.094 as well as 1.458 PAR by default.

[SixdeeBee]

@scharfis_brain
@WorBry

Partly I don't agree :p therefore let us clear the problem:

Let me compare between TV-Broadcast and DV home video

1.

ITU-BT-601 part A and EBU R92-1999 explicitly defines the number of samples of a line to be 864 in 50 field PAL systems.
The total time-length of a Gerber/PAL-norm line is 64µs, 12µs is the line-blanking time and 52µs the visible line. In the digital world line-blanking does not have importantance but the 52µs are the base for the actual SD-PAL system.

864 samples x 52µs/64µs = 702 samples (=> horizontal pixels).

Considering to 8 x 8 matrixes in encoders, the number is 704 samples per line
=> 52,14µs (within specs).

BT-601 specifies the duration of a digital active line as 720 samples (pixels). Therefore the 704 visible samples must be filled up with 16 (black) samples.

An ITU-BT-601/EBU complaining sample therefore is:

8 (black pixels) + 704 (52,14µs picture content) + 8(black pixels) = 720 pixels.

To show the 704 pixels on a PC in 4:3 there must be an upscaling by 768/704 = 1,091.
If the 16 additional rows have not been cropped before one gets 720 x 1,091 = 786 horizontal pixels where 786 - 768 = 18 pixel-rows are redundant in editing systems.

To show 16:9 there must be an upscaling with 1024/704 = 1,4545.
720 x 1,4545 = 1048 pixels, 1048 - 1024 = 24 redundant pixels, too.

Luminance signal uses 220 quantization levels, 16 for black and 235 for white.
Color-difference signal uses 225 qauntization levels.

2.

DV (is not a standard but Sony "house-norm" )

Instead of 704 it uses 720 active pixels in a line. The active time-length is 53,33µs.
and does not comply with the norm because only a maximun variation of +/-0,25%
is allowed (based on Gerber/PAL).
Because of the longer line-time-length, the upscaling factors 1,091 and 1,4545 are no
longer correct if we suppose, that both, a BT-601 and a DV camera, use a CCD-chip
with 768 row-pixels (4:3) or 1024 row-pixels (16:9).
The BT-601 camera delivers a 768/1024 full sampled row within 52,14 µs => 704 pixels
while the DV-camera needs 53,33µs = 720 pixels.
With other words, the BT-601 camera squeezes more than the DV-camera and therefore its correction factor (PAR) must be higher (1,091/1,4545 instead of 1,067/1,422).

Using 1,4545 and a 768/1024-pixel-DV-CCD-camera will later show light-squeezed circles on a "class-1-monitor" and exactly this is the problem, when DV sources are mixed with TV sources in the same production, one of them must be preprocessed to comply with the PAR of the other.

Last but not least: The Luminance and color-difference signal uses 256 levels.

In summary: DV-files can be used with BT-601 compatible systems (e.g. in TV studios) but should be preprocessed to get into the specs of broadcast-studio-systems. If they were BT-compatible, the preprocessing would not be necessary ...:rolleyes:

Therefore it is not "exacly" correct to say that Premier always is using the wrong PAR ...
as it is not correct to say that DV is 100% compliant to BT-601/EBU ... it is not :mad:

... I think that we can meet on half the way ...:)

But ... please feel free to turn me around ...


SixdeeBee

[scharfis_brain]

Who says that the digital overscan has to be filled black?

DV-Cams simply show a more wide image instead of filling the overscan (analogue blanking with black vertical bars)
Record a circle with a DV-Cam and measure its height and widht on your computer in pixels. you may notice that DV-Cams will go for BT-601.

[facialz]

DV-Cams simply show a more wide image instead of filling the overscan

I agree. In every 720-samples-per-row system the display aspect ratio is not 4/3 or 16/9, but 15/11 or 20/11, respectively. Trying to fit, say, a 16/9 picture onto 720 * 576 image is thus definitively wrong. A 20/11 test picture should be used instead.

[SixdeeBee]

.. Heureka, we got it!


Originally Posted by SixdeeBee
With other words, the BT-601 camera squeezes more than the DV-camera ...

Originally Posted by scharfis_brain
DV-Cams simply show a more wide image instead of filling the overscan ...

... no comment :p

Originally Posted by scharfis_brain
Who says that the digital overscan has to be filled black?

E.g. the specifications (in DE: Pflichtenheft der XYZ) published by a TV-station. Of course in privat environments every colour is possible :)
Video journalists who contribute video clips to our local cable-TV-station, must deliver them with 8black + 704content + 8black pixels. If borders are not black, the hardware (!) rejects the files.

Originally Posted by scharfis_brain
... measure its height and widht on your computer ...

Yes, that is a possibility but there is another way, too:

Capture a testcard, encode it to MPEG-2 (for TV purposes), export to a hardware MPEG-player and show it on a class-two (or even a class-one) monitor with an inbuild circle-generator and one can even recognize the difference between 9 + 702 + 9 and 8 + 704 + 8 pixels.


If the target format is a MPEG-2 for a DVD or TV-production there is always a correction factor which gives exact circles "outside" of a PC. Premier Pro, with its non-ITU-PAR, makes 1024 x 576 pixels by multiplying the 720 rows with 1,422. The same format one gets with 704 pixels x 1,4545 therefore we have a "smallest common denominator" in 16:9 productions. Problems occur when TV-sources and DV-sources must be mixed in a production ... but that is another story ...:)

...

SixdeeBee

[2Bdecided]

SixdeeBee,

I fully understand what you're saying, but I've got to question the idea that all DV camcorders are so careful, or that all have sensors with 1:1 pixel ratio to the final video pixels. I don't think this is the case.

Whether most treat 720 pixels as equal to the 4x3 or 16x9 width, I don't know. Whether some commercial DVD releases and broadcast HD>SD conversions do this too, I don't know. It would be nice to try the "real" circle to find out.


I think converting 720>704 to fix such a problem will degrade the picture. This is more objectionable than a slight aspect ratio error.

Finally, the BBC at least is happy for the "extra" pixels either side of 702 to be black or picture content. They theoretically object if it's something else (i.e. junk) but in practice you'll see junk sometimes on actual broadcasts, so they are obviously not that careful.

Cheers,
David.

[facialz]

With other words, the BT-601 camera squeezes more than the DV-camera ...


DV-Cams simply show a more wide image instead of filling the overscan ...

"Squeezing more/less" means different image aspect ratios (e.g. 720/576 v 704/576) resulted from the same picture aspect ratio (16/9) captured under different pixel aspect ratios (64/45 v 16/11).

"Showing wider/narrower image", on the other hand, means different image aspect ratios (720/576 v 704/576) resulted from different picture aspect ratios (20/11 v 16/9) captured under the same pixel aspect ratio (16/11).

So, I interpret the two above as completely different statements. Sorry if I misunderstood.

[scharfis_brain]

facialz, you got it right.

To clarify myself: DV-Cams (as well as the DV-CoDec) use the ITU BT-601 Pixel Aspect Ratio (PAR) of 1:1.094 (4x3) & 1:1.459 (16x9).
generic PARs 1:1.067 (4x3) and 1:1.422 (16x9) aren't used.
These ones are Software specific bugs or lazyness-features.


Just the active image is a bit more wide, thus the Display Aspect Ratio (DAR) for
4x3 is actually 1:1.37
and for
16x9 is actually 1:1.82

And if one overlays black stripes left & right each 9 pixels wide, you got your BT-601 with analogue blanking and ultracorrect DAR, but PAR remains unchanged and correct.

[SixdeeBee]

Originally Posted by 2Bdecided
... but I've got to question the idea that all DV camcorders are so careful ...

The line-time-ratio between BT-601 and DV always is 53,33µs and 52,0µs (based on 702 active rows).

Therefore we can declare an Eliptic-Error-Factor (>... EEF...<) which shows the ratio of the diameters of the elipse
we get, when a DV camera "photographs" a circle and a BT-601-compliant TV-monitor shows it not round.

EEF = 53,33µs/52,00µs = 1.025
EEF = 53,33µs/52,14µs = 1.023 [based on 704 rows]

Note: The EEF is not the mathematical defined linear excentricity resp. the numerical excentricity !

[B]It seems that all DV-camcorders stay inside the > 704 rows < specification. The pixel type (square or rectangular) in a camera is not important because the chip-set "behind" the CCD-sensor generates the output format.

The linear linking between different PARs can be shown in a table, based on 704 rows.

BT-601.............DV.................4:3...............16:9
-------------------------------------------------

704 x 1,023 => 720 x 1,067 => 768 x 1,33 => 1024

704 x 1,091 =============> 768

704 x 1,4545 =======================> 1024

.....................720 x 1,067 => 768

.....................720 x 1,422 ============> 1024

Some additional values based on 702 pixels:

704/702 = 1,002849 => EEF = 0,285%
720/702 = 1,025641 => EEF = 2,564% <=> 53,33µs/52µs

Originally Posted by 2Bdecided
I think converting 720>704 to fix such a problem will degrade the picture...

Yes, I agree. There are two ways we can go if we real need BT-601:

1. Converting to a pseudo-BT-format with 704 rows:

#
AviSource("X:\path\DV.avi",true,pixeltype="YUY2") # use Lagarith/HuffYUV codec
#
TDeint(mode=1,order=0)
#
Crop(8,0,-8,0,align=true).AddBorders(8,0,8,0)
#
AssumeTFF().separatefields().selectevery(4,0,3).weave()
#

The output format is:

8 + 704 + 8 pixels, TFF, luminance quantization = 16 .. 235 (Because we use YUY2)

There is no > resize < => we get the original quality ... but:
The EEF has not been kompensated => circles stay eliptic !

2. Converting to the true-BT-format

#
AviSource("X:\path\DV.avi",true,pixeltype="YUY2") # use Lagarith/HuffYUV codec
#
TDeint(mode=1,order=0)
#
GaussResize(704,576,p=50.0).AddBorders(8,0,8,0)
#
AssumeTFF().separatefields().selectevery(4,0,3).weave()
#

The rows have been resized with a factor of 1/1,023 = 0,977.

The output format is:

8 + 704 + 8, TFF, luminance quantization = 16 .. 235 (because we use YUY2)

There is no EEF => circles stay round.

Note 1) In both examples the deinterlacing/reinterlacing can be ignored for BFF compatible targets (e.g. DVD))
Note 2) The gauss-function is "free of ringing" but pay attention with the factor p, be carefull with values neer 100.
Note 3) The Lagarith/HuffYUV-codec must be set to YUY2

Originally Posted by [B]2Bdecided
... the BBC at least is happy for the "extra" pixels either side of 702 to be black or picture content ...

If am informed correctly, the BBC is a member of the EBU (European Broadcast Union). This organization send to all
their members in 1999 a "memo" with the following content (EBU Technical Recommendation R92-1999).

In 625-line television systems sampled to ITU-R Rec. BT.601 part A, only the central 702 luminance samples of the digital active line (sample 9-710 inclusive) and their associated chrominance samples should be used to carry the active picture ...

It is comforting that the "professionals" seem to have problems with BT-601, too.:p

PAR = 1,422 or better 1,4545 ?

Software with DV-SmartRendering (PAR=1,422) function only rerenders parts of a clip which must be processed (e.g. transitions, morphs, titels etc.). All other parts of a clip are pushed = copied unprocessed to the editors output.
Software which offers BT-601 compliant output (PAR=1,4545) based on DV-input cannot use smartrendering because all frames must be rerendered.
The worst case scenario is: deinterlacing, resizing, bordercorrection, luminance/crominance sample range correction, reinterlace to TFF ...


SixdeeBee

[facialz]

Attached is a screenshot of Sony Vegas software [1], reflecting the Sony's point that regarding pixel aspect ratio, DV is ITU-R BT.601 compliant.



[1] http://eugenia.gnomefiles.org/2007/10/30/understanding-pixel-aspect-ratios/

[2Bdecided]

SixdeeBee,

I wonder if you're trying to confuse people here.

You quote the EBU memo, as if it contradicts the BBC - but the very next line after the one you quoted says exactly what the BBC says. The two organisations are in agreement: the extra pixels can contain picture information or black, but not any other junk:

http://www.ebu.ch/CMSimages/en/tec_text_r92-1999_tcm6-4619.pdf

In 625-line television systems sampled to ITU-R Rec. BT.601 part A, only the central 702 luminance
samples of the digital active line (samples 9-710 inclusive) and their associated chrominance samples
should be used to carry the active picture. The remaining 18 luminance samples and their associated
chrominance samples may be used to carry picture information only but for no other purpose. It
cannot be guaranteed that picture information in these samples will be displayed in either 4:3 or 16:9
aspect ratio images.

vs

http://www.bbc.co.uk/guidelines/dq/pdf/tv/tv_standards_london.pdf
4.1.4 Video Signal Timings.
Digitally delivered pictures are considered to have a nominal active width of 702 pixels
(52us) starting on the 10th pixel and ending on the 711th pixel in a standard REC 601 (720
sample) width. A minimum width of 699 pixels (51.75us) within these limits must be
achieved. Additional active pixels outside the above limits must be an extension of the main
picture.

You also talk about deinterlacing in order to swap from BFF to TFF. That is a horrible, potentially very lossy way of doing it. There are at least two other ways:

1) crop a line from the top (or bottom), and add a line to the bottom (or top)
2) separate fields, field shift the video (add or remove one field at the start, and remove or add one field at the end), and re-weave

The first one moves the picture up or down by a line, and the second one creates a duplicate field at the beginning or end - however, all the other lines/fields of the original video are preserved intact in the output video; whereas in your version, if I've understood it correctly, all the output video is made by the deinterlacer - none of the original video survives!

Given how misleading you have been on these issues, I think you're going to have to bring forward some pretty convincing evidence for people to believe the other things you're saying: that DV isn't BT.601 timing compliant. It may be true (it may be true of much MPEG-2 as well!) but evidence is needed, not speculation.

Cheers,
David.

[SixdeeBee]

@2Bdecided

I wonder if you're trying to confuse people here.

Sorry if you feel confused. It was not my intention ! :)

Source: http://www.bbc.co.uk/guidelines/dq/p...rds_london.pdf

page 8:

Active picture width is 52µs/702 pixels. All aspect ratio calculations are based on this. Any process based on 720 pixels width may introduce unwanted geometry or save area errors.

... It cannot be guaranteed that picture information in these samples will be displayed in either 4:3 or 16:9 aspect ratio images

Hey ... do you need a comment ?? :):):)

... Well, it is a fact that something which cannot be guaranteed is not specified by a specification.:rolleyes:

Given how misleading you have been on these issues, I think you're going to have to bring forward some pretty convincing evidence for people to believe the other things you're saying: that DV isn't BT.601 timing compliant. It may be true (it may be true of much MPEG-2 as well!) but evidence is needed, not speculation.

Well, there are this nonspeculation facts (again)::confused:

1. BT-601 compliant system use 52µs and not 53,33µs.

2. DV is 720 pixels based and even if one crops it to 702 pixels, the geometry of the left overs are based on the "spread" horizontal dimension of DV. Therefore the geometric distortion stays.

3. Cropping DV to get 702 pixels is not consistent with conversion to BT-601. You loose 16 rows of the original sample.

While a BT-compliant camera shows one line in exactly 52µs the cropped DV is loosing about 1,3µs of its content which results in a reduced line-time information length of about 50,7µs only. You get the same effect as if you have spread the frames to increase the overscan.

Deinterlacing using bobbing does not loose any information. Of course one can take the deinterlacer he/she trusts. :)
Because deinterlacing was not the main theme of the post, I used bobbing as an example ... sorry if it was the wrong way for you ...:mad:
... And do you know which sort of deinterlacing Premier is using ? Based on the bad behavior of older Premier versions, bobbing outside of Premier seems not to be the worst case.

One last sample: 16:9 anamorphic Widescreen to PC and back:

1. BT-601

Source is a 9 + 702 + 9 sample with 52µs content/line:
To show circles on the PC-screen round one must use a scaling factor of 1,4587:

(9+702+9) * 1,4587 = 1050 pixel. The image consist of 13 black + 1024 content + 13 black pixels. The 26 black bars are redundant in a video editing system, we can crop them .
Important is only the content which has been upscaled to 1024 pixels
If we scale back: 1024 * 1/1,4587 = 702 pixels. We add the overscan bars: 9left + 702content + 9 right => 720 pixels.

2. DV, native (=> uncropped, unresized)

We use the same upscaling factor:

720 x 1,4587 = 1050 pixel. There are no black bars.
We get an image were circles are "geoids" (flattend circles) (The number of lines stays unchanged (576)).
If we scale back: 1050 * 1/1,4587 = 720 pixels. We did not reach the BT-dimension ! Therefore the up/downscaling factor must be wrong.

3. Same procedure but upscaling with 1,422

720 x 1,422 = 1024 pixel, no black bars. Circles stay round.

If we scale back we use the BT-scaling factor :

1024 * 1/1,4587 = 702 pixels. We add 18 overscan-bars and we
have a BT-601 compliant sample without geometric error.

Problem is not that we have 720 pixels but the fact, that DV uses the overscan for image content and therefore spreads the lines over the 52µs border. This difference was the reason I wrote >>> DV is not 100% BT-601 compliant <<<

@facialz
Thank you for the link.:)

When Sony create DV in the mid of the 90s of last century, they had already a product-segment with their professional studio equipment. If DV is BT-601 compliant, why not buy DV instead of expensive and heavy weighted cameras ? This could have been a thought of their managers and then they construct those
tiny sweet differences to protect their own professional segment.

1. Timings altered little bit
2. Usage of the overscan for image content
3. 4:2:0 (PAL), 4:1:1 (NTSC) colourspace and not e.g. 4:2:2 YUV
4. BFF instead of TFF

The differences are not strong enough to be "dangerous" for video hobbyists but for BT-601 based studio equipment they can be "deadly"...:eek:

Edit: I have overseen the picture, sorry

Yes, of course it is possible to make a BT-601 compliant clip based on DV but it implements processing:

1. No SmartRendering
2. Upscaling (inside of the video editor) by e.g. 1,422
3. Downscaling by 1,4545 (PAL 704 rows) or 1,4586 (PAL 702 rows)
4. Adding black bars.
.
.
BT-compliant means: SmartRendering and no processing => not possible with DV in a BT-environment, sorry ..

The only gremium that can declare DV as BT-601 compliant is the ITU and not Sony, sorry...:mad:

... But please don't shoot me, I am only a poor user who has problems with DV in a TV-studio environment and must explain to other people why their videos are send back as "not transmittable"...:devil:


SixdeeBee

[scharfis_brain]

provide by evidence that DV shows non-ITU-compliant PAR!

take several DV-cams and record a sphere (maybe a globe)
then measure its width and height in pixels.

btw.: look at the DVB broadcasts today they are full of mixed content:all 720 pixels MPEG width. and mixed with 9+702+9 and full 720 pixels width active contents.
I doubt that the full 720 active pixels images are recorded by DV-equipment!

[SixdeeBee]

The attachment contents 3 images, based on a 1024 x 576 pixel testcard with PAR=1.0

* BT_601

It shows an anamorphic testcard, 8 + 704 active pixels + 8 pixels, it shows on a studio-monitor an exact round circle.

* Cropped_DV

The same testcard, 720 active rows, cropped on both sides and filled up with borders. Therefore it is a 8 + 704 + 8 image, too.
Borders are green to show the difference > green minus black < in the difference image. This testfile shows a geoid on a studio-monitor.

* Differenz (= difference)

Shows a nonanamorphic difference image Cropped_DV minus BT_601.

The pictures have been grabbed with a player, sources are AVI, 50 fps, progressive.

This is a simulation to show the principle. It is valid for all PC-internal 16:9-productions e.g. with

1. Bryce (landscape animations)
2. Fraps screen captures
3. Celestia space animations
4. Blender 16:9 productions
5. etc.


@scharfis_brain
provide by evidence that DV shows ITU-compliant PAR! :D ... please ...
..look at the DVB broadcasts today they are full of mixed content...

I agree, there is much scrap on DVB stations today but it is their decision and not all stations must follow the low-quality-way ...:devil:


SixdeeBee

[JohnnyMalaria]

According to the official DV specification (IEC 61834-2):

The sampling structure is the same as a sampling structure of 4:2:2 component television signals which is described in ITU-R Recommendation BT601-5. Sampling structures of luminance (Y) and two colour difference signals (CR, CB) are shown in table 20.

[facialz]

take several DV-cams and record a sphere (maybe a globe) then measure its width and height in pixels.

I don't think a sphere is absolutely necessary. Any rectangle test picture showing a circle or square would suffice. We only have to verify that the image of the test picture is a rectangle before going to measure the contained circle or square.

[SixdeeBee]

@JohnnyMalaria
Thank you for the hint.
Yes, I agree. The sample structure must be the same (or at least in the specs) to show DV on a TV-monitor. But there is already the tiny little difference between 702 active rows and 720 active rows.
Because BT-601 allows 720 rows, one can use the additional 18 rows in principle as you like but in any system which only accept 702 active rows problems are programmed.

But nevertheless: Unprocessed DV-clips show a geometric error.

@facialz

I agree. Therefore I recommend to use what I called "pseudo-BT". The images in the attachment in my last post show exactly what we get ... but e.g. on a 45" plasma screen the little error is visible even without having a reference.

@scharfis_brain

Could you please show us where you use PAR=1,4545 in this environment:

Source: 720 x 576 pixels DV

PAR-coefficient to show circles round on the editor preview-screen (PC)
PAR-coefficient to show circles round on the editing screen (PC)
PAR-coefficient to show circles round using BT-601-export.

Theese three cases are the standard in a video-editing-environment. Therefore this should be interesting.

SixdeeBee

[scharfis_brain]

I need to get a DV-Cam to my hands first, so I can make test.
I currently have no suitable footage here...

[JohnnyMalaria]

but DV unfortunately is not 100% ITU-BT-601 (rev. 5) compliant.

Yes it is.

It is software DV codecs that do not implement the DV specification properly.

A compliant encoder would take your earlier 1024 x 576 test card, resize to the correct 702 x 576 and then add the vertical black bars to create a 720 x 576 image.

Non-compliant (i.e., most) DV encoders blindly resize to 720 x 576.

Hence, you need to do all the resizing gymnastics that you describe. You are correct to state as such. But it isn't because DV isn't 601 compliant.

All my DV equipment (I have quite a bit) encodes S-video with the padding.

All my DV camcorders record images across the full 720 pixel width. i.e., more picture information is contained in the image. The camcorders could blank the edges but that would be unnecessary. The effective 1:1 PAR size of a full widescreen image recorded by the camcorder is slightly wider than 1024 x 576.

Given that a company like Sony is one of the major players in broadcast television production equipment, it is highly unlikely that they would get it wrong.

[SixdeeBee]

I add an another image. It shows a sample of the difference between a 704 x 576 pixel BT and a 720 x 576 DV which has been cropped to 704 and got 16 black rows.
The yellow grid is BT, the white is DV.

In the middle of the active screen the difference is zero, the geometric error symmetrical adds up to both sides.

@JohnnyMalaria

It is software DV codecs that do not implement the DV specification properly.

Sorry, I don't agree. A "pure" DV-codec should not process a source to another format but keep the original

For a conversion DV to BT one needs a DV to BT codec.

A compliant encoder would take your earlier 1024 x 576 test card, resize to the correct 702 x 576 and then add the vertical black bars to create a 720 x 576 image.

Yes, I agree :) ... and one does not need a DV codec in such an environment, PAR = 1,45..

Hence, you need to do all the resizing gymnastics ...

Hey ... gymnastics is healthy ...

All my DV camcorders record images across the full 720 pixel width. i.e., more picture information is contained in the image.

This is exactly the question: Does a DV-camera show more horizontal information or does it show the same horizontal information as a professional camera does ?
Comparing DV-camcorders with portable-TV-studio cameras from Panasonic (the WV-E5xx and WV-E6xx production line) showed, that all DV-camcorders, we got for testing, spread the visible width therefore those camcorders did not offer more horizontal information.

Given that a company like Sony is one of the major players in broadcast television production equipment, it is highly unlikely that they would get it wrong.

DV has not been intended to be for broadcast use ! Sony themselves spoke of it as a "semi-professional" system.
And their system is not > wrong < ... it seems to be slightly different.


SixdeeBee

[2Bdecided]

SixdeeBee,

At first I though you were coming here with new information.

However, I think all your posts are simply based on your own misunderstanding.

Most importantly, you didn't understand the significance of what JohnnyMalaria attached in post 23 (http://forum.doom9.org/showthread.php?p=1106943#post1106943). It states the Y sampling frequency is 13.5MHz. This means is that 52us = 702 pixels (52us * 13.5MHz = 702).

Now, unless you believe that the DV format isn't designed to display correctly on any analogue TV, this proves that the centre 702 pixels in DV are the same as the centre 702 pixels in every other 13.5MHz based digital video system: they are the active line that defines the aspect ratio. The extra pixels, like in every other 13.5MHz based digital video systems, are just that: extra pixels.


Source: http://www.bbc.co.uk/guidelines/dq/p...rds_london.pdf

Active picture width is 52µs/702 pixels. All aspect ratio calculations are based on this. Any process based on 720 pixels width may introduce unwanted geometry or save area errors.

... It cannot be guaranteed that picture information in these samples will be displayed in either 4:3 or 16:9 aspect ratio images
Hey ... do you need a comment ?? :):):)

... Well, it is a fact that something which cannot be guaranteed is not specified by a specification.:rolleyes:

You don't seem to understand how this works! The analogue active line fills 702 pixels. 720 pixels are sampled to ensure the entire line is captured, even if the start and ends points are shifted somewhat (as they can be whilst remaining within the tolerance of an analogue PAL video signal). In digital systems, the entire 720 pixels are often filled with correct active picture, the extra 9 pixels each side being extra picture outside of the area defining the aspect ratio. Given that some studios still use analogue processing, and most consumers still use analogue connections, there is no guarantee that these extra pixels will be displayed, even if overscan is disabled.

Well, there are this nonspeculation facts (again)::confused:

1. BT-601 compliant system use 52µs and not 53,33µs.

BT601 uses 13.5MHz sampling of an analogue video signal, filling 702 pixels with 52us active line. However, we sample 720 pixels, given 53.33us captured. Most older cameras will have black in this area. Some newer sources will include content in this area.

2. DV is 720 pixels based and even if one crops it to 702 pixels, the geometry of the left overs are based on the "spread" horizontal dimension of DV. Therefore the geometric distortion stays.DV is based on BT601. You have not proven that the extra pixels in DV are any different from the extra pixels in anything else 601 related. You keep claiming that they are, but you haven't posted any proof.


Deinterlacing using bobbing does not loose any information. Of course one can take the deinterlacer he/she trusts. :)
Because deinterlacing was not the main theme of the post, I used bobbing as an example ... sorry if it was the wrong way for you ...:mad:
Yet again, you didn't understand. Firstly, bobbing can lose information if the wrong bobber is used (see the AVIsynth docs for coefficients to avoid this) - however, the point was that bobbing BFF content, and then grabbing the appropriate lines to deliver TFF content will grab only interpolated lines - all the original information is lost!



None of this is to say that DV camcorders definitively use 702, 704, 720 or anything else as the actual aspect ratio defining width. I am sure there are examples of equipment (hardware and software) that claims full BT.601 compliance that gets it completely wrong. DV camcorders may consistently get it "wrong" too.

We don't know, and apart from claiming "Comparing DV-camcorders with portable-TV-studio cameras from Panasonic (the WV-E5xx and WV-E6xx production line) showed, that all DV-camcorders, we got for testing, spread the visible width therefore those camcorders did not offer more horizontal information" you have not addressed this point. Given the technical inaccuracies that fill your posts, I can't rely on you simply claiming that something is true. I would like to see evidence.


I'm sorry if this sounds harsh, but while what you say about the actual performance of DV camcorders may be true, most of the technical arguments you make are simply wrong.

Cheers,
David.

[facialz]

I attached relevant data from BT.601 for comparison.

The specification (see Table 2) applies to the 4:2:2member of the family, to be used for the standard digital interface between main digital studio equipment and for international programme exchange of 4:3 aspect ratio digital television or wide-screen 16:9 aspect ratio digital television when it is necessary to keep the same analogue signal bandwidth and digital rates.

Table 2

http://img.photobucket.com/albums/v629/cabo2004/ITU-R-BT601-Table2.gif


Verification that data are consistent:
PAL : 864 * 625 * 50/2 = 13 500 000
NTSC: 858 * 525 * 60/2*1000/1001 = 13 500 000

[2Bdecided]

Did we scare him/her off?

I was hoping for some nice pictures of circles - though taking a perfect picture of something flat without introducing geometric distortion is harder than you would think.

Cheers,
David.

[facialz]

Such test may need some time. Even a studio may not get a new camera for testing every day. Especially when it's about an example of wrong design from Sony.

[SeeMoreDigital]

Did we scare him/her off?

I was hoping for some nice pictures of circles - though taking a perfect picture of something flat without introducing geometric distortion is harder than you would think.I hope not. I really enjoy these kinds of debates!

Besides I was going to ask SixdeeBee if he could do me a favour.

[WorBry]

This (checkbox for setting the 16/9 flag in the DV encoded output) is allready implemented, but not released.

Any prospect of an update to build 0.2.0 incorporating this feature?

[tartak]

One way to set the 16:9 flag in cedocida's output is to do a search and replace in any hex editor - search for all 613FC8FCFF and replace with 613FCAFCFF.

Adding the aspect ratio setting to the code is simple too. Since this feature has been asked for more than once, in a few forums I frequent, I thought I'd post my mod. The only new feature - selection of the aspect ratio, 4:3 or 16:9. Hope it might be useful to someone. cedocida is really the top dv codec around.

[SeeMoreDigital]

Nice one... And welcome to the forum :)

[Guest]

I have updated the version hosted at my web site.

Thank you for the contribution.

[Midzuki]

One way to set the 16:9 flag in cedocida's output is to do a search and replace in any hex editor - search for all 613FC8FCFF and replace with 613FCAFCFF.

Adding the aspect ratio setting to the code is simple too. Since this feature has been asked for more than once, in a few forums I frequent, I thought I'd post my mod. The only new feature - selection of the aspect ratio, 4:3 or 16:9. Hope it might be useful to someone. cedocida is really the top dv codec around.

:goodpost: :goodpost: :goodpost:

:thanks: :thanks: :thanks: :thanks: :thanks:

[tartak]

I have updated the version hosted at my web site.

Thank you for the contribution.
Thanks!

I noticed you deleted the ini file. But there was a simple reason I included it and changed the cedocida.inf script to copy the ini to the windows directory. The new ini is incompatible with the old, so if you install over the existing cedocida installation, the codec will read a wrong configuration instead of the default one.

[Guest]

OK, I will fix that and link the source as well this evening.

[WorBry]

I didnt want to cross post:

http://forum.doom9.org/showthread.php?p=1399593#post1399593

Cedocida doesnt seem to have been around the forum for a while.