MediaInfo(Lib) 0.7 - Reading information about media files

[Zenitram]

Avisynth refused to concatenate this file with a blankclip(...fps=30...) saying that framerates wouldn't match.
Deeper investigations using abcavi showed [dwMicroSecPerFrame] 33333, Framerate 30,0003 fps

My point of view is that the the frame rate is 30.000000000 fps. The issue is that 30.000000000 fps = 33333 microseconds when rounded and saved into the file. So there is no reasons to display more digits, I would put 30.000000000. My point of view is that your software has a bug not "translating" 1/0.033333 to 30.00000000, its rounding system is not good: to be exact, 1/0.033333 +/-0.0000005 (the precision of the value) --> 29.99985 < real fps <= 30.00075, and 30.000000000 would be "valid" (and is the expected value from the guy who wrote the file, I think)

[ipanema]

MediaInfo does not seem to support the vprp AVI header which allows AVI files to describe the display aspect ratio of its video stream.

vprp is in the official OpenDML specs but for some reason does not seem to be well supported by many programs, which is a pity (mplayer is one that does). Nevertheless it would be useful if MediaInfo could show the display aspect ratio from the vprp header if it was present.

[Zenitram]

MediaInfo does not seem to support the vprp AVI header which allows AVI files to describe the display aspect ratio of its video stream.

I parse (for trace) all fields from the vprp chunk but I currently do not use it, I don't remember the exact reason I did not yet implement it, oops. Anyway, please provide a file + the expected DAR and it should be implemented quickly (I prefer when I have validation from someone else, and you are there ;-) ).

[SeeMoreDigital]

Anyway, please provide a file + the expected DAR and it should be implemented quickly (I prefer when I have validation from someone else, and you are there ;-) ).I'm willing to test such files in my software and hardware media players ;)

[Emulgator]

My point of view is that the the frame rate is 30.000000000 fps. The issue is that 30.000000000 fps = 33333 microseconds when rounded and saved into the file. So there is no reasons to display more digits, I would put 30.000000000. My point of view is that your software has a bug not "translating" 1/0.033333 to 30.00000000, its rounding system is not good: to be exact, 1/0.033333 +/-0.0000005 (the precision of the value) --> 29.99985 < real fps <= 30.00075, and 30.000000000 would be "valid" (and is the expected value from the guy who wrote the file, I think)

This is about Avisynth. True, a valid point.
Since the given granularity is microseconds there should be no other choice on AviSynth's side
than interpreting the AVI-tagged 33333µs as 30.00000000000fps.

And BTW, for 30000/1001 fps the interpretation of the AVI-tagged presentation time of 33367µs (1s/29.9697305721221...)
as 29.97 fps works as expected in Avisynth .

[ipanema]

I parse (for trace) all fields from the vprp chunk but I currently do not use it, I don't remember the exact reason I did not yet implement it, oops. Anyway, please provide a file + the expected DAR and it should be implemented quickly (I prefer when I have validation from someone else, and you are there ;-) ).

You can take any AVI file and convert it to an AVI file containing a vprp header using the command-line "mencoder.exe" program which comes with mplayer:

http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20and%20MEncoder/revision%2034401/

Just use this command to do the conversion:

mencoder inputfile.avi -ovc copy -oac copy -o outfile.avi -force-avi-aspect 1.77777

This sets the display aspect ratio in the output file's vprp header to 16:9 (1.777). Or use 1.333 for 4:3 display aspect ratio. According to the html manual page for mplayer/mencoder you can specify any value between 0.2−3.0

[SeeMoreDigital]

You can take any AVI file and convert it to an AVI file containing a vprp header using the command-line "mencoder.exe" program which comes with mplayer:I would rather have some short .AVI files please?

[Zenitram]

I would rather have some short .AVI files please?

I would also prefer a file, in order to 1/ share the work 2/ have a real-world file with real content instead of an artificial modified file.

Anyway, I added the change, vprp display aspect ratio is supported now.

[ipanema]

Anyway, I added the change, vprp display aspect ratio is supported now.

Thanks, I'll keep any eye out for the next release.

I would also prefer a file, in order to 1/ share the work 2/ have a real-world file with real content instead of an artificial modified file.

If I provided a file it would just be the same as above - created by mencoder.

It isn't an artificially modified file. Mencoder is a general encoder - the above command creates a new AVI file from scratch. It's just that the video and audio streams are copied from another avi file (not-reencoded).

For more details of mencoder, see the manual:

http://www.mplayerhq.hu/DOCS/HTML/en/intro.html

[SeeMoreDigital]

Hmmm...

If you want us to help you, why can't you just provide us with an small .AVI file?

[ipanema]

If you want us to help you, why can't you just provide us with an small .AVI file?

Because it seemed a bit pointless when anyone could download mencoder and have as many examples files as they wanted, and be able to experiment with as many aspect ratio values as they wanted.

You just need to download mencoder from the link I provided - it is just a zipped folder. Unzip it and simply run the mencoder command I gave.

But here's an example 16:9 file if you really need one:

http://www.mediafire.com/?hh8kcqa5blcer26

[SeeMoreDigital]

You must be having a laugh... Who generates video using Microsoft Video 1. Are you wasting our time?

And no. I don't want to download mencoder!

[ipanema]

You must be having a laugh... Who generates video using Microsoft Video 1.

The codec isn't relevant. It was just a small example file that I went to the trouble of generating for you just now. The point was to demontrate the vprp header not the codec.

[SeeMoreDigital]

The codec isn't relevant. It was just a small example file that I went to the trouble of generating for you just now. The point was to demontrate the vprp header not the codec.
But by using a video format that nobody uses or is supported any-more, you don't know if the software decoder filter even supports aspect ratio signalling, let alone MediaInfo! Also your sample can't be played in any hardware media player!

If you want us to help you. Give us something "current" to work with please?

[Zenitram]

If you want us to help you. Give us something "current" to work with please?

I don't think there is a need to be so aggressive. the spec is official, the patch was 4 lines of code (else I would not have implement it now), and maybe some other person can use it in real world somewhere (I still think this is not real world because this is not someone using it every day from the creation of the file to the final user, but this is not the point).

So... Stay calm :rolleyes:

[SeeMoreDigital]

(I still think this is not real world because this is not someone using it every day from the creation of the file to the final user, but this is not the point).I agree with you in some respects... Because the "real world" video formats should be MPEG-4 Part-2, MPEG-4 Part-10 and VC-1...

Given only a numpty would place the latter two within the .AVI container, all that's left is "good old" MPEG-4 Part-2 which is very well catered for "at the video stream level" by MPEG4 Modifier and works fine with MediaInfo.

[Midzuki]

...
Because the "real world" video formats should be MPEG-4 Part-2, MPEG-4 Part-10 and VC-1...

Given only a numpty would place the latter two within the .AVI container,

Of course "AVI sucks", no discussion about this :p , but regarding VC-1 especifically, SFAIK there is only one DirectShow decoder which actually "hates VC-1 in AVI": Mainconcept.

[ipanema]

Lagarith and other lossless codecs can also be quite useful in AVI, but too big just to demonstrate a small header.

vprp is very poorly supported, its true. Some software like Premiere can use rules to interpret DAR based just on pixel dimensions. My original post was more of an observation than a plea for help. I only mentioned it in case Zenitram was interested in looking into it. Anyway, this is my last post on the subject. ;)

[LoRd_MuldeR]

I noticed that MediaInfo recently started to recognize .m3u playlist files as "HLS" files.

The info that it displays seems to be taken from the (first?) audio file on the list. This is different from the previous behavior, when MediaInfo didn't output any info for such playlist files at all.

Unfortunately this breaks my detection of playlist files:

As playlist files are just "Text" files, they are not easy to detect. So my logic has been: Let MediaInfo detect the file type. If (and only if) MediaInfo doesn't detect anything, guess playlist type be file extension.

Now I have a problem, because the info that MediaInfo returns for a .m3u file looks like it was info from some audio file. Is there a way to tell MediaInfo to ignore "redirections" to another file?

[qyot27]

I'm dealing with another date/time-related issue, in that the values I get from MediaInfo are correct, but I'm getting time skew with the other program due to DST conversion quirks.

Therefore, would it be possible to have a File_Created_Date_Local_UTC and File_Modified_Date_Local_UTC that report the local time along with the UTC offsets? So for instance:
mediainfo --inform=General;%File_Created_Date_Local_UTC% filename
UTC-4:00 2011-08-27 04:28:32.421

I would only hope that in such a case, the files have correct offsets - that files written during EST are stored with UTC-5, and files written during EDT are UTC-4.

[Zenitram]

I noticed that MediaInfo recently started to recognize .m3u playlist files as "HLS" files.

Yes, I support more and more formats, "playlists" included (actually, the goal was for HTTP Live Streaming, I did not care about "pure audio" playlist, I must put another name for them)

Now I have a problem, because the info that MediaInfo returns for a .m3u file looks like it was info from some audio file. Is there a way to tell MediaInfo to ignore "redirections" to another file?

Hum... I did not plan to add such possiblility, redirections are classic for lot of professional "containers". I could quickly add a "--ReferencedFiles=0" (for example) for command line, is it enough for your usage?

[LoRd_MuldeR]

I think it would be sufficient to indicate that the current file is a playlist file and that the audio/video info actually is from another file.

At the moment I simply ignore the file, if the general/format is "HLS". This works for the M3U files that I tested. It seems PLS files are not detected yet.

Are there any other playlist formats, in addition to "HLS", that I need to take care of?

[Zenitram]

I would only hope that in such a case, the files have correct offsets - that files written during EST are stored with UTC-5, and files written during EDT are UTC-4.

I could add the Time zone offset to the local date/time field.
But in (nearly) ISO format:
2011-08-27 04:28:32.421-04:00

Warning: DST is a piece of shit with Microsoft Windows: when there is a DST change, Windows changes the local time (funny!). And I rely on the UTC to local time function from Windows, so result is sometimes... Weird (I try to be polite :) ): depending of your DST/Not DST config (depending of the day of the year), local time will not be same.

[Zenitram]

I think it would be sufficient to indicate that the current file is a playlist file and that the audio/video info actually is from another file.

Actually, the option would disable HLS parser (and some others), so the behavior would be as before (unknown format).

At the moment I simply ignore the file, if the general/format is "HLS".

So maybe this is not the right method (I should not spend time on implementing this option).
Simply test that there is no "Source" field in Video or Audio part. If "Source" field is present, the file you are analyzing is referencing other files.

[LoRd_MuldeR]

Simply test that there is no "Source" field in Video or Audio part. If "Source" field is present, the file you are analyzing is referencing other files.

Thx. Now I need to figure out how to do that with the "--inform" method :D

[qyot27]

I could add the Time zone offset to the local date/time field.
But in (nearly) ISO format:
2011-08-27 04:28:32.421-04:00
For readability purposes, it might look better with a space separating the time and the offset. Otherwise, looks great.

Warning: DST is a piece of shit with Microsoft Windows: when there is a DST change, Windows changes the local time (funny!). And I rely on the UTC to local time function from Windows, so result is sometimes... Weird (I try to be polite :) ): depending of your DST/Not DST config (depending of the day of the year), local time will not be same.
This was actually the motivation behind my suggesting it, more precisely when trying to deal with programs that don't handle DST correctly. If there's some way of showing the discrepancy, I can manually correct for it, and I figured that by seeing the UTC offsets, that it would be fairly trivial to identify the problem.

I've witnessed the time changes when looking at the date fields in Windows Explorer, but thankfully MediaInfo reports the same date/time that Windows Explorer does, which is really all that can be asked for. My problem is with other programs that get the times 1 hour wrong in the completely opposite direction, based on whichever the current time is.

[Chetwood]

Any timeframe on this (http://sourceforge.net/tracker/?func=detail&aid=3431645&group_id=86862&atid=581184)? Just asking cause it looks like a quick fix to me (being a non-coder). Thx.

[Zenitram]

Any timeframe on this (http://sourceforge.net/tracker/?func=detail&aid=3431645&group_id=86862&atid=581184)? Just asking cause it looks like a quick fix to me (being a non-coder). Thx.

Not difficult but:
1/ I'll change the GUI (I say that for several years :( )
2/ I have hundreds of small requests. small x 1000 = not small.
3/ Honestly, this is not something very fun to code, and I am not intersted in it.

--> No time frame, not soon.

[Lotesdelere]

MediaInfo doesn't recognize the MP3 files using free format bitstream encoding.

A sample @ 512 kbps can be found here:
http://streams.videolan.org/streams/mp3/Owner-FreeFormat512k.mp3

[forclip]

+ Matroska: stream order (hidden by default), in order to provide the same numbers as mkvtoolnix 5.2+ Track ID
Any chance or future plans to add such info for other formats too? Currently I want to have it for MP4\MOV. :thanks:

[qyot27]

Any chance or future plans to add such info for other formats too? Currently I want to have it for MP4\MOV. :thanks:
It's certainly not a consolation for MediaInfo use, but mp4info (part of the old MPEG4IP package, although it's also available through the newer MP4v2 (https://code.google.com/p/mp4v2/)) has provided this for as long as I've been using it. I generally use mp4info, mp4box -info, and mediainfo in tandem for these types of reasons.

[forclip]

qyot27
Thanks for the reply. I know about other tools such MP4Box, ffmpeg\avconv e.t.c., but I want it to be possible to get this info from MI too.

[Zenitram]

MediaInfo doesn't recognize the MP3 files using free format bitstream encoding.

VLC and Winamp, the tools I have tested, don't too ;-).
On my ToDo-list, but very low priority, I never saw such stream before so I imagine it is pretty rare and the detection algorithm must be reviewed (I can not base the detection on the size of a frame)

Any chance or future plans to add such info for other formats too? Currently I want to have it for MP4\MOV. :thanks:

Implemented:
https://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.58%2B/
(at least 20120608)

[SeeMoreDigital]

VLC and Winamp, the tools I have tested, don't too ;-).
On my ToDo-list, but very low priority, I never saw such stream before so I imagine it is pretty rare and the detection algorithm must be reviewed (I can not base the detection on the size of a frame)Same here... I also tried re-muxing the .MP3 stream into other containers. That did not work either!

Out of interest... What player is used to play these streams?

[forclip]

Implemented
Thank you!

-------

Hmm.. I'm too sleepy or MediaInfo.dll from "MediaInfo_GUI_20120608_Windows_i386_WithoutInstaller.7z" still without this feature?

[StainlessS]

UK Release "Shawshank Redemption" show 2.4:1 whereas DGIndex shows correct 16:9 aspect ratio.
NOTE, Frame size 720x576, Display Size given as 540x576 in DGIndex (pan/scan).
The actual AR is about 1.85 with black borders top/bottom.
If extracted from VOB, then MI shows 16:9.

PS, MI stands for MediaInfo not "Mission Impossible".


General
Complete name : E:\DVDIN\shawshank\VIDEO_TS\VTS_02_1.VOB
Format : MPEG-PS
File size : 1 024 MiB
Duration : 27mn 14s
Overall bit rate mode : Variable
Overall bit rate : 5 256 Kbps

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=2, N=5
Duration : 27mn 14s
Bit rate mode : Variable
Bit rate : 4 928 Kbps
Maximum bit rate : 7 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 2.40:1
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.475
Stream size : 960 MiB (94%)
Color primaries : BT.470-2 System B, BT.470-2 System G
Transfer characteristics : BT.470-2 System B, BT.470-2 System G
Matrix coefficients : BT.470-2 System B, BT.470-2 System G

Audio
ID : 189 (0xBD)-128 (0x80)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Muxing mode : DVD-Video
Duration : 27mn 14s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 43.6 MiB (4%)

Text
ID : 189 (0xBD)-32 (0x20)
Format : RLE
Format/Info : Run-length encoding
Muxing mode : DVD-Video

[Zenitram]

UK Release "Shawshank Redemption" show 2.4:1 whereas DGIndex shows correct 16:9 aspect ratio.

I need a sample (I only need few MB).

[StainlessS]

Simple file cutting of ~ 1.4 MB, ~ 2 secs of VOB file.
Please acknowledge DL, want to delete file.

EDIT: Link DELETED.

[Zenitram]

Please acknowledge DL, want to delete file.

Done. (private message next time ;-) )

[Zenitram]

UK Release "Shawshank Redemption" show 2.4:1 whereas DGIndex shows correct 16:9 aspect ratio.

From your file:
sequence_display:
00000008 horizontal_size_value: 720 (0x02D0)
00000004 vertical_size_value: 576 (0x0240)
00000008 aspect_ratio_information: 3 (0x03) - 9:16
sequence_display_extension:
0000001C display_horizontal_size: 540 (0x021C)
0000001D display_vertical_size: 576 (0x0240)

--> DAR = 9/16 (note: in MPEG-2 Video specs, numbers are inverted)

Specs (ISO/IEC 13818-2:1995) say: "If sequence_display_extension() is present then the sample aspect ratio may be calculated as follows:
SAR = DAR * display_horizontal_size / display_vertical_size"

Definition of SAR:
"sample aspect ratio: (abbreviated to SAR). This specifies the relative distance between
samples. It is defined (for the purposes of this specification) as the vertical displacement of
the lines of luminance samples in a frame divided by the horizontal displacement of the
luminance samples."
(warning: inverted compared to common usage)

--> SAR = 9/16 * 540/576 = 0.52734375

--> Display Aspect ratio = vertical_size_value / horizontal_size_value * SAR = 0.421875

Display Aspect Ratio in common language is 1/x (from MPEG) = 1/0.421875 = 2.37.
I round it to well known Display Aspect Ratio (I am maybe too much aggressive on the rounding...)

Conclusion: I think your file is buggy, report the bug to the DVD manufacturer (goog luck ;-) ).
On my side, I think I follow specifications, or please demonstrate where I fail to conform to specs. I don't plan to change the behavior if I don't make an error compared to specs.
Note: this is not a problem for a DVD player because the corresponding IFO say 16:9 and a DVD player must conform to DVD specs only. But for the MPEG Stream, directly, it seems to be 2.4:1...

[SeeMoreDigital]

Conclusion: I think your file is buggy, report the bug to the DVD manufacturer (goog luck ;-) ).
On my side, I think I follow specifications, or please demonstrate where I fail to conform to specs. I don't plan to change the behavior if I don't make an error compared to specs.
Note: this is not a problem for a DVD player because the corresponding IFO say 16:9 and a DVD player must conform to DVD specs only. But for the MPEG Stream, directly, it seems to be 2.4:1...
Agreed... This issue has come up a few times before. Where the video streams "aspect ratio" meta-data does not match the IFO files "aspect ratio" information.

Thankfully, the "sequence display extension" can be corrected using ReStream ;)

[Lotesdelere]

VLC and Winamp, the tools I have tested, don't too ;-).
The new upcoming VLC 2.0.2 (http://nightlies.videolan.org/build/win32/vlc-2.0.2-/) does play free format since this commit:
http://git.videolan.org/?p=vlc/vlc-2.0.git;a=commit;h=df908f831a56d50676969f787d1910ef24cf5143

;)

[forclip]

When MI provides an output like this:

Width : 1 280 pixels / 1 280 pixels
Original width : 1 280 pixels
Height : 720 pixels / 720 pixels
Original height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant / Constant
Frame rate : 23.976 fps / 23.976 fps
Original frame rate : 23.976 fps

What does it mean (I'm talking about those double-values)?

[Zenitram]

When MI provides an output like this:

What does it mean (I'm talking about those double-values)?

Double values are expected when there is a legacy stream inside a stream (e.g. "HE-AAC / AAC")
For video, is could be a scalable video in theory, but it is not supported currently. I have such field to with MOV files containing 2 video "sub-streams" inside a stream.
please provide a sample file so I can test.

[forclip]

please provide a sample file so I can test.
I will PM you..

[StainlessS]

Thankyou Zenitram for your answer, perhaps DGIndex gets it wrong then.
(putting down a little bait there, lets see if we get a bite). :)

[Guest]

Thankyou Zenitram for your answer, perhaps DGIndex gets it wrong then.
(putting down a little bait there, lets see if we get a bite). :) Can't take the bait because you deleted the sample file.

[Zenitram]

When MI provides an output like this:

What does it mean (I'm talking about those double-values)?

Corrected (due to the information being twice in the file, weird file...)
https://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.58%2B/
(minimum 20120610)

[forclip]

Corrected
Thanks!

And could you please take a look at this (http://ge.tt/5EGIzuI/v/0?c) sample? It's a MP4 with negative audio delay set to -500ms using MP4Box, but

Delay relative to video : 40s 0ms

[Zenitram]

It's a MP4 with negative audio delay set to -500ms using MP4Box, but

Corrected in version 20120611.