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

Poutnik
5th March 2013, 08:20
Is it possible to resume an encode in meGUI?

Do you mean stop/resume, or resume as restart ?

For the former, the encoding processes can be suspended, e.g. by Process Explorer.

Or, even the whole computer can be put in Standby/hibernation.
This once or few times happened to me by accident, and after waking up the encoding continued.

x265
5th March 2013, 09:10
MeGUI crashed during the encoding process.

LigH
5th March 2013, 16:17
MeGUI won't know the timestamp / frame number when the crash happened. And even if it knew ... appending incompletely encoded videos is not at all trivial with the complex current formats.

magsoud
5th March 2013, 18:36
How to Add FAAC in MeGUI?

LigH
6th March 2013, 08:28
FAAC has been removed due to the superior quality of QAAC (and even Nero AAC). The quality of FAAC is not even reliably better than the one of LAME MP3.

You don't have to install QuickTime or iTunes to enable the use of QAAC. There are guides how to extract the necessary DLLs and put them where QAAC can access them, without installing the whole software into the system.

raynold
9th March 2013, 08:39
i started to encode a capture dvb HD file.

i used one click encoder with standard x264 and mp3 settings.

Im now at step 4: Automatic deinterlacing

Megui is keeping counting up the time. I am now at 7 days for this step. Time elapsed is 17 minutes.

I have a Intel e8400 and dont remember that this step took so much in the past. what did i do wrong??

raynold
9th March 2013, 18:08
now my remaining time is at 30 days

raynold
10th March 2013, 09:13
After one hole day i aborted the job. As i do righclick and change status from aborted to waiting megui does so but then it switches back to aborted automatically.

AMED
10th March 2013, 10:01
@raynold

post your log please.

raynold
10th March 2013, 10:20
I just started a new job without automatic deinterlacing and that works better.

Before I didnt get to the audio encoding, now i do.

Which log should I post? Should I run a automatic deinterlacing job and abort it at the point the remaining time counts up do ~ 1 months?

At first here is a media info log from the file which I wanna encode:

Allgemein
ID : 16 (0x10)
Complete name : D:\temp\cut\New Sniper Project.ts
Format : MPEG-TS
File size : 8,70 GiB
Duration : 1h 41min
Overall bit rate mode : variabel
Overall bit rate : 12,3 Mbps

Video
ID : 48 (0x30)
Menu ID : 137 (0x89)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : Ja
Format settings, ReFrames : 5 frames
Codec ID : 27
Duration : 1h 41min
Bit rate : 11,2 Mbps
Width : 1 280 Pixel
Height : 720 Pixel
Display aspect ratio : 16:9
Frame rate : 50,000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : progressiv
Bits/(Pixel*Frame) : 0.243
Stream size : 7,95 GiB (91%)
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

Audio
ID : 66 (0x42)
Menu ID : 137 (0x89)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 1h 41min
Bit rate mode : konstant
Bit rate : 448 Kbps
Channel(s) : 2 Kanäle
Channel positions : Front: L R
Sampling rate : 48,0 KHz
Bit depth : 16 bits
Delay relative to video : 27ms
Stream size : 325 MiB (4%)
Language : Deutsch
Language, more info : Clean effects

raynold
10th March 2013, 11:30
Here come my megui log. I ran a job with automatic deinterlacing and aborted at remaining time over 1 day. Although I cleared everything before, it became so big that I had to attach it.

As I went to the Log-Tab i saw, that the megui window is flashing every 1-2 seconds.

I remembered that megui crashed always after I exited the programm after encoding this special file.

----- edit ----

I now cleared the log Tab and got repeatingly poping up error windows

AMED
11th March 2013, 05:00
Hi raynold,

Any chance of uploading a small sample that triggers this problem?

raynold
11th March 2013, 06:04
already encoded without automatic deinterlacing and deleted the source file


by the way: how could i make a small sample of a 8 GB file?

LigH
11th March 2013, 09:12
For the case of AVC in TS: By cutting a few GOPs out with TSSniper (you obviously edited it already - the file name reveals it).

ryszardzonk
11th March 2013, 10:32
Guys have any one been able to solve problem first reported by eni9ma in this post (http://forum.doom9.org/showthread.php?p=1607539#post1607539)?

Just like him I have run into same issue I confirmed earlier (http://forum.doom9.org/showpost.php?p=1615748&postcount=6922) but I do no think it was answered hence the expanded information

that is met with following message in 99/100 encodesWarning: The track number 0 from the file 'D:\mp4\rt dok 03 02 - 2.mkv' can probably not be appended correctly to the track number 0 from the file 'D:\mp4\rt dok 03 02 - 1.mkv': The codec's private data does not match (lengths: 42 and 42). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file.


Resulting mkv file plays correctly only through first part. Skipping past the place where files were joined result in complete garbage on the screen. It does not matter if I join 2 mp4 files with or without audio. Result is the same. Files 1 & 2 by themselves play just fine.

I am using Megui for ages since I first switch from using Nandub + Gordian Knot years ago and this issue never have happen prior to ver 2237. It might have been introduced sometime prior to version 2237 but definitely previous stable version did not have this issue.

Steps to reproduce:
1. Create two or more projects out of a single file in DGIndex 1.5.8 from MeGUI\tools\dgindex\DGIndex.exe [to cut out commercials and to rejoin them later on].
2. Create avisynth sripts using Megui 2237 or higher with same settings for both [resolution, deinterlance, color corection, mpeg2 deblocking]
3. Use x264 high profile / unrestricted to encode with default tunning and following options
program --pass 2 --bitrate 500 --stats ".stats" --bframes 5 --ref 7 --ratetol 7.5 --rc-lookahead 50 --merange 32 --partitions all --no-fast-pskip --output "output" "input"
4. join files in mkvmerge from MeGUI\tools\mkvmerge\mmg.exe

Same happens for any kind of content I can put my hands on - SD, HD, Proggressive, Interlanced you name it. All those files have in common is they are recorded from DVB-S/S2 via IPBOX HD sat receiver and are in PAL standard

Please advice of way to fix that. If any logs are needed please let me know as well.

Kurtnoise
11th March 2013, 11:11
Yes, please post the mediainfo report from rt dok 03 02 - 2.mkv & rt dok 03 02 - 1.mkv files...

ryszardzonk
11th March 2013, 12:59
Here they are. I just recreated them and got the same results hence the date in them is newer than my first post

1.mkv
General
Unique ID : 172130910061999592920723453498473889891 (0x817F351872CAF02CA151BAAA246CC063)
Complete name : D:\mp4\rt dok 03 02 - 1.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 49.6 MiB
Duration : 12mn 40s
Overall bit rate : 547 Kbps
Encoded date : UTC 2013-03-11 11:52:00
Writing application : mkvmerge v6.1.0 ('Old Devil') built on Mar 2 2013 14:32:37
Writing library : libebml v1.3.0 + libmatroska v1.4.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L2.1
Format settings, CABAC : Yes
Format settings, ReFrames : 7 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 12mn 40s
Nominal bit rate : 500 Kbps
Width : 544 pixels
Height : 304 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.121
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=7 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 /
lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 /
b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 /
rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=500 / ratetol=7.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 /
qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 12mn 40s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 20ms
Default : Yes
Forced : No

2.mkv
General
Unique ID : 253343693789735334981335836976384887241 (0xBE983879D70FF297BB94CAD9CDD0C9C9)
Complete name : D:\mp4\rt dok 03 02 - 2.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 51.8 MiB
Duration : 13mn 17s
Overall bit rate : 544 Kbps
Encoded date : UTC 2013-03-11 11:52:02
Writing application : mkvmerge v6.1.0 ('Old Devil') built on Mar 2 2013 14:32:37
Writing library : libebml v1.3.0 + libmatroska v1.4.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L2.1
Format settings, CABAC : Yes
Format settings, ReFrames : 7 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 13mn 17s
Nominal bit rate : 500 Kbps
Width : 544 pixels
Height : 304 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.121
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=7 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 /
lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 /
b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 /
rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=500 / ratetol=7.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 /
qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 13mn 17s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 20ms
Default : Yes
Forced : No

For completness. This mp4 files are created with using megui directly unlike mkv files which are created by use of mkvmerge
1.mp4
General
Complete name : D:\mp4\rt dok 03 02 - 1.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 45.3 MiB
Duration : 12mn 40s
Overall bit rate : 499 Kbps
Encoded date : UTC 2013-03-11 11:41:33
Tagged date : UTC 2013-03-11 11:41:33

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L2.1
Format settings, CABAC : Yes
Format settings, ReFrames : 7 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12mn 40s
Bit rate : 500 Kbps
Maximum bit rate : 2 158 Kbps
Width : 544 pixels
Height : 304 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.121
Stream size : 45.1 MiB (100%)
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=7 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 /
lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 /
b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 /
rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=500 / ratetol=7.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 /
qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-03-11 11:41:33
Tagged date : UTC 2013-03-11 11:44:55

2.mp4
General
Complete name : D:\mp4\rt dok 03 02 - 2.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 47.3 MiB
Duration : 13mn 17s
Overall bit rate : 497 Kbps
Encoded date : UTC 2013-03-11 11:47:57
Tagged date : UTC 2013-03-11 11:47:57

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L2.1
Format settings, CABAC : Yes
Format settings, ReFrames : 7 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 13mn 17s
Bit rate : 500 Kbps
Maximum bit rate : 2 212 Kbps
Width : 544 pixels
Height : 304 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.121
Stream size : 47.0 MiB (100%)
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=7 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 /
lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 /
b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 /
rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=500 / ratetol=7.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 /
qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-03-11 11:47:57
Tagged date : UTC 2013-03-11 11:51:30

Zathor
11th March 2013, 22:04
Resulting mkv file plays correctly only through first part. Skipping past the place where files were joined result in complete garbage on the screen. It does not matter if I join 2 mp4 files with or without audio. Result is the same. Files 1 & 2 by themselves play just fine.

I am using Megui for ages since I first switch from using Nandub + Gordian Knot years ago and this issue never have happen prior to ver 2237. It might have been introduced sometime prior to version 2237 but definitely previous stable version did not have this issue.

You can try to downgrade MkvMerge and x264 to the builds used before MeGUI 2237.

ryszardzonk
12th March 2013, 01:00
You can try to downgrade MkvMerge and x264 to the builds used before MeGUI 2237.

I tried dowgrading mkvtoolnix package to 5.6 which I believe was the one that was there with previous stable version but that didn't really help.

I would give different x264 versions a try. If You could just let me know which x264 versions where used between 2237 and 2153. I would not like to start with to acient version.

2200 (http://mirror01.x264.nl/x264/?dir=./32bit/8bit_depth) perhaps?

hello_hello
12th March 2013, 03:23
ryszardzonk,
I've had a similar problem quite a few times when trying to re-encode a small section of video at a later date (say to encode subtitles in a section which needed them but I didn't realise originally) but generally the error message when trying to rejoin the sections at least appears to make sense as it'll look something like this: (lengths: 41 and 42). However I have had instances where the private data is reported as being different while the lengths are reported as being the same and the two files still won't append properly. It's happened with older versions of x264 and I've tried different versions of MKVMergeGUI with the same result. I've not been able to solve it though.
Only one time did I think I'd found the cause.... I'd set the colour characteristics in the command line when encoding one section but not the other, and that seemed to be enough to do it, but obviously that's not what's happening in your case.

Anyway, as a workaround you could probably just encode both scripts as a single encode which should eliminate the problem. You'd create a script which imports both your single scripts while joining them together, so you'd end up with a script which looks like this:

Import ("E:\script 1.avs") ++ Import("E:\script 2.avs")

How you'd handle the audio probably depends on what sort of editing you'd added to the original script, but the above should solve the video part of the problem.

I've got some encodes currently sitting in the job queue where in order to apply different cropping to a section of video, I've split the encoding job into three scripts to later join the output files with MKVMergeGUI. I've done this quite a few times and never had a problem joining them when they've been encoded one after the other. A few weeks ago I encoded a video that way using one computer to encode two sections of it, while a second encoded the other and they still joined without a problem.
Later today, after the encodes I have in the job queue finish, I'll report back regarding whether I could join the output files successfully. If I can, I'll try some quick encodes again using the same scripts, but with your x264 settings to see if for some reason that makes a difference. It'd be nice to get to the bottom of this. Currently I'm just using the x264 default settings and the slow or slower speed preset.

hello_hello
12th March 2013, 03:33
PS. Here's where I asked about the problem in the MKVToolnix thread. While it was nice to receive an explanation regarding what a codec's private data actually is, it didn't really help me solve it. http://forum.doom9.org/showthread.php?p=1610745#post1610745
(http://forum.doom9.org/showthread.php?p=1610745#post1610745)
Mosu: "CodecPrivate data is an element that stores data that the codec in question needs in order to decode the file properly. Different codecs have very different requirements for their private data (it's often called "codec initialization data" as wel). For example, Vorbis needs its codebook which tells the codec how to expand the encoded/compressed stuff back to the uncompressed stuff that can be played back.

Same with AVC/h.264. The CodecPrivate data contains (amongst other things) the sequence parameter sets and picture parameter sets. They contain important information like pixel resolution, codec features used etc.

So it is generally technially impossible to decode video from an encoding A with the private data from encoding B (and mkvmerge can do nothing about it). However, there are situations in which that will work: if the codec private data only differns in unimportant fields (e.g. the frame rate is also stored in the sequence parameter sets, and if they and only they differ then there should not be any problem). That's why mkvmerge doesn't prevent you from doing it."

I guess the next step, if it's possible to view the "codec private data", would be to look at it for each encode to determine where it's different, but if there's a way to do so I don't know how.

hello_hello
12th March 2013, 07:25
ryszardzonk,
I've narrowed the problem down a little.....
Encoding 2 files using 2 pass encoding (I used the same bitrate as your last log file) produces the "codec private data" error when you try to append the output files, and so far that seems to be regardless of any other x264 settings you may be using. If you use CRF encoding and try to append the output files, there's no error. As I pretty much always use CRF encoding these days......

Maybe now I've discovered cause, someone more knowledgeable than myself might be able to work out the "why" part, or maybe offer a way to prevent the problem from happening when using 2 pass encoding.

I'd take a guess and suggest appending a 2 pass encode to a CRF encode will once again produce the error, but I haven't tested it. It's a very hot day where I am and I want to give the PC a rest because it's not helping with the room temperature. I'd be thinking though, when I've tried to re-encode a section of old video and then append the new version to the original, I've used CRF encoding to re-encode a section of it while the original probably used 2 passes.... back before I'd discovered the joy of CRF encoding.

Kurtnoise
12th March 2013, 08:54
didnt test yet on my side but this doesnt look like an error...more a warning (mkvtoolnix-wise).

Your input are mp4 or raw h264 ?

Could you post also your logfile, especially the muxing part ?

ryszardzonk
12th March 2013, 10:12
@hello_hello

To start with your very first post I did make mistakes in the past as well and back than MKV was always right as for example I forgot to add audio to one of the source files so it obviously did not match. Sometimes the errors where becouse of more subtle differences as different settings in AVS scripts like with ot without color correction, but that was easily eliminated with creation of "Avisynth profiles". Encoder settings presets where also a big help. This time around it is something completly different so I am somewhat glad it is reproducible so hopefully the solution will be found.
I'll try using different x264 versions now to see if they are to blame. I trust here that if I just replace recent version of x264 with an old one the new MeGUI version would not complain to any missing or moved setting or anything of that sort ;)

I have tried the workaround You mention in the past which did the trick, but I have 2 issues with it. One is that it adds another layer of work which may not seem much but I record number of of videos daily and taking every extra step is not what tigers like best. Another is the issue with audio which is quite error prone to out of sync errors for the additional videos.

As far as the determining differences in codec private data stuff it seems out of my league and I would rather not comment on something I did not even egxamine in the past at all

I was not aware of the CRF method so I did a little bit of reading about it (http://www.tools4movies.com/2012/03/crf/) which actually sounds quite promising as it is definetly better judge of scene complexity than I am but it seems it will not be miracle quality boost (http://en.wikibooks.org/wiki/MeGUI/x264_Settings#crf) "CRF mode gives almost exactly equivalent quality to 2pass at the same bitrate".
I have gained some experience as of what bitrate to give to any given video and ussually aim to use preset which gives codec enought bitrate (usually falls between 0,11 - 0,13 bits per pixel and about 15%-20% less for anime) depending on its scene changing needs so that it itself does not really a must have but definetly worth trying out. Hopefully crf would take less time than 2pass encode even with its result/time unpredictability.

It seems however that if the issue with 2pass encoding will not be resolved I would have to move to the crf method regardless.
Thanks for finding out that it is 2 pass encode behaviour that have changed!

ryszardzonk
12th March 2013, 10:34
didnt test yet on my side but this doesnt look like an error...more a warning (mkvtoolnix-wise).

Your input are mp4 or raw h264 ?

Could you post also your logfile, especially the muxing part ?

I am using MP4 format to encode videos. I never used RAWAVC

Well mkvtoolnix would be the last I would blame for the change as version 5.6 was used with previous megui stable where it all just worked and reverting to 5.6 to join newly created files results in the same error. Still mkvtoolnix somehow knows there is the difference is the video in the private data as program is able to recognize it hence the warning/error message. Maybe it could inform of what is actually different

warning message
Warning: The track number 0 from the file 'D:\mp4\rt dok 03 02 - 2.mp4' can probably not be appended correctly to the track number 0 from the file 'D:\mp4\rt dok 03 02 - 1.mp4': The codec's private data does not match (lengths: 42 and 42). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file.

muxing message for videos files only just like they appear after encode [no audio muxed to them]
mkvmerge v6.1.0 ('Old Devil') built on Mar 2 2013 14:32:37
'D:\mp4\rt dok 03 02 - 1.mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'D:\mp4\rt dok 03 02 - 2.mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'D:\mp4\rt dok 03 02 - 1.mp4' track 0: Using the output module for the format 'AVC/h.264'.
'D:\mp4\rt dok 03 02 - 2.mp4' track 0: Using the output module for the format 'AVC/h.264'.
The file 'D:\mp4\rt dok 03 02 - 1.mkv' has been opened for writing.
'D:\mp4\rt dok 03 02 - 1.mp4' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 544/304.
Appending track 0 from file no. 1 ('D:\mp4\rt dok 03 02 - 2.mp4') to track 0 from file no. 0 ('D:\mp4\rt dok 03 02 - 1.mp4').
The cue entries (the index) are being written...
Muxing took 4 seconds.

hello_hello
12th March 2013, 11:16
The encodes seem fine. The warning comes from MKVToolnix when you try to join them. I'd say it's an encoder issue, and nothing to do with MeGUI as such, but I'm guessing.

I just ran another two short encodes and tried to join them together. Identical scripts both times, except I used Trim() to encode different sections of it. When using 2 pass encoding MKVMergeGUI complains about the codec's private data not being the same. If I repeat the process using CRF encoding, there's no problem appending the output files.

I tried to post both log files but the forum complained about my post being too long. I tried to upload the samples as attachments but apparently the file size limit for this video conversion forum is 200KB. :confused: Only at doom9....

Here's a link instead (http://depositfiles.com/files/gsvgze2la), assuming there's no ridiculous forum limitation on those as well. I changed the name of the output files because last time I uploaded video files without doing so they were deleted for being unauthorised. The log files are included.

hello_hello
12th March 2013, 11:24
ryszardzonk,
I didn't see your post until after submitting my last one. It's interesting to see you say the behaviour for 2 pass encoding, in relation to appending files, has changed at some stage. I didn't know as I almost never encode that way.

But yeah.... when I saw your encoder settings, that's where the penny dropped for me regarding where to start looking for the cause of the problem. I was going to add a little CRF vs 2 pass encoding rant to my post, but thought it might be a little out of place (I know it upsets some people when discussions take place in a discussion forum), but I guess maybe you've seen the light already. ;)
No, it doesn't provide a quality boost. You've read about it encoding the same way as 2 pass encoding if the resulting bitrate is the same (all else being equal) but the difference is CRF lets you pick the quality you want while the file size/bitrate varies accordingly, whereas 2 pass lets you choose the bitrate/file size, but the quality is the unknown. And CRF is faster too....
CRF18 is around where the x264 encoder is roughly considered to be "transparent", but anything up to CRF22 will probably still look pretty good. How high you can go before the quality drop starts to annoy you is a personal thing. I pretty much encode everything using CRF18 myself.

ryszardzonk
12th March 2013, 13:18
@hello_hello
I did few CFR encode tests and I confirm that creating the video with using that setting works as there is no problem with joining the created files together. Sweet :)

I am fairly positive I may speak of behavior change as I create movies for several years and no such problem appeared previously. IMHO if all settings remain constant and the program/s version change and previous setting no longer work than definitely one may speak of behavior change and in that particular case probably even bug/error.

I tend to agree that it seems like the thing to do is just to confirm which x264 version is to blame. Hopefully nothing older that 2200.

Could be that CFR method is just superior (seems like you say constant good quality, faster encodes, but I would definitely would have to make more test encodes prior to really establish my own opinion) that almost no one uses 2pass encoding anymore and problem was spotted only by those few like me that use ancient method of encoding that is about decade old ;)

PS Rant is last thing I fought about when you mentioned CFR, but more like a hint as getting best quality possible with the use of certain codec settings.

PS Back to x264 version tests

ryszardzonk
12th March 2013, 17:21
I have run tests with using builds available x264.nl (http://mirror01.x264.nl/x264/?dir=./32bit/8bit_depth) for playback issues with 2 files being joined together while the files have been created with Automated 2pass profile.

It turns out that somewhere between rev 2216 and 2230 the change was made that altered codec private data just enough for the files not being able to be joined together

Tested revisions:
2200: OK
2216: OK
2230: broken
2245: broken
2273: broken

Test therefore reveled this is not a Megui nor MKVtoolnix issue ;)

hello_hello
12th March 2013, 17:54
@hello_hello
PS Rant is lat thing I fought about when you mentioned CFR, but more like a hint as getting best quality possible with the use of certain codec settings.

I usually do rant about it. ;)
But yeah given hard drive space isn't an issue any more and squishing a file down to fit on a disc is less important than it once was, I think the majority of people would just use CRF encoding these days.
If I had to pick a word, it'd be about getting "consistent" quality rather than "best" quality, although because the bitrate varies you're not wasting bits on quality you can't see when encoding one file and having too few bits for the next.


It turns out that somewhere between rev 2216 and 2230 the change was made that altered codec private data just enough for the files not being able to be joined together.

Problem solved.... well "cause found"... at least
I wonder if the x264 developers know it's happening? I'm not sure where you'd report such a "bug".

Poutnik
13th March 2013, 08:46
I have recently tried to mux SRT subtitles to AVI, making MKV, using adaptive and MKV muxers.
I have noticed it did not allow me to use AVI as the Audio source.
I thought it may take audio stream as default, but it did not.

But if I have launched standalone mmg GUI from MKVmerge tool of MeGUI,
it took audio stream automatically.

Do I have to demux AVI, or provide AVS audio script to do that in MeGUI ?
Or, are MeGUI muxers aimed to elementary stream muxing only ? ( Using last MeGUI stable )

Edit>I have checked Always mux MKV encoding via MKVmerge.

goldensun87
13th March 2013, 09:13
Hello everyone, I just ripped my BD of Wreck It Ralph, and I wanna encode it. But, I see that the main movie is split into many m2ts files. So, will I be able to encode the entire movie if I rename the files like, "filename_1", "filename_2, ... and load filename_1 into the file indexer? Or do I have to do something else?

AMED
13th March 2013, 09:49
@goldensun87

Use the HD stream extractor and it will merge all the m2ts in to one mkv video file and any audio languages you choose.

goldensun87
13th March 2013, 12:19
@goldensun87

Use the HD stream extractor and it will merge all the m2ts in to one mkv video file and any audio languages you choose.

Thank you :) . I extracted as raw h264, then remuxed into m2ts. Now, I will attempt to encode down to 720p. Hopefully it will do so without a hitch.

Edit: Just out of curiosity, would my idea have worked?

AMED
13th March 2013, 19:57
It should work but it would be easier (possibly safer) to just mux the video in to MKV. I think FFMS can have some issues with seeking when using M2TS files (is this still true?).

My procedure is;

1. Rip full disc in MakeMKV.
2. Use the HD stream extractor to get the streams I want, video = mkv, audio = AC3/DTS
3. Index with FFMS
4. Use AVISynth creator to crop, resize and apply MvDegrain1
5. Autoencode just the video portion with CRF 19 and --grain and mux in the audio, chapter and subtitles.

Octo-puss
14th March 2013, 09:29
Why does it take MeGui like three seconds to close? Before you ask - no I am not running out of time, just curious what's going on in the background so intense it takes so long to shut down, when much more complex programs close instantly :P

Kurtnoise
14th March 2013, 12:37
this depends on your machine but megui saves all profiles, settings, jobs and delete files if needed when you close it...

Octo-puss
14th March 2013, 14:38
Well, my machine is pretty fast, and MeGui does this even if I simply launch it and immediatelly close. There's nothing to save or process...

Kurtnoise
14th March 2013, 17:40
Please advice of way to fix that.
Using raw output file (i.e h264 instead of mp4 or mkv), concatenation seems to be ok. No more warning like this...

Well, my machine is pretty fast, and MeGui does this even if I simply launch it and immediatelly close. There's nothing to save or process...
Each time you launch MeGUI and close it afterwards, all settings/jobs/profiles are saved...

hello_hello
15th March 2013, 14:23
It should work but it would be easier (possibly safer) to just mux the video in to MKV. I think FFMS can have some issues with seeking when using M2TS files (is this still true?).

Yes, but I've got several versions of ffms on my hard drive because each version seems to have different issues.
Recently I ripped six Bluray discs using HD Streams Extractor and ffms indexed each MKV fine, but every single one of them failed to encode. If I opened the scripts with MeGUI they appeared okay, but when I opened the scripts with MPC-HC, which caused the video to be played from the first frame, I got an error along the lines of "insanity detected, the decoder has returned an empty frame". I switched to an older version of ffms, re-indexed each MKV, and the problem went away. I'm pretty sure all of the original video was VC-1 in this case.

Speaking of ffms....
If you set MeGUI to use an output folder different to the input folder, the ffms index file is created in the correct directory, but if you use the Script Creator to analyse the video, it's indexed again and a second index file is created in the same folder as the source video. Could MeGUI's analysis be told where to find the existing index file so it doesn't need to create another one?

Zathor
15th March 2013, 19:42
If you set MeGUI to use an output folder different to the input folder, the ffms index file is created in the correct directory, but if you use the Script Creator to analyse the video, it's indexed again and a second index file is created in the same folder as the source video. Could MeGUI's analysis be told where to find the existing index file so it doesn't need to create another one?
Thanks - will be fixed in 2304.

hello_hello
17th March 2013, 17:19
Cheers.

In case you don't notice it Zathor, I've finally gotten around to finding one of the samples you requested in this thread:
http://forum.doom9.org/showthread.php?t=163906

I've described the problem again in today's post there to refresh your memory.

Richard1485
3rd April 2013, 21:06
Sometimes MeGUI's icon has either a yellow triangle with a black exclamation mark or a red circle with a white cross on it. What do these symbols mean?

rapscallion
3rd April 2013, 21:11
Icon on your desktop or the program's upper left corner?

Either case, never seen either one of those.

Richard1485
3rd April 2013, 21:14
They appear on the icon in the taskbar, where I have MeGUI pinned. (I'm running Windows7.)

Sci-Fi-Fan
3rd April 2013, 21:31
They appear on the icon in the taskbar, where I have MeGUI pinned. (I'm running Windows7.)

Those symbols means an error has occurred, exclamation mark is a warning, red x is a fatal error that stops the current queue process.

go to Megui;s main window/log tab to see an explanation of the errors that occurred.

Richard1485
3rd April 2013, 21:35
Ah! I didn't realize there was an explanation in the log tab. It was Haali Media Splitter. I've reinstalled it, and the symbol has gone.

Thank you both for your time. :)

Richard1485
3rd April 2013, 22:35
It looks as if I spoke too soon.

MediaInfo - Unhandled Error
Exception message: Object reference not set to an instance of an object.
Stacktrace

Reinstalling Haali solved the yellow triangle with a black exclamation mark, but when I tried to encode something I received the red circle with a white cross and the above error message, which I don't understand. I tried reinstalling Mediainfo, but the problem persists. I think these errors started occurring when I updated MegUI today.

Zathor
3rd April 2013, 23:21
Try it with this debug build:
http://www.mediafire.com/?s73g85fg7fq2a4q

If you still get an error please upload the full error log especially the stacktrace.

Richard1485
5th April 2013, 10:53
Thanks, Zathor. I've come to the conclusion that something is wrong in terms of hardware, but once I have it fixed I shall use the debug build if I experience further problems.