View Full Version : mkvtoolnix (Matroska toolkit): new release
Pages :
1
2
3
4
5
6
7
8
9
10
11
[
12]
13
14
15
16
17
18
19
20
Mosu
14th March 2004, 10:15
Originally posted by pixolex
maybe some flag should be reseted when you hit the remove botton and when the muxing process is finished ;)
Use File -> New
pixolex
14th March 2004, 14:36
Originally posted by Mosu
Use File -> New
well, OK!
Chiru
19th March 2004, 15:13
I tryed remux sample.avi to sample.mkv by GraphEdit and MatroskaMuxer1.0.0.8
AVI/WAVSource -> AVI Splitter -> MatroskaMuxer -> FileWriter
This file is playable.
+ EBML head
+ Segment, size -13
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 1703513)
|+ Segment information
| + Timecode scale: 1000000
| + Duration: 1449.950s (00:24:09.950)
| + Date: Fri Mar 19 22:28:06 2004 UTC
| + Muxing application: DirectShow Matroska Muxer
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 21238
| + Track type: video
| + MinCache: 1
| + MaxCache: 1
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 40 (FourCC: DX50, 0x30355844)
| + Default duration: 33.367ms (29.970 fps for a video track)
| + Video track
| + Pixel width: 640
| + Pixel height: 360
| + Frame rate: 29.969999
| + A track
| + Track number: 2
| + Track UID: 2437
| + Track type: audio
| + MinCache: 1
| + MaxCache: 1
| + Codec ID: A_MS/ACM
| + CodecPrivate, length 30 (format tag: 0x0055)
| + Audio track
| + Sampling frequency: 48000.000000
| + Channels: 2
| + Bit depth: 0
|+ Cluster
And tryed,
mkvmerge sample.mkv -o sample2.mkv
this file cannot remux,follow error is occer.
:
progress: 1444.978s/1449.950s (99%)
'die' called: bref_packet == NULL. Wanted bref: 1000000. Contents of the queue:
Packet 0, timecode 0, bref -1, fref -1
Packet 1, timecode 0, bref -1, fref -1
Packet 2, timecode 33000000, bref 1000000, fref -1
Packet 3, timecode 33000000, bref -1, fref -1
Packet 4, timecode 67000000, bref 34000000, fref -1
Packet 5, timecode 67000000, bref -1, fref -1
Packet 6, timecode 67000000, bref -1, fref -1
:
Packet 103862, timecode -1848946048, bref -1881946048, fref -1
Packet 103863, timecode -1815946048, bref -1847946048, fref -1
Packet 103864, timecode -1781946048, bref -1814946048, fref -1
and read sample.mkv by VirtualDubMod, and output to sample2.mkv by direct copy.
+ EBML head
+ Segment, size 105574750
|+ Segment information
| + Muxing application: libebml-0.6.3 & libmatroska-0.6.1
| + Writing application: VirtualDubMod 1.5.10.1 (build 2366/release)
| + Segment UID: 0xe1 0x2f 0xf1 0x97 0x5e 0x56 0x2f 0xab 0x0e 0x5d 0x87 0xae 0x6
5 0x2b 0xb3 0x95
| + Duration: 1449.950s (00:24:09.950)
| + Date: Fri Mar 19 13:32:41 2004 UTC
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 2950)
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 2549166049
| + Track type: video
| + MinCache: 1
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 40 (FourCC: DX50, 0x30355844)
| + Lacing flag: 0
| + Default duration: 33.367ms (29.970 fps for a video track)
| + Video track
| + Pixel width: 640
| + Pixel height: 360
| + Display width: 640
| + Display height: 360
| + A track
| + Track number: 2
| + Track UID: 2872006238
| + Track type: audio
| + Codec ID: A_MS/ACM
| + CodecPrivate, length 30 (format tag: 0x0055)
| + Audio track
| + Sampling frequency: 48000.000000
| + Channels: 2
| + Bit depth: 0
|+ ClusterAnd tryed,
mkvmerge sample2.mkv -o sample3.mkv
This command is complete fine.
What happend?:confused:
Mosu
19th March 2004, 15:20
Originally posted by Chiru
I tryed remux sample.avi to sample.mkv by GraphEdit and MatroskaMuxer1.0.0.8
AVI/WAVSource -> AVI Splitter -> MatroskaMuxer -> FileWriter
Why don't you use sample.avi as the input in mkvmerge directly?
Anyway, please run 'mkvinfo -v -v -v -v sample.mkv > sample.txt', compress sample.txt with whatever you like (RAR, ZIP...) and upload that somewhere, e.g. on my FTP server.
Thanks.
Chiru
19th March 2004, 15:41
Originally posted by Mosu
Anyway, please run 'mkvinfo -v -v -v -v sample.mkv > sample.txt', compress sample.txt with whatever you like (RAR, ZIP...) and upload that somewhere, e.g. on my FTP server.
I uploaded sample.txt
sorry,not compressed.:(
SonGokuDBZ
21st March 2004, 14:01
@ Mosu:
I'm new to Matroska files and I like them very much.
I have a music-DVD which I want to backup, but the quality is so bad (noisy and so one) that it doesn't make sense to compress to Xvid/DivX. I would like to use the origin mpeg2 video stream in a mkv. file, but it isn't possible at the moment.
My question: Is mpeg2-input on your "to-do-list" and if it is, when do you think could it be implemented?
Thanks!
Mosu
21st March 2004, 14:04
Originally posted by SonGokuDBZ
@ Mosu:
My question: Is mpeg2-input on your "to-do-list" and if it is, when do you think could it be implemented?
It is, but the 'when' is pretty much unknown. Don't expect it anytime soon (probably still in 2004).
Mosu
21st March 2004, 14:12
Sorry for the delay. Here's my analysis:
Originally posted by Chiru
I tryed remux sample.avi to sample.mkv by GraphEdit and MatroskaMuxer1.0.0.8
AVI/WAVSource -> AVI Splitter -> MatroskaMuxer -> FileWriter
This file is playable.
...
And tryed,
mkvmerge sample.mkv -o sample2.mkv
this file cannot remux,follow error is occer.
The problem is that the file in question is broken. It contains backwards references that are off by 1ms. Backward references are used for non-key frames.
Example from the mkvinfo output you've uploaded:
| + Block group at 1744646
| + Reference block: -32.000ms at 1744648
| + Block (track number 1, 1 frame(s), timecode 0.033s = 00:00:00.033) at 1744651
| + Frame with size 1
| + [P frame for track 1, timecode 33]
| + Block group at 1745202
| + Reference block: -33.000ms at 1745205
| + Block (track number 1, 1 frame(s), timecode 0.067s = 00:00:00.067) at 1745208
| + Frame with size 4513
| + [P frame for track 1, timecode 67]
Ignoring all the other stuff you can see that the reference block at 67ms references with -33ms which would require a block to exist at 34ms, but there is none - only one at 33ms. I can try to work around this, but this is a bug in the MatroskaMuxer.
I'll file a bug report against it.
hulkenstrong
21st March 2004, 21:46
Hi. I use mkvtoolnix alot and use matroska for all my personal music videos backups. Problems is that I have been using mkvtoolnix for a while now and well aparently somethhings have changed along the way. Thats fine but now to the problem.
All matroska files works in windows 2000/xp/2003/
All newer matroska files (dont know exact version but like 2-3months back) works in linux (mandrake 10.0)
All older muxed matroska files will not play in Linux (tried mplayer/vlc and if I remux they work so must be something that has changed).
So the problem is Im trying to use linux more and would like to be able enjoy my own videos :). All is fine if I could just remux the files.
1. I can open every *mkv file in nmg and remux (rather not a bit timeconsuming)
2. Copy all .mkv to a dir and mkvtoolnix and create batch file. (a bit space/timeconsuming would like to skip that)
3. This option is what Im wishing for :). A good coder of mkvtoolnix incorporates some nice drag and drop batch gui for nmg that remuxes my files in a few nice mouse clicks and let me chose a output directory where the new files are stored using input filenames.
It could be usefull to have this batch thing for more than just this purpose and maybe there are something more changing in future where this woudl be a usefull thing.
Just a little request.
Mosu
21st March 2004, 21:55
Originally posted by hulkenstrong
All matroska files works in windows 2000/xp/2003/
All newer matroska files (dont know exact version but like 2-3months back) works in linux (mandrake 10.0)
All older muxed matroska files will not play in Linux (tried mplayer/vlc and if I remux they work so must be something that has changed).
Can you please tell me the application that was used to create these files? Run 'mkvinfo file.mkv' and look for 'muxing application' and 'writing application'. If you have the bandwidth to spare please also upload the first 5MB of one of the older, non-working files to my FTP server (see my signature). Just start uploading and abort after 5MB.
So the problem is Im trying to use linux more and would like to be able enjoy my own videos :). All is fine if I could just remux the files.
1. I can open every *mkv file in nmg and remux (rather not a bit timeconsuming)
2. Copy all .mkv to a dir and mkvtoolnix and create batch file. (a bit space/timeconsuming would like to skip that)
3. This option is what Im wishing for :). A good coder of mkvtoolnix incorporates some nice drag and drop batch gui for nmg that remuxes my files in a few nice mouse clicks and let me chose a output directory where the new files are stored using input filenames.
No need. 2. is already good and fast enough. Copy all files into one directory and then run:
for FILE in *.mkv ; do
NEWNAME="`basename "$FILE" .mkv`-remuxed.mkv"
mkvmerge -o "$NEWNAME" "$FILE"
done
This will remux each file. The new files with have '-remuxed' appended to the name before the extension.
hulkenstrong
21st March 2004, 22:10
-------------------------First file that wonth run in linux-----------
E:\Backup\DVD Ripp\mkvtoolnix-0.8.6>mkvinfo Soul.mkv
+ EBML head
+ Segment, size 30086598
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 61)
|+ Segment information
| + Muxing application: libebml v0.5.1 + libmatroska v0.5.1
| + Writing application: mkvmerge v0.7.0
| + Duration: 268.212s (00:04:28.212)
| + Date: Sun Oct 12 17:33:49 2003 UTC
| + Segment UID: 0xf9 0xf8 0xad 0xec 0x4d 0xb2 0xcb 0x8e 0xda 0x86 0x63 0xf8 0xc
e 0xa3 0x4e 0xda
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 3041981602
| + Track type: video
| + MinCache: 1
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 40 (FourCC: XVID, 0x44495658)
| + MaxCache: 1
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Video track
| + Pixel width: 384
| + Pixel height: 288
| + Display width: 384
| + Display height: 288
| + Lacing flag: 0
| + A track
| + Track number: 2
| + Track UID: 1882517500
| + Track type: audio
| + Codec ID: A_AAC/MPEG4/LC/SBR
| + Default duration: 42.667ms (23.438 fps for a video track)
| + Audio track
| + Sampling frequency: 24000.000000
| + Output sampling frequency: 48000.000000
| + Lacing flag: 0
|+ Cluster
---------------------second file that wonth run in linux--------------
+ EBML head
+ Segment, size 27616773
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 61)
|+ Segment information
| + Muxing application: libebml v0.6.0 + libmatroska v0.5.2
| + Writing application: mkvmerge v0.7.2
| + Duration: 172.200s (00:02:52.200)
| + Date: Sat Nov 01 13:59:51 2003 UTC
| + Segment UID: 0xe7 0x67 0xaf 0x19 0xd7 0xe8 0x8a 0x67 0x42 0xbb 0x98 0x7d 0xe
8 0x35 0x92 0x71
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 2782408404
| + Track type: video
| + MinCache: 1
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 40 (FourCC: XVID, 0x44495658)
| + MaxCache: 1
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Video track
| + Pixel width: 384
| + Pixel height: 288
| + Display width: 384
| + Display height: 288
| + Lacing flag: 0
| + A track
| + Track number: 2
| + Track UID: 2629732174
| + Track type: audio
| + Codec ID: A_AAC/MPEG4/LC
| + Audio track
| + Sampling frequency: 48000.000000
|+ Cluster
------then there are more that wonth run but hope this is enough------
Uploaded now "soul.mkv" 5mb.
The code is it for linux? As I tried copying it to a *.bat file and couldnt run it. I got no coding skills whatsoever so a bit lost.
Thank you for the fast reply.
omion
21st March 2004, 23:08
I've been trying to make AC3 audio sync up with MKVmerge, and strange things happen. If I specify a negative offset, the audio starts at the positive offset value, but is not delayed. For example:
File 1: No offset
File 2: -2000ms
File 3: +2000ms
File 2's audio will start 2 seconds in, but when it starts it will be the exact same as File 1. The audio is not shifted at all, only cropped.
File 3's audio will also start at 2 seconds in, and seems to be delayed correctly, but MPC freezes for about a second when the audio starts playing. Looking through MKVinfo, I found the following fishy lines:
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
...
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
...
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
...
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
...
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
...
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
...
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
...
| + Block group
| + Block (track number 2, 8 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0xad6a67a9)
| + Frame with size 768 (adler: 0xad6a67a9)
| + Frame with size 768 (adler: 0xad6a67a9)
| + Frame with size 768 (adler: 0xad6a67a9)
| + Frame with size 768 (adler: 0xad6a67a9)
| + Frame with size 768 (adler: 0xad6a67a9)
| + Frame with size 768 (adler: 0xad6a67a9)
| + Frame with size 768 (adler: 0x7eca746a)
| + Block group
| + Block (track number 2, 6 frame(s), timecode 2.000s = 00:00:02.000)
| + Frame with size 768 (adler: 0x45036aac)
| + Frame with size 768 (adler: 0x9ee27be0)
| + Frame with size 768 (adler: 0xedcd6d74)
| + Frame with size 768 (adler: 0x837d7fd8)
| + Frame with size 768 (adler: 0x95be7bac)
| + Frame with size 768 (adler: 0x3b88765b)
NOTE: I omitted most of the audio frames, and replaced them with '...' They're exactly the same as the first one in the group.
I don't know much about Matroska, but having 9 blocks with the same timecode seems counter-productive.
I uploaded the MKVinfo output for the files in a zip archive (http://people.ucsc.edu/~rswilson/other/ac3-delay-example.zip).
Note that the video is much longer than the audio; this was to make sure that the last audio frame was included in the file.
Thanks!
I'm using MKVmerge GUI 0.8.6
Mosu
22nd March 2004, 00:15
Originally posted by omion
I don't know much about Matroska, but having 9 blocks with the same timecode seems counter-productive.
Definitely ;) Stupid bug. Thanks for noticing. It should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.8.6-build20040322-1.rar
Mosu
22nd March 2004, 00:20
Originally posted by hulkenstrong
Uploaded now "soul.mkv" 5mb.
Thanks. It plays fine here on Linux with the current MPlayer CVS version. So there's nothing I can fix. You should download the current CVS version and compile it yourself - it should play that file just fine.
The code is it for linux?
Yes, it is for Linux and won't work on Windows. You can put everything into a shell script. Create a file called 'remux.sh' or whatever you want to call it and put this into it:
#!/bin/sh
for NAME in *.mkv ; do
NEWNAME="`basename "$NAME" .mkv`-remuxed.mkv"
mkvmerge -o "$NEWNAME" "$NAME"
done
Then make the script executable with 'chmod u+x remux.sh'. Now you can execute it (but change to the dir with the Matroska files before running it).
omion
22nd March 2004, 01:08
Thanks, Mosu! It plays perfectly! :D
There is a slight oddity I just noticed, however. In my file with +2000ms delay, there are still audio frames starting long before then (according to MKVinfo). It plays correctly (offset by 2 seconds) so I think the frames are just filler. But if they are, then it seems to me that just deleting them would save space.
Anyway, the files play perfectly, so I guess I can't complain ;).
PS. Wow - that was a fast bug-fix! I'm impressed.
Mosu
22nd March 2004, 09:02
Originally posted by omion
Thanks, Mosu! It plays perfectly! :D
There is a slight oddity I just noticed, however. In my file with +2000ms delay, there are still audio frames starting long before then (according to MKVinfo). It plays correctly (offset by 2 seconds) so I think the frames are just filler. But if they are, then it seems to me that just deleting them would save space.
This is intentional. If the audio is being delayed then I insert either silence (if I know how, for Vorbis, MP3 and PCM I do) or duplicate the first packet often enough (if I don't know how to produce 'silence packets' which I don't for the others). As to the 'save space' argument - well let's take your case with 2s worth of duplicated packets. With a sampling frequency of 48000Hz and 1536 samples/packet we have 2s * 48000samples/s / (1536samples/packet) = 62.5 packets, each 768 bytes long = 48000 bytes. Not really an issue, I'd say ;)
omion
22nd March 2004, 10:28
Originally posted by Mosu
As to the 'save space' argument - well let's take your case with 2s worth of duplicated packets. With a sampling frequency of 48000Hz and 1536 samples/packet we have 2s * 48000samples/s / (1536samples/packet) = 62.5 packets, each 768 bytes long = 48000 bytes. Not really an issue, I'd say ;)
I really didn't think it would be enough to worry about, as I did see only 63 identical packets at 768 bytes each, just as you said (Plus, I've never had an offset of more than 300ms in DVD encoding). I suppose I was really just wondering why they needed to be there in the first place. Is there any reason why the audio track must have data starting from time 0?
ChristianHJW
22nd March 2004, 10:29
Originally posted by Mosu With a sampling frequency of 48000Hz and 1536 samples/packet we have 2s * 48000samples/s / (1536samples/packet) = 62.5 packets, each 768 bytes long = 48000 bytes. Not really an issue, I'd say ;) .... still, there is another possibility for that, if we implemented the matroska track delay feature, which was discussed a lot and found to be great by everyone, but unfortunately didnt find its way into the specs, nor was it implemented.
The idea of track delay was to be able to change sync of individual tracks, compared to track nr. 1 ( video in most cases ), by simply editing the track delay field. Changing this delay value should be as quickly as rewriting those 4 bytes in the track header, instead of having to remux the complete file all the time. Think of files with 30 audio tracks or more .... if you have to remux the complete file to change sync for all of them, you turn crazy after the 5th track :eek: ...
Mosu
22nd March 2004, 10:53
Originally posted by omion
I really didn't think it would be enough to worry about, as I did see only 63 identical packets at 768 bytes each, just as you said (Plus, I've never had an offset of more than 300ms in DVD encoding). I suppose I was really just wondering why they needed to be there in the first place. Is there any reason why the audio track must have data starting from time 0?
I do that in order to make life easier for players. For small delays this won't matter, of course, but I know players (mplayer... *sigh*) that don't handle gaps in a track (and yes, missing audio at the beginning is a gap, technically) gracefully. mplayer will start playing audio immediately but notice that the timecodes of audio and video are out of sync, so it'll adjust sync over the next two or three seconds (depeding on how big this gap is). So if I don't pad the audio stream for positive delays mplayer will have some sync issues at the start of the file.
Technically you're right - I could just as well leave them out and have the stream start at 2s.
Mosu
22nd March 2004, 10:54
Originally posted by ChristianHJW
.... still, there is another possibility for that, if we implemented the matroska track delay feature, which was discussed a lot and found to be great by everyone, but unfortunately didnt find its way into the specs, nor was it implemented.
I totally agree, it'd be a cool feature if it had already been implemented :) Hmm, maybe we can do that quickly...
omion
22nd March 2004, 20:55
Thanks, Mosu & Christian! That was exactly what I wanted to know. :)
hulkenstrong
22nd March 2004, 21:54
Mosu thanx for all the help.
Unfortunality I couldnt try the script in linux. I didnt have enough space for it (all my drives are using NTFS and well linux cant write to them yet). Now all are remuxed atleast did use the gui took an hour but hey now atleast Im guaranted to have working matroska files in linux. (saving script for future use and might be usefull when Im using linux as my main os.)
Are going to check out the latest mplayer CVS soon (have saved one old matroska file just for my own fun bug/test hunt :) ). Since linux is a complex operating system the problem could aswell be in my installation and as Im not to advanced user...well I cant hunt those things down easily.
Emp3r0r
23rd March 2004, 04:22
I having trouble muxing a ogm/mkv file using mkvmerge. The file was originally a ogm file and mkvmerge wouldn't open it so I used vdubmod to convert it to mkv and I get same error message seen below. I am uploading the file to your server now.
http://jvance.com/images/mmg.gif
update: image link
screenshot of mmg
Mosu
23rd March 2004, 15:25
Originally posted by Emp3r0r
I having trouble muxing a ogm/mkv file using mkvmerge. The file was originally a ogm file and mkvmerge wouldn't open it so I used vdubmod to convert it to mkv and I get same error message seen below. I am uploading the file to your server now.
http://jvance.dnsalias.com/images/mmg.gif
That file muxes fine here, but the link to the gif you've included just says 'You are not authorized to view this page'.
empty
25th March 2004, 00:42
Due to an DB error I can't connect to anthill for bug report.:( So I post here. Every Xvid-File I muxed with mkvmerge 0.86 in winxp can't be correct decoded by Xvid. ZoomPlayer and MPC ends at once and VDMod crashes with an error message that xvidcore.dll has an integer division by zero while decoding Frame 0. If I use ffdshow for decoding everything goes fine (except for a bad picture ;) ). I don't know if this is an error of mkvmerge or xvid.:( But older mkvs with Xvid are running. Hope you can fix it without any problems.;)
I used Xvid RC3 from Koepi.
greetings bb empty
Mosu
25th March 2004, 09:38
Originally posted by Emp3r0r
I having trouble muxing a ogm/mkv file using mkvmerge.
Ah yes, this stupid bug - I forgot to build newer versions of libebml for the 0.8.6 release on Windows :( Please download this new build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.8.6-build20040325-1.rar
Mosu
25th March 2004, 09:43
Originally posted by empty
Due to an DB error I can't connect to anthill for bug report.:(
Thanks for noticing. Fixed.
Every Xvid-File I muxed with mkvmerge 0.86 in winxp can't be correct decoded by Xvid.
I just tried what you described - no problems here. Latest MPC with Koepi's XviD 1.0rc3 binary.
empty
25th March 2004, 11:27
Hmm, strange. Okay, I will test a little more, perhaps it depends on the subs. ;)
bb empty
Emp3r0r
26th March 2004, 04:42
Originally posted by Mosu
Please download this new build New build fixed my problems. Thanks.
echo
27th March 2004, 16:49
@Mosu
Could you implement reading the AR info from avi files produced with mencoder, so you don't have to set it again when muxing to mkv? I think it should also work for XviD vfw,3ivX and ffvfw avi AR...
regards
echo
Mosu
27th March 2004, 17:22
Originally posted by echo
@Mosu
Could you implement reading the AR info from avi files produced with mencoder, so you don't have to set it again when muxing to mkv? I think it should also work for XviD vfw,3ivX and ffvfw avi AR...
regards
echo
Tell me how ;)
Mosu
27th March 2004, 21:49
Originally posted by echo
@Mosu
Could you implement reading the AR info from avi files produced with mencoder, so you don't have to set it again when muxing to mkv? I think it should also work for XviD vfw,3ivX and ffvfw avi AR...
regards
echo
Implemented, somewhat. mkvmerge will now extract the AR information from the MPEG4 stream if the video stream is MPEG4 (not divx 3.x, n oothers, just for all codecs that are MPEG4) if the user hasn't overridden that on the command line. It'll also tell you explicitely what it changed the display dimenions to.
The stuff is in my SVN repo. The Windows users can check out this new build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.8.6-build20040327-1.rar
echo
27th March 2004, 23:06
Mosu, you're the man! :cool: It only takes someone to dream about a feature and its already there! :D mpeg4 AR was all I was looking for. Thanks a lot! :)
regards
echo
KpeX
28th March 2004, 00:32
Originally posted by Mosu
mkvmerge will now extract the AR information from the MPEG4 stream if the video stream is MPEG4 (not divx 3.x, n oothers, just for all codecs that are MPEG4) if the user hasn't overridden that on the command line. It'll also tell you explicitely what it changed the display dimenions to. Nice....works great in my quick tests :). Although some players should be able to read the AR from the bitstream, this is a very good and easy solution for playing back anamorphic MP4 video using directshow based players. Nice work Mosu :).
Mosu
28th March 2004, 08:25
Originally posted by KpeX
Nice....works great in my quick tests :). Although some players should be able to read the AR from the bitstream, this is a very good and easy solution for playing back anamorphic MP4 video using directshow based players. Nice work Mosu :).
Yes, but probably more important is that the container AR and bitstream AR information are both the same. Normally mkvmerge will always write the display dimensions into the Matroska file in order to make allow changing them without having to remux the complete file. They're set to the same as the picture dimensions (pixelwidth, pixelheight). This is of course counterproductive if the stream contains a different pixel AR than 1.0 :)
empty
29th March 2004, 16:56
Every Xvid-File I muxed with mkvmerge 0.86 in winxp can't be correct decoded by Xvid.
I just tried what you described - no problems here. Latest MPC with Koepi's XviD 1.0rc3 binary. Okay, as I promised I've tested a little bit more. The Bug seems to affect only 2GB+ Files. I muxed 1 Xvid-Stream + 2xAC3-Streams + 2xSRT-Streams + chapters with mmg under Windows XP, same bug like described. With VDMod muxed, there are no problems.
The video track name has a special character "ü", but I think this doesn't matter, as I can't play the single untagged videostream muxed with mmg to mkv. If the files are under 2GB there is no problem.
I hope you can reproduce the error. ;)
bb empty
Mosu
29th March 2004, 17:13
Originally posted by empty
Okay, as I promised I've tested a little bit more. The Bug seems to affect only 2GB+ Files.
You mean that if the Matroska file is bigger than 2GB then you have this problem?
I hope you can reproduce the error. ;)
bb empty
Definitely not before the weekend... Such big files require some time to generate.
Chez_Wimpy
31st March 2004, 11:52
Sometimes when encoding I have two or more avi segments that I need to join prior to their inclusion in a matroska file. Credits, for example, I usually encode at a much lower bitrate than the actual content, into a seperate credits.avi clip. Other times I am splicing multiple clips together, cutting out commericals for example. Would it be possible for mkvmerge to support the sequential joining of multiple avi clips during the muxing process? I only mention this because I realized it would save a lot of wasted hard disk writing if I could leave out copying a 700meg file from one drive to another... and back again! I usually use virtualdub to join the avis, sometime they have an mp3 audio stream attached. Great job Mosu, without your tool I would never have tried mkv in the first place!
Mosu
31st March 2004, 12:06
Originally posted by Chez_Wimpy
SWould it be possible for mkvmerge to support the sequential joining of multiple avi clips during the muxing process?
So far it's not possible, but I've thought about it a lot lately, and I think I'll start implementing it soon. However, it's a LOT of work, and I have no idea when I'll get it working.
empty
31st March 2004, 23:36
You mean that if the Matroska file is bigger than 2GB then you have this problem? Perhaps this happens only if the pure videostream is over 2GB. I hadn't tested it, my mkv is 1 DVD and so the videostream ist bigger than 2GB. But I will test it with files with only the mkv is 2GB+. Thanks for your engagement. :)
bb empty
ChristianHJW
1st April 2004, 11:34
Originally posted by Mosu
So far it's not possible, but I've thought about it a lot lately, and I think I'll start implementing it soon. However, it's a LOT of work, and I have no idea when I'll get it working.
Could we, as an alternative, think about an automated 'batch process' muxing for the AVIs, and joining of the MKV files instead of joining AVI files, to be muxed with sound in another muxing process ?
alexnoe has joining of MKV files done already, and the advantage compared to joining AVIs for what chez_wimpy wants to do, is that this would allow the same to be done for all kind of input files, like RM, MOV, MP4, etc. , as well as joining segments with different framerates.
In short, most of the work would be
- extension of the GUI ( mmg.exe ), to allow 'batch muxing' of several video segments into single MKVs
- coding a general use MKV concatenator ( 'mkvjoiner' ? ), but only for the same type of stream ( same codec IC, same track header, tool should check this before starting the joining, and could even delete the merged segment during the process, to save HDD space )
- another extension to the GUI to be able to use the output from the joining process from above to be muxed with audio and subs streams
and while you're at it
- a last extension to the GUI to allow calling of mkvextract for stream demuxing ( an old wish of mine ... nobody say a GUI can only call one single exe, right ? )
:)
hofmetzger
1st April 2004, 11:55
Originally posted by ChristianHJW
Could we, as an alternative, think about an automated 'batch process' muxing for the AVIs, and joining of the MKV files instead of joining AVI files, to be muxed with sound in another muxing process ?
I dont know the technical details, but would this be as "proper" as avi-joining before muxing? I fear this would lead to "patchwork" or at least some overhead.
Second, it would be a 2-Step muxing, which it doesnt have to be, if the avis would be streamcopied one after another in muxing process
Originally posted by ChristianHJW
alexnoe has joining of MKV files done already, and the advantage compared to joining AVIs for what chez_wimpy wants to do, is that this would allow the same to be done for all kind of input files, like RM, MOV, MP4, etc. , as well as joining segments with different framerates.
Well, that is important and therefore goes without saying, doesnt it?:D
What im thinking (or better: dreaming) of is a kind of 2-dimensional muxing application, where you have the tracks (as today) in one dimension, and several files per track (avis, mp3,...) played seamlessly one after another.
Mosu
1st April 2004, 12:45
No, if I do it I'll do it right. Implementing a separate tool for concatenating is IMHO just a dirty hack, nothing more. I've done that for my ogmtools, but I should know better now, and OGM has some design issues that Matroska does not have, so it should be easier to do with mkvmerge.
Just a suggestion, I don’t even know if this is technically possible, but what about a Direct stream server in VirtualDubMod?
Mosu
1st April 2004, 15:05
Originally posted by GIR
Just a suggestion, I don’t even know if this is technically possible, but what about a Direct stream server in VirtualDubMod?
Doesn't help the non-Windows users (and yes, I do care about them).
empty
1st April 2004, 22:26
I've found some more things about the 2GB+ problem. It seems to depend on the OGM-splitter, because it only occurs with 2GB+ OGMs! if I use AVI instead, there is no problem. I can play 2GB+ OGMs so I think it's not my system. ;) I use OggDS 0.9.9.5 by Tobias.
I hope in you to fix this :D , but I can use the workaround with AVI.
bb empty
Mosu
2nd April 2004, 18:05
Originally posted by empty
I've found some more things about the 2GB+ problem. It seems to depend on the OGM-splitter, because it only occurs with 2GB+ OGMs! if I use AVI instead, there is no problem. I can play 2GB+ OGMs so I think it's not my system. ;) I use OggDS 0.9.9.5 by Tobias.
I hope in you to fix this :D , but I can use the workaround with AVI.
bb empty
Just to make sure I understand this correctly.
1) If the source is an OGM that is bigger than 2GB then the resulting Matroska file is broken.
2) If the source is an OGM that is smaller than 2GB then the resulting Matroska file is OK.
3) If the source is an AVI that is bigger than 2GB then the resulting Matroska file is OK.
Is that correct?
empty
4th April 2004, 01:12
Yes, it is.
bb empty
SonGokuDBZ
4th April 2004, 12:03
I don't know if this is a stupid question, but I wonder why the Chapter Editor doesn't work with frame-numbers instead of hh:mm:ss...
For me it would be very easy when I could import for example Micro DVD Player chapter files!!!
Thanks (Mosu: Your program is great ;) )
Mosu
5th April 2004, 11:13
Originally posted by SonGokuDBZ
I don't know if this is a stupid question, but I wonder why the Chapter Editor doesn't work with frame-numbers instead of hh:mm:ss...
For me it would be very easy when I could import for example Micro DVD Player chapter files!!!
Because Matroska is time based and certainly not on frame numbers. What about files without a video track? What about files with multiple video tracks? What about files in which VFR is used and the original (e.g. an AVI) was CFR?
I can add support for importing such chapter files if you send my some, but the editor will always be based on timestamps.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.