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. |
14th April 2016, 13:23 | #5041 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
So the reason is probably not the encoder itself, but possibly the hardware (e.g. overheating CPU or RAM), especially when it's a different location each time you try, and crashing earlier with less cool-down break. Or the source video when it's always at the same position.
|
14th April 2016, 16:14 | #5042 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
Thanks for info. If not x264 then maybe Avisynth.
Could you try to delete (comment out) the line from your script: InterFrame(Cores=4, GPU=True) I know that this will be different result of encoding but this is only for testing. |
14th April 2016, 16:53 | #5043 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
The encode in the log file only ran for a minute or so before it crashed, but MeGUI seemed to be able to finish the cleanup jobs without any problem, so my vote wouldn't be for overheating.
DirectShowSource + Interframe seems a bit daring to me. DSS2 + Interframe mightn't be as daring, but still a little brave. The first thing I'd try would be something other than DSS2 to open the video with GPU=True taken out of the equation for Interframe. You can open MP4s without indexing with L-Smash. They open pretty quickly. You still need to use the File Indexer to open them or you'll only be offered DirectShowSource as an alternative, but after the File Indexer runs the Script Creator opens an MP4 with LSMASHVideoSource (LSMASHAudioSource for audio encoding) rather than LWLibavVideoSource. I'd try that rather than DSS2. Last edited by hello_hello; 14th April 2016 at 16:58. |
16th April 2016, 12:23 | #5044 | Link |
Registered User
Join Date: Nov 2015
Location: GB
Posts: 20
|
the thing is, I don't get this error in every video, it was happening before too with some videos but when I replace an old version of x264.exe, it was working fine, but this time it doesn't work, always giving error with this video, tried another video with same type, I mean really same type, bitrate and all but it worked well, this video gives error :/
@hello_hello I deleted them manually cause it gave error... @Ma it gave error ''cannot open video output'' I think I will just give up on this video :/ it is working with same type other videos but not this one, too weird. |
16th April 2016, 17:50 | #5045 | Link |
Registered User
Join Date: Aug 2007
Posts: 79
|
I just wanted to make some comparison tests between x264 and x265. it seems there is a missing space when megui creates the commandline for x265 in the case of using high bit depth input.
check out the error log: Code:
--[Information] [16.04.2016 18:46:29] resolution: 2560x534 --[Information] [16.04.2016 18:46:29] frame rate: 24000/1001 --[Information] [16.04.2016 18:46:29] aspect ratio: 12:5 (2.400) --[Information] [16.04.2016 18:46:29] custom command line: --output-depth 12 --input-depth 16 --input-csp i444 --ssim --[Information] [16.04.2016 18:46:29] Job command line: "C:\Software\MeGUI\tools\x265\avs4x265.exe" --x265-binary "C:\Software\MeGUI\tools\x265\x64\x265.exe" --tune ssim --crf 23 --output-depth 12 --input-depth 16 --input-csp i444 --ssim --output "D:\!x264\x265_crf23_medium.hevc" "D:\!x264\encode.avs" --[Information] [16.04.2016 18:46:29] Process started --[Information] [16.04.2016 18:46:29] Standard output stream ---[Information] [16.04.2016 18:46:29] avs [info]: AviSynth 2.60, build:Feb 20 2015 [03:16:45] ---[Information] [16.04.2016 18:46:29] avs [info]: Video colorspace: YV24 ---[Information] [16.04.2016 18:46:29] avs [info]: Video resolution: 2560x534 ---[Information] [16.04.2016 18:46:29] avs [info]: Video framerate: 24000/1001 ---[Information] [16.04.2016 18:46:29] avs [info]: Video framecount: 1440 ---[Information] [16.04.2016 18:46:29] avs4x265 [info]: High bit depth detected, resolution corrected ---[Information] [16.04.2016 18:46:29] avs4x265 [info]: "C:\Software\MeGUI\tools\x265\x64\x265.exe" - --frames 1440 --fps 24000/1001 --input-res 1280x534--tune ssim --crf 23 --output-depth 12 --input-depth 16 --input-csp i444 --ssim --output D:\!x264\x265_crf23_medium.hevc --[Error] [16.04.2016 18:46:29] Standard error stream ---[Warning] [16.04.2016 18:46:29] x265 [warning]: extra unused command arguments given <ssim> ---[Error] [16.04.2016 18:46:29] avs [error]: Error occurred while writing frame 0 ---[Information] [16.04.2016 18:46:29] (Maybe x265.exe closed) --[Error] [16.04.2016 18:46:29] Process exits with error: 1 --[Information] [16.04.2016 18:46:29] Job completed edit: tried some more. it seems it is a general problem if one tries to use a custom command line in the x265 configuration dialog. edit2: by removing the parameter "--input-csp i444" (which should be optional according to the commandline help) the issue disappeared. weird... Last edited by Sp00kyFox; 16th April 2016 at 20:54. |
29th April 2016, 12:48 | #5046 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
The numbering in the changelog seems to be a little off:
2934 [L-SMASH Indexer] added support for MSVC 2015 runtimes 2933 updated the wiki links to point to https://en.wikibooks.org/wiki/MeGUI 2931 [MediaInfo] improved DVD audio track language detection 2930 [Audio Encoder] fixed a crash if a very large audio delay is used I assume they should be 2630, 2631, 2633 and 2634? |
22nd May 2016, 23:08 | #5048 | Link |
Registered User
Join Date: Feb 2004
Location: NYC
Posts: 124
|
MediaInfo consistently throws up errors when I load up an avs:
Code:
[Error] [5/22/2016 5:55:31 PM] Error parsing media file D:\path\to\video.avs |
23rd May 2016, 08:16 | #5049 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
I would not be surprised about that. AviSynth scripts are text files. I doubt that MediaInfo supports the AviSynth API to report details about the frameserver output. MediaInfo is a tool to analyze headers of "physical" media files, it will most probably not handle logical media sources.
But I believe MeGUI should not report this error prominently when using an AviSynth script as source. There is not much sense in checking *.avs with MediaInfo, except to ensure that it is not an accidentally renamed file with a wrong filename extension. |
23rd May 2016, 13:26 | #5050 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
I assume you're referring to loading a script in the video section for encoding? Under the MediaInfo section in the log file, I found this after loading a script and having a look. Quote:
I reverted AvisynthWrapper.dll in the MeGUI folder to the old version quite a while ago. I don't know the version number but the file date is 2009. I haven't tried the new one again since, but it gave me grief at the time, hence the switch. It's something you could try. A slightly related question..... Has anyone noticed if loading scripts with LWLibavVideoSource (and probably also containing slow filtering such as QTGMC), takes a fair bit longer than the same script with ffmsindex? The cursor turns to "busy" for a little while, then the script loads. It's not a tragically long time but I'm sure it takes longer than an ffms2 script to load. It could be an XP thing or the older XP compatible L-Smash I'm using, and I did play with AvisynthWrapper.dll, which is why I'm asking the question. I don't have a non-XP PC I can use as a comparison at the moment, so I'm wondering if anyone else has noticed a script loading speed difference. Encoding speed is fine, it's just the script loading. Last edited by hello_hello; 23rd May 2016 at 13:28. |
||
24th May 2016, 11:55 | #5051 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Specifically mentioning XP (in case I should), is there a way to tell software to stop complaining and get on with it if the software itself doesn't offer an option to try?
MeGUI drives me a little nutty with this when it's in the middle of an encoding job and there's a few in the queue. The job still finishes, but I have to keep my eye on the x264 process using Task Manager and restart MeGUI's job queue when it's done. This was a result of my second favourite way to make MeGUI think it's crashed.... by changing the resolution of the output with complex filtering in the script, maybe combined with having done something dumb, then refreshing the preview. As you can see from the the tasks I initiated after it happened (aside from the running encode), MeGUI appears to be functioning perfectly. I'd like to be able to dismiss the error message or at least change it's "always on top" status so it's not in the way. I'm not sure if it's possible at the moment though. Thanks. |
15th July 2016, 19:25 | #5054 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
As a result of a discussion here I discovered a bit of a problem with MeGUI muxing DVD subtitles into an MP4 container.... sometimes..... but here's a copy and paste of what I wrote in the other thread after a bit of experimenting.
It seems there's an oddity in the way VobSubber extracts subtitles and the way MeGUI adds them to the command line for MP4 muxing in relation to the track number of the subtitle.... or something..... I'm not 100% sure yet. It seems though, automatically adding them via the OneClick encoder mightn't always work. When I opened the IFO file I was using for testing, VobSubber showed a single English subtitle stream numbered 01. When I checked the "show all subtitle streams" option there was a stream 00 listed, a stream 02 listed, a stream 03 listed etc, but all listed as "not detected". I extracted the single English stream and MeGUI used the following to add it to the command line for MP4 muxing: -add "E:\testing\VTS_01_0.idx#trackID=1:lang=eng:na me=" There was an obscure warning in the log file about "track 1 ID not being found in file" and there were no subtitles muxed. I tried again, but rather than selecting the single subtitle when extracting, I checked "keep all subtitle streams" in VobSubber. Only the stream "01 English" was being displayed. After extracting I tried muxing again and MeGUI created the same command line. This time though, the subtitles were muxed and the warning was replaced with: VobSub import - subpicture stream 'eng' I don't quite understand what's happening. When opened with VobSubber, the English subtitle (and the only subtitle) appears to be track one (although the first stream could be track zero). When extracting by selecting the single English stream VobSubber must extract it as track zero and MeGUI can't find it, although why it detects it as track one when adding it for muxing I don't know. I'm making guesses here, but if it's a track identification problem it only effects MP4 muxing as far as I can tell. MKV muxing is fine. I tried three different versions of MP4Box and I could successfully mux the subtitle file MeGUI didn't mux with MyMP4BoxGUI, so I'm fairly confident Mp4Box is not to blame. Anyone experienced anything similar? Last edited by hello_hello; 15th July 2016 at 19:30. |
24th July 2016, 07:16 | #5056 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
http://forum.videohelp.com/threads/3...=1#post2453503 There's a possible issue with MeGUI detecting subtitles in DVD (IFO) files I'm yet to test properly, but that aside, MeGUI detected a single subtitle stream for the DVD I was experimenting with, and they were subtitle stream one. Subtitle streams appear to be numbered beginning with zero, so in this case after VobSubber extracted the subtitle stream, it created an idx file where stream 0 was empty and stream 1 contained the subtitles. Best as I can tell, when muxing subtitles into an MP4, MeGUI always specifies track 1 in the command line. Track 1 = Subtitle Stream 0, which means when Stream 0 is empty no subtitles are muxed. When muxing MKVs, whatever the command line MeGUI uses (I can't remember) MKVToolnix always muxes all the streams containing subtitles (found in the extracted idx file). If what I've written doesn't make immediate sense, the screenshots in the post I link to should illustrate the problem. |
|
29th July 2016, 18:46 | #5057 | Link |
Registered User
Join Date: Mar 2014
Location: Germany
Posts: 6
|
I installed this days Windows 10 on my new Computer and have now a problem with MeGui.
Since I have Win10 installed, I can't drag & drop any file into MeGui. For other programs (for example MKVToolNix, MKVExtractGui or TSMuxerGui), there are no issues. As I know, it has to do with User account control, but disabling UAC should not be the solution. Because drag & drop works in other programs as well, I think there must be another way. Do you known this issues and is there a solution or you working on a solution? Greets Carlo |
31st July 2016, 22:10 | #5058 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
The reason is probably that MeGUI wants to create job files below its installation directory.
The most usual solution is to install MeGUI outside of an UAC monitored directory branch (e.g. if you have several partitions, to D:\MeGUI). To adapt the structure of MeGUI to circumvent the UAC would require some efforts (e.g. storing job files as well as executable tools - to be easily updateable - in %APPDATA%). Last edited by LigH; 31st July 2016 at 22:13. |
Thread Tools | Search this Thread |
Display Modes | |
|
|