Log in

View Full Version : MediaInfo(Lib) 0.7 - Reading information about media files


Pages : 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Zenitram
9th July 2009, 07:31
ok, so for the life of me I never see the the 'Original Display Aspect Ratio' displayed in any view.
This kind of files are not so common...
Any ideas on what I'm doing wrong?

Are you sure you have different aspect ratio?
If yes, provide a sample.

jmnk
9th July 2009, 17:47
This kind of files are not so common...


Are you sure you have different aspect ratio?
If yes, provide a sample.
I can't now, later today. Perhaps the muxers are messing things up. Essentially I encoded a short x264 into raw stream, with set sar flag in megui. SAR was like 32:27. the original video was 720x358. Than I took that x264 stream and muxed it into mkv using mkvtoolnix, and specified Display Aspect Ratio like 3.00 (purpousely too stretched) so it is definitely different that what stream signaling is. As per mkvtoolnix manual it is now supposed to preserve stream signaling. So I would expect to see:
Width : 720 pixels
Height : 358 pixels
Display aspect ratio : 3.00
Original display aspect ratio : 16/9

but I definitely did not see 'Original display aspect ratio' anywhere. Maybe mkvtoolnix did remove the stream signaling? Do you know of any tool that for sure --does not-- remove signaling when muxing?

Zenitram
9th July 2009, 18:03
So I would expect to see:
Width : 720 pixels
Height : 358 pixels
Display aspect ratio : 3.00
Original display aspect ratio : 16/9

Correct.

but I definitely did not see 'Original display aspect ratio' anywhere. Maybe mkvtoolnix did remove the stream signaling? Do you know of any tool that for sure --does not-- remove signaling when muxing?

No idea! I give info, but do not create it.
Wehn you send a file, I say if the signaling is present and if there is a problem in MediaInfo.

jmnk
10th July 2009, 07:06
Correct.



No idea! I give info, but do not create it.
Wehn you send a file, I say if the signaling is present and if there is a problem in MediaInfo.
@Zenitram
I've uploaded two short video clips.
First is a x264 stream with no container. I've encoded 720X358 resolution, with Megui calculated flag 1969:1620. This results in Display Aspect Ratio of 2.44, which is correctly reported as such by mediainfo. Although I would expect mediainfo to say that 'original display aspect ratio' as you indicated that this is how stream level ratio is identified.
here's the link: http://uploading.com/files/JRHMFOVZ/test.264.html

The other file is the very same stream muxed into mkv file, where I specified mkvtoolnix display aspect ratio of 3.00. mediainfo does say that Display Aspect Ratio is 3.00 - so that is good. But it does not say anything about Original Display Aspect Ratio.
that file is here:http://uploading.com/files/KE5OZL7V/test_3.00.mkv.html

SeeMoreDigital
10th July 2009, 09:25
I'e encoded 720X358 resolution, with Megui calculated flag 1969:1620. This results in Display Aspect Ratio of 2.44, which is correctly reported as such by mediainfo. Although I would expect mediainfo to say that 'original display aspect ratio' as you indicated that this is how stream level ratio is identified. Just so as you know. Creating 4 digit values is pretty much pointless. There's no greater accuracy to be obtained over a 3 digit value.


Cheers

Zenitram
10th July 2009, 10:07
First is a x264 stream with no container. I've encoded 720X358 resolution, with Megui calculated flag 1969:1620. This results in Display Aspect Ratio of 2.44, which is correctly reported as such by mediainfo. Although I would expect mediainfo to say that 'original display aspect ratio' as you indicated that this is how stream level ratio is identified.

1/ Orignal DAR is displayed only if it is different from DAR.
2/ What is the Original DAR? None. there is only a DAR (from the raw stream). Orignal DAR is only set when 2 values are possible. You can NOT extract a raw stream from a raw stream, there is not original DAR...


The other file is the very same stream muxed into mkv file, where I specified mkvtoolnix display aspect ratio of 3.00. mediainfo does say that Display Aspect Ratio is 3.00 - so that is good. But it does not say anything about Original Display Aspect Ratio.

OK, problem in my code for MKV.
Corrected: development snapshot is available at:
http://sourceforge.net/projects/mediainfo/files/
(development snapshot part, at least 20090710 version)

Width : 720 pixels
Height : 358 pixels
Display aspect ratio : 3.000
Original display aspect ratio : 2.444

Just so as you know. Creating 4 digit values is pretty much pointless. There's no greater accuracy to be obtained over a 3 digit value

You're right for MPEG-4 Visual (par_width/par_height are coded with 8 bits, precision is ~0.004, between 2 and 3 digits)
You're wrong for AVC (sar_width/sar_height are coded with 16 bits, precision is ~0.00002, between 5 and 6 digits)
And here, this is AVC, the file really contains sar_width=1969 and sar_height=1620.
Not very useful, but if you want to be precise, you can.

jmnk
10th July 2009, 17:11
Just so as you know. Creating 4 digit values is pretty much pointless. There's no greater accuracy to be obtained over a 3 digit value.


Cheers
thanks for the comment. I agree 4 digit is pointless. I did not put it in myself. MeGUI did. In fact, see this question http://forum.doom9.org/showthread.php?p=1303776#post1303776 where I ask why MeGUI does that. Nobody with knowledge addressed that question yet.

jmnk
10th July 2009, 17:13
1/ Orignal DAR is displayed only if it is different from DAR.
2/ What is the Original DAR? None. there is only a DAR (from the raw stream). Orignal DAR is only set when 2 values are possible. You can NOT extract a raw stream from a raw stream, there is not original DAR... I see. Makes sense once you explain it. All good here.



OK, problem in my code for MKV.
Corrected: development snapshot is available at:
http://sourceforge.net/projects/mediainfo/files/
(development snapshot part, at least 20090710 version)

Width : 720 pixels
Height : 358 pixels
Display aspect ratio : 3.000
Original display aspect ratio : 2.444

Thanks for the fix. I'll try later today. Since you mentioned 'problem in my code for MKV' - I'm pretty sure 'Original display aspect ratio' was not displayed for mp4 files either, have you looked into that too?

Zenitram
10th July 2009, 17:29
Thanks for the fix. I'll try later today. Since you mentioned 'problem in my code for MKV' - I'm pretty sure 'Original display aspect ratio' was not displayed for mp4 files either, have you looked into that too?

I have some mp4 files with Original DAR.
Same method as before: a sample.

jmnk
10th July 2009, 18:58
I have some mp4 files with Original DAR.
Same method as before: a sample.
can have sample later today. If you want it right now, and have YAMB, you can take the x264 sample I posted earlier and mux it with YAMB to mp4 file while specifying Pixel Aspect Ratio in YAMB (and set it to something different that x264 SAR stream is). That's what my sample would be. Although for the life of me I can't figure out what YAMB Pixel Aspect Ratio is supposed to do, and my question on YAMB thread remains unanswered. But I'm assuming it does 'something' so there should be container level and stream level signaling in the resulting file.
Your mp4 samples with Original DAR - what do you use to get mp4 file? YAMB? mp4box command line? MeGUI muxer? Else? Maybe my YAMB does not behave as expected (I use the latest version as posted on YAMB thread).

jmnk
11th July 2009, 06:13
I have some mp4 files with Original DAR.
Same method as before: a sample.
Here's an mp4 file that does not show 'Original display aspect ratio' (even with the latest 07102009 version of mediainfo)
http://uploading.com/files/BL0AE4SG/test-yamb4by3NTSC.mp4.html

SeeMoreDigital
11th July 2009, 11:02
Here's an mp4 file that does not show 'Original display aspect ratio' (even with the latest 07102009 version of mediainfo)
http://uploading.com/files/BL0AE4SG/test-yamb4by3NTSC.mp4.htmlI don't undertand... What is the "original display aspect ratio"?

Zenitram
11th July 2009, 11:40
If you want it right now, and have YAMB, you can take the x264 sample I posted earlier and mux it with YAMB to mp4 file while specifying Pixel Aspect Ratio in YAMB

I always prefer to have real sample from user, to have the same base of discussion

what do you use to get mp4 file? YAMB? mp4box command line? MeGUI muxer? Else?

None.
I analyse, I don't create.

Maybe my YAMB does not behave as expected (I use the latest version as posted on YAMB thread).

This is the reason I prefer to have your file.

Here's an mp4 file that does not show 'Original display aspect ratio' (even with the latest 07102009 version of mediainfo)

Deleted before I can get it :( (stupid!)

jmnk
11th July 2009, 17:03
I always prefer to have real sample from user, to have the same base of discussion



None.
I analyse, I don't create.



This is the reason I prefer to have your file.



Deleted before I can get it :( (stupid!)

@Zenitram: try again on mediafire
http://www.mediafire.com/file/hdgwu0mxwen/test-yamb4by3NTSC.mp4

Zenitram
11th July 2009, 17:13
@Zenitram: try again on mediafire
http://www.mediafire.com/file/hdgwu0mxwen/test-yamb4by3NTSC.mp4

Pixel Aspect Ratio box from MP4 (pasp box in the stsd box, hSpacing and vSpacing parts) is set to 10/11.
Pixel Aspect Ratio indice from AVC (aspect_ratio_idc in the VUI in the SQS) is set to 3 (--> set to 10/11)

--> DAR is 1.828 for both container and raw stream (rounded to 16/9)

This is normal, there is no Original DAR displayed because it is exactly the same as container DAR.

jmnk
11th July 2009, 19:15
Pixel Aspect Ratio box from MP4 (pasp box in the stsd box, hSpacing and vSpacing parts) is set to 10/11.
Pixel Aspect Ratio indice from AVC (aspect_ratio_idc in the VUI in the SQS) is set to 3 (--> set to 10/11)

--> DAR is 1.828 for both container and raw stream (rounded to 16/9)

This is normal, there is no Original DAR displayed because it is exactly the same as container DAR.
thanks for looking into it. I'm even more intrigued now.
To remove any possibility of getting wrong results because of non mod16 resolution I did one more test. I use MPC player to see how file plays.
I take NTSC sample, flagged as 16/9 DAR, no cropping, no resizing of any kind. So I'm encoding 720x480 stream. I encode using MeGUI to raw x264 stream. In MeGUI I select 'clever anamorphic..', but no resize, no cropping.
MeGUI calculates SAR = 96:79 (I do not know exactly why, but that is another story. To me it should be 32:27). Anyway, the resulting file plays at around 16:9 DAR, and mediainfo reports it as such (for all three x264 stream. mp4, mkv): 'Display aspect ratio : 16/9' There's no 'Original Display Aspect Ratio'. So far so good.
So now I take x264 and mux it into another mp4 using YAMB. I specify Pixel Aspect Ratio in YAMB as 4:3 NTSC (which is wrong, purpously). It appears that this results in YAMB passing PAR=10:11 to mp4box - which is correct. The resulting file plays at 720:528, which is almost 4:3 ratio, which is correct (I think the reason it is not exactly correct starts with MeGUI using ITU aspect ratios, but not suggesting that I should crop 720 to 704 - but that is not really related to mediainfo). Mediainfo shows only 'Display aspect ratio : 4/3' - which could be correct. That means that YAMB either:
- removed stream level signaling from x264 stream (but can you do that? Shouldn't mediainfo say 'Original Display Aspect Ratio: unspecified', or assume the signaling is 1:1 and than say 'Original Display Aspect Ratio: 1/1', or
- replace stream level signaling to match container level signaling.
fair enough.
So now I unmux that mp4 file with YAMB to get the raw x264 stream back. That unmuxed file plays at 720x480 resolution - which would indicate that stream level signaling is now set to 1:1 (which would indicate that during original muxing YAMB removes stream level signaling). But mediainfo says 'Display aspect ratio : 4/3' - which would indicate that there's stream level signaling present. So why does it play at 720x480 as if no signaling was present?
the files are here (there are three in zipped zrchived: x264, muxed mp4, and unmuxed mp4 back to raw stream).
http://www.mediafire.com/file/gz0mdmknqtm/test.zip

Keiyakusha
11th July 2009, 19:26
So now I take x264 and mux it into another mp4 using YAMB. I specify Pixel Aspect Ratio in YAMB as 4:3 NTSC (which is wrong, purpously).
Why you need to override aspect ratio? Afaik you should leave it blank. Also if you will mux to mp4 using Megui - then you will see that it doesn't put any PAR overrides to commandline.

jmnk
11th July 2009, 19:31
Why you need to override aspect ratio? Afaik you should leave it blank. Also if you will mux to mp4 using Megui - then you will see that it doesn't put any PAR overrides to commandline.
@Keiyakusha - thanks for comments. We are having theoretical discussion here with Zenitram, so please do not ask what is the practical reason. We just want to figure out what is going on.

Zenitram
11th July 2009, 20:09
- replace stream level signaling to match container level signaling.

This is this method.
Trace from my debug tool (not yet released, but I plan to release it ;-) ):

test720by480_MeGUIsar96by79.264
(...)
00000014 vui_parameters_present_flag (18 bytes)
00000014 vui_parameters_present_flag: Yes
00000014 aspect_ratio_info_present_flag (6 bytes)
00000014 aspect_ratio_info_present_flag: Yes
00000014 aspect_ratio_idc: FF (255)
00000015 sar_width: 60 (96)
00000017 sar_height: 4F (79)
00000019 overscan_info_present_flag: No
(...)

test720by480_MeGUIsar96by79_yambPAR4by3NTSC_unmuxedBack.h264 (exactly the same as in the mp4 file) :
(...)
0000000E vui_parameters_present_flag (14 bytes)
0000000E vui_parameters_present_flag: Yes
0000000E aspect_ratio_info_present_flag (2 bytes)
0000000E aspect_ratio_info_present_flag: Yes
0000000E aspect_ratio_idc: 3 (3) - 0.909
0000000F overscan_info_present_flag: No
(...)

Note: this is the only thing modified in the SQS.
Complete traces are attached.

But mediainfo says 'Display aspect ratio : 4/3' - which would indicate that there's stream level signaling present. So why does it play at 720x480 as if no signaling was present?

No idea. With VLC, it plays as 4/3 file (720*540 squaree pixels equivalent), normal the signaling is present wiht 0.909 SAR.
Your player is wrong if it does not play as 4/3.

Conlcusion : raw stream SAR is modified (not removed. Modified) during the muxing to comply with the container SAR, and is kept during the demux (the original SAR is not registred in the container and/or the raw stream).


Shouldn't mediainfo say 'Original Display Aspect Ratio: unspecified',

Currently, nothing is displayed (as if AR are same).
This was never requested by users.
What would be the need of such an indication for user? Same SAR or no SAR in the raw stream, the result is the same with all player I know.

Why you need to override aspect ratio? Afaik you should leave it blank. Also if you will mux to mp4 using Megui - then you will see that it doesn't put any PAR overrides to commandline.

This kind of files exist on the web.
There is this option in the muxers.
Why? No idea. This is not the (my) problem.
The problem is to detect such files (at least for me, developer of a tools with users wanting to detect this problem), so we need to create them in order to have samples, and to be sure about the origin of theses samples.
And as jmnk said, this is theoretical discussion (but about a real life problem)

Atak_Snajpera
21st July 2009, 16:42
General
Complete name : C:\Users\Dawidos\Desktop\Test split 4.mkv
Format : Matroska
File size : 33.9 MiB
Duration : 56s 724ms
Overall bit rate : 5 019 Kbps
Movie name : Test split 4
Encoded date : UTC 2009-07-21 15:38:26
Writing application : mkvmerge v2.9.0 ('Moanin'') built on May 22 2009 17:46:31
Writing library : libebml v0.7.7 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Muxing mode : Container profile=Unknown@4.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 56s 666ms
Bit rate : 3 409 Kbps
Width : 1 280 pixels
Height : 534 pixels
Display aspect ratio : 2.35
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.208
Stream size : 23.0 MiB (68%)

Shouldn't be 2.40 ? (1280/534 =~2.397...)

Zenitram
21st July 2009, 20:00
Shouldn't be 2.40 ? (1280/534 =~2.397...)

This field uses well known values.
Exact value is available with "advanced mode", the displayed field is what is the more coherent for the user.
2.35 is typical for movies.

Edit: oups, maybe a problem, Wikipedia says:
2.35: 35 mm anamorphic prior to 1970
2.39: 35 mm anamorphic from 1970 onwards
and "The anamorphic standard has subtly changed so that modern anamorphic productions are actually 2.39, but often referred to as 2.35 anyway, due to old convention."
--> I will add a "2.39" well known value.

Atak_Snajpera
21st July 2009, 20:14
-> I will add a "2.39" well known value.

This field uses well known values.
I would prefer real aspect ratio rounded to 2 digits (2.40). Blu-Ray movies use 2.40:1 instead of 2.39:1.

smok3
21st July 2009, 20:24
test720by480_MeGUIsar96by79.264
(...)
00000014 vui_parameters_present_flag (18 bytes)
00000014 vui_parameters_present_flag: Yes
00000014 aspect_ratio_info_present_flag (6 bytes)
00000014 aspect_ratio_info_present_flag: Yes
00000014 aspect_ratio_idc: FF (255)
00000015 sar_width: 60 (96)
00000017 sar_height: 4F (79)
00000019 overscan_info_present_flag: No
(...)

test720by480_MeGUIsar96by79_yambPAR4by3NTSC_unmuxedBack.h264 (exactly the same as in the mp4 file) :
(...)
0000000E vui_parameters_present_flag (14 bytes)
0000000E vui_parameters_present_flag: Yes
0000000E aspect_ratio_info_present_flag (2 bytes)
0000000E aspect_ratio_info_present_flag: Yes
0000000E aspect_ratio_idc: 3 (3) - 0.909
0000000F overscan_info_present_flag: No
(...)

ok, so eSAR turned into SAR, nothing really unexpected, only slight confusion about not being told from yamb that there is indeed an eSAR value allready present... (aspect_ratio_idc = 255)

Zenitram: why exactly do you think there is a need to print DAR values? (and even worse: known ones), imho it would be better to get the exact SAR/PAR and be done with it (maybe with DAR as a second display filed, like so: DAR : exactly 2.38773, approx known/wikipedia value 2.40)

p.s. probably i should start with: Zenitram, great tool mediainfo is, i use it daily! (the cli version)

Zenitram
21st July 2009, 20:28
I would prefer real aspect ratio rounded to 2 digits. Blu-Ray movies use 2.40:1 instead of 2.39:1.

From Wikipedia:
The 2.39:1 ratio is commonly labeled 2.40:1, e.g., in the American Society of Cinematographers' American Cinematographer Manual,

but in the discussion page:
The exact frame from a scope element is 2.34 and change, rounded to 2.35:1. The SMPTE projection aperture is 2.39 and change, rounded to 2.40:1

I try to conform to the reality, not what the biggest say (for example, I refuse too to call DivX all MPEG-4 Visual ASP streams, DivX is only an encoder...)
So... what is the real DAR? 2.39 or 2.40? Difficult to say.
I googled a bit, I foud this text "In the seventies, the 2.35:1 aspect ratio was projected a little narrower to hide the splice marks visible on the reels. So it became 2.39:1 (actually closer to 2.40:1)"

--> OK, 2.40 seems to be a good display.

Zenitram
21st July 2009, 20:34
Zentram: why exactly do you think there is a need to print DAR values? (and even worse: known ones), imho it would be better to get the exact SAR or PAR and be done with it (maybe with DAR as a second display filed, like so: DAR : exactly 2.38773, approx known value 2.39)

"classic" formats were limited to 16*16 blocks, so AR was never precise (this is a bit less true with AVC, cropping in the stream is possible) + I try to display what is the industry standard.
--> Well known values are are more useful for people (is it interessant to see 1.81 badly encoded instead of 16/9. I don't think so), I display it. real aspect ratio is still available (custom template)

smok3
21st July 2009, 20:38
what i actually do sometimes (but thats just me) is to crop to closest mod16 resolution and use appropriate SAR with encoding (that will preserve the correct shapes, round will be round, but will indeed kill the original DAR, which is not really that interesting anyway (again thats only my opinion)).
edit: i need to learn how to do those custom templates.

SeeMoreDigital
21st July 2009, 20:45
Here's my 2 cents...

I'm of the opinion that the DAR should be calculated from the encodes resolution. And rounded to the closest two point (ie: x.xx) value.

The movie aspect ratio very rarely complies exactly to 2.35, 2.39, 2.40 etc, etc...

Zenitram
21st July 2009, 20:55
It is calculated from encodes resolution (this is the only one I have ;-) ).
but my "classic" users are more interested in what is the "industry" DAR (ie: is it 4/3? 16/9? 2.40? as with the original blu-ray support), not the precise DAR (they don't car of 1.81 DAR, this is not very sexy to read) if a DAR is near from a known value (if this is 1.95, I display 1.95 ;-) ).

I try to make most people happy, but I can't make everyone happy when they have opposite wishes.

For making everyone happy, exact DAR is provided but not displayed by default, and I provide a template system, not currently sexy enough (laking of customization for tree view for example), but I work on it.

I thought about something like "1.81 (16/9)" as default display, but this provides a lot of information, too much numbers, screen may have too much data (there is already too much data in theses screens...), too confusing for "classic" users (don't forget: I don't have only experts as in Doom9 forums, I have a lot of newbees too).

SeeMoreDigital
21st July 2009, 21:12
One thing that puzzles me is why you offer so many "view" options (ie: Basic, Sheet, Tree, Text, HTML and Custom). Do you really need to offer all these options?

Zenitram
21st July 2009, 21:29
One thing that puzzles me is why you offer so many "view" options (ie: Basic, Sheet, Tree, Text, HTML and Custom). Do you really need to offer all these options?

Which view do you like? whatever is your reply, your neighbour would reply another view.
If I remove a view (I already tried!), I have complains from users who were using this view.

Historicly, there were only one view: Tree view.
some times after, users were wanting copy/paste option --> Text view
some times after, users were wanting a "better" display, copy/paste option for website --> HTML view
some times after, user were wanting their cutom view, with templates --> Custom view
some times after, AVIcodec was abandonned, and a link to MediaInfo was made, users from AVIcodec requested the same view "as before" --> Sheet view
some times after, users were complaing about too complex views, too much data whatever is the selected view --> Easy view (default, I have a lot of newbees).

No, they were not the same users... So each view is for each user. Each user can select its best view and remove all menus (top and left menu), so a MediaInfo lite (not made by me) is a bit strange for me: it may be done by setting Text view as default, unchecking menu and toolbar display option ;-).
I have a lot of requests for other kind of view, but I don't create them, this is too much... The current count of view is for me the best count between a simple interface and users requests.

My goal is to be good for all users, and users are not the same.
I have the same problem with fields: If I listen everybody, 10x the count of displayed fields would be displayed, never the same, awful! I try to select the more interessant, and let the others available for templates, I don't remove them.

SeeMoreDigital
21st July 2009, 22:09
How about offering two selectivity options. Say, "Basic" and "Expert"?

With the "Basic" version offering all the "view" options. And the "Expert" version offering only the "Text" option...

SeeMoreDigital
21st August 2009, 12:24
Hi Jerome,

I've been experimenting with creating chapters in MKA files and have noticed that although MediaPlayer Classic HC is able to display the chapter information correctly: -

http://i27.tinypic.com/2w34brm.png

The chapter information MediaInfo provides is very different: -

http://i25.tinypic.com/25usdbo.png

Is it a bug or something I'm doing wrong?


Cheers

Zenitram
21st August 2009, 16:31
Is it a bug or something I'm doing wrong?

This is undoubtly a bug (duration of 59 hours!), please provide a sample (only the "header", menu debug from the GUI, is enough if you don't want to send the whole file)

SeeMoreDigital
21st August 2009, 16:57
Thanks... Here you go: -

http://www.one.seemoredigital.net/Downloads/Header_Debug.zip

EDIT: Just so as you know, the chapter data for .MP4 files looks okay: -

http://i32.tinypic.com/2ey9gzc.png


Cheers

Mangix
21st August 2009, 20:48
small OT: what's the difference between creating an mka album with chapters instead of creating an aac file with an embedded cuesheet?

SeeMoreDigital
21st August 2009, 20:52
small OT: what's the difference between creating an mka album with chapters instead of creating an aac file with an embedded cuesheet?Please confirm. What container is the AAC stream and embedded cue sheet in?

Mangix
21st August 2009, 22:03
my apologies. the regular mp4

SeeMoreDigital
21st August 2009, 22:06
my apologies. the regular mp4As far as I'm aware the .MP4 container does not support "embedded" cue sheets!

Mangix
22nd August 2009, 20:35
my bad again. it seems mp4 doesn't support cuesheets like you said. But it does at least support chapters. should be good enough in most cases.

vlada
1st September 2009, 08:50
Hi,

I have a VOB file which MediaInfo 0.7.20 reports as 16:9. I have an old version 0.7.7 which reports it as 4:3. The correct AR is 4:3 (according to picture) and also MPC-HC plays it as 4:3. On the other side VLC plays it as 16:9. The file comes from a Panasonic DVD recorder. Do you have any idea what might be wrong with this file?

Zenitram
1st September 2009, 08:52
I have a VOB file which MediaInfo 0.7.20 reports as 16:9. I have an old version 0.7.7 which reports it as 4:3. The correct AR is 4:3 (according to picture) and also MPC-HC plays it as 4:3. On the other side VLC plays it as 16:9. The file comes from a Panasonic DVD recorder. Do you have any idea what might be wrong with this file?

I need a small part (few seconds) of the file in order to say which software is right.

vlada
1st September 2009, 09:59
Here is a 1MB sample: http://www.sendspace.com/file/2obf4b

SeeMoreDigital
1st September 2009, 10:30
The MPEG-2 streams "Sequence Display Extension" horizontal size (Display Size in DGIndex) is set to 540 pixels, not 720 :scared:

Zenitram
1st September 2009, 11:06
The MPEG-2 streams "Sequence Display Extension" horizontal size (Display Size in DGIndex) is set to 540 pixels, not 720 :scared:

Yes, problem is from this ;-)

If sequence_display_extension() is present (it is in this sample), PAR is based on it: 4:3 AR for 540*576 pixel.
The real file is 720*576, do AR is streched to 4:3 * 720 / 540 = 16:9.

DAR displayed depends of the decoder, specification say it can do what it wants:
- cut the movie and display 4:3 with 540 pixels
- not cut and display 16:9 with 720 pixels

If your movie is complete (720 pixels wide) and displayed 4:3 by your decoder, your decoder is wrong.
If your movie is 4:3 with 720 pixel in reality, your encoder is wrong (it should not put 540 as displayed width).

In the latests releases, MediaInfo handles sequence_display_extension() (it wasn't before), this is the reason your files is analyzed differently now. In reality, I think the encoder is wrong if you say the real DAr is 4:3 with 720 pixels wide...
Two many options in MPEG-2 Video, DAR calculation is difficult...

Note: MPC (normal) plays it as 16:9 too. PowerDVD plays is as 4:3. Crazy.

vlada
1st September 2009, 12:22
Thanks a lot guys for your analysis. It is really wired. The movie is full 720x576 and should be 4:3.

Btw. how do you get the value of sequence_display_extension? I would like to check if other files from the recorder have the same problem.

Zenitram
1st September 2009, 12:26
Btw. how do you get the value of sequence_display_extension? I would like to check if other files from the recorder have the same problem.

Not available in MediaInfo (too many values if I display all for all formats...).
SeeMoreDigital gave the solution with DGIndex

Zenitram
4th September 2009, 17:00
I've been experimenting with creating chapters in MKA files and have noticed that although MediaPlayer Classic HC is able to display the chapter information correctly

MediaInfo 0.7.21 is released, and your bug is corrected.

SeeMoreDigital
4th September 2009, 17:13
MediaInfo 0.7.21 is released, and your bug is corrected.I'll give it a go right now... Thanks mate :)

vlada
8th September 2009, 08:41
Hi,

I have another video with strange (inconsistent) AR information. This time it is DV AVI. MediaInfo reports this:

Display aspect ratio : 5:4
Original display aspect ratio : 16:9


What does this mean? The video should be 16:9 (according to picture). Do you have any explanation for this? I'm asking just out of curiosity.

Zenitram
8th September 2009, 08:51
Display aspect ratio : 5:4
Original display aspect ratio : 16:9


What does this mean?

"Display aspect ratio" is the DAR from the container (AVI in your case, but surprising, see below)
"Original display aspect ratio" is the DAR from the raw stream (DV in your case).
This makes more sense in MKV or MP4, container may adapt the raw stream, but not classic in AVI.

The video should be 16:9 (according to picture). Do you have any explanation for this? I'm asking just out of curiosity.

I am interested in having at least the "header" of the file (GUI: menu "debug", "create a header file", because there is usualy no DAR in an AVI, so the DAR from DV should be the normal DAR.