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. |
|
|
Thread Tools | Search this Thread | Display Modes |
2nd September 2015, 22:10 | #1441 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
New 0.7.77 is working fine with SSE.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
3rd September 2015, 10:36 | #1442 | Link | |
Swallowed in the Sea
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
|
Quote:
Could we have an example of what you had before/after ? |
|
3rd September 2015, 10:55 | #1443 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
20th September 2015, 18:20 | #1445 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
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. |
20th September 2015, 20:37 | #1446 | Link | |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,227
|
Quote:
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 |
|
|
20th September 2015, 20:43 | #1447 | Link | |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
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 |
|
20th September 2015, 20:47 | #1448 | Link | |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
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 |
|
20th September 2015, 21:22 | #1449 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Quote:
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 |
|
20th September 2015, 21:51 | #1450 | Link | |||
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
Again, this is the goal (fix of some bugs with the previous algorithm, which was not good for all files, only sometimes right). Quote:
Quote:
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 |
|||
20th September 2015, 23:30 | #1451 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Quote:
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 |
|
21st September 2015, 06:23 | #1452 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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. |
21st September 2015, 08:35 | #1453 | Link | |||
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
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:
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:
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 |
|||
21st September 2015, 16:42 | #1454 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
@ 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 |
21st September 2015, 17:39 | #1455 | Link | |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
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 |
|
21st September 2015, 21:13 | #1456 | Link |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,227
|
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 |
|
31st October 2015, 11:14 | #1458 | Link |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
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 |
1st November 2015, 11:45 | #1460 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
FWIW, I recently added "fresh" static builds of MediaInfo (CLI + GUI):
https://github.com/lordmulder/mediai...ases/tag/v2.18
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
|