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. |
30th March 2007, 01:31 | #261 | Link | |
Registered User
Join Date: Oct 2003
Posts: 435
|
Quote:
looks like its running at 29.97 to me.. update: ok using this timecode gives me a perfect sync result: # timecode format v1 assume 29.97 0,126292,23.976 just have to change the amount of frames to match the calc frames given from EVOdemux # timecode format v1 assume 29.97 0,[FRAME AMOUNT],23.976 Last edited by woah!; 30th March 2007 at 07:53. |
|
30th March 2007, 12:31 | #262 | Link |
Registered User
Join Date: Feb 2004
Posts: 51
|
It's probably the right place to ask... Long time ago i compress some video with first vfw-version of h264 (i guess, still compiled by syskin) and mux them into mkv (mkvmerge, versions <1.5.X). Now i need to remux them again, namely, to add new subtitle streams. When i've tried to do it, the current version (2.0) gives me the error -1073741819. I guess it means "no longer support for vfw h264-videostreams", doesnt it? Well, the question is
1. can somebody provide a link for old mkvmerge versions? 2. is there any other way to add subtitles to this video or make it compliant to new mkvmerge versions? Thanks. |
30th March 2007, 14:39 | #263 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Such error numbers are usually crashes in mkvmerge which should normally not happen. Care to upload the file?
All older versions of mkvtoolnix are still available at http://www.bunkus.org/videotools/mkvtoolnix/win32/old/
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
30th March 2007, 15:42 | #264 | Link |
Registered User
Join Date: Feb 2004
Posts: 51
|
Thanks for a link... you are absolutely right, the older version (1.5) crashes with the same error. Upload? I'm sorry, the whole file was too large (~800MB). So i've splitted the first 1.3MB in TotalCommander (the crash still remains for this file, 20sec) and sent it by e-mail (our server doesnt allow ftp connection) to moritz at bunkus dot org.
|
3rd April 2007, 01:18 | #265 | Link |
Registered User
Join Date: Jan 2003
Posts: 130
|
Hi Mosu! I've found myself a bug! When the path contains greek letters and you drag'n'drop a file in mmg I get a "file identification failed" error (Return code: 2) and the path is shown as garbage. If I use the Add button everything works fine...
Oh, it's version 2.0.2 in linux if it matters... |
5th April 2007, 20:19 | #266 | Link |
Registered User
Join Date: Sep 2002
Posts: 4
|
Loosing frames when splitting and linking.
When studing the mkv format i found this nice feature: linking split files. So I planned to use it to burn files that are too big. Split them up into ca 1 gig pieces and then archive. But when I split a 11 gig file into 11 pieces and then let the haali splitter glue them all back together, i noticed the result was 10 frames shorter than the original. I use avisynth/directshowsource to virtualdub to analize the files. Used mkvmerge 2.0.2 with mmg.exe to split the files and Haali splitter 1.7.121.0 to view them. The content of the file is h264 video, ac3 audio and S_TEXT/UTF8 subs. The original h264 and ac3 audio came from a ts file that was converted to an mkv using haali splitter and muxer in graphedit. I always check that the converted file plays back properly and is in sync. If i try to glue the split files back together, i'm getting the following error: Warning: 'E:\!burn\1\e\H264.1080.50i.AC3.5.1-001.mkv' track 2: The current packet's timecode is smaller than that of the previous packet. This usually means that the source file is a Matroska file that has not been created 100% correctly. The timecodes of all packets will be adjusted by 224ms in order not to lose any data. This may throw A/V sync off, but that can be corrected with mkvmerge's "--sync" option. If you already use "--sync" and you still get this warning then do NOT worry -- this is normal. If this error happens more than once and you get this message more than once for a particular track then either is the source file badly mastered, or mkvmerge contains a bug. In this case you should contact the author Moritz Bunkus <moritz@bunkus.org>. for each of the 11 files. I'm getting that error as well on other files that i've remuxed with subtitles and then try to mux again. I sometimes add a delay to the audio track to correct sync, I wonder if that has something to do with it. After the files are appended back together into one file, the 10 frames are still missing..... On an other sample where it didn't give errors when muxing the video back, the audio gradually goes out of sync. On a third sample, the linked files play back properly and in sync, but muxing them back together into 1 file gives the same audio errors again and the audio goes terrably out of sync: 192 ms per glued file... UPDATE: looks like the ac3 track in the original mkv file was not upto spec. after remuxing, extracting and then muxing again, it finally was happy about the ac3 track and no longer gave timecode errors. Now, after splitting and letting the haali splitter link all the files, it's still missing 10 frames. But when I append all the files back, I get the original number of frames back, except it's one frame shorter than the mkv file that I started out with. So it looks like the haali splitter is skipping one frame for each mkv file it loads. UPDATE2: After splitting and then glueing, an analizis of the timecodes reveales that there is a difference: In the original file, the timestamps go up smoothly by every 40ms for video and 32ms for audio. This is also true for the split files. They contain the original timestamps. However, in the glued file, there is now a duplicate timestamp for the video after each glued file, so that every file now starts 40ms earlier and earlier. The audio timestamps "jump" after the second glue point and again after glue points after that to keep up with the video. CONCLUSION: It looks like the splitting process works ok, but the glue does not maintain the original timestamps and in the process starts making rounding errors. The Haali splitter must suffer from a similar rounding error and removes a frame around the split point for each file. jwa. Last edited by jwa999; 12th April 2007 at 23:42. |
6th April 2007, 07:56 | #268 | Link |
Registered User
Join Date: May 2006
Posts: 2
|
i tried to use mkvmerge to split a D9 mkv file into two D5s
it says 'die' called: mm_text_io_c::read_next_char(): Invalid UTF-8 char. First byte: 0xfe i am using 2.0.2 unicode windows version is there any way to resolve this issue? thanks sorry apparently mkvmerge is having some conflict with another program after shutting down that program the problem is fixed Last edited by philipshu; 6th April 2007 at 08:54. Reason: solved |
7th April 2007, 15:23 | #269 | Link | |
Emperor building empire
Join Date: Mar 2007
Location: ZAR
Posts: 674
|
Colour muxing options
Quote:
It all started with 'Band of Brother'... an Q18 CQ-CRF encode that looked lacklustre and bleached compared to the original (see post)... I have posted an enquiry on H264 Filters... but that's a 'complete makeover'... perhaps a small (simple) solution would work best. I was so impressed with MKV's ability to morph movies after encoding rather than before... that perhaps it's possible to boost colour saturation during the muxing process rather than during the entire encoding process itself. Are there any colour muxing options available to MKV ? Pascal |
|
8th April 2007, 13:06 | #270 | Link |
Registered User
Join Date: Feb 2007
Posts: 94
|
I have a large h264 video file that I got from from and Blu-ray "xport". The file is fine and I can play it back with CoreAVC for example
I want to put it in a MKV container but I am having some problems with it. MKVmerge accepts the file and everything seams to be fine. But when I play back the resulting MKV file the video is totally distorted. Anyone have any idea how to mux this file properly? |
11th April 2007, 11:48 | #272 | Link |
Registered User
Join Date: Mar 2002
Posts: 2,323
|
Just a theoretical question: how does the stretch function of an audio stream is working? (it's very useful)
eg: if the value is 1.5, it means that we have 1 and a half times longer duration than the video stream. So what it does exactly? Does it duplicate frames ? Or miss out some audio samples? Thanks |
11th April 2007, 12:35 | #273 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
It only modifies the timecodes, not the samples.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
11th April 2007, 23:29 | #275 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
It does neither. It only multiplies the timecodes with the factor.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
13th April 2007, 17:43 | #276 | Link |
Pain and suffering
Join Date: Jul 2002
Posts: 1,337
|
@Mosu
I have found some problems with certain .ts H.264 MBAFF files. Some seek and mux .... some dont seek and dont mux using Haali's gdsmux.exe (lenght is not calculated also) Now Haali wants a sample file. As i also had problems with Big H.264 MBAFF files with mkvtoolnix, muxing sometimes stalls at a certain point. I have this: George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.ts 12.2GB Rarred (.001 = rar) on a server. Now my question is: Can i upload (FXP ftp to ftp) it to you? Edit: Indeed the demuxed video.h264, trying to mux into .mkv gives this again: Code:
mkvmerge v2.0.2 ('You're My Flame') built on Mar 12 2007 16:12:08 'G:\cap\BBC-HD\video.h264': Using the AVC/h.264 ES demultiplexer. Track 0 of 'G:\cap\BBC-HD\video.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1964/1080. 'G:\cap\BBC-HD\video.h264' track 0: Using the MPEG-4 part 10 ES video output module. The file 'G:\cap\BBC-HD\video.mkv' has been opened for writing. 'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 198068 bytes. So it is the perfect sample! P.S. can you explain: "set the display dimensions to 1964/1080." Where does the 1964/1080 come from? Last edited by bob0r; 13th April 2007 at 18:08. |
16th April 2007, 09:40 | #278 | Link | |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
|
16th April 2007, 21:09 | #279 | Link |
Pain and suffering
Join Date: Jul 2002
Posts: 1,337
|
Haali already is downloading the file, i FXPed him the file.
FXP works............ now pray we get some speed Edit: [22:18:58] Transferred: george.gently.2007.bbc-hd.1080p.h.264.ac3.2.0.133 72,264,381 bytes in 6 minutes 45 seconds (173.9 KB/s) ETA: ~ 20 hours.... hope you got 13GB(*2) free Last edited by bob0r; 16th April 2007 at 21:16. |
18th April 2007, 08:42 | #280 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Damn, I should have read your message sooner. The reason why mkvmerge eats such huge amounts of memory is because it doesn't support MPEG transport streams. It mis-detects your file as a raw AVC elementary stream and tries to parse the file that way. I will add detection of transport streams to mkvmerge so that it'll abort with an appropriate error message and not display this behaviour.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
Thread Tools | Search this Thread |
Display Modes | |
|
|