MediaInfo(Lib) 0.7 - Reading information about media files

[NikosD]

Originally Posted by manolito

Thanks a lot, works well...

But I also need the DLL...


Cheers
manolito

New 0.7.77 is working fine with SSE.

[Kurtnoise]

Originally Posted by stax76

It seems there was a change which broke a feature of my app and I don't know how to get the old behavior, the code I was using is:

MediaInfo_Option(mi.Handle, "Complete", "1")
Return Marshal.PtrToStringUni(MediaInfo_Inform(mi.Handle, 0))

Same version back this was getting parameter names with underscore but now it gets friendly names without underscore, I need to know all parameter names.

Nothing has changed regarding this part...

Could we have an example of what you had before/after ?

[stax76]

My MediaInfo GUI feature isn't working as before, now I get this:

File size : 47948706
File size : 45.7 MiB
File size : 46 MiB
File size : 46 MiB
File size : 45.7 MiB
File size : 45.73 MiB

I don't know exactly what it was before but think something like this:

File_size/String1 : 45.7 MiB
File_size/String2 : 46 MiB
File_size/String3 : 46 MiB
File_size/String4 : 45.7 MiB
File_size/String5 : 45.73 MiB

[manolito]

Originally Posted by NikosD

New 0.7.77 is working fine with SSE.

Confirmed, thanks Nikos for the info. And thanks to Zenitram of course...


Cheers
manolito

[manolito]

No Detection of duration and frame rate for VFR MKV files

There are some VFR files (created by HandBrake) where the current MediaInfo versions cannot detect the frame rate (not even framerate_original) and the duration.

A sample file is here:
http://www3.zippyshare.com/v/VURfwwA3/file.html

The last MediaInfo version which handles these files correctly is version 0.7.58.


Cheers
manolito

[SeeMoreDigital]

Originally Posted by manolito

There are some VFR files (created by HandBrake) where the current MediaInfo versions cannot detect the frame rate (not even framerate_original) and the duration.

What makes you think that these VFR encoded files actually contain 'the original frame rate' meta-data?

Why anybody thinks generating VFR encodes is a good idea is beyond me!

[Zenitram]

Originally Posted by manolito

There are some VFR files (created by HandBrake) where the current MediaInfo versions cannot detect the frame rate (not even framerate_original) and the duration.

A sample file is here:
http://www3.zippyshare.com/v/VURfwwA3/file.html

The last MediaInfo version which handles these files correctly is version 0.7.58.

It is VFR, so versions before 0.7.58 were actually bug (wrong information).
I understand that the current behavior (no information) is the right one, because it is VFR.

Duration is provided at the container ("general" part) level because this is the only one available, same: it is a fix of a previous bad behavior, so the current behavior (no information at the stream level) is the right one, because such information is not known.

There are some ideas (feature requests, not bug. A bug is when a piece of information is wrong, and you did not demonstrate that a piece of information is wrong) for getting duration with probing of the end of the file, and add an option for scanning the whole file (slow!) in order to get min/avg/max framerate, but there is currently no ETA (but this is planned for maximum next year, thanks to some global funding about Matroska)

[Zenitram]

Originally Posted by SeeMoreDigital

What makes you think that these VFR encoded files actually contain 'the original frame rate' meta-data?

Hint: they do not (AVC frmea rate info is set to "no fixed frame rate").

Originally Posted by SeeMoreDigital

Why anybody thinks generating VFR encodes is a good idea is beyond me!

Beside the case of concatanation of 2 stream with different frame rate, we have variable bitrate, so why not variable frame rate if global quality is improved with it?

[manolito]

Originally Posted by Zenitram

It is VFR, so versions before 0.7.58 were actually bug (wrong information).
I understand that the current behavior (no information) is the right one, because it is VFR.

I disagree. The current versions of MediaInfo just say: VFR, nothing else. No frame rate, no duration.

MediaInfo 0.7.58 says: VFR, correct duration, correct frame rate. This just works.


Another indication that the frame rate and the duration in fact can be retrieved from the source file (without parsing the whole file) is that I only have to repack the MKV to MP4 using ffmpeg (-acodec copy -vcodec copy), and voilà, even the current MediaInfo suddenly detects the frame rate and the duration.


Cheers
manolito

[Zenitram]

Originally Posted by manolito

I disagree. The current versions of MediaInfo just say: VFR, nothing else. No frame rate, no duration.

So no bug (no incorrect result, an empty field means "unknown", that's all).
Again, this is the goal (fix of some bugs with the previous algorithm, which was not good for all files, only sometimes right).

Originally Posted by manolito

MediaInfo 0.7.58 says: VFR, correct duration, correct frame rate. This just works.

It works for this file, not for all files. And it is impossible with the old algorithm to do the difference between your correct behavior and incorrect behavior with some other files, so the only solution for not having wrong results is to disable this algorithm.

Originally Posted by manolito

Another indication that the frame rate and the duration in fact can be retrieved from the source file (without parsing the whole file) is that I only have to repack the MKV to MP4 using ffmpeg (-acodec copy -vcodec copy), and voilà, even the current MediaInfo suddenly detects the frame rate and the duration.

Good, you just learned that MP4 has frame duration of all frames in the MP4 header. this is not the case of of MKV (it is in hte frame header of each frame).
Hint: you repacked your MKV, so FFmpeg has read the whole file, it is aware of the duration of each frame for each stream, before writing the MP4 header.

Note: if you think you can get average frame rate and duration of all streams for sure, without any error with all files I have (that means that e.g. video stream duration and audio stream duration may be different) without parsing the whole file, I am interested in a patch and/or hint about how to get it.

[manolito]

Originally Posted by Zenitram

Note: if you think you can get average frame rate and duration of all streams for sure, without any error with all files I have (that means that e.g. video stream duration and audio stream duration may be different) without parsing the whole file, I am interested in a patch and/or hint about how to get it.

Sorry, all the VFR files I ever had to deal with were created by HandBrake, and for these files the older MediaInfo 0.7.58 reports the correct frame rate.

I mainly use MediaInfo from within AVStoDVD, and situations where video and audio stream durations are different do not really matter here. AVStoDVD needs a frame rate, and if MediaInfo does not report it, I can only enter a frame rate manually - I have no way to know which one.

With the old MediaInfo version I do get a frame rate. And even if this rate is not totally correct, it will still work as long as VFR is detected. If the source is VFR, AVStoDVD will open it with with the DirectShowSource parameter "convertfps=true", and this will convert the source to CFR by inserting or dropping frames (similar if FFMpegSource is used).
Since AVStoDVD creates DVDs (which do not support VFR), a conversion from VFR to CFR is mandatory at some point in the chain, so doing this right at the source filter stage makes sense.


Maybe you can provide a link to some problematic VFR files where this old algorithm does not work...


Cheers
manolito

[foxyshadis]

If no frame rate is available, or even if one is but it's nonstandard, I'd just open with DSS's convertfps=true with exactly double whatever the final framerate of the DVD is, weave the fields, and encode interlaced. That handles all VFR as optimally as possible without either blending or mo-comp.

More advanced analysis could reveal where progressive with soft pulldown is possible, but you have to parse the timecodes for that and pass the ranges on. Encoding interlaced just works.

[Zenitram]

Originally Posted by manolito

Sorry, all the VFR files I ever had to deal with were created by HandBrake, and for these files the older MediaInfo 0.7.58 reports the correct frame rate.

Did you test on a file more than 1 minute? Your sample file is small, so MediaInfo actually parses the whole file here (it parses ~500 frames for different reasons). So the previous algorithm was OK in this specific case.
Note: actually, it was not OK, the duration of the last frame was not used, real average frame rate is 15.111, not 15.167.

Not a big difference here, but it may be a bigger one for other files.

Originally Posted by manolito

I mainly use MediaInfo from within AVStoDVD, and situations where video and audio stream durations are different do not really matter here.

Good for you. It does matter for me. And actually, you get the duration you are looking for (in the "general" part).
I'll be direct (and arogant): and I don't develop only for you. If you pay me, I could develop a specific version for you and/or add an option for having what you are looking for, and if you don't I just release a version whose I think is best for all people and which does not take too much time for me to develop.
"I" is not a good argument here.

Originally Posted by manolito

Maybe you can provide a link to some problematic VFR files where this old algorithm does not work...

I would provide the same link than you: your file is a good example.

Let's play with this file, some fun:

- It has no metadata for hte duration of the stream. So we know that the program duration is 12.678 seconds, we know that the last frame timestamp is 12.612, but that's all. OK, let's try and say that the last frame has a duration of 66 ms (we cheat: we consider the program duration as the video duration). there are 191 frames in it (full scan, could not be done by default for all files, too slow), so average frame rate is 15.111. old algorithm does not work here (it says 15.167).
- Let's check the audio duration: last time stamp is 12.608. Audio block duration is provided by the AAC frame, 1024 samples/32000 Hz = 32 ms so total duration is 12.640. old algorithm (and the current one too, something is wrong because duration should not be displayed, I'll fix that) reuses the program duration (12.678), obviously wrong.

Let's rewrap to MP4 with FFmpeg:
- video duration: 12.611. Ho, funny, not same as Matroska program duration, ha ha... Actually, FFmpeg forces the last frame duration to 0. I guess it is wanted, but it is wrong (but actually it is not easy to know the real duration, we can cheat and read the program duration, this is a choice, FFmpeg did not choose that). You can see that old MediaInfo does not report the same frame rate (15.146 fps), so this is obvious that there is a problem somewhere.
- audio duration: 12.640. easier to get the right duration (thanks to AAC block duration information), not same as the algo in MediaInfo for the audio track (because MediaInfo is wrong for the audio track, actually).

***

I took some time for explaining issues, I won't take more time. old algo was wrong, not usable for a general purpose, that's all.
Current behavior is the expected one (actually, I should also remove the audio duration, this is a bug).
Improvement of the old algorithm in order to provide correct information for small files without showing incoherant values for some other files and an option for parsing the whole file in order to provide such value are on the ToDo-list, but is not the priority for the moment (no sponsor for it, sponsors have higher priority).

and please, don't say that I am wrong without being able to demonstrate in the specifications of the formats (Matroska, AVC, AAC...) how to readout such pieces of information. Example with FFmpeg transcode (which may introduce issues e.g. last frame duration of 0 which is not so real) or how you specificaly use a bunch of tools are not relevant (especially when you don't read the resut of your work, you say that MediaInfo can read frame rate from a MP4 transwrap, you "forgot" to say that the numbers are not same).

TLDR; I did not remove such information because I like to remove data, I removed it because I got too many complains about wrong results and it was the quickest way for me to provide less buggy information.

[manolito]

@ foxyshadis
Thanks for the tip to encode VFR as interlaced. Very useful, I will forward it to MrC...

@Zenitram
Looks like I stepped on your feet when I used the word "Bug Report" in my initial post. What I saw was that with these files the current version did not work, but the older version did. So I called it a regression, i.e. a bug.

I had no intention to offend you, you made your point very clear that the old algo was wrong and so you removed it, so the current version has the correct behavior and the old version was buggy.

If I did offend you, I do apologize, I also edited the header of my original post.


But I will stick with my point, this whole thing looks like the typical dispute between the academic world and the real world.

You say: If I am unable to report the exact and precise data, then I will rather not report anything at all.

I say: If I can get an approximation of the data with an acceptable margin of error (acceptable depends on the context where the application is used in) then I'd much rather use this approximation than getting no data at all.

In the context of AVStoDVD the margin of error for the old algo is small enough, errors of this magnitude have no influence on the quality of the conversion results.

In the medical community there is an old saying: "Whoever heals is right". I would change this saying for the computer programming world: "Whatever works is right". So I will continue using the old MediaInfo version 0.7.58 in AVStDVD until I stumble over a VFR conversion which looks terrible because the old algo screwed things up.



Cheers
manolito

[Zenitram]

Originally Posted by manolito

In the medical community there is an old saying: "Whoever heals is right". I would change this saying for the computer programming world: "Whatever works is right".

Exactly my point: it was not working, I fixed it with the quickest way I found, because I did not have the time to fix it better. Whatever works is right, and it works better now than in 0.7.58 for my needs (genenral purpose, and I try to receive less complains by email about buggy values), at least.
Again, you have small differences with your files but other people may have more differences.
Again, I am not against reintroducing the old algo or finding a way to detect when algo is too much wrong on request, but this is development time (option to add, code maintenance...), time is money, and I don't want to spend my money on it for the moment, and nobody else is ready to spend his money (not his time for coding) on it, that's all.

[SeeMoreDigital]

Originally Posted by Zenitram

Beside the case of concatanation of 2 stream with different frame rate, we have variable bitrate, so why not variable frame rate if global quality is improved with it?

Personally speaking I don't recommend the use of VFR because it's not supported by hardware playback devices

[XinHong]

@Zenitram: Is it possible to detect if a TrueHD track contains the Atmos extension ?

[Zenitram]

Originally Posted by XinHong

@Zenitram: Is it possible to detect if a TrueHD track contains the Atmos extension ?

I have some Atmos files, but I did not have yet the time to implement the detection of Atmos. On the ToDo-list with low priority.

[XinHong]

Thanks for this ultra fast reply

[LoRd_MuldeR]

FWIW, I recently added "fresh" static builds of MediaInfo (CLI + GUI):
https://github.com/lordmulder/mediai...ases/tag/v2.18