Cedocida and anamorphic PAL

[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! ... 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 ...


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]

Originally Posted by scharfis_brain

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]

Originally Posted by SixdeeBee

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. 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.

Originally Posted by SixdeeBee

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

Hey ... do you need a comment ??

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

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):

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 ...

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

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]

Originally Posted by 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.

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]

Originally Posted by cedocida

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]

Originally Posted by 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.

[tartak]

Originally Posted by neuron2

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.