MediaInfo(Lib) 0.7 - Reading information about media files [Archive] - Page 19

Zenitram

9th February 2011, 13:37

i just noticed starting version 0.7.39 some of my mp4 files can't open in mediainfo.

Crash, oups.
Corrected in latest development snapshot
http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.41%2B/MediaInfo_GUI_20110209_Windows_i386_WithoutInstaller.7z/download

hey SeeMoreDigital. there's probably some irony in your remark which i couldnt understand, so i just have non-funny answer-
1920x1080 ->(resized to SD, mod16) -> 720x400 (SAR 80:81, DAR 16:9)
btw thats the mod16 resolution suggested by megui.

Seriously, this is a big quality impact to do this (SAR 1:1 to 80:81 during encoding, and back to 1:1 during decoding).
Industry decided to stop to deal with SAR != 1:1 for a good reason...
why do you need to do mod16 on a source not mod16? AVC has cropping features --> Do 720x405 with SAR 1:1, you will have more quality.

kypec

9th February 2011, 15:10

Seriously, this is a big quality impact to do this (SAR 1:1 to 80:81 during encoding, and back to 1:1 during decoding).
Industry decided to stop to deal with SAR != 1:1 for a good reason...
why do you need to do mod16 on a source not mod16? AVC has cropping features --> Do 720x405 with SAR 1:1, you will have more quality.
Huh? What quality impact has specifying SAR during encoding? Encoder just analyzes the input frames (width x height) in pixels. SAR is just a number being added into many other tags which are included along the picture data in the output stream. It has absolutely no impact on quality nor performance of encoding process. The only factor affecting the visual quality is how good is decode/render process handling SAR specified and scaling/mapping virtual resolution onto physical display device like LCD, CRT, PDP or anything else there might be.

LoRd_MuldeR

9th February 2011, 15:43

Huh? What quality impact has specifying SAR during encoding? Encoder just analyzes the input frames (width x height) in pixels. SAR is just a number being added into many other tags hewhich are included along the picture data in the output stream.

Well, you are correct. Embedding the SAR info alone doesn't effect quality. But if we embed a SAR different from 1:1, this means that we must resize (stretch) the video in order to get the desired DAR. Or in other words: You can't simply decode the pixels and send them to the display "as-is", instead they have to go through a resizer at least once. That's what gives "worse" quality, compared to a "SAR = 1:1" source that matches the resolution of your display exactly. For example a 16:9 PAL source encoded at 720x576 with the corresponding PAR will have to be upscaled to 1024x576 for proper 16:9 display and thus won't look as good as a "native" 1024x576 source. Using a "better" scaling algorithm might help a bit, but no scaling algorithm in existence can magically restore detail that isn't in your source anymore.

Vincent Vega

9th February 2011, 18:02

Corrected in latest development snapshot
http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.41%2B/MediaInfo_GUI_20110209_Windows_i386_WithoutInstaller.7z/download
1. thanx a lot, any chance for x64 build too?
Seriously, this is a big quality impact to do this (SAR 1:1 to 80:81 during encoding, and back to 1:1 during decoding).
Industry decided to stop to deal with SAR != 1:1 for a good reason...
why do you need to do mod16 on a source not mod16? AVC has cropping features --> Do 720x405 with SAR 1:1, you will have more quality.

2. ok will keep that in mind, just thought non-mod16 makes an h264 encoder significantly less efficient.

3. in this m2ts audio #2 is dd+ [bd target] 7.1 core/ext, mediainfo reports "5 channels".
here's audio only remuxed with Ts4Np - 3MB (+ dolby media decoder report on the ES):
http://www.mediafire.com/?ddyp1jucuif90bl
in case you might need it too, full 15 sec original sample from scenarist bd - 50MB:
http://www.mediafire.com/?1af1uwjkdgp6iip

4. some childish ui requests: can you add an option to remember window size/position, stay on top?

thanks

Fullmetal Encoder

11th February 2011, 20:57

I was wondering if anyone else was having this problem or if it might be a real bug in the way MediaInfo (.7.4.1) pulls its information. I've tried searching through google and the forums but haven't discovered anything like it.

Recently I started playing with the new lossless codec UT Video Codec, which I intend to be using heavily, and I've noticed that after encoding a file with it in ULY0 setting (YUV 4:2:0) the output color space is reported by MediaInfo as YUV 4:2:2. When I open the resulting file in MPC-HC it's using AVI Decompressor and Color Space Converter and displaying the video in something other than YV12 (YUY2 or RGB32). However, if I use...

AVISource("Test.avi")
Info()

in MPC-HC I get the color space in YV12. If I specify the fourCC (ULY0) in AVISource I get the video in YV12 so I know that the codec is being used properly. As I understand it, there shouldn't be any color conversion taking place between AVISource and my display and Avisynth is obviously able to find and access the UT Video Codec in my system. What's more, is that when I right-click the file and use MediaInfo, MediaInfo correctly identifies the codec as well as the proper fourCC but still shows the color space as YUV 4:2:2.

Could this be a bug in MediaInfo, some sort of problem with UT Video Codec, or am I missing something fundamental here?

Does MediaInfo pull it's color space information from the file by accessing the file in the same way that MPC-HC would open the file? If so, that would explain why both of them are not displaying the correct color format. Incidentally I'm not entirely clear on why MPC-HC isn't able to correctly display the video with AVI Compressor/color space converter, etc. while AVISource has no problem with it but I only plan on using UT Codec for the first pass in an encoding chain so it doesn't matter much to me.

In case it's useful information... using INFO() with FFMS2 to display the video returns "Video codec not found" while DirectShowSource() returns the video in RGB32 color space. I trust AVISource because of the fourCC tests I've run with it as well as the fact that my chain up until the point of encoding with UT Codec is purely YV12.

Zenitram

11th February 2011, 22:24

I've noticed that after encoding a file with it in ULY0 setting (YUV 4:2:0) the output color space is reported by MediaInfo as YUV 4:2:2.

Information is from a database.
But this one is obviously wrong:
http://umezawa.dyndns.info/archive/utvideo/utvideo-8.4.0-readme.en.html

I have changed the database, for next version.

Fullmetal Encoder

12th February 2011, 20:31

Information is from a database.
But this one is obviously wrong:
http://umezawa.dyndns.info/archive/utvideo/utvideo-8.4.0-readme.en.html

I have changed the database, for next version.

Whew, thanks a lot for this. Earlier this was driving me nuts as I couldn't figure out at first if it was a problem with the codec, or a problem with Avisynth or the decoder that was being used, etc...

Thanks also for this software as it really is an invaluable tool.

vlada

3rd March 2011, 11:23

Hi,

I need to get album art image from an audio file (MP3, MP4/AAC, Ogg Vorbis etc.) I can see that MediaInfo detects if it is present and also reads the actual album art data. But I can't figure out what is the format of these data. I use MediaInfo as a shared library and the GUI of my application is using Qt (QML to be precise). Could somebody help me to find a way to read the album art data and display it in Qt? The preferred way for me would be to store the image temporarily as a standalone file (JPEG, PNG etc.) Thank you!

LoRd_MuldeR

3rd March 2011, 14:49

Zenitram

4th March 2011, 19:45

I can see that MediaInfo detects if it is present and also reads the actual album art data. But I can't figure out what is the format of these data.

This is Base64 encoded (in orer to be compatible with text based API). There is a Base64 decoder in ZenLib (used by MediaInfo library), or in a lot of example in the web.

I use MediaInfo as a shared library and the GUI of my application is using Qt (QML to be precise). Could somebody help me to find a way to read the album art data and display it in Qt?

Is there a public release of your tool?

The preferred way for me would be to store the image temporarily as a standalone file (JPEG, PNG etc.)

the encoded image is in the original format in the file. So the format is "forced" by the analyzed file.

LoRd_MuldeR

4th March 2011, 21:21

Any chance to do this with the CLI interface?

vlada

4th March 2011, 23:39

This is Base64 encoded (in orer to be compatible with text based API). There is a Base64 decoder in ZenLib (used by MediaInfo library), or in a lot of example in the web.

There is a module for Python which can convert between ASCII and binary data, so I hope this shouldn't be a problem. I'll play with it on weekend.

Is there a public release of your tool?

Not yet, it is a media player for touchscreen devices running Linux (mainly MeeGo) or Windows. I'm still not satisfied with it enough to make the first public release. What bothers me most is playback backend. Currently I use MPlayer which has many limitations (poor replaygain support, bad volume control, no gapeless playback and others). I would like to switch to Qt Multimedia, but I can't make it to compile correctly on Windows.

Anyway I hope to make a public release within a couple of weeks.

LoRd_MuldeR

5th March 2011, 01:37

There is a module for Python which can convert between ASCII and binary data, so I hope this shouldn't be a problem. I'll play with it on weekend.

As you initially asked for a solution in Qt, you may want to have a look at QByteArray::fromBase64().

vlada

5th March 2011, 11:06

Thank you, I'll try it and will use whatever will be easier for me. Btw. I use PySide to develop the player, which is a Python binding for Qt.

Zenitram

5th March 2011, 20:57

Any chance to do this with the CLI interface?

I don't understand. You have the text output with the CLI (with -f option in order to have all fields), so you do what you want with the Cover_Data field. What is missing?

LoRd_MuldeR

5th March 2011, 21:18

I don't understand. You have the text output with the CLI (with -f option in order to have all fields), so you do what you want with the Cover_Data field. What is missing?

I don't have a cover field, even with "-f" option, in CLI.

I take an MP3 with cover art:
http://img121.imageshack.us/img121/3472/clipboard32.png

And MediaInfo reports this:
http://pastie.org/private/bedogmrc1v1jwspvtpbiw

What am I missing here? :confused:

Zenitram

5th March 2011, 21:22

I don't have a cover field, even with "-f" option, in CLI.

The cover is not detected. I need the file to test it.

LoRd_MuldeR

5th March 2011, 21:32

The cover is not detected. I need the file to test it.

Okay, but before I need to find out, if the cover was embedded properly.

I personally don't care about useless bling-bling, such as cover pictures embedded in an audio file, and therefore I never used that "feature" before. But users request cover art support frequently.

So I simply took Winamp to "embed" the album art into my test file. But I have not been able to "display" the embedded art with anything, except for Winamp.

Now I wonder if maybe Winamp has stored the picture in its internal database or something, instead of in the audio file. Can you recommend a player/tool that I can use to verify and/or embed?

vlada

5th March 2011, 22:12

Can you recommend a player/tool that I can use to verify and/or embed?

mp3tag (http://www.mp3tag.de/)

LoRd_MuldeR

5th March 2011, 22:19

mp3tag (http://www.mp3tag.de/)

:thanks:

According to mp3tag there was no cover embedded in my MP3 file. I have no idea how Winamp associated the cover picture with the MP3, but it obviously didn't embed it :rolleyes:

After actually embedding the cover JPEG file with the help of mp3tag, MediaInfo (CLI) does detect and extract it properly, of course. Sorry...

SeeMoreDigital

13th March 2011, 14:09

Given that the last release version of 0.6.x.x was on the 25 June 2005... Is it possible for one of the Administrators to amend this threads topic title?

LoRd_MuldeR

13th March 2011, 14:12

Given that the last release version of 0.6.x.x was on the 25 June 2005... Is it possible for one of the Administrators to amend this threads topic title?

Done. Although Zenitram should be able to edit his thread's title, if he wishes to do so ;)

SeeMoreDigital

13th March 2011, 14:21

Nice one :)

Zenitram

13th March 2011, 18:38

Done. Although Zenitram should be able to edit his thread's title, if he wishes to do so ;)

Yeah, yeah... I didn't remark the title... This thread is so old! (and me too, ouch :) )

jj666

21st March 2011, 13:22

PGS streams in .TS container support seems to be broken for the last few versions (nothing detected at all).

Let me know in case any samples needed :-)

Cheers,

-jj-

Zenitram

21st March 2011, 13:39

Let me know in case any samples needed :-)

I need samples.

jj666

21st March 2011, 20:47

I need samples.

http://www.megaupload.com/?d=GTEOFCSV
50mb chunk of The Beyond remuxed.

TS, 1 video track, 1 audio track, 2 subtitle tracks, 0:00:29, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
3: Subtitle (PGS), English
4: Subtitle (PGS), English

General
ID : 1 (0x1)
Complete name : E:\the beyond 1080p bluray h264.ts
Format : MPEG-TS
File size : 50.0 MiB
Duration : 28s 543ms
Overall bit rate : 14.7 Mbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : 27
Duration : 28s 654ms
Bit rate mode : Variable
Bit rate : 12.4 Mbps
Maximum bit rate : 38.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.249
Stream size : 42.3 MiB (85%)
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Muxing mode : Stream extension
Codec ID : 134
Duration : 28s 533ms
Bit rate mode : Variable
Bit rate : 1 561 Kbps / 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy
Language : English

I just did a full scan on my latest remuxes, it seems to be pretty random - PGS details given in some cases, not in others.

Let me know how many more samples you need.

Cheers,

-jj-

LoRd_MuldeR

21st March 2011, 21:31

SeeMoreDigital

22nd March 2011, 11:13

Feature request:

Detect the dummy ".cda" files that Windows emulates on the CD-ROM drive when an Audio disk is inserted.

These are RIFF files (like AVI/Wave), but with an "CDDA" type identifier. However these files do NOT actually contain any audio data (it's more a reference to the audio track).

:thanks:Nice request...

Would it be too much of a leap to provide support for detecting CD-TEXT (http://en.wikipedia.org/wiki/CD-Text) data. Which Sony (and their affiliated companies) place on their audio CD's?

LoRd_MuldeR

23rd March 2011, 01:19

MediaInfo v0.7.43:
http://code.google.com/p/mulder/downloads/detail?name=MediaInfo.2011-03-23.zip&can=2&q=

roozhou

23rd March 2011, 16:51

Hi Zenitram,

Why do you always assume 120fps avi to be 24/30fps mixed VFR video?

if (FrameRate.To_int32u()==120)
{
Fill(Stream_Video, StreamPos_Last, Video_FrameRate_String, MediaInfoLib::Config.Language_Get(FrameRate+_T(" (24/30)"), _T(" fps")), true);
Fill(Stream_Video, StreamPos_Last, Video_FrameRate_Minimum, 24, 10, true);
Fill(Stream_Video, StreamPos_Last, Video_FrameRate_Maximum, 30, 10, true);
Fill(Stream_Video, StreamPos_Last, Video_FrameRate_Mode, "VFR");
}

The actual frame rate can be detected by looking for 0-byte frames in the index.

Zenitram

20th April 2011, 09:45

http://www.megaupload.com/?d=GTEOFCSV
50mb chunk of The Beyond remuxed.

Tehre is no subtitle packets in the sample you provided. The program table indicates the 2 PGS, but I display the stream only if I find a packet.

Maybe the difference is that I limit more than before the duration (in MB) of the scan, I must see how I can do (maybe do a longer scan if there is PGS in the program table).

Is it possible to have a longer sample (one including at list a subtilte displayed)?

Zenitram

20th April 2011, 09:48

Feature request:

Detect the dummy ".cda" files that Windows emulates on the CD-ROM drive when an Audio disk is inserted.

On the (long) ToDo list

Hi Zenitram,

Why do you always assume 120fps avi to be 24/30fps mixed VFR video?

This is a quick and dirty method. I'll change this when I have time (definitely not a priority for me, but patch is welcome)

Vincent Vega

20th April 2011, 14:57

i have someone's h264/mkv file for which mediainfo reports
Format Profile: High@L4.1
Muxing mode:Container profile=Unknown@0.0
(in mkvinfo: "CodecPrivate, length 157 (h.264 profile: Unknown @L0.0)").
then i demux video as raw h264 stream and remux it again in mkv, now it shows up in mediainfo as expected:
Format Profile: High@L4.1
Muxing mode: Header stripping

two questions:
1. do i understand correctly, in the original file proper profile/level values were missing at container level, though were still contained in the stream?

2. if so, shouldn't mediainfo report for the original file be smth like this instead:
Format Profile: High@L4.1
Container profile=Unknown@0.0
Muxing mode: Header stripping

thanks

LoRd_MuldeR

25th April 2011, 12:20

It seems there is a regression in version 0.7.44:
Apparently "escape sequences" in the path to file name are replaced, e.g. "\n" (like in "C:\foo\new.mp3") gets replaced with a newline. Same with "\r".

Example:
http://pastie.org/private/68zut8lpmdfueaq9528sgg
(note the "Complete name" line)

I thought this was fixed a while ago, but somehow the issue is back now. Would be great if you could have a look...

Zenitram

25th April 2011, 13:11

It seems there is a regression in version 0.7.44:
Apparently "escape sequences" in the path to file name are replaced, e.g. "\n" (like in "C:\foo\new.mp3") gets replaced with a newline. Same with "\r".

Arghh... I worked a bit on this part of the code, and this is obviosly a wrong modification. But I will not be able to work on MediaInfo before next week. :(

LoRd_MuldeR

25th April 2011, 13:15

Arghh... I worked a bit on this part of the code, and this is obviosly a wrong modification. But I will not be able to work on MediaInfo before next week. :(

Thanks for the quick reply and for confirming the issue!

Quick workaround: Pass path's to MediaInfo that use '/' rather than '\' as separator. This works because the Windows API will gracefully handle '/' like '\' :)

(Unfortunately this cannot work for meta tags that happen to contain escape sequences!)

LoRd_MuldeR

1st May 2011, 13:20

Any news yet? :)

Zenitram

1st May 2011, 21:40

Any news yet? :)

Sorry. I just removed the wrong code from the SVN and I made development snapshots (https://sourceforge.net/projects/mediainfo/files/development_snapshots/)

LoRd_MuldeR

1st May 2011, 22:11

Sorry. I just removed the wrong code from the SVN and I made development snapshots (https://sourceforge.net/projects/mediainfo/files/development_snapshots/)

:thanks:

LoRd_MuldeR

2nd May 2011, 13:52

May I suggest a small cosmetical fix:

CL_OPTION(Help)
{
MI.Menu_Help_Version();

TEXTOUT("MediaInfo Command line, ");
STRINGOUT(MI.Text_Get().append(_T("\n\n")));
return Help();
}

smok3

4th May 2011, 08:52

may i have a 11.04 ubuntu deb or ppa or something? (no hurry) :thanks:

Zenitram

4th May 2011, 11:13

may i have a 11.04 ubuntu deb or ppa or something? (no hurry) :thanks:
OpenSuseBuildService (the compilation farm I use for Linux distro) just updated their distro support yesterday. for libzen and libmediainfo:
http://download.opensuse.org/repositories/home:/MediaArea_net/Ubuntu_11.04/

for the GUI and CLI, this is still the one from Debian 6.0 (binary compatibility, actually all 10.10 binaries should be compatible with 11.04...)

roozhou

7th May 2011, 17:49

Hi Zenitram,
With latest 7.4.4 it seems all 4:2:0 JPEGs are recognized as 4:4:4.

SeeMoreDigital

8th May 2011, 11:53

Hi Zenitram,
With latest 7.4.4 it seems all 4:2:0 JPEGs are recognized as 4:4:4.I can confirm this also...

4:2:2 JPEG sources are correctly detected ;)

Zenitram

8th May 2011, 22:50

Hi Zenitram,
With latest 7.4.4 it seems all 4:2:0 JPEGs are recognized as 4:4:4.

Updated algorithm was totaly wrong :(.
I changed it.
Development snapshot: http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.44%2B/MediaInfo_GUI_20110508_Windows_i386_WithoutInstaller.7z/download

roozhou

9th May 2011, 09:38

Hi Zenitram,
How can I integrate MediaInfo to right-click menu for all file formats?

SeeMoreDigital

9th May 2011, 16:33

Updated algorithm was totaly wrong :(.
I changed it.
Development snapshot: http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.44%2B/MediaInfo_GUI_20110508_Windows_i386_WithoutInstaller.7z/downloadThanks... The colourmetry detection is working fine now ;)

smok3

9th May 2011, 17:34

OpenSuseBuildService (the compilation farm I use for Linux distro) just updated their distro support yesterday. for libzen and libmediainfo:
http://download.opensuse.org/repositories/home:/MediaArea_net/Ubuntu_11.04/

for the GUI and CLI, this is still the one from Debian 6.0 (binary compatibility, actually all 10.10 binaries should be compatible with 11.04...)

:thanks:

p.s. natty snap:
http://img694.imageshack.us/img694/876/screenshotro.th.jpg (http://img694.imageshack.us/i/screenshotro.jpg/)

p.s.2. to get rmb click functionality in ubuntu (tested in 10.04, 10.10, 11.04) add a script (!mediainfo) like:
#!/bin/bash
picture=$1

/usr/bin/mediainfo "$picture" > /tmp/mediainfo_tmp.txt && gedit /tmp/mediainfo_tmp.txt

into ~/.gnome2/nautilus-scripts