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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 18th January 2007, 10:36   #61  |  Link
bob0r
Pain and suffering
 
bob0r's Avatar
 
Join Date: Jul 2002
Posts: 1,337
I deleted that source file, i am working on the.recruit.ts 16gb from BBC-HD now, i am trying to cut a none working sample from that.

On my own (clean) captures h264tsto works .ts to .mkv, on this weird cut into 4 pieces .ts it does not, so i hope this will do, else you just need to copy and join the sample as many times till mkvmerge fails

I am converting all my .ts files to .mkv, some way or another... i cant stand skipping a .ts and wait 30 seconds for it to continue :O)

Ofcourse i will do this 1x, mirror all files, and never wait again!

Edit:
I am uploading test.h264 842 MB (883,053,919 bytes) to your ftp, this one does this.....
Arg while i am typing this, it did manage to create the file.

So it seems if the file is too big, there is a memory leak or something, you as programmer should be able to make a 4+GB file out of my 50mb sample, just copy copy copy and join them all.
Can't do much more here....


You may delete test.h264

Last edited by bob0r; 18th January 2007 at 10:42.
bob0r is offline  
Old 18th January 2007, 11:22   #62  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,960
Quote:
Originally Posted by foxyshadis View Post
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?
It's not a matter of the number of slices, because each slice is prefixed with the NALU size. Maybe I'm using the term "slice" in the wrong way here, I'm not sure. Maybe I mean that there can be several NALUs for each frame, and each NALU has its own size.

Quote:
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.
"Simply restarting" is not as simple :/ Quite a lot of work.

Quote:
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.
Nah. I'll leave all options separate and not merge them into one "do it this way or the other way" option. But the options will get their own dialog soon.

Quote:
Can it fix the nalu size of premuxed stuff coming from mp4/mkv/avi as well?
Not yet, but that's easy to implement. I hadn't thought of it before...

Quote:
(It's still a little too happy to read wmvs as AVC ES. But that's my fault for trying to add one.)
No WMV support in the near future. Sorry.

Quote:
Minor bug report: An extra space between --engage no_default_header_values and --engage native_mpeg4 caused mkvmerge to fail.
Huh? Extra spaces should be ignored by mkvmerge... OK, maybe mmg is interpreting this as an extra option. Will have to look.
__________________
Latest MKVToolNix is v56.1.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 18th January 2007, 11:35   #63  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,566
Quote:
Originally Posted by Mosu View Post
It's not a matter of the number of slices, because each slice is prefixed with the NALU size. Maybe I'm using the term "slice" in the wrong way here, I'm not sure. Maybe I mean that there can be several NALUs for each frame, and each NALU has its own size.
I just meant the added overhead for single- or two-nalu frames will be pretty negligible, sorry, compared to your example.

Quote:
"Simply restarting" is not as simple :/ Quite a lot of work.
I was thinking, mkvmerge itself would error out with a specific error code, and mmg would go back and feed it the new command line. It seems to be simpler than restarting internally in mkvmerge. If that's what you're thinking, apologies.
foxyshadis is offline  
Old 18th January 2007, 14:07   #64  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,960
Quote:
Originally Posted by foxyshadis View Post
I was thinking, mkvmerge itself would error out with a specific error code, and mmg would go back and feed it the new command line. It seems to be simpler than restarting internally in mkvmerge. If that's what you're thinking, apologies.
That's possible, of course, but there are a lot of folks who use mkvmerge without mmg, and for those this would not be a proper solution.
__________________
Latest MKVToolNix is v56.1.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 18th January 2007, 21:29   #65  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
@Mosu, I feel a bit bad to ask you this, as you've done so much already and you're already looking into TS import (which would be lovely), but have you thought about adding EVOB import yet? I'm asking because I've read in another thread that it's very similar to MPG, just with some additions or something like that. If you don't want to do it, just say no, that's ok. But I thought it wouldn't harm to ask...

FWIW, I just dropped a little EVOB with a MPEG2 video stream into mmg and mkvmerge successfully imported the MPEG2 stream into a mkv!!! It just didn't find the audio part. So it seems that mkvmerge already understands EVOB quite a bit, just not completely.

Here's a thread about EVOB demuxing:

http://forum.doom9.org/showthread.php?t=120652&page=5

At page 3 drmpeg offers a little EVOB demuxer. Maybe he'd be willing to spill the beans about what (if any) changes EVOB has to MPG/VOB?

P.S: Actually his EVOB demuxer comes with full source code and it looks VERY simple!

Last edited by madshi; 18th January 2007 at 21:35.
madshi is offline  
Old 18th January 2007, 21:36   #66  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,960
EVOB is definitely not on my top-priority-list for at least the next two months
__________________
Latest MKVToolNix is v56.1.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 18th January 2007, 21:57   #67  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Ok, thanks anyway!

You may ignore this:
(FWIW, my current impression is that EVOB is nothing but MPG. It seems to me that mkvmerge already fully supports EVOB - it just doesn't understand some of the stream IDs. I've just tried the TMPGEnc Demuxer Tool and it shows all streams just fine and can extract them successfully. It seems that 0xBF is Dolby Digital Plus and 0xFD is VC-1.)
madshi is offline  
Old 18th January 2007, 22:07   #68  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
Sorry to report, but mkvmerge doesn't 'fully' understand EVOBs... mine causes mkvmerge to hang with 100% CPU usage.

Last edited by Isochroma; 30th January 2007 at 20:25.
Isochroma is offline  
Old 27th January 2007, 23:10   #69  |  Link
LeMoi
Registered User
 
Join Date: Sep 2004
Location: France
Posts: 360
Quote:
Error: 'H:\file.mkv' track 1: This AVC/h.264 contains frames that are too big for the current maximum NALU size. You have to re-run mkvmerge and set the maximum NALU size to 3 for this track (command line parameter '--nalu-size-length 1:3').
Nalu case is greyed in MMG :s
EDIT : never mind, i was able to add it "extra options" for the track. Anyway it's not normal that this case is greyed

Last edited by LeMoi; 27th January 2007 at 23:14.
LeMoi is offline  
Old 28th January 2007, 00:14   #70  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,960
Quote:
Originally Posted by madshi View Post
FWIW, my current impression is that EVOB is nothing but MPG.
Following the discussions and patches on the mplayer mailing lists I think that EVOB is basically VOB with a couple of small but important differences.

Quote:
Originally Posted by Isochroma
Sorry to report, but mkvmerge doesn't 'fully' understand EVOBs... mine causes mkvmerge to hang with 100% CPU usage.
I'm not suprised at all

Quote:
Originally Posted by LeMoi
Nalu case is greyed in MMG :s
Ah yes. I think it's only active for AVC ES files at the moment, neither for AVC-in-AVI nor for AVC-in-VfW-mode-in-Matroska. I'll fix that soon.
__________________
Latest MKVToolNix is v56.1.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 29th January 2007, 20:28   #71  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
Just to let you know, I'm having the same problem as LeMoi - I have an MKV with VFW track fourcc "H264". I cannot be remuxed with 2.0.0 beause the NALU setting box is grayed out.

When I copy the cmdline and paste into cmdbox with the recommended nalu string added, it doesn't work, complaining about a track missing.

Last edited by Isochroma; 30th January 2007 at 20:26.
Isochroma is offline  
Old 30th January 2007, 08:56   #72  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,960
Quote:
Originally Posted by Isochroma View Post
Also, I've encountered two more .mp4 files that after muxing won't play (stuck on frame 0, won't seek).
Upload, please
__________________
Latest MKVToolNix is v56.1.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 30th January 2007, 11:43   #73  |  Link
Yong
Registered User
 
Join Date: Jun 2004
Posts: 577
Mosu, i have a good thing for you

mkvtoolnix tell me this sample is h264 es...
its actually is png/qdm2 mov.
http://www.shynola.com/movies/j_s/moveyourfeet.mov

more info about the mov read this thread
http://forum.doom9.org/showthread.ph...535#post926535
Yong is offline  
Old 30th January 2007, 21:05   #74  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,960
Quote:
Originally Posted by Yong View Post
Mosu, i have a good thing for you

mkvtoolnix tell me this sample is h264 es...
its actually is png/qdm2 mov.
http://www.shynola.com/movies/j_s/moveyourfeet.mov
Hmm. Ok, I've fixed the file type detection issue, so the file is recognized as QT/MP4 now. But PNG video tracks are not supported, and I won't add support for them now. So you'd only be able to mux the audio track.
__________________
Latest MKVToolNix is v56.1.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 30th January 2007, 22:53   #75  |  Link
Yong
Registered User
 
Join Date: Jun 2004
Posts: 577
Quote:
Originally Posted by Mosu View Post
Hmm. Ok, I've fixed the file type detection issue, so the file is recognized as QT/MP4 now. But PNG video tracks are not supported, and I won't add support for them now. So you'd only be able to mux the audio track.
Great, i didnt expect you to add support for it, just a bug report
and thx for the hard work.
Yong is offline  
Old 1st February 2007, 04:23   #76  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
I have an AVI file which has 119.880 fps drop-frame H264 inside. Using previous versions of MKVMerge, I could mux into MKV using the VFW override and it would work great.

The current version can't mux the source because the NALU needs to be set larger.

But I'm wondering, how will MKVMerge deal with the 119.880 drop frames? Because the old way it was stored, the drop frames were just preserved in the VFW-mode structure, right?

But the new native format for AVC will require that those drop frames be removed, because there is no drop-frames outside of VFW tracks, right?

Personally, I'd prefer if the next version of MKVMerge restored the ability to mux H264 from VFW mode to VFW-mode tracks. The reason is until the native support is debugged, there is no way to mux certain VFW mode tracks, and it is uncertain what will happen to drop frames. New versions have become less useful by omitting the VFW function, such that they cannot be used on a significant fraction of files of this type.

This kind of gap is bound to happen in such rapid developement, of course. Rest assured I have faith that soon, such cases will be handled properly. Blame for these cases ultimately reverts to those who used VFW mode for H264 tracks. MP4 and native AVC mode in MKV are a kind of salvation for this sin; and as priests, MKVMerge and MP4Box can provide redemption, perhaps even salvation. Thus it is easy to understand why the AVC-in-VFW option was removed: to prevent the passing on into new files of corruption, a corrupt practice or way of doing something.

I also tried the latest MP4Box GUI YAMB; it reported an unspecified error and failed. So I guess right now MKVMerge is the last hope for this type of file...

Last edited by Isochroma; 1st February 2007 at 05:06.
Isochroma is offline  
Old 1st February 2007, 08:58   #77  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,960
Quote:
Originally Posted by Isochroma View Post
But I'm wondering, how will MKVMerge deal with the 119.880 drop frames? Because the old way it was stored, the drop frames were just preserved in the VFW-mode structure, right?
Wrong. mkvmerge has always removed zero-sized entries.

Quote:
But the new native format for AVC will require that those drop frames be removed, because there is no drop-frames outside of VFW tracks, right?
They should be removed, yes.

Quote:
Personally, I'd prefer if the next version of MKVMerge restored the ability to mux H264 from VFW mode to VFW-mode tracks.
This will definitely not happen. The vfw-mode storage has always been the wrong thing to do, and I only left it in because mkvmerge couldn't handle such files any other way at that point.

You can try this build: http://www.bunkus.org/videotools/mkv...20070201-1.rar

It defaults to a NALU size of 4 and mmg allows the selection of the NALU size if the AVC track comes from an AVI or VFW-mode Matroska file.

BTW: If this build does not work right with your file then I'd be very happy if you uploaded it to my FTP server. I don't have a single 119.880 FPS AVI file, especially not with h264 inside.
__________________
Latest MKVToolNix is v56.1.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 1st February 2007, 12:11   #78  |  Link
Milvus
Registered User
 
Milvus's Avatar
 
Join Date: Nov 2006
Location: Paris, France
Posts: 53
Quote:
Originally Posted by Isochroma View Post

But I'm wondering, how will MKVMerge deal with the 119.880 drop frames? Because the old way it was stored, the drop frames were just preserved in the VFW-mode structure, right?
These 119.88fps pseudo-VFR AVI files are quite an abomination, and storing them as is in MKV is definitely a wrong idea. It can lead to jerky playback on some computer.

The right thing to do was to use avi_tc_package to convert the original AVI file to a CFR AVI without dropframes and a timecode file. MKVmerge can then use them to produce a true MKV VFR with native AVC.

But now that MKVmerge can handle them correctly, I suppose there's no further need to complicate our life. We have true MKV VFR with native AVC directly !

Last edited by Milvus; 1st February 2007 at 12:19.
Milvus is offline  
Old 1st February 2007, 16:09   #79  |  Link
dragonle87
Registered User
 
Join Date: Dec 2004
Posts: 15
Hello, forgive me if this is the wrong thread to post this but I would like to request two small features be implemented:

1) Can you make it so that users can select which "command line options" to always be enabled by default, instead of having to manually select it from the "Muxing" menu? It's because I always use "--engage native_mpeg4" for every file that I muxed to be clean of avi compatibility hacks. I got this idea when I saw you have the checkbox option "Always use simple blocks" under the "Settings" tab.

2) Another thing i regularly do when muxing files to mkv is naming it in the "file/segment title" textbox under the "Global" tab. The only thing missing is an additional separate "creator/author" textbox and I was wondering if you could add that in your next version. Having a "title" and "author" textboxes is really useful for providing very basic file information. I find this simple, fast, and convenient rather than going through the trouble of creating tags, which I think should be reserved for those users who want to provide more detailed file information.

Most of all, keep up the good work, your program just rocks. As an avid mkv user, I really enjoy using it...very easy and straightforward at creating mkv files.

Last edited by dragonle87; 1st February 2007 at 16:16.
dragonle87 is offline  
Old 1st February 2007, 16:40   #80  |  Link
LeMoi
Registered User
 
Join Date: Sep 2004
Location: France
Posts: 360
Quote:
Originally Posted by dragonle87 View Post
2) Another thing i regularly do when muxing files to mkv is naming it in the "file/segment title" textbox under the "Global" tab. The only thing missing is an additional separate "creator/author" textbox and I was wondering if you could add that in your next version. Having a "title" and "author" textboxes is really useful for providing very basic file information. I find this simple, fast, and convenient rather than going through the trouble of creating tags, which I think should be reserved for those users who want to provide more detailed file information.
+1
LeMoi is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:07.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.