MediaInfo(Lib) 0.7 - Reading information about media files

[Zenitram]

Originally Posted by LoRd_MuldeR

Now with Windows 2000 compatibility fix

What is wrong with my official build and Windows 2000?

[LoRd_MuldeR]

Originally Posted by Zenitram

What is wrong with my official build and Windows 2000?

If you still use MSVC 9.0 to make your builds, then probably nothing.

But I use MSVC 10.0 for quite some now and therefore the binaries won't run on Windows 2000 without the fix

See also:
http://mulder.googlecode.com/svn/tru...Lib/README.txt

[Zenitram]

Originally Posted by LoRd_MuldeR

If you still use MSVC 9.0 to make your builds, then probably nothing.

I use MSVC 9.0 for CLI versions of MediaInfo for this reason actually, I was afraid you mean that my version was not working anymore with Windows 2000.
Worse, I use MSVC 8.0 (MSVC 2005!) for 32-bit DLL in order to be compatible with Windows 95 ;-) (yes, some crazy people still use Windows 95, and they use up to date MediaInfo... I force myself not to try to understand this)

(64-bit versions are built with MSVC 10 because all 64-bit OS are currently supported).

Such limitations from Microsoft is a bit frustrating...

[LoRd_MuldeR]

Originally Posted by Zenitram

I use MSVC 9.0 for CLI versions of MediaInfo for this reason actually

It actually is pretty easy to get MSVC 10.0 binaries running under Windows 2000.

In my test even complex stuff, such as the Qt-framework, appears to work flawlessly this way.

Originally Posted by Zenitram

Worse, I use MSVC 8.0 (MSVC 2005!) for 32-bit DLL in order to be compatible with Windows 95 ;-) (yes, some crazy people still use Windows 95, and they use up to date MediaInfo... I force myself not to try to understand this)

People even try to run Win32 GUI applications on DOS, using the HX Extender

Originally Posted by Zenitram

Such limitations from Microsoft is a bit frustrating...

To be fair, the backward compatibility provided by Microsoft is pretty good compared to, let's say, Apple

[smok3]

question, this:

head -c 100000 filebig.ext > filesmall.ext
mediainfo filesmall.ext = mediainfo filebig.ext

will fail in what circumstances (if any) ?

[Zenitram]

Originally Posted by smok3

head -c 100000 filebig.ext > filesmall.ext
mediainfo filesmall.ext = mediainfo filebig.ext

will fail in what circumstances (if any) ?

May fail.
May not fail.
This depends of the content of the file (if header is at beginning or at end of the file, if index is included in the partial file...), format (for MPEG-TS, you'll have the duration of the partial file...).

MediaInfo is designed to provide maximum info it can with partial files. But there is no list of circumstances, currently (nobody has requested such thing).

[smok3]

just thinkering with the idea to make a sort of a web app, but so far i can't see a php/http upload way which would stop uploading when certain file size is reached.

p.s. my usual avi and mp4 files do pass the head test.

[Zenitram]

Originally Posted by smok3

just thinkering with the idea to make a sort of a web app, but so far i can't see a php/http upload way which would stop uploading when certain file size is reached.

This is in the pipe on my side, but with a C++ server, in order to have fine control about when and how to cut the connexion (MediaInfo DLL API provides fine control of when to cut instead of a hard-coded value)

Originally Posted by smok3

p.s. my usual avi and mp4 files do pass the head test.

You are lucky. This is not the case of all the files I have.

[Brazil2]

Zenitram, you may want to check this:

http://forum.doom9.org/showthread.ph...12#post1522012
http://forum.doom9.org/showthread.ph...35#post1522035

[Zenitram]

Originally Posted by Brazil2

Zenitram, you may want to check this:

Done. Thanks for reporting the issue to me.

[Kurtnoise]

Originally Posted by Kurtnoise

cdda support is on the way...

Originally Posted by Zenitram

I wait ;-)

http://sourceforge.net/tracker/index...62&atid=581183

[Zenitram]

Originally Posted by Kurtnoise

http://sourceforge.net/tracker/index...62&atid=581183

Don't worry, I am on it (several disagreements ;-) )

[Zenitram]

Originally Posted by Atak_Snajpera

Are you going to add support for .y4m ?

Already done since 0.7.45:
General
Complete name : akiyo_cif.y4m
Format : YUV4MPEG2
File size : 43.5 MiB

Video
Format : YUV
Width : 352 pixels
Height : 288 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 fps
Standard : PAL
Color space : YUV
Scan type : Progressive
Compression mode : Lossless

Edit: I remarked that Windows explorer integration is not done for .y4m, I'll add it.

[LoRd_MuldeR]

Thanks for the new version.

However there still is a longstanding "cosmetic" bug:

D:\SVN\Tools\mediainfo_0.7.50_AllInclusive>MediaInfo-x64.exe --Help
MediaInfo Command line,
MediaInfoLib - v0.7.50Usage: "MediaInfo [-Options...] FileName1 [Filename2...]"

I think there should be a linebreak or at least a whitespace after the version number

[iwod]

Will MediaTab gets updated or is it an entirely separate project?

[Zenitram]

Originally Posted by LoRd_MuldeR

However there still is a longstanding "cosmetic" bug:
I think there should be a linebreak or at least a whitespace after the version number

Oups. Windows Unicode only. Corrected.

Originally Posted by iwod

Will MediaTab gets updated or is it an entirely separate project?

This is a third-party project, I am not involved in it. Anyway, I asked its author to do a new version.

[Zenitram]

Originally Posted by iwod

Will MediaTab gets updated or is it an entirely separate project?

From its author (he can not post here due to the stupid 5-day "you must wait" obligation for new registerd users):

"I have some ideas for a next version (including unicode file names support) but I'm actually a little bit busy. The project is alive but next version has no date release. Execute the updater once at week "

[LoRd_MuldeR]

Zenitram, what do you think about a more general fix for stdout/stderr and cout/cerr on Win32?

http://pastie.org/private/a5cz9atppnrcgcwyuega

[Zenitram]

Originally Posted by LoRd_MuldeR

Zenitram, what do you think about a more general fix for stdout/stderr and cout/cerr on Win32?

This is a bit cryptic for me .
OK, I take it. In SVN.

[LoRd_MuldeR]

Originally Posted by Zenitram

This is a bit cryptic for me .

It definitely is cryptic

Unfortunately the only way to convert an operating system file HANDLE into a normal C-style FILE pointer (as needed to replace 'stdout' and fix the 'cout' object) is converting it into a CRT file descriptor first, by calling _open_osfhandle(), and then converting it further to a FILE pointer, by calling _fdopen(). For the 'cout' we additionally need to wrap it into an std::filebuf object...

But it's more or less what Microsoft recommends, except that we explicitly do not want "text" (aka "UTF-8 mangling") mode:
http://support.microsoft.com/default...b;en-us;105305