How to use MediaInfo.dll 0.7.1.2 in Delphi and other developer tools

[Amnon82]

I updated an old sample for mediainfo.dll to 0.7.1.2.

Maybe somebody can use it for his own delphi projects.

http://img95.imageshack.us/img95/7383/mdll07124xp.png

Download Sample + source + DLL + calls (http://home.arcor.de/autoq2_amsoft/files/delphi/source/BeispielGUI_Source0712.zip)

Also you can get some informations about aspect ratio and other stuff of mediainfo.dll.

[Inc]

MediainfoLib parses ARs wrong. I wanted to include it in PARanoia but the parsed ARs are totally away from whats included in the bitstream.

Example:
Encoded a capture using XViD 704x576 and a DAR of 4:3.
Result is a simple math of 704/576 --> AR = 1,2222

But the biggest problem is in case of mpeg2/VOBs:
720x576 non-anamoprh results in 1,3333:1 which is wrong --> 1,3675:1 would be correct.
720x576 anamorph results in 1,7778 (as also your screenshot shows) --> 1,8234 would be correct.

I think Ill get in contact with the developer ...

[Sirber]

Look in New container forums, all infos there. Or get RealAnime sources ;)

[Inc]

Look in New container forums, all infos there.
Please specify a concrete link or do quote that formula part from your source (where I already do assume what kind of formula this will be).

[Sirber]

procedure TAnalyze.AnalyzeMKV();
var
handle: Cardinal;
filename: pWideChar;
source: TSource;
iNbTrack,
iCpt: integer;
sFPS,
sID: string;
begin
// Convert filename
GetMem(filename, sizeof(WideChar) * Succ(Length(setting.source_copy)));
StringToWideChar(setting.source_copy, filename, Succ(Length(setting.source_copy)));

// Open
handle := MediaInfo_New();
MediaInfo_Open(handle, filename);
FreeMemory(filename);

//get infos of file
setting.source_ar := MediaInfo_Get(handle, StreamKind_Video, 0 , 'AspectRatio/String' , InfoKind_Text, 0);
setting.source_width := MediaInfo_Get(handle, StreamKind_Video, 0 , 'Width' , InfoKind_Text, 0);
setting.source_heigth := MediaInfo_Get(handle, StreamKind_Video, 0 , 'Height' , InfoKind_Text, 0);

// ** look for tracks
// Audio
iNbTrack := MediaInfo_Count_Get(handle, StreamKind_Audio, -1) - 1;
for iCpt := 0 to iNbTrack do
begin
// Add track
source := CleanSource(source);
source.codec := MediaInfo_Get(handle, StreamKind_Audio, iCpt, 'Codec', InfoKind_Text, 0);
source.source := setting.dir_temp + 'audio_' + IntToStr(iCpt) + GetCodec(source.codec, StreamKind_Audio);
source.output := setting.dir_temp + 'audio_enc_' + IntToStr(iCpt) + '.mp4';
source.tracktype := StreamKind_Audio;
source.lang := GetLang(MediaInfo_Get(handle, StreamKind_Audio, iCpt, 'Language', InfoKind_Text, 0));
source.toencode := true;
source.toextract := true;
source.toremerge := false;
source.channel := MediaInfo_Get(handle, StreamKind_Audio, iCpt, 'Channels', InfoKind_Text, 0);
sID := MediaInfo_Get(handle, StreamKind_Audio, iCpt, 'ID', InfoKind_Text, 0);
if (sID <> '') then
source.trackid := StrToInt(sID); // MKV
AddTrack(source);
end;

// Video
iNbTrack := MediaInfo_Count_Get(handle, StreamKind_Video, -1) - 1;
for iCpt := 0 to iNbTrack do
begin
// Add track
source := CleanSource(source);
source.codec := MediaInfo_Get(handle, StreamKind_Video, iCpt, 'Codec', InfoKind_Text, 0);
//source.source := setting.dir_temp + 'video_' + IntToStr(iCpt) + GetCodec(source.codec, InfoKind_Text);
source.source := setting.dir_temp + 'video_' + IntToStr(iCpt) + '.mkv';
source.output := setting.dir_temp + 'video_enc_' + IntToStr(iCpt);
source.tracktype := StreamKind_Video;
source.height := StrToInt(MediaInfo_Get(handle, StreamKind_Video, 0 , 'Height' , InfoKind_Text, 0));
source.width := StrToInt(MediaInfo_Get(handle, StreamKind_Video, 0 , 'Width' , InfoKind_Text, 0));
source.ar := MediaInfo_Get(handle, StreamKind_Video, 0 , 'AspectRatio/String' , InfoKind_Text, 0);
source.lang := GetLang(MediaInfo_Get(handle, StreamKind_Video, iCpt, 'Language', InfoKind_Text, 0));
sFPS := MediaInfo_Get(handle, StreamKind_Video, iCpt, 'FrameRate', InfoKind_Text, 0);
if ( sFPS = '') then
source.fps := -1
else
source.fps := StrToFloat(sFPS);
source.toencode := true;
source.toextract := true;
source.toremerge := false;
sID := MediaInfo_Get(handle, StreamKind_Video, iCpt, 'ID', InfoKind_Text, 0);
if (sID <> '') then
source.trackid := StrToInt(sID); // MKV
AddTrack(source);
end;

// Subtitles
iNbTrack := MediaInfo_Count_Get(handle, StreamKind_Text, -1) - 1;
for iCpt := 0 to iNbTrack do
begin
// Add track
source := CleanSource(source);
source.codec := MediaInfo_Get(handle, StreamKind_Text, iCpt, 'Codec', InfoKind_Text, 0);
source.source := setting.dir_temp + 'subtitle_' + IntToStr(iCpt) + GetCodec(source.codec, StreamKind_Text);
source.output := setting.dir_temp + 'subtitle_' + IntToStr(iCpt) + GetCodec(source.codec, StreamKind_Text);
source.tracktype := StreamKind_Text;
source.lang := GetLang(MediaInfo_Get(handle, StreamKind_Text, iCpt, 'Language', InfoKind_Text, 0));
source.toencode := true;
source.toextract := false;
source.toremerge := true;
sID := MediaInfo_Get(handle, StreamKind_Text, iCpt, 'ID', InfoKind_Text, 0);
if (sID <> '') then
source.trackid := StrToInt(sID); // MKV
if (source.codec = 'S_VOBSUB') then // Vobsub Tweak (only need idx file to merge)
source.output := setting.dir_temp + 'subtitle_' + IntToStr(iCpt) + '.idx';
AddTrack(source);

end;

MediaInfo_Close(handle);
//MediaInfo_Delete(handle);
bAnalyzed := true;
end;

procedure TFInfo.DumpFile(input: string);
var
handle: Cardinal;
filename: pWideChar;
begin
sInput := input;
GetMem(filename, sizeof(WideChar) * Succ(Length(input)));
StringToWideChar(input, filename, Succ(Length(input)));

// Open
handle := MediaInfo_New();
MediaInfo_Open(handle, filename);
FreeMemory(filename);

MediaInfo_Option(handle, 'Complete', '1');
mmoInfo.Text := MediaInfo_Inform(handle, InformOptions_Nothing);

// Close
MediaInfo_Close(handle);
//MediaInfo_Delete(handle);
end;

unit MediaInfoDll;

interface
uses
{$IFDEF WIN32}
Windows;
{$ELSE}
Wintypes, WinProcs;
{$ENDIF}

// Widechars
function MediaInfo_New(): Cardinal cdecl {$IFDEF WIN32} stdcall {$ENDIF};

procedure MediaInfo_Delete(Handle: Cardinal) cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfo_Open(Handle: Cardinal;
File__: PWideChar): Boolean cdecl {$IFDEF WIN32} stdcall {$ENDIF};

procedure MediaInfo_Close(Handle: Cardinal) cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfo_Inform(Handle: Cardinal;
Options: Integer): PWideChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfo_GetI(Handle: Cardinal;
StreamKind: Integer;
StreamNumber: Integer;
Parameter: Integer;
KindOfInfo: Integer): PWideChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfo_Get(Handle: Cardinal;
StreamKind: Integer;
StreamNumber: Integer;
Parameter: PWideChar;
KindOfInfo: Integer;
KindOfSearch: Integer): PWideChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfo_Option(Handle: Cardinal;
Option: PWideChar;
Value: PWideChar): PWideChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfo_State_Get(Handle: Cardinal): Integer cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfo_Count_Get(Handle: Cardinal;
StreamKind: Integer;
StreamNumber: Integer): Integer cdecl {$IFDEF WIN32} stdcall {$ENDIF};

// Ainsi
function MediaInfoA_New(): Cardinal cdecl {$IFDEF WIN32} stdcall {$ENDIF};

procedure MediaInfoA_Delete(Handle: Cardinal) cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfoA_Open(Handle: Cardinal;
File__: PChar): Cardinal cdecl {$IFDEF WIN32} stdcall {$ENDIF};

procedure MediaInfoA_Close(Handle: Cardinal) cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfoA_Inform(Handle: Cardinal;
Options: Integer): PChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfoA_GetI(Handle: Cardinal;
StreamKind: Integer;
StreamNumber: Integer;
Parameter: Integer;
KindOfInfo: Integer): PChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfoA_Get(Handle: Cardinal;
StreamKind: Integer;
StreamNumber: Integer;
Parameter: PChar;
KindOfInfo: Integer;
KindOfSearch: Integer): PChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfoA_Option(Handle: Cardinal;
Option: PChar;
Value: PChar): PChar cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfoA_State_Get(Handle: Cardinal): Integer cdecl {$IFDEF WIN32} stdcall {$ENDIF};

function MediaInfoA_Count_Get(Handle: Cardinal;
StreamKind: Integer;
StreamNumber: Integer): Integer cdecl {$IFDEF WIN32} stdcall {$ENDIF};

// 0.7.0.2
const
StreamKind_General : integer = 0;
StreamKind_Video : integer = 1;
StreamKind_Audio : integer = 2;
StreamKind_Text : integer = 3;
StreamKind_Chapters : integer = 4;
StreamKind_Image : integer = 5;

InfoKind_Name : integer = 0;
InfoKind_Text : integer = 1;
InfoKind_Measure : integer = 2;
InfoKind_Options : integer = 3;
InfoKind_NameText : integer = 4;
InfoKind_MeasureText: integer = 5;
InfoKind_Info : integer = 6;
InfoKind_HowTo : integer = 7;

InfoOptions_ShowInInform : integer = 0;
InfoOptions_Support : integer = 1;
InfoOptions_ShowInSupported : integer = 2;
InfoOptions_TypeOfValue : integer = 3;

InformOptions_Nothing : integer = 0;
InformOptions_Custom : integer = 1;
InformOptions_HTML : integer = 2;

implementation

function MediaInfo_New; external 'MediaInfo.Dll';
procedure MediaInfo_Delete; external 'MediaInfo.Dll';
function MediaInfo_Open; external 'MediaInfo.Dll';
procedure MediaInfo_Close; external 'MediaInfo.Dll';
function MediaInfo_Inform; external 'MediaInfo.Dll';
function MediaInfo_GetI; external 'MediaInfo.Dll';
function MediaInfo_Get; external 'MediaInfo.Dll';
function MediaInfo_Option; external 'MediaInfo.Dll';
function MediaInfo_State_Get; external 'MediaInfo.Dll';
function MediaInfo_Count_Get; external 'MediaInfo.Dll';

function MediaInfoA_New; external 'MediaInfo.Dll';
procedure MediaInfoA_Delete; external 'MediaInfo.Dll';
function MediaInfoA_Open; external 'MediaInfo.Dll';
procedure MediaInfoA_Close; external 'MediaInfo.Dll';
function MediaInfoA_Inform; external 'MediaInfo.Dll';
function MediaInfoA_GetI; external 'MediaInfo.Dll';
function MediaInfoA_Get; external 'MediaInfo.Dll';
function MediaInfoA_Option; external 'MediaInfo.Dll';
function MediaInfoA_State_Get; external 'MediaInfo.Dll';
function MediaInfoA_Count_Get; external 'MediaInfo.Dll';

end.

[Inc]

As I do see you show me how to acess the dll. Thanks. I know that.
But we are talking about the DAR issue as seen above.

[Sirber]

ha, sorry, I misread. I thought you needed code to manage MI. Sorry :(

[Inc]

Never mind :)

[Zenitram]

MediainfoLib parses ARs wrong. I wanted to include it in PARanoia but the parsed ARs are totally away from whats included in the bitstream.
I am the developper of MediaInfo.
For MPEG-1 and 2, I test the Pixel Aspect Ratio, the formula is :
DAR=Width/Heigth*PAR.

If there is a problem with some of your files (MPEG-2 or other), I am intersted to have some examples.
Please contact me at zen@mediaarea.net

[mpucoder]

How can that work in mpeg-2? You do realize that mpeg-2 changed the definition of aspect ratio in the sequence header to DAR?
Another thing to be aware of is that for DVD an encoded stream of 4:3 which has Sequence_Display_Extension giving 540 as the width or has Picture_Display_Extension's is Pan/Scan, and is compatible with either 4:3 (as panscan) or 16:9 (as widescreen)

In all cases mpeg-2 DAR refers to the display dimensions, not picture size. Without a Sequence_Display_Extension these are the same.

[Inc]

For mpeg2 here the AR is "just" a defenition of a flag, but NOT a real DAR value. Means an anamorph (16:9 flag) 720x576 is not 1,7778:1 neither 1,33333 in case of non anamorph (4:3 flag).

Here the correct PARs of mepg2 and mpeg1 or better said for the common resolutions of 720xXXX, 704xXXX, 544xXXX, 352xXXX are shown here which should be also taken into account in case of mpeg4.
http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table
So a XVID of 704x576 also gots a PAR of 128:117.

Anyhow If I do load a XVID capture of 704x576 with an AR flag of 4:3 set, the AspectRatio in Mediainfo's output is 4:3 but assigned by a PAR of 1,22 which is simply 704/576.

Could you have a look at it Zenitram? Thanks for all your efforts :)

[Wilbert]

For mpeg2 here the AR is "just" a defenition of a flag, but NOT a real DAR value.
What do you mean not a *real* DAR value? It's a specification how the video should be displayed (page 47 of the mpeg-2 specs):

aspect_ratio_information either specifies that the “sample aspect ratio” (SAR) of the reconstructed frame is 1,0 (square samples) or alternatively it gives the “display aspect ratio” (DAR).

If sequence_display_extension() is not present then it is intended that the entire reconstructed
frame is intended to be mapped to the entire active region of the display. The sample aspect ratio
may be calculated as follows:
SAR = DAR * horizontal_size / vertical_ size


As mpucoder says, mpeg-2 doesn't know any PAR (any other than 1:1). So 720x576 16:9 should be stretched to 1024x576 upon playback.

[Inc]

????

720*(128/117) x 576 = 788 x 576 (nonanamorph brought to Par 1:1)
720*((128/117)/0.75) x 576 = 1050 x 576 (anamorph brought to Par 1:1)

The sample aspect ratio
may be calculated as follows:
SAR = DAR * horizontal_size / vertical_ size
ok, lets calc a D1 720x576 nonanamorph one. And we do keep in mind ITU.
SAR = 4/3 * 720 / 576 = 1,66667
So you gonna tell me that a D1 720x576 gots a SAR/PAR of 1,6667 one? Isnt it 128/117 --> Would mean in case of your quote, that a 720 source would keep 52.000us.

If sequence_display_extension() is not present then it is intended that the entire reconstructed
frame is intended to be mapped to the entire active region of the display.Yup, but we're talking in here about a setted Flag/SeqDisplExt. which is parsed & outputtet by Mediainfo, Restream etc.

EDIT: Same in case of FitCD .... do input a 16/9 anamoprh 720x576 d2v project and the formula also here is (720*(128/117))/0,75 --> not 1024

[Zenitram]

This is difficult for my mind ;-)

So, let's summary all of this please : I analyse a video stream, not where it comes from, and I want to show the Display Aspect Ratio, so I trust what is said in the header.

* MPEG-2: The ISO 13818-2 book 6.3.3. says: aspect_ratio_information either specifies that the “sample aspect ratio” (SAR) of the reconstructed frame is 1,0 (square samples) or alternatively it gives the “display aspect ratio” (DAR).

If sequence_display_extension() is present then the sample aspect ratio may be calculated as
follows:
SAR = DAR * display_ horizontal_ size / display_vertical _ size
So for MPEG-2, I use it, and for example in a DVD (PAL) Anamorphic, this is 720*576, with DisplayAspectRatio = 16/9 = 1.77778 exactly.
So I show 16/9.
What's wrong with this?
(and a more precise question : what is Sample Aspect Ratio? same as Pixel Aspect Ratio?)

* MPEG-4 (for XviD): I was always thinking that MPEG-4 has only defined square pixels, so I have never be careful to this, and at this time I do not analyse a MPEG-4 raw stream, only a container (AVI, MKV...) to have the width and height in pixels, and DAR=Width/Height.
I just took a look on the ISO 14496-2 book 6.3.3, and it there is a pixel AR value.
aspect_ratio_info: This is a four-bit integer which defines the value of pixel aspect ratio. Table 6-12 shows the
meaning of the code. If aspect_ratio_info indicates extended PAR, pixel_aspect_ratio is represented by par_width
and par_height. The par_width and par_height shall be relatively prime.
I will implement the reading of this value soon.
I took a example from a DivX file, the PAR is 1 for a 704*404 file, so MediaInfo shows 704/404=1.74 and is right, but I should calculate 704/404*PAR to be sure to be exact, Do I right?
Inc, I am interested in your XviD file with not square pixels (and I am not sure to understand the ISO : is DAR=Width/Height*12/11 or DAR=Width/Height*11/12 for a 4/3 picture?)

Anyway, if the container says a Display AR (MKV does), I will show it in priority

[Kika]

Do we really have to discuss this over and over again?

BTW: SAR isn't used on MPEG2.

What we have to know is:
DAR - what's the Display Aspect Ratio of the Video
PAR - what's the Aspect Ratio of the Pixels or (and better), how they have to be stretched.
At last we must know, how to work with all of this.

Working with a generic PAR is ... um... the source of all evil in the video world. 1.0667:1 doesn't really exist. So resizing 720x576 to 1024x576 (16:9) or to 768x576 (4:3) is wrong - in any case!

Maybe we should dig out some of the old threads (2001-2002).
I'm tired of reading this wrong stuff over and over again.
OK, some things in the ITU / CCIR are a bit strange - but these rules do exist, and we have to use them, because DVD producers do use them too.

[Inc]

I used the 720x576 DVD Template to determine the active capt.Cards sampling area. On 3 diff. DVD SAP Brands these 720x576 do overhead the 702x576 frame which equals exactly 4:3 by 9+9px cropped.

And its quite simple to calculate HOW the SAPs do playback these sources. And sources are mastered primary for SAP playback purposes.

720x576 mpeg2 will be played back @13.5Mhz and do got an active window of 53.333us. These do result in 13.5*53.333 = 720px!
The full 4:3 PAL area on a PC Monitor Screen results equals 14.769231Mhz MHz and 52.000us, thus 14.769231* 52.000 = 768px

The PAR so determined by 14.769231/13.5 = 1.094017.
This equals to 768/702 and also this equals to 128/117.

So 720x576 will be played back using 128/117 and NOT using that "rumour" generic PAR.

Case of 480x576: Here the Mhz playback rate is 9Mhz:

14.769231/9 = 1,641026

So 480*(1.641026) x 576 is shown at 788x576 px which also here isnt 4:3 1.3333 but 1.368 ... Thats why you can directly resize from 720xXXX to 480xXXX with no AR errors.

[Wilbert]

Do we really have to discuss this over and over again?
Once in a year, yes :)

Inc, that is the case for the playback on your analog tv, where it makes sense to use ITU. For playback on a digital tv using a hardware/software dvd player, it doesn't make sense to follow ITU. Most (all?) software players follow the mpeg-2 specification upon playback.

The fact is that the mpeg-2 specification and ITU contradict each other, so you can't follow both. At least, that's how I see it.

@Zenitram,
and a more precise question : what is Sample Aspect Ratio? same as Pixel Aspect Ratio?
Yes.

@Kika,
OK, some things in the ITU / CCIR are a bit strange - but these rules do exist, and we have to use them, because DVD producers do use them too.
How do you know? Do you have any evidence that they always follow ITU, and not the mpeg-2 specification?

[Zenitram]

The fact is that the mpeg-2 specification and ITU contradict each other, so you can't follow both. At least, that's how I see it.
Exact, I can not follow multiple documents in contradiction. Even more when the display is different if I use Analog or digital TV.
So I will keep 720x576 with a DAR in the stream of 16/9, as 16/9... Mainly because my digital projector show the 720 pixels! ;-)

And: HDTV (1920x1080) has square pixels. The document does not speak about this, so how must I do? This is not possible to follow all documents, and the world is more and more digital...

So, I think I will do because this is the best compromise (if not, say me how to do, folowing the document is not possible because all picture sizes are not written):
- Keep in MediaInfo the reading of the aspect_ratio tag in the MPEG-2 stream. if MPEG-2 says 16/9, I will show 16/9, and I will not take care of width and height (could be 360, 720, 1280, 1920...)
- Work on the aspect ratio tag in the MPEG-4 stream, which is not yet implemented in MediaInfo, to fix the bug of "Inc" with a XviD movie (because computing I do now is out of the MPEG-4 specifications)

[Inc]

How do you know? Do you have any evidence that they always follow ITU, and not the mpeg-2 specification?
This would make the purpose of FitCD PARanoia etc. useless.

Ok, you do encode your mpeg4s for these SW Player outputs. Like in a case of using a SW Player on a PC or a HTPC as playback device. But what about playing back an original DVD source via SUCH a setup. Both formats would contradict each other (as you already said).

Inc, that is the case for the playback on your analog tv, where it makes sense to use ITU. For playback on a digital tv using a hardware/software dvd player, it doesn't make sense to follow ITU. Most (all?) software players follow the mpeg-2 specification upon playback.

Btw. If I would agree that 720x576 will be played back at real 4:3 means 768x576 by such SW players --> I still can't just apply at a mpeg4 backup of an orig DVD 720x576 stream a PAR/SAR obtained by this formula:
SAR = DAR * display_ horizontal_ size / display_vertical _ size

...cause the DVD source ITSELF isnt 4:3 so I still would have to first crop these 720x576 to 702x576, resizing it back to 720x576 and THEN applying a PAR of 1,666667 ... this would end up in no AR display error but a blurrier picture cause of nonsense inner-upscale-interpolation. Wilbert, do you see the point?. BECAUSE most of our backups to mpeg4 do base on orig DVD sources. If we totally get into doubt of trusting the ITU content of such DVDs, then again ... lets drop FitCD, PARanoia, GripFit and so on ..... and for shure no more refering to such sites like Jukka Aho.

[Kika]

Do you have any evidence that they always follow ITU, and not the mpeg-2 specification?

Existing DVDs? Done measurements? Simply encoded real circles? Plenty of examples on Doom9 - done years ago?
Do you have any evidence for a change in handling the rules by the producers?

In fact, nothing changed, but there are producers who are using generic PAR, that's a pity, but true :(

Mainly because my digital projector show the 720 pixels!
My LCD-TV does not show 720 Pixels, just 704. ;)


For playback on a digital tv using a hardware/software dvd player, it doesn't make sense to follow ITU.

Why? Please tell me why. All TVs have to do a resizing so it does not matter how to resize - they have just to do it the right way.
I don't see any logic in handling a given DAR/PAR different on CRTs and digital devices. On the contrary (and as an example):

A producer follows the ITU and the digital TV handles 720x576 as 16:9 - what's the result? Right, black bars or a (slightly) streched picture.
And what's about all these DVDs with already encoded black bars left and/or right?
On my TV they aren't visible.

[Wilbert]

First, a small correction. The mpeg-2 specification gives a DAR of 3/4 and 9/16. Thus

SAR = 3/4 * 720 / 576 = 0.9375

For clarity, i'm not claiming that dvds are not encoded in a non-ITU compliance way, i'm also not claiming they are. I just don't know.

Existing DVDs? Done measurements? Simply encoded real circles? Plenty of examples on Doom9 - done years ago?
Do you have any evidence for a change in handling the rules by the producers?

In fact, nothing changed, but there are producers who are using generic PAR, that's a pity, but true

I never have seen those examples (meaning existing movie/music dvds). Like i said, i don't know the rules that are used by the majority of the producers.

This would make the purpose of FitCD PARanoia etc. useless.
I think it's great for my analog caps :) No, I don't use it for dvd backups (though that's more a result of laziness).

...cause the DVD source ITSELF isnt 4:3 so I still would have to first crop these 720x576 to 702x576, resizing it back to 720x576 and THEN applying a PAR of 1,666667 ... this would end up in no AR display error but a blurrier picture cause of nonsense inner-upscale-interpolation. Wilbert, do you see the point?
Sorry, I don't understand you here. If the DVD source is not encoded as being ITU compliant, it is 4:3 right?

Why? Please tell me why. All TVs have to do a resizing so it does not matter how to resize - they have just to do it the right way.
I don't see any logic in handling a given DAR/PAR different on CRTs and digital devices.
Well, me neither. I can't help it that the specifications are conflicting.

And what's about all these DVDs with already encoded black bars left and/or right?
On my TV they aren't visible.
Yes, overscan. On digital devices they are visible though. So i'm not sure what your point is here.

[Inc]

I never have seen those examples (meaning existing movie/music dvds). Like i said, i don't know the rules that are used by the majority of the producers.I got here a reference DVD where beside color/luma/audio stuff also a circle within a 720x576 anamorph and nonanamorph is shown.
I used that one for testings earlier. The Result was if resizing these 720x576 to 768x576 the circle ended up still too sqeezed.

2 SAPs of mine and one of a friend do show actually 702x576 or 704x576 px out of the original 720x576 (so resulting out of the common 128/117 PAR usage).

EVEN if a DVD is not mastered ITU compilant. We should not jump on the train by changing an incorrect way to a standard.

BTW. if we cant trust SAPs, then that DVD image example for determining the act. capt.cards window would be useless.

Sorry, I don't understand you here. If the DVD source is not encoded as being ITU compliant, it is 4:3 right?
Yes, but that was not the purpose of my statement.

Lets say we DO accept the circumstancies that common software players do desqueez a common 720x576 using 4:3 and therefore a playback image of 720x576 brought to 768x576.
If its so then (by keeping in mind the DVDs ITU source compilancy) we would first have to crop these 720x576 to 702x576 and resize it back to 720x576. THEN when using a generic par (used by common softwareplayers) the resulted 768x576 out of the 720x576 would be correct.

Conclusion: 720 is tricky. If you want to end up as secure as possible when treating DVDs in a way SAPs do ..then the best would be to crop 720 DVD sources to 704x576 and encode. THEN it doesn't matter WHAT will be used - no matter if SAR/PAR = 128/117 ... or a SAR/PAR = 3/4 * 704 / 576 = 0,9167 ... both ways would end up in almost correct ARs at 768x576.

Yes, overscan. On digital devices they are visible though. So i'm not sure what your point is here.The point is that KIKA tries to explain that DVDs are mostly purposed to be played back by SAPs.
Correct working digital devices wont display an overscan as almost no TV broadcast gots continously clean borders. Especially when commercials do appear. These do change significantly in their borders-size & -position from each commercial to other.
The consumer would suffer very fast from a headache when recognising these.

[mpucoder]

First, a small correction. The mpeg-2 specification gives a DAR of 3/4 and 9/16. Thus

SAR = 3/4 * 720 / 576 = 0.9375
Which is the SAR value to be used for mpeg-1 (code value 8)
If you want to end up as secure as possible when treating DVDs in a way SAPs do ..then the best would be to crop 720 DVD sources to 704x576 and encode. Which is why there is a 704x576 resolution for DVD.
But regardless of whether the width is 704 or 720 the pixel clock of DVD players is still 13.5MHz (ITU 601 compliant). The extra pixels get removed by the blanking pulse.

What your arguing about is the active region, which for PAL is about 702 samples, but for NTSC that is about 711 pixels wide. The difference to NTSC is so small as to be lost in the overscan/alignment/linearity of CRTs.

[Inc]

But regardless of whether the width is 704 or 720 the pixel clock of DVD players is still 13.5MHz (ITU 601 compliant). The extra pixels get removed by the blanking pulse.Right, but I did refer my lines above to both: a SAP and Softwareplayer playback and to obtain "at both" as less AR error as possible.

SAPs do handle the 720 at 13.5Mhz ITU, but as I also figured out, most Softwareplayers (VLC, mplayer etc) do bring 720x576 to 768x576 at playback.

What your arguing about is the active region, which for PAL is about 702 samples, but for NTSC that is about 711 pixels wide.
Ok, but in case of NTSC also here only the inner 702 are needed for a proper 4:3 display --> 702x480 brought to 640x480 --> AR = ok.
So as still at the height not the full NTSC range is given (486) also here 704 would be the way to go also.
Its thee exact middle of 768 and 640 so the compromise between the formats. So in case of digital handling Imho 704xXXX is the most secure choice.

The reasons of 720 are:
Isn't 720 the real width of a 4:3 image? If not, then why are 720 pixels sampled instead of 711 or 702 (or whatever)?

720 pixels are sampled to allow for little deviation from the ideal timing values for blanking and active line lenght in analog signal. In practice, analog video signal - especially if coming from a wobbly home video tape recorder - can never be that precise in timing. It is useful to have a little headroom for digitizing all of the signal even if it is of a bit shoddy quality or otherwise non-standard.

720 pixels are also sampled to make it sure that the signal-to-be-digitized has had the time to slope back to blanking level at the both ends. (This is to avoid nasty overshooting or ringing effects, comparable to the clicks and pops you can hear at the start and end of an audio sample.)

Last but not least, 720 pixels are sampled because a common sampling rate (13.5 MHz) and amount of samples per line (720) makes it easier for the hardware manufactures to design multi-standard digital video equipment.

[Kika]

And to make things more complicated... What we are talking about is analogue signaling, but with digital signals, things are different.
On my TV/DVD-Player-Combination (Loewe Xelos A37/ Denon DVD 2910) it's the following situation:
F-Bas, S-Video, RGB and SDTV-Component: Picture is limited to 704 on PAL and 716(?) on NTSC
HDMI (YCbCr and RGB) and HDTV-Component (also progressive Scan): Picture is shown as is - and that's sometimes terrible. On DVDs, encoded in 720x576/480 with black bars left and/or right, the bars are visible and the picture isn't centered.
Cropped and eencoded to 704x576/480 - no black bars and a centered picture.

Isn't the new digital world fun? ;)

[Inc]

On DVDs, encoded in 720x576/480 with black bars left and/or right, the bars are visible and the picture isn't centered.
Youre right, I mixed that up. digital-->digital.

[Zenitram]

The title of this thread is "How to use MediaInfo.dll 0.7.1.2 in Delphi"... We are a lot far from this title!!! ;-)
(but interressant)

[Amnon82]

I updated the title to 'How to use MediaInfo.dll 0.7.1.2 in Delphi and other developer tools', also my first thread.

[Kurtnoise]

Amnon, I've a question for you : did you try to replace edit components by some listbox or checklistbox ? If yes, does it work for you ?

I mean, if we are look at your example tool, replace edit1.text (edit component where is stored your input file) by a listbox.items.strings or a checklistbox.items.strings...For me this doesn't work properly. I've got no strings return, though my file is opened and the handle is fine.

[Amnon82]

No I didn't. I only compiled a newer version of this.
I'm using AVISynth_C in my projects ...

[danpos]

The title of this thread is "How to use MediaInfo.dll 0.7.1.2 in Delphi"... We are a lot far from this title!!! ;-)
(but interressant)

It's truth and I agree that the discussion is very interesting so far. I've a question that (I guess) is on-topic: did you think about to implement support to AVS scripts through CLI version of MediaInfo ? I think that this would be very usefull feature ... ;)

Cheers,

[Darksoul71]

@danpos:
I've a question that (I guess) is on-topic: did you think about to implement support to AVS scripts through CLI version of MediaInfo ? I think that this would be very usefull feature ...
..esp. for some other project which is currently in development, huh ? :D

-D$

[Zenitram]

It's truth and I agree that the discussion is very interesting so far. I've a question that (I guess) is on-topic: did you think about to implement support to AVS scripts through CLI version of MediaInfo ? I think that this would be very usefull feature ... ;)
This was sometimes requested, but I don't know what you really want with AVS.
Could you explain me what you want from AVS?
For me, AVS is only a script, no data.
So I can look for the source file, and give you information about the source file, or try to parse the script to know the subtitles files, the cropping... What is your needs?

[Darksoul71]

@Zenitram:
I´m not danpos but will try to answer.
In first place you are right: AVS is plainly a text file with no data but in combination with AVISynth.dll you get a "AVI file" with infos that any AVI file has:
- Width
- Height
- FPS
- Frames
- Audiorate
- # of Audio Channels
etc.

So the typical need to use a tool such as MediaInfo CLI is when you "develop" scripts that do not provide a good interface to DLLs, e.g. AutoIt, AHK and need to obtain informations on a video file because you want to encode it. I for one have used a workaround for my "Komprezz"-Script and use the AVS WriteFile function to obtain those infos.

-D$

[Zenitram]

AVS is plainly a text file with no data but in combination with AVISynth.dll you get a "AVI file" with infos that any AVI file has:
OK, if I understand well, you would like to have, for example, the wanted width outputed by AVISynth.dll.
I am not sure to understand all (sorry for my bad english), I prefer to speak with an example, if you have a MPEG-2 file with width=1920 and fps=25, and you have a script with "LanczosResize(1080,720)", you would that MediaInfoCLI give you "width=1080, fps=25"?

[Darksoul71]

Hi Zenitram,

no need to excuse. My french is a lot more rusty than your english and I´m not a native english speaker either :)

Yes, I would prefer if MediaInfoCLI gives me those values either via standardout (console) or outputs a text file.

Example of my need:
I use an avi file as source for encoding, add some resize & denoise via AVISynth and need to find out the duration of the avi file. So MediaInfoCLI could "tell" me "Frames=133345,fps=25" So I can easily calculate the duration in seconds.

[Zenitram]

I use an avi file as source for encoding, add some resize & denoise via AVISynth and need to find out the duration of the avi file. So MediaInfoCLI could "tell" me "Frames=133345,fps=25" So I can easily calculate the duration in seconds.
But: MediaInfo can already give you this kind of information, if you give to it the AVI file name, do you need I look for the AVI file name in the AVS file, and give you information about the AVI file (frames and fps will not be modified by resize and denoise)?

[Darksoul71]

Agreed, my example left out a few other things I do such as "cutting" the video. Thus the AVI doesn´t reveal the final length of the edited video.

This is a part of infos I extract from an AVS file:

23:26:49 >>Width = 480
23:26:49 >>Height = 576
23:26:49 >>Frames = 36922
23:26:49 >>Framerate = 25.000000 FPS
23:26:49 >>Audiochannels = 2
23:26:49 >>Samplerate = 32000 Hz


My FileWrite Stuff I currently use in AVISynth looks like this:

filename ="E:\__KomprezzQMatOp2MPEG__\movie_info.txt"
WriteFileIf(filename, "current_frame == 0","Width")
WriteFileIf(filename, "current_frame == 0","Height")
WriteFileIf(filename, "current_frame == 0","Framerate")
WriteFileIf(filename, "current_frame == 0","Framecount")
WriteFileIf(filename, "current_frame == 0","Audiochannels")
WriteFileIf(filename, "current_frame == 0","Audiorate")


Do you get a better understanding ?

[Zenitram]

Do you get a better understanding ? Nearly ;-).
I need you send me some example files.
I don't promise to work on it now, but I will have information, and this is not impossible that MediaInfo will be able to support it.
You can send them to zen@mediaarea.net

[Darksoul71]

Examplefiles of my AVISynth scripts ?
I could post them here.
Or do you mean example files of the AVI material I encode ?

[Zenitram]

Examplefiles of my AVISynth scripts ?
I could post them here.
Or do you mean example files of the AVI material I encode ?
You can post your AVISynth scripts here, but I thougth that it is better to discuss by email about them... And this will be simplier for me to store them!

[Amnon82]

@ Kurtnoise13:

Amnon, I've a question for you : did you try to replace edit components by some listbox or checklistbox ? If yes, does it work for you ?

I mean, if we are look at your example tool, replace edit1.text (edit component where is stored your input file) by a listbox.items.strings or a checklistbox.items.strings...For me this doesn't work properly. I've got no strings return, though my file is opened and the handle is fine.

Garfield send me a compile of him. Maybe you ment this:

Example GUI with Combobox - by Garfield (http://home.arcor.de/autoq2_amsoft/files/sources/ExampleGUI_Source.7z)

[Kurtnoise]

In fact, I solved my problem. :) MediaInfo.dll needs the whole path for the files and I had used only the FileName with ExtractFileName(...). That's why it didn't work properly.

but thanks anyway...

[Amnon82]

K. Now we know what your problem was ...