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 > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 29th April 2019, 21:44   #6741  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,881
Yes is a VFR timestamp:
Quote:
# timestamp format v2
0
33 (33 ms)
83 (50 ms)
117 (34 ms)
167 (50 ms)
200 (33 ms)
250 (50 ms)
284 (34 ms)
334 (50 ms)
367 (33 ms)
417 (50 ms)
450 (33 ms)
501 (51 ms)
...

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.
tebasuna51 is offline   Reply With Quote
Old 29th April 2019, 21:52   #6742  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
See:
Quote:
  • With variable frame rate (e.g. if an external timecode file is used) video the default duration is calculated in a totally different way. mkvmerge calculates the duration for all frames according to the timecode file, counts how often each duration occurs and then uses the duration that occurs the most as the new default duration. This may be a value that doesn't even reverse to any of the often-used frame rates that people are used to.
https://gitlab.com/mbunkus/mkvtoolni...rate-displayed
sneaker_ger is offline   Reply With Quote
Old 29th April 2019, 22:08   #6743  |  Link
bowlingbeeg
Registered User
 
Join Date: Jun 2015
Posts: 4
Quote:
Originally Posted by tebasuna51 View Post
Yes is a VFR timestamp:



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
Is there a way to specify in MeGUI that I don't want the VFR? Looked to me like that was hardcoded if mediaInfo said it was VFR.

Sent from my Pixel using Tapatalk
bowlingbeeg is offline   Reply With Quote
Old 30th April 2019, 00:16   #6744  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,881
@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.
tebasuna51 is offline   Reply With Quote
Old 30th April 2019, 09:57   #6745  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
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:
0
33 (33 ms)
83 (50 ms)
117 (34 ms)
167 (50 ms)
200 (33 ms)
250 (50 ms)
284 (34 ms)
334 (50 ms)
367 (33 ms)
417 (50 ms)
450 (33 ms)
501 (51 ms)
Is the frame rate uneven because the source was telecined (pulldown flags), so instead of each frame having the same 41 point something ms duration, there's a 23.976fps frame followed by one with a 23.976fps and a half duration, or something similar....

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.
hello_hello is offline   Reply With Quote
Old 3rd May 2019, 19:16   #6746  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Nobody understands how the encoder timebase works?? Anyone?? (see the question in my previous post).
hello_hello is offline   Reply With Quote
Old 4th May 2019, 13:59   #6747  |  Link
imsrk48
Registered User
 
imsrk48's Avatar
 
Join Date: Nov 2017
Posts: 154
#bug

Packages are auto disabling after closed MeGUI
imsrk48 is offline   Reply With Quote
Old 6th May 2019, 07:36   #6748  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 6th May 2019, 09:53   #6749  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,881
Quote:
Originally Posted by LigH View Post
...it doesn't make sense to update packages more regularly than using them.
Unless the packages are used out of MeGUI... with command line bat's.

I use MeGUI to keep updated my system, and I need enable the packages I use each time, no problem.
__________________
BeHappy, AviSynth audio transcoder.
tebasuna51 is offline   Reply With Quote
Old 8th May 2019, 09:13   #6750  |  Link
imsrk48
Registered User
 
imsrk48's Avatar
 
Join Date: Nov 2017
Posts: 154
Quote:
Originally Posted by LigH View Post
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.
I'm facing issues when all packages are not enabled my encoding speed goes slow and take too much time in Encoding so please add option for keep all packages enabled

I bag you Sir. Try to understand i don't care about Bandwidth
imsrk48 is offline   Reply With Quote
Old 8th May 2019, 13:39   #6751  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 8th May 2019, 22:17   #6752  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,881
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.
tebasuna51 is offline   Reply With Quote
Old 9th May 2019, 17:08   #6753  |  Link
wthreex
Registered User
 
Join Date: Oct 2015
Posts: 97
Today ive lost all of my Oneclick Profiles i dont know why, But i remember a error showed up and said "Unable to read Nero AAc"... and my profiles gone.

Last edited by wthreex; 9th May 2019 at 18:00.
wthreex is offline   Reply With Quote
Old 15th May 2019, 16:32   #6754  |  Link
yorkfield25
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
Anu ideas?
yorkfield25 is offline   Reply With Quote
Old 16th May 2019, 07:18   #6755  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 16th May 2019, 15:16   #6756  |  Link
LouieChuckyMerry
Registered User
 
LouieChuckyMerry's Avatar
 
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
LouieChuckyMerry is offline   Reply With Quote
Old 23rd May 2019, 12:19   #6757  |  Link
LouieChuckyMerry
Registered User
 
LouieChuckyMerry's Avatar
 
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
LouieChuckyMerry is offline   Reply With Quote
Old 23rd May 2019, 17:35   #6758  |  Link
Taurus
Registered User
 
Taurus's Avatar
 
Join Date: Mar 2002
Location: Krautland
Posts: 903
Quote:
Originally Posted by LouieChuckyMerry View Post
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.
Same here...
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...
Taurus is offline   Reply With Quote
Old 30th May 2019, 22:52   #6759  |  Link
LouieChuckyMerry
Registered User
 
LouieChuckyMerry's Avatar
 
Join Date: Feb 2014
Posts: 355
The update issue seems to have fixed itself. Perhaps Zathor used his super powers ...
LouieChuckyMerry is offline   Reply With Quote
Old 31st May 2019, 01:13   #6760  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 481
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.
Barough 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 10:37.


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