Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd September 2015, 22:10   #1441  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,661
Quote:
Originally Posted by manolito View Post
Thanks a lot, works well...

But I also need the DLL...


Cheers
manolito
New 0.7.77 is working fine with SSE.
__________________
Win 10 x64 (18362.388) - Core i3-9100F - nVidia 1660 (436.15)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 3rd September 2015, 10:36   #1442  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,183
Quote:
Originally Posted by stax76 View Post
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 ?
Kurtnoise is offline   Reply With Quote
Old 3rd September 2015, 10:55   #1443  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Germany
Posts: 5,787
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
stax76 is offline   Reply With Quote
Old 3rd September 2015, 12:52   #1444  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,612
Quote:
Originally Posted by NikosD View Post
New 0.7.77 is working fine with SSE.
Confirmed, thanks Nikos for the info. And thanks to Zenitram of course...


Cheers
manolito
manolito is offline   Reply With Quote
Old 20th September 2015, 18:20   #1445  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,612
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

Last edited by manolito; 21st September 2015 at 16:26.
manolito is offline   Reply With Quote
Old 20th September 2015, 20:37   #1446  |  Link
SeeMoreDigital
Life looks better in UHD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 11,448
Quote:
Originally Posted by manolito View Post
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!
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 20th September 2015, 20:43   #1447  |  Link
Zenitram
Registered User
 
Join Date: Aug 2002
Location: France, Paris
Posts: 672
Quote:
Originally Posted by manolito View Post
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)
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo
Zenitram is offline   Reply With Quote
Old 20th September 2015, 20:47   #1448  |  Link
Zenitram
Registered User
 
Join Date: Aug 2002
Location: France, Paris
Posts: 672
Quote:
Originally Posted by SeeMoreDigital View Post
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").

Quote:
Originally Posted by SeeMoreDigital View Post
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?
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo
Zenitram is offline   Reply With Quote
Old 20th September 2015, 21:22   #1449  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,612
Quote:
Originally Posted by Zenitram View Post
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
manolito is offline   Reply With Quote
Old 20th September 2015, 21:51   #1450  |  Link
Zenitram
Registered User
 
Join Date: Aug 2002
Location: France, Paris
Posts: 672
Quote:
Originally Posted by manolito View Post
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).

Quote:
Originally Posted by manolito View Post
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.

Quote:
Originally Posted by manolito View Post
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.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo
Zenitram is offline   Reply With Quote
Old 20th September 2015, 23:30   #1451  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,612
Quote:
Originally Posted by Zenitram View Post
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
manolito is offline   Reply With Quote
Old 21st September 2015, 06:23   #1452  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,413
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.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 21st September 2015, 08:35   #1453  |  Link
Zenitram
Registered User
 
Join Date: Aug 2002
Location: France, Paris
Posts: 672
Quote:
Originally Posted by manolito View Post
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.

Quote:
Originally Posted by manolito View Post
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.

Quote:
Originally Posted by manolito View Post
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.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo
Zenitram is offline   Reply With Quote
Old 21st September 2015, 16:42   #1454  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,612
@ 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
manolito is offline   Reply With Quote
Old 21st September 2015, 17:39   #1455  |  Link
Zenitram
Registered User
 
Join Date: Aug 2002
Location: France, Paris
Posts: 672
Quote:
Originally Posted by manolito View Post
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.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo
Zenitram is offline   Reply With Quote
Old 21st September 2015, 21:13   #1456  |  Link
SeeMoreDigital
Life looks better in UHD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 11,448
Quote:
Originally Posted by Zenitram View Post
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
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 31st October 2015, 10:09   #1457  |  Link
XinHong
Registered User
 
Join Date: Jan 2011
Location: France
Posts: 32
@Zenitram: Is it possible to detect if a TrueHD track contains the Atmos extension ?
XinHong is offline   Reply With Quote
Old 31st October 2015, 10:14   #1458  |  Link
Zenitram
Registered User
 
Join Date: Aug 2002
Location: France, Paris
Posts: 672
Quote:
Originally Posted by XinHong View Post
@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.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo
Zenitram is offline   Reply With Quote
Old 31st October 2015, 10:15   #1459  |  Link
XinHong
Registered User
 
Join Date: Jan 2011
Location: France
Posts: 32
Thanks for this ultra fast reply
XinHong is offline   Reply With Quote
Old 1st November 2015, 10:45   #1460  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,039
FWIW, I recently added "fresh" static builds of MediaInfo (CLI + GUI):
https://github.com/lordmulder/mediai...ases/tag/v2.18
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.