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. |
29th April 2019, 21:44 | #6741 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Yes is a VFR timestamp:
Quote:
Delay initial: 0 Frame: 0, Duration min: 33 ms Frame: 11, Duration max: 51 ms Duration: 5434095 ms (01:30:34.095) Frames : 130288 Fps min : 19.6078431372549 Fps max : 30.3030303030303 Fps avg : 23.9760254467395 But the average is the correct 23.97602, I don't know how mkvmerge can create a mkv with the "Default duration" 50 ms when there are frames with 33 and 51 ms of duration: mkvmerge ... --timestamps 0:"G:\MainMovie\HOLMES_AND_WATSON\h2fkrskg.e0p\HOLMES_AND_WATSON_t00.mkv.timestamps.txt" ... Of course I don't know the sense of put these frame durations. The workaround is forget the VFR and use a CFR of 24000/1001
__________________
BeHappy, AviSynth audio transcoder. |
|
29th April 2019, 21:52 | #6742 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
See:
Quote:
|
|
29th April 2019, 22:08 | #6743 | Link | |
Registered User
Join Date: Jun 2015
Posts: 4
|
Quote:
Sent from my Pixel using Tapatalk |
|
30th April 2019, 00:16 | #6744 | Link |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
@sneaker_ger
Thanks for the info, that explain the wrong mkvmerge behaviour. Instead the duration that occurs the most the default duration must be the average. @bowlingbeeg I don't know if you can disable the VFR, I don't use OneClick.
__________________
BeHappy, AviSynth audio transcoder. |
30th April 2019, 09:57 | #6745 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
The VFR thing was actually my suggestion, so sorry about that, although Zathor implemented it for just the OneClick encoder so far, which I don't use myself, but I suspect it relies completely on the source being an MKV. If you remux the MKV as a TS file with TSMuxer and use that as the source, the problem will probably go away.
Should this be a cause for concern? Quote:
I'm not sure if Zathor intended the VFR encoding to apply to DVD video, and I'm not sure it'd work correctly as it is anyway, as by default ffms2 and Lsmash don't honour pulldown flags, so unless OneClick instructs them otherwise...... TS files should be indexed with DGIndex and pulldown flags honoured as expected. If the repeat field argument isn't added to the script for ffms2/Lsmash by MeGUI, there's a good chance NTSC DVDs won't be handled correctly. It probably explains the source detector thingy bitching about not being able to determine the source type in the log file. I assume it only understands 29.97fps or a constant frame rate, or something like that. Maybe it'd be better if the indexer/decoder created the timecodes file rather than extracting with MKVExtract. I don't know about Lsmash, but ffms2 can write timecodes while indexing. I wonder if ffms2 would've written a timecodes file with more evenly spaced frames? It'd be silly if it didn't. Edit1: I checked a few VFR MKVs and they have no default duration. For me, x264 usually writes the output to MKV and I remux with MKVToolNixGUI without specifying anything, and none of my VFR MKVs have a default duration. Maybe you should remove it. Edit2: I just read sneaker_ger's link. Removing it might be a bad idea (and now I've thought about it, I doubt it's the problem). Edit3: I searched old log files for "timebase", and for standard "hybrid" VFR NTSC, x264 is quite partial to a timebase of 1/1000000000. It also chose 1001/360000 on occasion. I didn't go nuts searching, but for normal VFR NTSC, I didn't see any other timebase. While we're on this subject..... I still don't completely understand how the timebase effects the way media players interpret the frame rate. I encode DVDs as VFR now and then (using TIVTC) and I always let x264 set the timebase. It set 1/1000 for bowlingbeeg's video, probably because the frame rate isn't a normal type of variable (combinations of 23.976fps and 29.97fps). Here's a VFR example. If someone could help me understand what's happening it'd be appreciated. Normally for combinations of film and video, x264 sets a timebase and I'm pretty sure ReClock knows when the frame rate is film or when it's video. The example below is not a standard thing. It's a combination of 25fps and 59.94fps. x264 chose 1/199900 as the timebase. This was the timecodes file: # timecode format v1 Assume 59.940060 0, 1213, 25 2646, 2894, 25 3020, 3155, 25 3268, 5984, 25 9604, 9668, 25 9744, 9861, 25 16850, 17178, 25 35429, 38675, 25 44475, 44889, 25 51266, 52322, 25 61777, 63079, 25 So my question is, why do MPC-HC, Reclock and ffdshow all report the video to be 25fps from start to finish? It's probably a good thing, because I recall the few times I set a timebase myself it caused ReClock to do odd things, so I'm sure x264 knows best (normally). I'd just like to understand it a bit more. MPC-HC and ffdshow count the frames at 25fps, so for the 59.94fps sections, ffdshow gives two or three frames in a row the same number. The screenshot below is from a 59.94fps section. Last edited by hello_hello; 30th April 2019 at 17:00. |
|
6th May 2019, 07:36 | #6748 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
This "bug" was an attempt to save bandwidth for the update servers: Only keep packages enabled which are regularly used, it doesn't make sense to update packages more regularly than using them.
|
6th May 2019, 09:53 | #6749 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Quote:
I use MeGUI to keep updated my system, and I need enable the packages I use each time, no problem.
__________________
BeHappy, AviSynth audio transcoder. |
|
8th May 2019, 09:13 | #6750 | Link | |
Registered User
Join Date: Nov 2017
Posts: 154
|
Quote:
I bag you Sir. Try to understand i don't care about Bandwidth |
|
8th May 2019, 13:39 | #6751 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Nonsense. Updating packages or not does not slow down the encoding. It is not your bandwidth to be saved, but the amount of data downloaded from MeGUI's update servers during an update. Not during your encode. You can manually enable all packages which have been disabled while not using them for a while (only NeroAacEnc and Haali Media Splitter are obsolete and can be kept disabled).
There is surely a different reason for your encodes to be slower than expected. Most probably a lack of knowledge, rather in front of your monitor than inside MeGUI. |
8th May 2019, 22:17 | #6752 | Link |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
No only NeroAacEnc and Haali Media Splitter can be kept disabled safely, there are also other with development stoped:
Avi-Mux GUI, BeSplit, Oggenc2, PgcDemux and tsMuxeR.
__________________
BeHappy, AviSynth audio transcoder. |
15th May 2019, 16:32 | #6754 | Link |
Registered User
Join Date: Sep 2010
Posts: 1
|
Code:
Preliminary log file only. During closing of MeGUI the well formed log file will be written. -[Information] Versions --[Information] MeGUI: 2908 x86 --[Information] MeGUI Debug Data: available --[Information] Update Check: development update server -[Information] Operating System: Windows 10 Pro 1809 x64 (10.0.17763.503) -[Information] .NET Framework: 4.0 (4.0.0.0) -[Information] .NET Framework: 4.7 (4.7.03190) -[Information] Microsoft Visual C++ 2010 x64: 10.0.40219 -[Information] Microsoft Visual C++ 2010 x86: 10.0.40219 -[Information] Microsoft Visual C++ 2012 x64: 11.0.61030 -[Information] Microsoft Visual C++ 2012 x86: 11.0.61030 -[Information] Microsoft Visual C++ 2013 x64: 12.0.30501 -[Information] Microsoft Visual C++ 2013 x86: 12.0.30501 -[Information] Microsoft Visual C++ 2017 x64: 14.16.27027 -[Information] Microsoft Visual C++ 2017 x86: 14.16.27027 -[Information] Redistributables -[Information] DPI: 100% (96/96) -[Information] Resolution: 1920x1080 -[Information] Primary Screen: True -[Information] Monitor 1 --[Information] System Information -[Information] Update detection -[Information] Haali Media Splitter: 1.13.138.14 (14-04-2013) -[Information] Haali DSS2: (14-04-2013) -[Information] ICSharpCode.SharpZipLib: 0.85.5.452 (07-08-2008) -[Information] MediaInfo: 18.05.0.0 (08-05-2018) -[Information] SevenZipSharp: 0.64.3890.29348 (02-01-2011) -[Information] 7z: 9.20 (18-11-2010) --[Information] Component Information -[Information] Version: 1.0.2847.0 -[Information] Date: 06-05-2018 -[Information] Interface: 3 -[Information] AviSynth Wrapper -[Information] File Version: 0.1 -[Information] File Date: 20-12-2018 -[Information] File Name: AviSynth+ 0.1 (r2772, MT, i386) -[Information] File Path: c:\windows\system32\avisynth.dll -[Information] AviSynth Version: AviSynth+ 0.1 (r2772, MT, i386) -[Information] AviSynth+: true -[Information] AviSynth MT: true -[Information] AviSynth --[Information] AviSynth Information --[Information] [15.05.2019 17:31:32] Connected to server: http://megui.tmebi.de/test/ -[Error] Unhandled error --[Information] [15.05.2019 17:31:32] Exception message: Nieprawidłowy format ciągu wejściowego. -[NoImage] w System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) -[NoImage] w System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt) -[NoImage] w System.Convert.ToDecimal(String value, IFormatProvider provider) -[NoImage] w MeGUI.UpdateHandler.ParseFileData(XmlNode node, XmlNode groupNode) w D:\MeGUI\_MeGUI_clean\packages\tools\update\UpdateHandler.cs:wiersz 1123 -[NoImage] w MeGUI.UpdateHandler.ParseUpdateXml(XmlNode currentNode, XmlNode groupNode, String path) w D:\MeGUI\_MeGUI_clean\packages\tools\update\UpdateHandler.cs:wiersz 1021 -[NoImage] w MeGUI.UpdateHandler.ParseUpdateXml(XmlNode currentNode, XmlNode groupNode, String path) w D:\MeGUI\_MeGUI_clean\packages\tools\update\UpdateHandler.cs:wiersz 1027 -[NoImage] w MeGUI.UpdateHandler.ParseUpdateXML() w D:\MeGUI\_MeGUI_clean\packages\tools\update\UpdateHandler.cs:wiersz 963 -[NoImage] w MeGUI.UpdateHandler.RefreshUpdateData() w D:\MeGUI\_MeGUI_clean\packages\tools\update\UpdateHandler.cs:wiersz 189 -[NoImage] w System.Threading.ThreadHelper.ThreadStart_Context(Object state) -[NoImage] w System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) -[NoImage] w System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) -[NoImage] w System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) -[NoImage] w System.Threading.ThreadHelper.ThreadStart() --[Information] [15.05.2019 17:31:32] Stacktrace --[Information] [15.05.2019 17:31:32] Inner exception: null |
16th May 2019, 07:18 | #6755 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Bold guess: The XML info from the update server contains a field that is expected to be a number but is not formatted like one? Looks like an issue to be investigates on the update server(s).
|
16th May 2019, 15:16 | #6756 | Link |
Registered User
Join Date: Feb 2014
Posts: 355
|
I'm not sure if this is a bug or the way it should be. When I select a folder under "Options/Default Output Directory" then index a video file from a different folder, the index and script files are created in the "Default Output Directory"--which is correct--and the path written to the index file is to the different folder--which is also correct--but the path written to the AviSynth script file is the "Default Output Directory" which to me is wrong, as the script throws an error because the indexed video file is in a different folder. Hope this makes sense...
Edit: After deep, painful contemplation, I now understand why: The script's source is for the index file--not the video file--so the path is correct. I am an Eye-Die-Ott, and am also with myself Last edited by LouieChuckyMerry; 30th May 2019 at 22:50. Reason: Clarity |
23rd May 2019, 12:19 | #6757 | Link |
Registered User
Join Date: Feb 2014
Posts: 355
|
Hello. I'm using MeGUI 2908 set to "Use Auto Update", but the updates don't "stick". A few days ago it updated a couple things but I didn't notice exactly what. Yesterday upon restart it updated FFMpeg, MKVMerge, and QAAC, but I didn't take note of the versions. Today upon a restart it updated FFMpeg from v4.1.1 to v4.1.3, MKVMerge from v32.0.0 to v34.0.0, and QAAC from v2.67 to v2.68; however, if I hit "Ctrl+U" all three packages are back to their pre-update versions. Thanks for any help.
P.S.--Any input on my last post about the "Options/Default Output Directory" path for the .avs file being wrong? Thanks . Last edited by LouieChuckyMerry; 23rd May 2019 at 12:21. Reason: Information |
23rd May 2019, 17:35 | #6758 | Link | |
Registered User
Join Date: Mar 2002
Location: Krautland
Posts: 903
|
Quote:
Whenever I open MeGui it happily updates the three binaries. Next time opening MeGui it switches back to older versions. Next time to newer versions and so on and so on...... Funny game... |
|
31st May 2019, 01:13 | #6760 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
New stable x265 version available
x265 v3.0+3-566b05ac7721 (Stable) x265 v3.1 is around the corner also. Last edited by Barough; 31st May 2019 at 14:11. |
Thread Tools | Search this Thread |
Display Modes | |
|
|