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. |
18th January 2011, 03:16 | #1762 | Link |
Registered User
Join Date: Sep 2008
Location: Holland, Belgium
Posts: 330
|
Hello,
I have problems muxing raw AVC + AAC streams into .mp4 (mp4box). Audio is out-of-sync with variable framerate as Selur noted here. Don't know if it's a bug in mp4box, user mistake, or incorrect usage of mp4box muxer. |
18th January 2011, 07:48 | #1765 | Link | |
The Black Reaper
Join Date: Nov 2009
Posts: 320
|
Quote:
Anyway, if I named my .264 to 1.264 and feed it to the the One-Click, a fatal error window appears. Edit: It would seem that the error occurs with all source with numerical filename. Log: Code:
[Error] Log -[Information] Versions --[Information] MeGUI Version : 1913 (svn) --[Information] OS : Windows Seven x64 (6.1.0.7600) --[Information] Latest .Net Framework installed : 4.0 (4.0.30319) --[Information] Avisynth Version : 2.6.0.1 (27/9/2009 8:39:26 AM) -[Information] Update detection --[Information] [18/1/2011 5:56:00 PM] Connecting to server: http://megui.xvidvideo.ru/auto/ --[Information] [18/1/2011 5:56:02 PM] All files are up to date -[Error] Unhandled error --[Information] Exception message ---[NoImage] Index and length must refer to a location within the string. ---[NoImage] Parameter name: length --[Information] Stacktrace ---[NoImage] at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy) ---[NoImage] at MeGUI.VideoUtil.getChapterFile(String fileName) ---[NoImage] at MeGUI.OneClickWindow.openInput(String fileName) ---[NoImage] at MeGUI.OneClickWindow.input_FileSelected(FileBar sender, FileBarEventArgs args) ---[NoImage] at MeGUI.FileBar.triggerEvent() ---[NoImage] at MeGUI.FileBar.setFilename(String filename) ---[NoImage] at MeGUI.FileBar.openButton_Click(Object sender, EventArgs e) ---[NoImage] at System.Windows.Forms.Control.OnClick(EventArgs e) ---[NoImage] at System.Windows.Forms.Button.OnClick(EventArgs e) ---[NoImage] at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) ---[NoImage] at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) ---[NoImage] at System.Windows.Forms.Control.WndProc(Message& m) ---[NoImage] at System.Windows.Forms.ButtonBase.WndProc(Message& m) ---[NoImage] at System.Windows.Forms.Button.WndProc(Message& m) ---[NoImage] at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) ---[NoImage] at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) ---[NoImage] at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) --[Information] Inner exception: null Last edited by Lighto; 18th January 2011 at 10:58. |
|
18th January 2011, 21:33 | #1766 | Link |
My iPod was a gift!
Join Date: Aug 2006
Posts: 57
|
Hi. I dusted off my old iPod (5.5G) and encoded some TV shows I got for Xmas (Lucky Louie and Max Headroom... some fun stuff!!) I encoded the Max Headroom stuff with the previous stable build of MeGUI (3.5.0) and videos looked, encoded and played perfectly with the x264 version included in that version of MeGUI. I recently applied the new update (svn1911) and encoded some episodes of Lucky Louie and so far all the stuffed encoded with the version of x264 included with this version of MeGUI has contained corrupted video frames. I singled out that it was indeed x264 by going back and renaming the old .backup files in the MeGUI tools\x264 folders and using the older version of x264 to encode the same stuff over again. The older version of x264 worked great. The corrupted video frames looks similar to what happens when you seek video in VLC and you don't land on an I-frame. The video looks all pixelated until the next keyframe. Please look into it.
Thanks. |
19th January 2011, 00:36 | #1767 | Link |
Registered User
Join Date: Jan 2011
Posts: 28
|
I've been doing a significant amount of re-encoding BluRays to 720P for streaming to my DLNA compliant BD player over the past week. I immediately noticed that after the 1911 upgrade, ALL of my re-encodes display higher average Bit Rates [double in many cases] DESPITE the encoding settings being identical. This, of course has resulted in larger files and longer encoding times.
These are x264 encodes and the only difference I see in the MediaInfo output is the Writing Library - originally "core 98" and now "core 112". I encode video only. Here are my current pre-sets... program --tune film --crf 16 --qpmin 10 --level 4.1 --bframes 3 --ref 4 --slices 4 --aud --nal-hrd vbr --b-pyramid strict --keyint 24 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 40000 --weightp 0 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --output "output" "input" Again, my average bitrate has risen from 4500 to 10000 despite identical crf settings. Ideas? Kurt |
19th January 2011, 03:48 | #1768 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
you're using CRF and complaining about the bitrate? rise it to get the expected results.
CRF behaviour may vary from (x264) builds to builds.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
19th January 2011, 08:54 | #1769 | Link |
Unreasonable User
Join Date: Nov 2003
Posts: 216
|
Including the latest build. As of r1867, x264 now takes frame-rate into account when calculating crf. Frame-rates higher than 25fps will now have slightly higher average quantization per frame than the immediate previous builds (and thus slightly smaller file sizes), while frame-rates below 25 fps will have the opposite behavior.
|
19th January 2011, 14:40 | #1771 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
kierank, actually it is not possible. however, make a feature request.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
19th January 2011, 16:23 | #1772 | Link | |
Registered User
Join Date: Jan 2011
Posts: 28
|
Quote:
Suddenly I see a new writing library x264 core [changed from 98 to 112] and this changes the output bitrate [everything else equal] by a factor of 2 - yielding twice the filesize and twice the encoding time. Now my "library" of encodes is inconsistent. Maybe I'm asking too much [considering the price of the software] - but I don't think that one should have to test each new release of MeGUI [or x264 build] to see whether the output bitrate is in line with previous releases WITH NO PARAMETER CHANGES. I don't think that one should have to vary crf or any other parameter to realize the same result. To me [as a developer], the purpose of parameters is to tweak or fine tune outputs while always maintaining consistency from build to build - not to correct for changes in the engine. And wouldn't it have been prudent for the x264 developers to stipulate that core X produces a significantly different result than core Y? Just my thoughts... Kurt Last edited by kws53; 19th January 2011 at 16:52. |
|
19th January 2011, 17:20 | #1773 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
megui has nothing to do with your problem. the real problem is you cant count on CRF to be constant across x264 builds. also, if you're using CRF it means you dont care about the bitrate. if you do, then use a 2-pass bitrate mode or at least find the new CRF value that suits your needs. what you think is not relevant. Dark Shikari always said the CRF mean may change across builds so, either you bare with that or use a bitrate mode.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
19th January 2011, 17:36 | #1774 | Link | ||
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Quote:
Quote:
|
||
19th January 2011, 17:58 | #1775 | Link |
Registered User
Join Date: Dec 2005
Posts: 1,460
|
The changelog doesn't list the core version unfortunately, but core 98 is somewhere around r1650, so there have been more than 200 new x264 versions in the meantime. Most of them don't influence the bitrate a CRF encode gives you a lot, if at all, but it adds up if you make a big jump like kws53 did.
|
20th January 2011, 00:42 | #1776 | Link |
My iPod was a gift!
Join Date: Aug 2006
Posts: 57
|
I posted earlier this week regarding corrupted video frames on my iPod-sized mp4 encodes using the new x264 build (r1867) in the new MeGUI update (svn1911). Rather than going back and replacing the new x264 build with the old one I decided to investigate.
I downloaded various old revisions of x264 from the x264.nl mirrors and began doing some test encodes. After a few dozen encodes I pinpointed the last build that worked for me as r1790. Revision 1803 and above all produced corrupted video frames with my test clip. Looking through the x264 changelog, I noticed various optimization having to do with weighted P frames. So I tried turning off/on the various "--weightp" options with x264r1804. They had no effect. The other notable change between r1790 and r1804 was setting qpmin default to "0." Sure enough that was the problem. Apparently the iPod 5.5G doesn't like qpmin values below six. Anything below --qpmin 6 would produce corrupt frames. My short clip includes a fade in and a fade out and the corruption would occur in the fade out portion of the video. So my suggestion would be to enforce the old qpmin value of 10 ("--qpmin 10") for the iPod (5G, 5.5G) preset. No idea if this change in x264 affects the later model iPods (Classic/Touch.) Hope I've been helpful. Thanks for reading. |
20th January 2011, 01:01 | #1777 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
thanks for reporting. it's indeed very helpful for fixing the presets for the next version.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
23rd January 2011, 15:23 | #1778 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Code:
1920 [Log] the content of an avs input file will be added to the log 1919 [VideoPlayer] some sizing adjustments 1918 [One-Click] added the FFMSIndexer so that e.g. most AVI and MKV files are now supported. if the FFMSIndexer is used the audio track must be encoded and cannot be muxed only. 1917 [FFMSIndexer] audio avs files will only be created if the indexing was successful 1916 [FileIndexer] added demux option to the audio tracks when using FFMSIndex these audio tracks will be added to the main input tab if "on completion load files" is selected. Feature request #3158957 1915 [VideoPlayer] changed zoom and size behavior fixed starting preview size so that it will always match the screen resolution. Bug #3159086 changed seek bar and buttons behavior. Feature request #3003726 try to ensure playback speed during playback 1914 [One-Click] fixed handling of video input files with short file names (less than 6 characters including extension). Bug #3160645 |
Thread Tools | Search this Thread |
Display Modes | |
|
|