MediaInfo(Lib) 0.7 - Reading information about media files

[vlada]

The header is here (http://www.mediafire.com/?ldzzysmypm8).

[Zenitram]

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

So... This is a bug from me, DV in AVI is a bit difficult to handle.
AR is 16:9, always.
You can check the latest development snapshot:
http://sourceforge.net/projects/mediainfo/files/zzz_Development%20snapshots/
(at least version 20090908)

[SeeMoreDigital]

"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.This is too confusing...

If the input source has a frame size (or resolution) of say, 720x576 pixels then yes, the lowest denomination of 720/576 is 5/4. However, this should not be referred to as DAR. It should be referred to as FAR, ie: Frame Aspect Ratio.

DAR should only refer to the shape of the output displayed image... and nothing else.


Cheers all

[Zenitram]

DAR should only refer to the shape of the output displayed image... and nothing else.

It does. Only the output displayed image. "5/4" in the vlada file was an error, I corrected it.

2 DAR values are requested by users, to be more precise:
"Display aspect ratio" is the DAR from the container if the player knows how to read the DAR from the container (all players don't support this optional feature).
"Original display aspect ratio" is the DAR from the raw stream, if you demux it or if the container DAR setting is removed, AND if it is different than the container DAR.

Both values are useful for some users. When there is a difference between theses 2 values, the file may be considered "Somebody has played with DAR, there may be a problem with DAR, be careful".
And some people play with DAR settings in the container...

[vlada]

Zenitram> Many thanks for the very quick fix!

[SeeMoreDigital]

"Original display aspect ratio" is the DAR from the raw stream, if you demux it or if the container DAR setting is removed, AND if it is different than the container DAR.And it is this "terminology" that should be changed to FAR, ie: Frame Aspect Ratio!

[Zenitram]

And it is this "terminology" that should be changed to FAR, ie: Frame Aspect Ratio!

Googling gives
http://help.adobe.com/en_US/AfterEffects/9.0/WS3878526689cb91655866c1103906c6dea-7f3aa.html
"Frame aspect ratio (sometimes called image aspect ratio or IAR) is the ratio of width to height of the image frame."
--> No indications about if it is from raw stream or container.

I saw avinaptic speaking of Frame Aspect Ratio.
--> is there somewhere some documentation about FAR? Other tools?


I am not against changing terminology, but I have another problem: how would you call Original PAR (if Original DAR is different, Original PAR is different too...)

I have an example:
Width : 720 pixels
Height : 576 pixels
Pixel aspect ratio : 1.422
Original pixel aspect ratio : 1.000
Display aspect ratio : 16:9
Original display aspect ratio : 5:4

How would you name "Original pixel aspect ratio" field?
I may change:
Pixel aspect ratio : 1.422
??? : 1.000
Display aspect ratio : 16:9
Frame aspect ratio : 5:4

[SeeMoreDigital]

Googling gives
http://help.adobe.com/en_US/AfterEffects/9.0/WS3878526689cb91655866c1103906c6dea-7f3aa.html
"Frame aspect ratio (sometimes called image aspect ratio or IAR) is the ratio of width to height of the image frame."
--> No indications about if it is from raw stream or container.

I saw avinaptic speaking of Frame Aspect Ratio.
--> is there somewhere some documentation about FAR? Other tools? The logic behind using the term "Frame Aspect Ratio" comes from the understanding that just as with film, video consistently uses the word "frames". Such as: frame rate, frame frequency, frame speed, frames per second, interlaced frame, progressive frame. Along with other expressions such as: frame grab, frame store, frame capture, frame serve, frame editor, etc, etc. Sufficed to say, everybody knows what a "frame" is.

Given this to be the case it "follows" that people should also understand what is meant by: frame height, frame width, frame dimensions and/or frame size. So when you know a video frames height and width you can work out the video frames aspect ratio (FAR).

http://i26.tinypic.com/nynug.png

http://i28.tinypic.com/2ce2nhj.png


Cheers

EDITED: To hopefully satisfy jmnk's linguistic requirements...

[Zenitram]

you can work out the video frames aspect ratio (FAR).

OK, I will change terminology for next version.
Thanks for your advice.

[jmnk]

OK, I will change terminology for next version.
Thanks for your advice.

Not that one's opinion is more valuable than others but I would suggest at least a tiny bit of research and/or poll before changing the label. In particular the argument "[...] it is safe to assume people should also understand what is meant by" is just flawed. You know what happens when you assume.....

[Brazil2]

Some multichannel sound samples can be found in this post:
http://forum.doom9.org/showthread.php?p=1322796#post1322796

For the TrueHD sample MediaInfo (0.7.21) detects only 6 channels:
Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Format profile : TrueHD
Duration : 1mn 34s
Bit rate mode : Variable
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Stream size : 7.21 MiB (4%)

For the E-AC-3 sample MediaInfo detects only 5 channels:
Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : E-AC-3
Format/Info : Audio Coding 3
Duration : 1mn 34s
Bit rate mode : Constant
Bit rate : 1 024 Kbps
Channel(s) : 5 channels
Sampling rate : 48.0 KHz
Stream size : 11.5 MiB (9%)

But eac3to detects all of the channels and extracts/converts them correctly to WAVs. Example with the TrueHD sample:
M2TS, 1 video track, 1 audio track, 0:01:34
1: h264/AVC, 1080i60 /1.001 (16:9)
2: TrueHD/AC3, 7.1 channels, 48khz
[a02] Extracting audio track number 2...
[a02] Extracting TrueHD stream...

However the detection of channels is correct for the DTS-HD HR sample.
I haven't downloaded the 241 MB LPCM 7.1 sample so maybe it's worth to check this one as well.


And also it seems that MediaInfo is parsing the whole M2TS file before displaying the results which can take a while in case of large files. I think it was not like that in older versions.

[Zenitram]

For the TrueHD sample MediaInfo (0.7.21) detects only 6 channels:

Unfortunatly, I don't know the format (the bitstream details) of HD part from AC-3, if someone has specifications...
VLC now supports more AC3 stuff, I will try to look on its source code.

For the E-AC-3 sample MediaInfo detects only 5 channels:

This one is more in the "bug" section. it should be easier to correct.

However the detection of channels is correct for the DTS-HD HR sample.

Thanks to eac3to developper, he helped me on this part!
If I don't succeed to find some useful code in VLC, I will try to contact him again for AC3 stuff.


And also it seems that MediaInfo is parsing the whole M2TS file before displaying the results which can take a while in case of large files. I think it was not like that in older versions.

It was a bug in versions <=0.7.20, but no more since 0.7.21.
(or my hard drive is very fast, 20 GB M2TS in 2 seconds ;-) ).
If you continue to have this problem with 0.7.21, I will need at least 200MB of the file in order to see why it doesn't seek.

[ipanema]

I'm a bit confused about "Video delay". When I point Mediainfo at a VOB I might see a Video delay of -62ms in the AC3 audio properties. I presume this is the same as the audio delay that is displayed by DVDLab though I can't check right now.

Also if I point Mediainfo at a MTS file from an AVCHD camcorder it might display a Video delay of -33ms for the AC3 audio stream.

As Mediainfo calls this VIDEO delay and it is negative then I assume it means the video leads (happens before) the audio by 62 or 33ms in the above examples.

But how is this delay value stored? Is it a value in the VOB or MTS structure, or a value in the AC3 structure, or is it calculated from the position of packets of video and audio having the same PTS ..... or something else?

[Zenitram]

But how is this delay value stored? Is it a value in the VOB or MTS structure, or a value in the AC3 structure, or is it calculated from the position of packets of video and audio having the same PTS ..... or something else?

For MPEG-TS (AVCHD, blu-ray included) or MPEG-PS (EVO included):
* "Delay" field: hidden by default (menu Debug --> "Advanced mode") will display the PTS (presentation timestamp) of the first detected packet with keyframe (for video or audio). P or B-frames before the first I-frame may be present in the file, but they will be discarded (without the I-frame before, they are not decodable)
* "Video delay" for audio is "Audio" timestamp minus "Video" timestamp.

There are often delays in MPEG-TS/PS because theses containers are "real time containers", you can cut the file when you want, the player synchronizes with PTS.


For the camrecorder, begin timestamps should be same when the file is not cut (the begin of the file is the start of the camrecorder), but I never had this kind of material, if you think there is an error send me the begin of file, I will show you the timestamps.

[ipanema]

So for an MTS file I just looked at,

Audio -> Delay: 1s 915ms
Audio -> Video Delay: 33ms

Video -> Delay: 1s 948ms

If I understand rightly, the first I frame in the file has a PTS of 1.948 secs, and the first audio packet has PTS of 1.915 secs.

So the "Video delay" is just the difference between these - that is -0.033 secs.

I had thought that the "video delay" value meant that it you took a video and audio packet that had the SAME PTS value, then the "video delay" would be the amount by which you would have to shift the audio samples in time so that they would give lip-sync in playback.

It seems I'm mistaken about that. It seems that the "video delay" is just a measure of the amount of audio "missing" at the start of the file (that is, the amount of silent video at the start of the file).

So if you were to demux an MTS file, how would subsequent re-muxing work? Would you have no PTS values to work with? Would you just have to assume that the first video I frame was in sync with the first audio sample?

If that is how muxing works then I guess the "video delay" would have to be passed to the muxer somehow to tell it to add or subtract an amount from the start PTS of the audio packets - this would again tell the playback system that there was N secs of audio missing at the start of the file.

Of course in my example the video delay is NEGATIVE so there is actually LEADING audio packets in the file before the video starts.

[Zenitram]

I had thought that the "video delay" value meant that it you took a video and audio packet that had the SAME PTS value, then the "video delay" would be the amount by which you would have to shift the audio samples in time so that they would give lip-sync in playback.

MediaInfo is "technical", it does not provide this kind of info.

So if you were to demux an MTS file, how would subsequent re-muxing work?.

You need this value.
This is the reason on the presence of this value.

Would you have no PTS values to work with? Would you just have to assume that the first video I frame was in sync with the first audio sample?

This is related to your muxer.
But because Delay info is kept out during the demuxing (PTS is in the container), your muxer can't know the delay between streams, you must provide this information.

Of course in my example the video delay is NEGATIVE so there is actually LEADING audio packets in the file before the video starts.

It may be negative or positive.
I display info as a lot of other software display it (for example, DVD Decrypter save this value in the name of the file something like "xxx Delay -33ms.ac3")

[ipanema]

Right, so the muxer would have to ASSUME that the first I-frame in the video file was in-sync with the first audio sample of the audio file, and apply the SAME start PTS to both in the multiplexed file.

But if you also tell the muxer a "video delay" value then it will add or subtract that amount to the audio's start PTS.

Is it also possible to have a "video delay" in VOB or MPEG TS files which have MPEG 1 layer 2 or PCM audio? I think I've only ever seen a "video delay" value for files which have AC3 audio - but this may just be coincidence.

[Zenitram]

Is it also possible to have a "video delay" in VOB or MPEG TS files which have MPEG 1 layer 2 or PCM audio? I think I've only ever seen a "video delay" value for files which have AC3 audio - but this may just be coincidence.

This is possible, coincidence only.

[ipanema]

Thanks for the info.

However in my example file I just noticed that after the I frame there is a B frame which has a lower PTS and it is the same as the first audio PTS (1.915 sec). This B frame would appear before the I frame in presentation order.

Then I noticed you said "Delay field: will display the PTS (presentation timestamp) of the first detected packet with keyframe (for video or audio). P or B-frames before the first I-frame may be present in the file, but they will be discarded (without the I-frame before, they are not decodable)"

This isn't the case if the GOP is closed. In the example file above the decoder DOES output the B frame then the I frame, so in the case of this file shouldn't the "video delay" be 0 ?

It seems that most camcorder MTS files do have closed GOPs and decoders do output the leading B frame(s).

[Zenitram]

This isn't the case if the GOP is closed. In the example file above the decoder DOES output the B frame then the I frame, so in the case of this file shouldn't the "video delay" be 0 ?

It seems that most camcorder MTS files do have closed GOPs and decoders do output the leading B frame(s).

If the B-frame is displayed by the decoder, this is definitly an error from MediaInfo (I still have problem in understanding all b-frame stuff).
This would be more logic (why the camrecorder would have a delay?)

Could you provide 20-30 MB of a file, I would like to improve MediaInfo delay detection in this case (closed GOP)

Stupid question: the B-frame is based on the I-frame after, OK, and which other frame?

[ipanema]

The B frame must be based only on the I frame that is presentationally AFTER it (i.e. the I frame appears BEFORE it in the file/encoding order). The B frame is not based on any earlier frames (there are none) - that's what a closed GOP means. If they were based on earlier frames which were not present then the GOP is open. Note that this applies to MPEG-2 also so you may need to look at how the video delay for MPEG-2 is calculated aswell.

Of course there may be 1 or 2 B frames (or more?) presentaionally before the I frame. I suggest something like .... look forward from the start of file for the first I frame, then continue searching forward for the next video frame whose PTS is greater than the I-frame's PTS - during the search count the number of frames you find whose PTS is less than the I-frame's PTS.

That will give you the number of B frames that are presentationally before the I frame, but it won't tell you whether the decoder WILL output the preceeding B frames. For that you need to look for the closed-gop flag in MPEG-2. Unfortunately for H.264 (MTS) I don't know where the corresponding flag is (I would love to know).

[ipanema]

I've PM-ed you but my Sent folder is still empty so I don't know if you have received the message - let me know if not.

[Shark007]

For your consideration; This 7.1 TrueHD audio (http://www.mediafire.com/download.php?jjytugeo5tm) sample is detected as only having 6 channels. Current FFDshow (rev3094) releases detect all 8 channels.

[SeeMoreDigital]

For your consideration; This 7.1 TrueHD audio (http://www.mediafire.com/download.php?jjytugeo5tm) sample is detected as only having 6 channels. Current FFDshow (rev3094) releases detect all 8 channels.If MediaInfo could identify the properties of the "core" and "HD" parts separately, yes this would be very useful.


Cheers

[Brazil2]

I'm getting strange results with a MTS file recorded with a Panasonic TZ7:

General
ID : 0
Complete name : F:\Test\TZ7.MTS
Format : BDAV
Format/Info : Blu-ray Video
File size : 8.46 MiB
Duration : 4s 672ms
Overall bit rate : 15.2 Mbps
Maximum Overall bit rate : 18.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Duration : 4s 640ms
Bit rate : 14.4 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : NTSC
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.624
Stream size : 7.95 MiB (94%)

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Duration : 4s 672ms
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Stream size : 110 KiB (1%)

How can it be NTSC with 25 FPS ?

And also MPC-HC, TsMuxer and MP4Box are all saying that the file is 50 FPS.
Example from MPC-HC:
Video: MPEG4 Video (H264) 1280x720 50.00fps [Video]
Audio: Dolby AC3 48000Hz stereo 192Kbps [Audio]

Sample:
http://www.megaupload.com/?d=4PFDDYK4

[LoRd_MuldeR]

How can it be NTSC with 25 FPS ?

It can't. The definition of NTSC in the "digital world" is 720x480@29.97fps. The video size of 1280x720 also isn't NTSC.

[SeeMoreDigital]

Hi Brazil2,

In order for these Panasonic 1280x720 video streams to comply with the Blu-ray specification they contain an implementation called "frame repeats". This raises the frame speed from 25fps to 50fps but not the number of "actual" progressive frames.

I guess it can be further described as a form of pull-down.

EDIT: After re-muxing the elementary stream into the .MP4 container, here's what AVInaptic reports. Is there any data listed here that could explain why MediaInfo thinks it's an NTSC stream: -

[ Relevant data ]

Resolution: 1280 x 720
Width: multiple of 32
Height: multiple of 16
Average DRF: 21.931623
Standard deviation: 1.875284
Std. dev. weighted mean: 1.746235

[ Video track ]

Codec: avc1
Resolution: 1280 x 720
Frame aspect ratio: 16:9 = 1.777777
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 16:9 = 1.777777
Framerate: 50 fps
Number of frames: 117
Bitrate: 28402.984615 kbps

[ About H.264 encoding ]

SPS id: 0
Profile: High@L4
Num ref frames: 1
Aspect ratio: Square pixels
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CAVLC
Weighted prediction: No
Weighted bipred idc: No
8x8dct: No
Custom intra4X4 luma:
5 7 10 12
7 10 12 16
10 12 16 20
12 16 20 20
Custom intra4X4 chromau:
5 8 12 16
8 12 16 16
12 16 20 24
16 20 24 24
Custom intra4x4 chromav:
5 8 12 16
8 12 16 16
12 16 20 24
16 20 24 24
Custom inter4X4 luma:
10 15 24 30
15 24 30 36
24 30 36 36
30 36 36 36
Custom inter4X4 chromau:
9 13 20 25
13 20 25 30
20 25 30 30
25 30 30 30
Custom inter4x4 chromav:
9 13 20 25 13 20 25 30
20 25 30 30 25 30 30 30
135 110 211 247 129 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Number of frames: 117
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 108 ( 92.308 %) #######################
B-slices: 0 ( 0.000 %)
I-slices: 9 ( 7.692 %) ##
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

[ DRF analysis ]

Average DRF: 21.931623
Standard deviation: 1.875284
Max DRF: 33

DRF<18: 0 ( 0.000 %)
DRF=18: 1 ( 0.855 %)
DRF=19: 0 ( 0.000 %)
DRF=20: 27 ( 23.077 %) ######
DRF=21: 18 ( 15.385 %) ####
DRF=22: 42 ( 35.897 %) #########
DRF=23: 12 ( 10.256 %) ###
DRF=24: 7 ( 5.983 %) #
DRF=25: 5 ( 4.274 %) #
DRF=26: 4 ( 3.419 %) #
DRF=27: 0 ( 0.000 %)
DRF=28: 0 ( 0.000 %)
DRF=29: 0 ( 0.000 %)
DRF=30: 0 ( 0.000 %)
DRF=31: 0 ( 0.000 %)
DRF=32: 0 ( 0.000 %)
DRF=33: 1 ( 0.855 %)
DRF>33: 0 ( 0.000 %)

P-slices average DRF: 21.888888
P-slices std. deviation: 1.553570
P-slices max DRF: 26

I-slices average DRF: 22.444444
I-slices std. deviation: 4.058218
I-slices max DRF: 33Cheers

[smok3]

unexpected behaviour/bug: unable to drop media file to icon in stack (osx snow leopard), with gui version of course.

[Zenitram]

For your consideration; This 7.1 TrueHD audio (http://www.mediafire.com/download.php?jjytugeo5tm) sample is detected as only having 6 channels. Current FFDshow (rev3094) releases detect all 8 channels.

Thanks for the file.
I currently don't parse the "HD" part, because I don't have any specifcations, so only the "Core" part is analyzed.
I look at ffmpeg code in order to see how they parse this HD part, and I hope to be able to display the "HD" part.

If MediaInfo could identify the properties of the "core" and "HD" parts separately, yes this would be very useful.

Good idea.
MediaInfo was not designed to handle multiple Channel count or sampling rate values for 1 stream, I try to see how I can handle this (for both AC-3 and DTS)

[Zenitram]

I'm getting strange results with a MTS file recorded with a Panasonic TZ7.
How can it be NTSC with 25 FPS ?

I only report data from the stream.
After demuxing:
00000001 access_unit_delimiter (5 bytes)
(...)
00000007 seq_parameter_set (46 bytes)
00000007 Header (4 bytes)
00000007 sync: 1 (1)
0000000A nal_ref_idc: 3 (3)
0000000A nal_unit_type: 7 (7)
0000000B profile_idc: 64 (100)
(...)
00000013 vui_parameters_present_flag (34 bytes)
00000013 vui_parameters_present_flag: Yes
(...)
00000015 video_signal_type_present_flag (2 bytes)
00000015 video_signal_type_present_flag: Yes
00000015 video_format: 2 (2) - NTSC
00000015 video_full_range_flag: No
00000016 colour_description_present_flag: No
(...)

--> video_format should be:
* not present
* or egal to 5 (no format)
But Panasonic decided to put this item in the stream, and to set it as NTSC. I report this.

It can't. The definition of NTSC in the "digital world" is 720x480@29.97fps. The video size of 1280x720 also isn't NTSC.

Panasonic has maybe decided to change the definition ;-)

And also MPC-HC, TsMuxer and MP4Box are all saying that the file is 50 FPS.
Example from MPC-HC:
Video: MPEG4 Video (H264) 1280x720 50.00fps [Video]
Audio: Dolby AC3 48000Hz stereo 192Kbps [Audio]


Yes, wrong detection from me, this is a 50 fps stream.

Hi Brazil2,

In order for these Panasonic 1280x720 video streams to comply with the Blu-ray specification they contain an implementation called "frame repeats". This raises the frame speed from 25fps to 50fps but not the number of "actual" progressive frames.

I guess it can be further described as a form of pull-down

You are nearly right:
* There is "frame doubling", I indicate it in the "Easy view": "(Frame doubling / 1 Ref Frames)", but I noticed this is not in the other views, I will modify other views.
* Time clock is set to 100 fps. So with Frame doubling AND progressive sequence, this is 50 fps (25 fps if frame doubling AND interlaced sequence)

[Zenitram]

unexpected behaviour/bug: unable to drop media file to icon in stack (osx snow leopard), with gui version of course.

I am limitated by drag n drop capacities of WxWidgets toolkit.
I am moving to Qt, which is a lot better for this kind of stuff, but it is unfortunatly not yet ready.

[Brazil2]

Sample: http://rapidshare.com/files/293457824/no-audio-in-mpc.mp2.html

MediaInfo reports the DAR as 2.35:1 :
General
Complete name : F:\Test\no-audio-in-mpc.mp2
Format : MPEG-PS
File size : 2.63 MiB
Duration : 3s 168ms
Overall bit rate : 6 966 Kbps

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, Matrix : Default
Duration : 3s 120ms
Bit rate mode : Constant
Bit rate : 6 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 2.35:1
Frame rate : 25.000 fps
Standard : PAL
Colorimetry : 4:2:0
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.627
Stream size : 2.42 MiB (92%)

Audio
ID : 128 (0x80)
Format : AC-3
Format/Info : Audio Coding 3
Duration : 3s 168ms
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Video delay : -48ms
Stream size : 173 KiB (6%)

But every other tool (e.g. Gspot, DGindex, ProjectX) and player (e.g. MPC-HC) reports the DAR as being 16:9. And players are playing it at 16:9.

Video: MPEG2 Video 720x576 (16:9) 25.00fps 6500Kbps [Video]
Audio: Dolby AC3 48000Hz 6ch 448Kbps [Audio]

So I wonder where this info comes from, the container or the video stream ? If the DAR information is different between the container and the video stream then why not showing both informations like this:
Format : MPEG-PS
File size : 2.63 MiB
Container DAR : 2.35:1
Duration : 3s 168ms
Overall bit rate : 6 966 Kbps

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, Matrix : Default
Duration : 3s 120ms
Bit rate mode : Constant
Bit rate : 6 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9

[Zenitram]

Sample: http://rapidshare.com/files/293457824/no-audio-in-mpc.mp2.html
(...)
But every other tool (e.g. Gspot, DGindex, ProjectX) and player (e.g. MPC-HC) reports the DAR as being 16:9. And players are playing it at 16:9.

So I wonder where this info comes from, the container or the video stream ?

For your file:
00000821 sequence_header (12 bytes)
00000828 aspect_ratio_information: 3 (3) - 1.778
0000082D extension_start - Sequence (10 bytes)
00000832 horizontal_size_extension: 0 (0)
00000833 vertical_size_extension: 0 (0)
00000837 extension_start - Sequence Display (12 bytes)
0000083F display_horizontal_size: 21C (540)
00000840 display_vertical_size: 240 (576)

"Sequence Display" description in specifications is not very precise, my formula is (if there is a "Sequence Display" extension):
(0x1000*horizontal_size_extension+horizontal_size_value)/(0x1000*vertical_size_extension+vertical_size_value)*Mpegv_aspect_ratio2[aspect_ratio_information]/(display_horizontal_size/display_vertical_size)

FYI, specifications say "display_horizontal_size and display_vertical_size do not affect the decoding process but may be used by the display process that is not standardised in this specification." (funny, isn't it?)

I think this formula is right or at least the more common (I trust a lot VLC), because both VLC and MPC (not HC) display it as 2.35 (picture is streched, because picture is actually recorded in 16:9 in your case). If I don't handle "Sequence Display" extension, some other files are not well detected.

If "Sequence Display" extension is not handled, DAR is "16:9", but there is a "Sequence Display" extension...

If I remember well, there already was here a discussion about "Sequence Display" extension and the problems with it.

If the DAR information is different between the container and the video stream then why not showing both informations

It already does.
* "Display Aspect Ratio" is the displayed DAR.
* "Original Display Aspect Ratio" is the DAR from the stream if different.

But this file has only one DAR value (the raw video DAR).

Edit:
If the DAR information is different between the container and the video stream then why not showing both informations like this

Your solution is not possible: how do you display data for multiple video stream in one container? "General" container can't have video information, because there are only 1 general item (data about the container) even if there are 30 video streams (this is possible, e.g. MPEG-TS from satellites)

[Shark007]

Sample: http://rapidshare.com/files/293457824/no-audio-in-mpc.mp2.html

But every other tool (e.g. Gspot, DGindex, ProjectX) and player (e.g. MPC-HC) reports the DAR as being 16:9. And players are playing it at 16:9.

PowerDVD 9's mpeg2 decoder will play this sample at the correct aspect ratio.

[Brazil2]

PowerDVD 9's mpeg2 decoder will play this sample at the correct aspect ratio.
Yes, every player I've tried is playing it at 16:9, even the 'old' MPC (not HC) with internal splitters and decoders and even with external ones despite of what Zenitram said. Only VLC is playing it at 2.35:1.

[Zenitram]

Yes, every player I've tried is playing it at 16:9, even the 'old' MPC (not HC) with internal splitters and decoders and even with external ones despite of what Zenitram said. Only VLC is playing it at 2.35:1.

yes, for MPC, this was due of my configuration of MPC, it was using external ffmpeg (ffdshow), as VLC does.

VLC is not a tiny software in a garage, they are not newbees... This is VLC/ffmpeg team vs Cyberlink/MPC!
Anyway, I am interested in your vision about how to interpret "Sequence Display" bytes. Theses bytes exist, I handle them, I need a formula or the signification of theses bytes. For what reason your encoder put theses bytes in the stream?

Ignoring completely "Sequence Display" is not so easy, some other files have wrong DAR if I do this, decision creates a winner and a looser.

So I propose something: I am not as expert as the VLC/ffmpeg team, send this bug report to VLC/ffmpeg team, if you succeed VLC/ffmpeg team to accept that VLC has a bug with your file, I change directly my code and ignore "Sequence Display" without discussion. Another possibility is to have a reply from your encoder creator about the signification of theses bytes in the stream and have an argument about how the creator of the stream imagine theses bytes. Else I don't see what is the purpose of theses bytes if I don't handle them as I currently do, so I prefer to handle them, as VLC/ffmpeg does: if theses bytes are in the stream, there is a reason, ignoring them is not a good solution.

[Brazil2]

I haven't encoded the file myself, it's only a sample that I've found on some forums. Here is another one showing the same issue:
http://rapidshare.com/files/289368716/Classic_Rock_Guitar_Solos_Vol_1.Title2.vob.html

I'm not sure it's a ffmpeg issue since the files are playing with the correct aspect ratio in Mplayer so it looks more like a splitter issue.
But is it an issue or a feature ? I don't know.
I'm not saying MediaInfo is wrong, in fact without MediaInfo I wouldn't be able to see this 2.35:1 DAR but since other tools and players are ignoring this Sequence Display it might be a good idea to show both aspect ratios in MediaInfo, the Sequence Display and the Aspect Ratio Information. So it will be easier to spot such conflicts.

[Zenitram]

but since other tools and players are ignoring this Sequence Display it might be a good idea to show both aspect ratios in MediaInfo, the Sequence Display and the Aspect Ratio Information. So it will be easier to spot such conflicts.

Yes, there is actually an issue for players, displaying both values may be a good reply because my goal is to propose the best tool for debugging players problems, I didn't reacted this is useful to have both values.
I will try to add this feature when I implement "multiple values" support with AC-3 / TrueHD (Core / HD values) proposed by SeeMoreDigital.

[LoRd_MuldeR]

Zenitram, a quick question: What exactly do the following pre-processor defines do?

NDEBUG; MEDIAINFO_MINIMIZESIZE; MEDIAINFO_LIBCURL_NO; MEDIAINFO_LIBMMS_NO

:thanks:

[Zenitram]

Zenitram, a quick question: What exactly do the following pre-processor defines do?

NDEBUG: identic for all software (No debug --> Release mode)
MEDIAINFO_MINIMIZESIZE: reduce binary size because it removes the trace feature (this feature is not yet completely ready, work in progress, this is the trace I display sometimes here in order to display what is the bytestream of files, no public GUI)
MEDIAINFO_LIBCURL_NO: don't use libcurl (for read from HTTP/FTP instead of HDD files) (works well on Linux but is not currently the default, "all in one" package is not yet ready on Windows, work in progress, but if you compile yourself libcurl you can remove this define)
MEDIAINFO_LIBMMS_NO: don't use libmms (for read from MMS/MMSH instead of HDD files) (this feature will not be available on Windows because libmms is not Windows-compatible, works well on Linux but is not currently the default)

[LoRd_MuldeR]

I see. So I should keep all those defines for my Win32 builds. Thanks for info :)

BTW: I wonder why we need both, NDEBUG and _DEBUG. Shouldn't the absence of _DEBUG already indicate that we are in "release mode" or vice versa :confused:

Doesn't #ifdef NDEBUG have the same meaning as #ifndef _DEBUG in practice? Or are there "historical" reasons?

[SeeMoreDigital]

It already does.
* "Display Aspect Ratio" is the displayed DAR.
* "Original Display Aspect Ratio" is the DAR from the stream if different.

But this file has only one DAR value (the raw video DAR).I still reckon the expression "Original Display Aspect Ratio" is wrong and should be replaced with "Frame Aspect Ratio". For the reasons I outlined here. (http://forum.doom9.org/showpost.php?p=1323332&postcount=508)


Your solution is not possible: how do you display data for multiple video stream in one container? "General" container can't have video information, because there are only 1 general item (data about the container) even if there are 30 video streams (this is possible, e.g. MPEG-TS from satellites)If the "General" heading was renamed to "Container". Then perhaps this area could be expanded to include information about the "container level signalling" used by .MKV and .MOV

For transport multiplexes with multiple video streams. Is it not possible to list the video streams information separately, like you do now with audio and subtitle streams?

[LoRd_MuldeR]

Oh, please don't rename things. There are people who have existing code to parse the output :p

Just had to adjust my code, because the "Format" of all WMA files is just "WMA" now, instead of "WMA1", "WMA2" and "WMA3" ;)

[Zenitram]

I still reckon the expression "Original Display Aspect Ratio" is wrong and should be replaced with "Frame Aspect Ratio".

I don't forget.
But as LoRd_MuldeR said, some users don't like I change too much. Legacy is important for other people.
I still plan to estimate the change when I do a bigger API update.

If the "General" heading was renamed to "Container".

Not a bad idea.
I don't promise to modify it, I will estimate the pro and cons when I change the API ("Container" is maybe not common enough, there is sometime tags or technical info like sattelitte positions and so on... Your point of view is maybe not the point of view from other users)

Then perhaps this area could be expanded to include information about the "container level signalling" used by .MKV and .MOV

About what expanding do you think?
If you think about video related stuff (new DAR...), I don't think this is a good idea (see below)

For transport multiplexes with multiple video streams. Is it not possible to list the video streams information separately, like you do now with audio and subtitle streams?

1/ User are interested in the DAR of his video first, they do not care about if it is at container level or stream level. Outputed video has a DAR, whatever is the origin of this DAR. Optionaly, they care about it, and they don't imagine to look in video part for one DAR and general/container part for another DAR.
2/ For multiple video streams, this adds a complexity of the interface (another level). This complexity is too much compared to gains (gains would be for 0.01% of videos, complexity for 100% of videos)

Again, I must manage different kind of users, from beginners to expert, from basic AVI file to very complex MPEG-TS with multiple programs files, from people who parse the CLI output to people using th DLL interface, and creating an understable output for all of them is not so easy as taking your advice directly.

[smok3]

I am limitated by drag n drop capacities of WxWidgets toolkit.
I am moving to Qt, which is a lot better for this kind of stuff, but it is unfortunatly not yet ready.

i was brave enough to do a little workaround, until this gets fixed (comes with this cool name: MediaInfoDroplet)

keywords: osx, mac, droplet, mediainfo

whatis:
drop some media files on the icon and it will return some mediainfo values.

download:
http://forum.doom9.org/showthread.php?p=1528488
(now part of the ffdrop collection)

install example:
click to unpack that zip, drag the app to Applications folder and from there to dock, finder window, desktop. The new version will also accept new files to be droped to the allready opened window.

(tested on Lion only)

bugs reported:
spaces in file names are not handled (can't reproduce)

--------------------------

source:
#!/bin/sh
cmd=$1/Contents/Resources/mediainfo

shift
for argument in "$@" ;do
echo $argument
$cmd "$argument"
echo "----------------------------------"
done


echo "droped files:"
for argument in "$@" ;do
echo $argument

done

"compiled" with platypus 4.4.

video, usage
http://youtu.be/qu2-mygpN5A

[Zenitram]

i was brave enough to do a little workaround

Thanks for this feature.
Do you see any problem if I include it in my official package?

[Brazil2]

Sample: http://www.megaupload.com/?d=B7YJAWF0

General
Complete name : F:\Test\Button.flv
Format : Flash Video
File size : 3.58 MiB
Duration : 18s 0ms
Overall bit rate : 1 670 Kbps

Video
Format : H.263
Duration : 18s 0ms
Bit rate : 62.5 Kbps
Width : 704 pixels
Height : 400 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Bits/(Pixel*Frame) : 0.009
Stream size : 137 KiB (4%)

Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Duration : 18s 0ms
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Resolution : 16 bits
Stream size : 211 KiB (6%)

The average bitrate of the video stream is about 1500 Kbps not 62.5 Kbps.

The total file size is 3.58 MB but the reported size of the streams is 137 KiB (4%) for the video and 211 KiB (6%) for the audio so there is something wrong.


Suggestion: for MP3 audio it would be nice if MediaInfo could report if the audio stream is Stereo or Joint Stereo.

[smok3]

Thanks for this feature.
Do you see any problem if I include it in my official package?

i can't see any problems.

[Zenitram]

The average bitrate of the video stream is about 1500 Kbps not 62.5 Kbps.

FLV has no index, I rely on Meta tags.
videodatarate value is 62500 bps.

00000009 Meta - onMetaData - 12 elements (283 bytes)
00000009 Header (15 bytes)
00000009 PreviousTagSize: 0 (0)
0000000D Type: 12 (18)
0000000E BodyLength: 10C (268)
00000011 Timestamp_Base: 0 (0)
00000014 Timestamp_Extended: 0 (0)
00000015 StreamID: 0 (0)
00000018 Type: 2 (2) - SCRIPTDATASTRING
00000019 Value_Size: A (10)
0000001B Value: onMetaData
00000025 Type: 8 (8) - SCRIPTDATAVARIABLE[ECMAArrayLength]
00000026 ECMAArrayLength: C (12)
(...)
0000005E videodatarate - 62500 (24 bytes)
0000005E StringLength: D (13)
00000060 StringData: videodatarate
0000006D Type: 0 (0) - DOUBLE
0000006E Value: 62.500
(...)

Currently, MediaInfo displays the result of a broken file (at least in the header): the file is broken, so result is broken.
I added an integrity check on bitrates (bitrates must be coherent, or metatag info is trashed), next version will have:

Video
Format : H.263
Duration : 18s 0ms
Bit rate : 1 499 Kbps
Width : 704 pixels
Height : 400 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Bits/(Pixel*Frame) : 0.213
Stream size : 3.22 MiB (90%)


Suggestion: for MP3 audio it would be nice if MediaInfo could report if the audio stream is Stereo or Joint Stereo.

New version will have:
Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Format settings, Mode : Joint stereo / MS Stereo
Duration : 18s 0ms
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Resolution : 16 bits
Stream size : 211 KiB (6%)

(both mode and mode_extension settings)

Thanks for feedback.

[Brazil2]

FLV has no index, I rely on Meta tags.
I didn't notice that because the file was playing fine in many different players I've tried.
Remuxing it with Mencoder fixed it for good.


Currently, MediaInfo displays the result of a broken file (at least in the header): the file is broken, so result is broken.
I added an integrity check on bitrates (bitrates must be coherent, or metatag info is trashed), next version will have
And/or add a warning maybe ? Saying that the file is somehow broken.
Might be very usefull.


New version will have:
Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Format settings, Mode : Joint stereo / MS Stereo
Nice, thanks :)