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 14th April 2016, 13:23   #5041  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th April 2016, 16:14   #5042  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
Quote:
Originally Posted by adem940 View Post
did as you said, replaced it with new one but crashed at 67% :/
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.
Ma is offline   Reply With Quote
Old 14th April 2016, 16:53   #5043  |  Link
hello_hello
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.
hello_hello is offline   Reply With Quote
Old 16th April 2016, 12:23   #5044  |  Link
adem940
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.
adem940 is offline   Reply With Quote
Old 16th April 2016, 17:50   #5045  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
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
between the paramters "--input-res 1280x534" and "--tune ssim" is a missing space.

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.
Sp00kyFox is offline   Reply With Quote
Old 29th April 2016, 12:48   #5046  |  Link
hello_hello
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?
hello_hello is offline   Reply With Quote
Old 20th May 2016, 20:53   #5047  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
QAAC v2.59 is out
Barough is offline   Reply With Quote
Old 22nd May 2016, 23:08   #5048  |  Link
bilditup1
Registered User
 
bilditup1's Avatar
 
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
I'm not sure when this started happening but I don't think it was an issue with the previous version of MeGUI/MediaInfo (on 2634/0.7.84.0, respectively)
bilditup1 is offline   Reply With Quote
Old 23rd May 2016, 08:16   #5049  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 23rd May 2016, 13:26   #5050  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by bilditup1 View Post
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
I'm not sure when this started happening but I don't think it was an issue with the previous version of MeGUI/MediaInfo (on 2634/0.7.84.0, respectively)
It's fine for me (running XP) and MeGUI 2634.
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:
[Information] [23/05/16 9:32:35 PM] MediaInfo
-[Information] [23/05/16 9:32:35 PM] File: D:\Video.lwi
-[Information] Indexed File: E:\Source Video.mkv
Are you using the same file indexing or script opening method each time?

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.
hello_hello is offline   Reply With Quote
Old 24th May 2016, 11:55   #5051  |  Link
hello_hello
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.

hello_hello is offline   Reply With Quote
Old 28th May 2016, 20:08   #5052  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
MediaInfo 0.7.86
MKVToolNix v9.2.0
QAAC v2.59
x264 r2705

Last edited by Barough; 18th June 2016 at 15:53.
Barough is offline   Reply With Quote
Old 2nd July 2016, 16:09   #5053  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
FFmpeg v3.1.1 'Laplace' (July 1st, 2016)
MediaInfo 0.7.87
Barough is offline   Reply With Quote
Old 15th July 2016, 19:25   #5054  |  Link
hello_hello
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.
hello_hello is offline   Reply With Quote
Old 18th July 2016, 16:32   #5055  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
MKVToolNix v9.3.1
x265 v2.0
Barough is offline   Reply With Quote
Old 24th July 2016, 07:16   #5056  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by hello_hello View Post
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.
In that same thread I eventually wrote a lengthy post describing the cause of the problem as I understand it.
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.
hello_hello is offline   Reply With Quote
Old 29th July 2016, 18:46   #5057  |  Link
Carlo75
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
Carlo75 is offline   Reply With Quote
Old 31st July 2016, 22:10   #5058  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
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%).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 31st July 2016 at 22:13.
LigH is offline   Reply With Quote
Old 1st August 2016, 17:09   #5059  |  Link
Carlo75
Registered User
 
Join Date: Mar 2014
Location: Germany
Posts: 6
I reinstalled MeGui on another patition and now works.
Thank you for support!

Greets Carlo

Last edited by Carlo75; 1st August 2016 at 17:26.
Carlo75 is offline   Reply With Quote
Old 5th August 2016, 02:35   #5060  |  Link
NyaR
Registered User
 
Join Date: Nov 2012
Posts: 10
every time user exports preset on megui version > 2525 the output zip is blank
NyaR 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 14:54.


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