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. |
17th January 2007, 09:03 | #41 | Link | |
Registered User
Join Date: Mar 2005
Posts: 136
|
Quote:
Thank you. |
|
17th January 2007, 09:25 | #42 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
I'm seriously considering working on it Problem is that I don't have any specs so far, and it's always easier working with specs than just digging into the source code of various media players and muxing applications.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
17th January 2007, 09:26 | #43 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Indeed you do Thanks for the samples.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
17th January 2007, 10:44 | #44 | Link | ||
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
Code:
0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ MP4Box test.mp4 -fps 23.976 -add test.264 ... 0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ mkvmerge -o test.mkv test.mp4 ... 0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ mkvinfo test.mkv | grep 'Default duration' | + Default duration: 41.708ms (23.976 fps for a video track) Quote:
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
||
17th January 2007, 10:53 | #45 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Defaulting the NALU size length to 3?
Hey,
this is a small "poll" of sorts. It concerns mkvmerge's AVC/h.264 ES handling code. As some of you have noticed mkvmerge has a new parameter, "--nalu-size-length". A short explanation of what it does and why it is neccessary: In MP4 and Matroska files each h.264 slice is prefixed with its size. This "NALU size" is always a fixed number of bytes long. It can be between one and four bytes, but it cannot vary inside a file. Two bytes means that each slice can be at most 65535 bytes long, three bytes allow for 16777215 bytes. mkvmerge defaults to "two bytes". However, with HDTV content this almost always seems to be too low, and three bytes are needed. Hence mkvmerge's error message. Now I can have mkvmerge default to "three bytes" for the NALU size. But what would that mean? Advantage: mkvmerge will no longer abort with this error message. Disadvantage: For each slice mkvmerge will need one more byte of space. As each frame can consist of many slices (I have files with six slices per frame) this may become quite an extra overhead. For example, take a 25 FPS movie with six slices per frame and a duration of 90 minutes. This would mean that the resulting file would be 90 (minutes) * 60 (seconds per minute) * 25 (frames per second) * 6 (slices per frame) = 810000 bytes. Another possibility would be to have mkvmerge scan the complete input file first in order to find the "optimal" value for the NALU size length. But that would, as I said, require reading the same file twice -- once for scanning, once for muxing. So I'd like to know which option you prefer. Is it... 1. keep it like it is (default "two bytes", no scanning), 2. change it to "three bytes", no scanning or 3. implement scanning? Thanks for the answers
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
17th January 2007, 14:07 | #46 | Link |
lost program in the net
Join Date: Jun 2006
Location: Germany
Posts: 106
|
I have a 4th possibility (I think):
Keep it as it is but if the NALU is to small try 3 bytes. Besides, I would prefer scanning as it gives me smaller sizes in a reasonable amount of time (and the chance of using just 1 byte). Edit: I think I found the TS specs: ISO 13818-1 Last edited by Eragon4ever; 17th January 2007 at 14:19. |
17th January 2007, 14:39 | #47 | Link | |||
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
Quote:
Quote:
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
|||
17th January 2007, 16:12 | #49 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Alternative: How late in the game could it happen that you find out that NALU 2 is not enough? If you can find out by scanning only the first 200 MB, that would be my most preferred option. |
|
17th January 2007, 17:19 | #50 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Worst case is that I find out with the very last slice that is read. Therefore scanning the first 200 MB should be enough for almost all files, but I don't want to rely on that too much.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
17th January 2007, 17:55 | #51 | Link |
Registered User
Join Date: Mar 2005
Posts: 468
|
810000 bytes is ridiculously small for an entire movie. What is that, 0.81 MB? Movies start at 700MB which would in this case be 0.12%?
For a two-CD size movie, that would be 0.06%, for a 4.7 GB video that would be 0.0172%. So yes, make the NALU 3. |
17th January 2007, 20:30 | #55 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
The option will definitely stay. If I change it to 3 then I'll also add a message at the end of the muxing if 2 would have sufficed -- so that people who really want the smallest possible size know that they can lower the overhead
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
18th January 2007, 01:17 | #56 | Link |
Pain and suffering
Join Date: Jul 2002
Posts: 1,337
|
beyonce.at.the.bbc.1080mbaff.sample.ts
47.6 MB (49,999,916 bytes) demuxed .h264 and .mp2 muxed into .mkv works beyonce.at.the.bbc.1080mbaff.ts 4.19 GB (4,504,797,720 bytes) demuxed .h264 and .mp2 muxing into .mkv fails. BBC HD uses H.264 MBAFF video coding. Also other big captures from BBC-HD fail, this error: 'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 124253 bytes. |
18th January 2007, 09:05 | #58 | Link | |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
BTW: The source code of your muxer you gave me quite a while ago used 3 as the default. I guess you've changed that by now. And MP4Box allows and uses 3, too.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
|
18th January 2007, 10:02 | #59 | 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. |
|
18th January 2007, 10:28 | #60 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
For x264 and Ateme, it's not much of an issue, since more than 1 or 2 slices is rare (currently impossible for x264). Unless chroma planes are separate slices?
Anyway, I'd go for a default of 4. Maximize compatibility and minimize inconvenience. I'd vote that --nalu 2 throw a warning and simply restart with 4 instead of flat erroring out, if the message is already going to be there. It'd be good for those of us die-hards who make streaming video and want to cut every byte of overhead from our 40kbps streams. Perhaps this could be integrated with the "always use simpleblock" option. Along with no default header values. Sort of an all-inclusive blood-of-turnip option. Can it fix the nalu size of premuxed stuff coming from mp4/mkv/avi as well? (It's still a little too happy to read wmvs as AVC ES. But that's my fault for trying to add one.) Minor bug report: An extra space between --engage no_default_header_values and --engage native_mpeg4 caused mkvmerge to fail. Last edited by foxyshadis; 18th January 2007 at 10:32. |
Thread Tools | Search this Thread |
Display Modes | |
|
|