Log in

View Full Version : MeGUI: General Questions and Troubleshooting Thread


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 [89] 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186

rapscallion
29th June 2009, 21:41
i know... everything from quant 18 and below is generally transparent... .
Quick question. Are you saying the average, like this :
---[NoImage] x264 [info]: slice I:8228 Avg QP:15.07 size: 96212
---[NoImage] x264 [info]: slice P:67843 Avg QP:16.18 size: 48725
---[NoImage] x264 [info]: slice B:83215 Avg QP:17.21 size: 27918
or the actual qp at any given point? Because, let's say the average is 18 in the 3 slices, then obviously some qp is above and some below. Sorry for the noob questions but I do find this stuff very interesting :confused:

kumi
29th June 2009, 22:39
One-click x264 jobs do not work for me. When I enqueue and run a one-click x264 job, MeGUI spits out:
--[Error] An error occurred: x264 [error]: can't open `'

When I look at the XML VideoJob file created by the one-click process, it contains:
<UseQPFile>true</UseQPFile>
<QPFile />

This is wrong: my x264 profile has "Use qp File" unchecked. When I load an .AVS file in the MeGUI Main tab and enqueue it directly using this same x264 profile, the resulting VideoJob XML is correct and encodes without errors. It contains:
<UseQPFile>false</UseQPFile>
<QPFile>.qp</QPFile>

Also, if I edit the x264 profile and make any changes to the "Use QP file" setting, the changes don't stick. It always shows the box unchecked, with a filename of ".qp".

Tested on a Clean XP SP3 VMware image + Windows Security updates + .NET 2.0 SP1 + DirectX 9.0 March 2009 redist + MeGUI 0.3.1.1046 fully updated

Can anyone reproduce?

Sharktooth
30th June 2009, 02:17
Quick question. Are you saying the average, like this :
---[NoImage] x264 [info]: slice I:8228 Avg QP:15.07 size: 96212
---[NoImage] x264 [info]: slice P:67843 Avg QP:16.18 size: 48725
---[NoImage] x264 [info]: slice B:83215 Avg QP:17.21 size: 27918
or the actual qp at any given point? Because, let's say the average is 18 in the 3 slices, then obviously some qp is above and some below. Sorry for the noob questions but I do find this stuff very interesting :confused:
it depends on what you want to compare. in both cases if you have an average qp18 encode you're encode will look as the original (except on cases where psy options make a huge difference).

@kumi: ill have a look at it as soon as i find some time. keep in mind im actually really busy 'till august.
be sure to post that in the megui bugtracker on sourceforge, so i wont forget it...

rack04
30th June 2009, 03:23
Currently AVS Script Creator will not use Nvidia Deinterlacer with DGM files. This should be possible with the latest releases.

kumi
30th June 2009, 03:33
@kumi: ill have a look at it as soon as i find some time. keep in mind im actually really busy 'till august.
be sure to post that in the megui bugtracker on sourceforge, so i wont forget it...
Roger that, thanks. Submitted as Broken one-click x264 VideoJob XML - ID: 2814331 (http://sourceforge.net/tracker/?func=detail&aid=2814331&group_id=156112&atid=798476). In the meantime I will downgrade to 0.3.1.1014, which doesn't have the qp file settings.

If I use the built-in updater and update all MeGUI components _except_ core, is that safe?

DJ Alik
30th June 2009, 07:32
Is there a limit on how big the final file can be? I am using meGui to mix 4 files into mp4 and it keeps crashing in the mp4box module on ntdll.dll

Log Name: Application
Source: Application Error
Date: 6/30/2009 1:25:40 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: ******
Description:
Faulting application MP4Box_x64.exe, version 0.0.0.0, time stamp 0x49cd37cd, faulting module ntdll.dll, version 6.0.6002.18005, time stamp 0x49e0421d, exception code 0xc0000374, fault offset 0x00000000000aef37, process id 0x18a8, application start time 0x01c9f94ade2b4e70.


Here are the files that I tried to put in there:

Complete name : movie.h264
Format : AVC
Format/Info : Advanced Video Codec
File size : 3.79 GiB

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Width : 704 pixels
Height : 304 pixels
Display aspect ratio : 2.35
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Writing library : x264 core 67 r1173M f6d3166
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=12 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=12 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=8.0 / qcomp=0.50 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=24000 / vbv_bufsize=24000 / ip_ratio=1.10 / pb_ratio=1.10 / aq=1:1.00

audio:
Complete name : audio.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 348 MiB
Duration : 2h 8mn
Overall bit rate : 379 Kbps
Encoded date : UTC 2009-06-29 12:46:39
Tagged date : UTC 2009-06-29 12:57:46
Writing application : Nero AAC codec / 1.3.3.0
cdec : ndaudio 1.3.3.0 / -cbr 384000 -lc

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 2h 8mn
Bit rate mode : Variable
Bit rate : 384 Kbps
Maximum bit rate : 504 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Rear: L R, LFE
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 346 MiB (100%)
Encoded date : UTC 2009-06-29 12:46:39
Tagged date : UTC 2009-06-29 12:57:46

subtitles:
subtitle.srt 122,880 bytes

chapters
chapters.txt 4,096 bytes

I tried on both XPSP3 and Vista 64 SP2

rapscallion
1st July 2009, 17:23
it depends on what you want to compare. in both cases if you have an average qp18 encode you're encode will look as the original (except on cases where psy options make a huge difference).


Thanks Sharktooth ! (psy options are via the SA-AVCHD preset)

ctl-tx
1st July 2009, 18:51
I would like to use MeGUI's audio cutter to cut some sound samples. Unfortunately, I don't know the proper way to create a cutlist for it. Is it just a sequence of times in a text file? And if so what format are they in and how are they arranged? Otherwise, how do I make a cutlist file? Please help.

Redsandro
2nd July 2009, 03:49
Not sure if this is the right place to ask, but maybe some of you had similar issues.

In Windows 7 x64 I get "x264 has stopped working" with any video and any settings.
Same video and settings work just fine in XP.

Do I need to tweak something to get this working?
Same problem with FFMPEG btw..

daberti
2nd July 2009, 08:49
I've a silly question for you folks.
My TV set supports only 720p and 1080i. PAL
I've a bunch of 1080p Blu-ray material and I'd like to make AVCHD out of it.
1)Better using 1080i or 720p on my TV set?
2)Supposing 8000mbps is the perfect video bitrate for 1080p AVC-H264 encoding, what video bitrate would you recommend me for 720p?

Thanks

tebasuna51
2nd July 2009, 10:01
My TV set supports only 720p and 1080i. PAL
I've a bunch of 1080p Blu-ray material and I'd like to make AVCHD out of it.
1)Better using 1080i or 720p on my TV set?
2)Supposing 8000mbps is the perfect video bitrate for 1080p AVC-H264 encoding, what video bitrate would you recommend me for 720p?

If you need recode your video better use 720p, but 1080p can be played also in HD Ready TV.

8000Kb/s is a low bitrate for 1920x1080 (Qf=0.16), at least 10000Kb/s (Qf=0.2), for average video material, is needed.

The relation between 1080 and 720 bitrate is:
(1920x1080)/(1280x720) = 2.25
then 10000Kb/s for 1080 is equivalent to 4500 Kb/s for 720

Douchie
2nd July 2009, 14:33
Hello all,

I have seem to run into a problem with MeGUI. I can't seem to get ANY of the encoder profiles for x264 or xvid to work with one click encoder.... as in I'll add the project to the queue list and click start, but it goes straight to skip in the status tab. I looked under the log tab and it said this:

Error starting job
Exception message: File exists and the user doesn't want to overwrite
Stacktrace: at MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
Inner exception: null


Any help would be great, thanks.

Also, running Vista 64bit SP2

ctl-tx
2nd July 2009, 15:46
Seems to me that this is your problem:
Exception message: File exists and the user doesn't want to overwrite

Check the output filename, is it the same as the input? Is there a file by that name in the target directory?

b66pak
2nd July 2009, 17:09
nicaudio has been updated...

http://forum.doom9.org/showthread.php?p=1300059#post1300059

can you include it in megui autoupdate?
_

Sharktooth
2nd July 2009, 17:45
no, since the syntax has changed. megui code needs to be updated and i actually have no time to do that.

daberti
2nd July 2009, 18:53
Sharktooth, I'm using your x264_dp_ Standalone-PS3-Xbox360_Fast.xml profile.
This in order to encode my m2ts files to an AVCHD compatible standard.
Yet I'd like to proceed even faster, without losing AVCHD compatibility. Any hint to a newbie?
Thanks for your profiles :)

Dan

nurbs
2nd July 2009, 19:19
First off the PS3/Xbox360 profile probably isn't really AVCHD compatible because of the high keyframe intervall and the missing --nal-hdr switch. Also AVCHD compatibility demands specific framesizes.
If you want faster encoding you can lower trellis, M.E. Range, M.E. Algorithm, the b-frame decision or subpixel refinement. You can turn off mixed references, lower the number of reference frames and lower the number of b-frames.

Sharktooth
2nd July 2009, 21:03
well... what nurbs said plus ensure to use fast avisynth filters and no complex scripts.

kumi
2nd July 2009, 22:06
Hello all,

I have seem to run into a problem with MeGUI. I can't seem to get ANY of the encoder profiles for x264 or xvid to work with one click encoder.... as in I'll add the project to the queue list and click start, but it goes straight to skip in the status tab. I looked under the log tab and it said this:

Error starting job
Exception message: File exists and the user doesn't want to overwrite
Stacktrace: at MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
Inner exception: null


Any help would be great, thanks.

Also, running Vista 64bit SP2See my "malformed VideoJob XML" bug I reported recently: http://sourceforge.net/tracker/?func=detail&aid=2814331&group_id=156112&atid=798476

When attempting an x264 One-Click job, do you see the same --[Error] An error occurred: x264 [error]: can't open `' error when you look in the Log tab? If yes, maybe it's the same bug, so post a quick comment in the sourceforge bug page confirming it.

daberti
2nd July 2009, 23:24
well... what nurbs said plus ensure to use fast avisynth filters and no complex scripts.

I tried with original resol. (1080p) thus no resize...6 hours expected for first pass to complete on 1hr 1/2 source on my Core2 Duo processor T7200 and 4GB of DDR2...no way...

nurbs
3rd July 2009, 08:11
That's not really slow. If you do an automated to pass encoding with turbo the only thing you can do to speed up the first pass is changing the b-frame decision from optimal (--b-adapt 2) to fast (--b-adapt 1).

tebasuna51
3rd July 2009, 10:48
nicaudio has been updated...
can you include it in megui autoupdate?

no, since the syntax has changed. megui code needs to be updated and i actually have no time to do that.

No problem with syntax, was only a mod to skip ID3v2,3,4 tags in mpX to avoid false headers.

Everybody can safely replace the v2.0.2 with v2.0.3

Sharktooth
3rd July 2009, 12:28
tnx. i'll update it then.

mczuzlak
5th July 2009, 22:42
I would like to get 3 threads in MeGui with my E8400 but I only get 2 of them. I've tried to set it manualy in the x264 commandline to 3 but no luck. Same with the default 0.
Any ideas what am I doing wrong ? :-)

daberti
6th July 2009, 23:38
That's not really slow. If you do an automated to pass encoding with turbo the only thing you can do to speed up the first pass is changing the b-frame decision from optimal (--b-adapt 2) to fast (--b-adapt 1).

Thanks. Should I change it for both passes or should I choose 1st pass only?
As a matter of fact my TV is HD Ready and not Full HD compliante, thus I'll stay with 720p, with significantly shorter encoding times.

nurbs
6th July 2009, 23:56
Frametype decision is done in first pass so changing it in the second doesn't have any effect.
BTW I also do 720p (or equivalent number of pixels for 2.35:1 AR) but I'm using --b-adapt 2 (with 3 b-frames). Quality is good enough for me and I like the comparatively smaller filesizes with crf encodes.
Also someone is working on on a patch for threaded lookahead, so if that's ever finished --b-adapt 2 should get faster.

Sharktooth
7th July 2009, 12:53
I would like to get 3 threads in MeGui with my E8400 but I only get 2 of them. I've tried to set it manualy in the x264 commandline to 3 but no luck. Same with the default 0.
Any ideas what am I doing wrong ? :-)
why you need to set 3 threads when 0 = auto that also mean 3 threads?
look in the preset configuration window, you will find a Threads option.

mczuzlak
7th July 2009, 17:02
It is set to 0. And I've got still only 2 threads. There are 10 jobs in my queue list and only 2 encodes at a time. Why ??

nurbs
7th July 2009, 17:29
Threads aren't used to make multiple encodes at the same time, they are there to speed one encode up basically by sending different frames to each core. If you want to do encodes simultaneously you need to add more workers. If you do that it is probably advisable to set the number of thread to 1 and use as many workers as your processor got cores, because using threads slightly reduces quality.

mavinashbabu
7th July 2009, 18:34
The way i use is split the total frames into 2 .avs files equally using Trim() function and send one job in worker1 and another to worker2, and run both of them which will complete the entire encode in < 11 hrs for 2hr and 20 mins long film.

I will join the resulting 2 videos by using VirtualDUB or MKVToolnix depending on the container i encoded.

Profile i use is x264 lossless

mczuzlak
7th July 2009, 18:54
Threads aren't used to make multiple encodes at the same time, they are there to speed one encode up basically by sending different frames to each core. If you want to do encodes simultaneously you need to add more workers. If you do that it is probably advisable to set the number of thread to 1 and use as many workers as your processor got cores, because using threads slightly reduces quality.

Thx to clarify this for me.:)

jmnk
9th July 2009, 06:30
first let me state that megui is a first class piece of software. But after trying to see reasoning I need to ask finally - what is the logic behind MeGui calculated --sar value. I mean I have pretty good understanding of what sar is for, so that is not the issue. But consider the following:
I encode a 16:9 NTSC DVD, after creating d2v file I load it to create avs. MeGUI correctly recognizes the source (input dar says 16:9 NTSC). I do no resizing, just cropping top and bottom black bars. So SAR should not be affected at all. Well, the 16:9 NTSC DVD has only one correct SAR, it is 32:27. Ok, if we go with ITU it could be 40:33. There should not be any other values, ever. So why is it that MeGUI comes up with these values like --sar 1969:1620. Again, I only talk about no-resize scenario.
Also, if I do not check clever anamorphic encoding MeGUI assumes that sar is 1:1, even if I specify my own SAR on the command line options (let's say I do --sar 32:27). Which results in the command line that has two sar options specified --sar 1:1 and --sar 32:27. I'm assuming that since my option is 'later' on on the line it actually is used, yes?

LigH
9th July 2009, 07:10
It appears the the MeGUI crashes when an AviSynth script is loaded which does not contain MOD 4 crop values.

See the attached screenshot in this german thread (http://forum.gleitz.info/showthread.php?t=40294).

MrVideo
9th July 2009, 09:16
I have pretty good understanding of what sar is for, so that is not the issue. But consider the following:

I think you do not have a complete handle on SAR (Source Aspect Ratio). I don't either, as explained below.

I encode a 16:9 NTSC DVD,

Why? Why not just use the files directly, instead of doing an encoding, only to re-encode again (resulting in reduced quality and MPEG-2 encoding errors from the multiple encodings)? Am I misunderstanding something? Just what is the original source?

after creating d2v file I load it to create avs. MeGUI correctly recognizes the source (input dar says 16:9 NTSC). I do no resizing, just cropping top and bottom black bars. So SAR should not be affected at all.

Not true, the SAR is definately affected. Is the source 2.35:1 displayed in a 16:9 frame, hence the letterbox bars? Because you cropped, the source is no longer at the SAR it originally was.

Well, the 16:9 NTSC DVD has only one correct SAR, it is 32:27. Ok, if we go with ITU it could be 40:33. There should not be any other values, ever. So why is it that MeGUI comes up with these values like --sar 1969:1620. Again, I only talk about no-resize scenario.

As stated above, you did resize it, when you cropped off the letterbox bars. It is no longer 720x480. If the video is 2.35:1, that would make the new size 720x364. The SAR has changed.

The weird SAR values are a result of the video not being 16:9.

Also, if I do not check clever anamorphic encoding MeGUI assumes that sar is 1:1, even if I specify my own SAR on the command line options (let's say I do --sar 32:27). Which results in the command line that has two sar options specified --sar 1:1 and --sar 32:27. I'm assuming that since my option is 'later' on on the line it actually is used, yes?

Replace the 1:1 SAR value with the new SAR. Don't just add another --sar, replace the existing.

OK, now this is where I don't get how 32:27 is determined. It isn't just SAR, as a 720x480 file has a SAR of 1.5:1, or 3:2. The DAR gets into that value as well, somehow, but I haven't discovered the magic formula.

If there is someplace within Doom9 that explains how the SAR value is determined, I do not know where it is.

nurbs
9th July 2009, 10:57
It appears the the MeGUI crashes when an AviSynth script is loaded which does not contain MOD 4 crop values.

See the attached screenshot in this german thread (http://forum.gleitz.info/showthread.php?t=40294).


Works fine for me with mod2 both vertical or horizontal. I didn't have a .d2v to test so I used DirectShowSource(). Also I didn't encode it, I only loaded it so the preview window came up, but that shouldn't make a difference and I can enqueue it without a problem.

Sharktooth
9th July 2009, 12:28
It appears the the MeGUI crashes when an AviSynth script is loaded which does not contain MOD 4 crop values.

See the attached screenshot in this german thread (http://forum.gleitz.info/showthread.php?t=40294).
not all avisynth filters like mod4 resolutions.

j8ee
9th July 2009, 16:54
I wanted to rearrange the video output name, but instantly discovered that the shortcut normally used for cutting text into the clipboard is the exit command. :( Actually, it wasn't that instant I understood it, I thought it was a crash first, preparing to leave a bug report. Leaving the Windows defaults alone and using Cmd-Q or Alt-X would be a better choice I think.

jmnk
9th July 2009, 17:30
I think you do not have a complete handle on SAR (Source Aspect Ratio). I don't either, as explained below. I believe in Megui (or more specifically in x264) SAR means Sample Aspect Ratio, so perhaps your entire post is based on wrong assumption. I'm sorry if I did not clearly stated what I mean by SAR.

Why? Why not just use the files directly, instead of doing an encoding, only to re-encode again (resulting in reduced quality and MPEG-2 encoding errors from the multiple encodings)? Am I misunderstanding something? Just what is the original source?

When I say I encode 16:9 NTSC DVD I mean 'I take a ripped DVD, run it through dgindex, create avs file and feed it to x264. It's not like I encode something --to-- DVD and than talke that and encode with MeGUI'. Again, sorry if that wasn't clear.


Not true, the SAR is definately affected. Is the source 2.35:1 displayed in a 16:9 frame, hence the letterbox bars? Because you cropped, the source is no longer at the SAR it originally was.



As stated above, you did resize it, when you cropped off the letterbox bars. It is no longer 720x480. If the video is 2.35:1, that would make the new size 720x364. The SAR has changed.

The weird SAR values are a result of the video not being 16:9.
I think that has been beaten to death many times, cropping does not change Sample Aspect Ratio.


Replace the 1:1 SAR value with the new SAR. Don't just add another --sar, replace the existing. Cool. Where exactly do I do that in MeGui? The replacing part. The SAR replacing.

OK, now this is where I don't get how 32:27 is determined. It isn't just SAR, as a 720x480 file has a SAR of 1.5:1, or 3:2. The DAR gets into that value as well, somehow, but I haven't discovered the magic formula.That is the easiest question. 32:27 comes from the fact that in order to make 720x480 DVD (the DVD standard) into 16:9 Display Aspect Ratio (the common TV resolutions) you need to make 720 into 853 pixels (because 853/480=16/9). And 720 * 32/27 = 853

@MrVideo thanks for response although I must say it does not bring any explanation to the discussion. Maybe I stated my problem wrongly.

So could someone knowledgeable comment on why MeGUI calculates those starnge SAR values?

Keiyakusha
9th July 2009, 18:18
Well this is my understanding, i can be wrong... Also I'm not using any auto-stuff and allways do resize/crop/setting ratios by myself so I can not fully understand megui's process.

First of all, sometimes by "SAR" peoples actually means PAR (pixel aspect ratio). This can be really confusing. I believe SAR is the original resolution (real width divided by real height). So image 720x480 - SAR 1.5; 640x480 - SAR 1.3, 873x349 - 2.5 and so on. But we don't need this.

All NTSC 16x9 DVDs has PAR 32:27. But if picture has black borders (letterbox), this mens that original video is not 16x9. It can be 1.85:1, 2.35:1, 2.4:1 etc. Its PAR depends on resolution that we get after cropping black borders and (maybe) resizing. So Megui calculates closest one.

j8ee
10th July 2009, 03:36
Is there a way to make your own first and second passes and encode them automatically? I'd like to use one really fast crf setting for first pass, and then feed the achieved bitrate from that pass to the second pass. I'm thinking maybe there is some kind of internal megui variable, like adding --bitrate %bitrate% to the custom command line, and %bitrate% would be stored from the previously run pass?

As I'm doing it now I first run a normal fast crf encode with --pass 1 and output nul and check the log for achieved bitrate when it's finished. (Even though output is nul, an empty file is written, a little strange.) Then I edit the second pass profile and put in the bitrate, save that, and start the final pass. So it's impossible to do a batch of files this way, it's constant waiting and manual editing.

I'm using this crf+second pass approach because crf and a VBV limit apparently doesn't work that well together, and if the crf bitrate would like to go over that limit, a second pass will make the best of it, as I understood it (post (http://forum.doom9.org/showthread.php?p=1304075#post1304075)). (And yes, if someone can clarify if you really should/must use VBV in both passes or if it's enough just in the last one, it would be appreciated!)

Sharktooth
11th July 2009, 16:10
Well this is my understanding, i can be wrong... Also I'm not using any auto-stuff and allways do resize/crop/setting ratios by myself so I can not fully understand megui's process.

First of all, sometimes by "SAR" peoples actually means PAR (pixel aspect ratio). This can be really confusing. I believe SAR is the original resolution (real width divided by real height). So image 720x480 - SAR 1.5; 640x480 - SAR 1.3, 873x349 - 2.5 and so on. But we don't need this.

All NTSC 16x9 DVDs has PAR 32:27. But if picture has black borders (letterbox), this mens that original video is not 16x9. It can be 1.85:1, 2.35:1, 2.4:1 etc. Its PAR depends on resolution that we get after cropping black borders and (maybe) resizing. So Megui calculates closest one.
SAR is (AKA) PAR. period.

@jmnk: MeGUI will encode with the original AR found on the DVD (that depends on how it was authored...). if the video gets resized MeGUI will correct the AR accordingly.

@j8ee: no automated way. 2pass encoding was not thought to be used that way.

kumi
11th July 2009, 16:27
MeGUI will encode with the original AR found on the DVDYeah, but watch out... MeGUI AR autodetection uses ITU values, which are often wrong for modern DVD content. In my experience.

Sharktooth
11th July 2009, 16:33
Yep since ITU is the standard for TVs.
Modern TVs are not meant to show anamorphic stuff anymore since we're in the HD era...

LeXXuz
11th July 2009, 16:42
I'm having trouble transcoding DTS-Audio files.

[Error] Log for job18 (audio, dtstest_6ch_768k_de.dts -> dtstest_6ch_768k_de.mp4)
-[Information] [11.07.2009 17:26:00] Started handling job
-[Information] [11.07.2009 17:26:00] Preprocessing
-[NoImage] Avisynth script
--[NoImage] DirectShowSource("D:\WORK\dtstest_6ch_768k_de.dts")
--[NoImage] EnsureVBRMP3Sync()
--[NoImage] 6<=Audiochannels(last)?x_dpl2b65f6e27c9c7451184cf89db8ea7d7c2(ConvertAudioToFloat(last)):last
--[NoImage] Normalize(0.9)
--[NoImage] return last
--[NoImage] function x_dpl2b65f6e27c9c7451184cf89db8ea7d7c2(clip a)
--[NoImage] {
--[NoImage] fl = GetChannel(a, 1)
--[NoImage] fr = GetChannel(a, 2)
--[NoImage] c = GetChannel(a, 3)
--[NoImage] sl = GetChannel(a, 5)
--[NoImage] sr = GetChannel(a, 6)
--[NoImage] ssl = MixAudio(sl, sr, 0.2818, 0.1627).Amplify(-1.0)
--[NoImage] fl_c = MixAudio(fl, c, 0.3254, 0.2301)
--[NoImage] ssr = MixAudio(sl, sr, 0.1627, 0.2818)
--[NoImage] fr_c = MixAudio(fr, c, 0.3254, 0.2301)
--[NoImage] l = MixAudio(ssl, fl_c, 1.0, 1.0)
--[NoImage] r = MixAudio(ssr, fr_c, 1.0, 1.0)
--[NoImage] return MergeChannels(l, r)
--[NoImage] }
-[NoImage] Commandline used: -ignorelength -lc -br 128000 -if - -of "{0}"
-[Information] [11.07.2009 17:26:00] Encode thread started
-[Information] [11.07.2009 17:26:00] Encoding started
-[Information] [11.07.2009 17:26:00] Avisynth script environment opened
-[Error] An error occurred
--[NoImage] Exception message
---[NoImage] DirectShowSource: Could not open as video or audio.
---[NoImage] Video returned: "DirectShowSource: couldn't open file D:\WORK\dtstest_6ch_768k_de.dts:
---[NoImage] Die Datei kann nicht wiedergegeben werden. Das Format wird nicht unterstützt."
---[NoImage] Audio returned: "DirectShowSource: couldn't open file D:\WORK\dtstest_6ch_768k_de.dts:
---[NoImage] Die Datei kann nicht wiedergegeben werden. Das Format wird nicht unterstützt."
--[NoImage] Stacktrace
---[NoImage] bei MeGUI.AviSynthClip..ctor(String func, String arg, AviSynthColorspace forceColorspace, AviSynthScriptEnvironment env)
---[NoImage] bei MeGUI.AviSynthAudioEncoder.encode()
--[NoImage] Inner exception: null
-[Information] [11.07.2009 17:26:05] Job completed

It seems DirectShow does not know what do to with the DTS-file. Avisynth is correctly installed, ffdshow (with enabled DTS-decoding) as well.

I don't know how to fix this and would appreciate any help. :)

Sharktooth
11th July 2009, 16:47
ac3filter?

LeXXuz
11th July 2009, 16:53
ac3filter?

Is installed and works. However I cannot playback any DTS-File with MPC (unless I enable the internal DTS-decoder of MPC) => cannot render file.

Simple avs-script with NICAudio works:
NicDTSSource("d:\work\dtstest_6ch_768k_de.dts")

AC3filter is active when using this script. (I can see the icon in the tray).

jmnk
11th July 2009, 19:28
@jmnk: MeGUI will encode with the original AR found on the DVD (that depends on how it was authored...). if the video gets resized MeGUI will correct the AR accordingly.



If I may ask - what kind of logic MeGUI uses to detect how DVD was authored? I thought the only thing it could use is what dgindex file says - which is going to be video resolution and Display Aspect Ratio flag.

You also mentioned that MeGUI uses ITU values. So for NTSC 16:9 DVD it should be 40:33, right? Always, no matter how much I crop the video, right? Why is it than that MeGUI comes up with these 4 digit SAR values, and more often than not varying from one job to another.
Please note that these are theoretical questions - the aspect ratio of MeGUI encoded files are correct (more/less) - just wanted to know why it does not use 40:33 every single time.
Also, if we agree that ITU values should be used - should MeGUI automatically crop any 16:9 NTSC DVD input file from 720 to 704, or at least suggest that the user does it? Because if that is not done than the resulting file (assuming no cropping, no resizing, 720x480 input file resolution) plays at like 720*40/33 = 872 by 480 - which is not really ideal. Not too much of a difference to really complain, but still....

tebasuna51
11th July 2009, 21:00
However I cannot playback any DTS-File with MPC (unless I enable the internal DTS-decoder of MPC) => cannot render file.
Then isn't a MeGUI problem.
Simple avs-script with NICAudio works.
Is always better use a dedicated decoder than directshowsource.

JK1974
12th July 2009, 01:24
Hi,

since a few days, encodings done with the iPhone/iPod/iPod 5.5G profiles are not accepted by my iPod touch anymore - iTunes gives a message that the playback would not work on my device and so no transfer is being done.
Doing little more tests (I unfortunately still have nearly no knowledge about the x264 encoder, that´s why I rely on MeGUI and it´s profiles) I believe that it worked with MeGUI+x264 v1173, while the x264 v1179 (the following daily snapshot I found) seem to have started the problems.
For testing, I used the following line I found on the web:
"C:\Program Files\x264\x264.exe" --crf 22.0 --level 3 --no-cabac --partitions p8x8,b8x8,i4x4 --vbv-bufsize 1200 --vbv-maxrate 10000 --threads auto --output F:\file.mp4 file.avs
The file made with x264 v1173 worked while the file produced by v1179 has been rejected.
If I have read correctly, some standard parameters of x264 have been changed recently - maybe the reasons can be found here, but I hope that it can be fixed by simply selecting or deselecting certain encoding parameters in MeGUI.

Thanks in advance ;)

LeXXuz
12th July 2009, 02:26
Then isn't a MeGUI problem.

Is always better use a dedicated decoder than directshowsource.

I don't want to spend any money in a commercial DTS-decoder. Occasions where I have to transcode DTS streams are too rare for that.


Ok. I will look for some advice in the audio forums...