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 25th April 2007, 17:23   #301  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by Brother John View Post
How about a fourth one: "Use file/segment title as file name if present". That's how I name my files and I'd be really surprised if this wasn't a common way to name output files.
That would be an additional option and has nothing to do with the other issues Maybe. Sounds useful.

Quote:
Concerning the "rename before" option. A common scenario: You have a video-only file called c:\movie.mkv (probably encoded by x264.exe or xvid_encraw). When you load this file into mmg to mux audio & Co the name for the muxed file is auto-set to c:\movie.mkv.
Oh, you're right. I'll definitely change this so that the automatically created output filename does not equal any of the input filenames.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 25th April 2007, 18:12   #302  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
@Mosu: Interesting ideas... my idea is that it can behave just like Word, etc. in that the user won't have to do any renaming after muxing, if the path\filename is the same for input/output. This would save a lot of work, and be really handy!

However, I just realized that there's a big problem with my original request: what to do if there are errors reported in the muxing process?

Some errors are trivial (ie. no definitive language ID from .ogm source tracks), while other errors may mean problems (xxx bytes of audio discarded... sync may be lost), and others definitely mean a useless output file.

In some of these cases, mkvmerge ought to refrain from purging the original input file, but others it is safe to do so.

So an errorlevel would have to be set in the preferences, above which no input file is purged...

Last edited by Isochroma; 25th April 2007 at 18:22.
Isochroma is offline  
Old 25th April 2007, 19:28   #303  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Way too much work, Isochroma, sorry.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 25th April 2007, 19:36   #304  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
Yeah, thought so... was just hashing out the complete theoretics for the joy of travelling that road.
Isochroma is offline  
Old 26th April 2007, 09:40   #305  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
I'd implement everything you're suggesting instantly if I was actually earning a lot of money with mkvmerge It's not that I don't like your ideas, it's just that with my day time job being a programmer most of the time I'm rather unwilling to do more coding in the evening.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 26th April 2007, 09:43   #306  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
http://www.bunkus.org/videotools/mkv...20070426-1.rar

Another build for you guys. This one is able to remux the h.264 stream demuxed from George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.ts.

Technical explanation: The problem was that the h.264 stream did not contain any IDR slice, and mkvmerge used those for determining when to assign time codes (IDR slice = Matroska key frame). Now mkvmerge also uses type 6 SEI NALUs ( = recovery point indicators) as key frame indicators. On my Linux system mkvmerge is using up to ~65 MB memory if I mux both the h.264 and the AC3 track at the end of the process. This looks promising, but I don't have any other file that big, so testing is up to you
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 26th April 2007, 10:00   #307  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
I've a question about h264 support:

When I mux raw h264 files with either mp4box, mp4creator or mkvmerge, I sometimes have the problem that the resulting video file plays slightly shorter or longer than the original file (doesn't matter which of the 3 mentioned tools I use, they behave identical). In such cases the audio track loses sync. I've analyzed the problem and found that in some scenes the mkvmerge muxed video plays like slow motion for a second or so. Then I've tried to mux the Equilibrium HD-DVD h264 stream and it runs too quickly. I guess that the Equilibrium h264 stream doesn't contain "enough" frames and that e.g. static images are realized by using timecodes instead of throwing multiple frames on the same image.

I was able to work around the problem by using Haali's Matroska Splitter + Muxer. Sync is perfect that way.

Is it possible that this new "recovery point indicator" reading could improve the situation? Or is this likely to be just another problem which is still to be solved?

Thanks!
madshi is offline  
Old 26th April 2007, 10:06   #308  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by madshi View Post
In such cases the audio track loses sync. I've analyzed the problem and found that in some scenes the mkvmerge muxed video plays like slow motion for a second or so. Then I've tried to mux the Equilibrium HD-DVD h264 stream and it runs too quickly. I guess that the Equilibrium h264 stream doesn't contain "enough" frames and that e.g. static images are realized by using timecodes instead of throwing multiple frames on the same image.

I was able to work around the problem by using Haali's Matroska Splitter + Muxer. Sync is perfect that way.

Is it possible that this new "recovery point indicator" reading could improve the situation? Or is this likely to be just another problem which is still to be solved?
No, the situation for such cases hasn't improved. As soon as you extract a raw h.264 elementary stream from any container (MPEG TS being a container, too) you lose all timecode information. That's why all three tools behave the same way and show the same problem: They all expect a fixed number of frames per second and create the timecodes accordingly.

What will bring an improvement is when I implement support for MPEG transport streams because then mkvmerge can handle the TS timecodes, too.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 26th April 2007, 12:56   #309  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Mosu View Post
No, the situation for such cases hasn't improved. As soon as you extract a raw h.264 elementary stream from any container (MPEG TS being a container, too) you lose all timecode information. That's why all three tools behave the same way and show the same problem: They all expect a fixed number of frames per second and create the timecodes accordingly.

What will bring an improvement is when I implement support for MPEG transport streams because then mkvmerge can handle the TS timecodes, too.
Ah ok. Thanks!

What about EVO parsing? Are there timecodes in EVOs? If so, does mkvmerge make use of those timecodes? Because when I feed a h264 EVO to mkvmerge, sync is lost, too.

Interestingly, with "TS -> raw h264 -> mkvmerge" usually the video is longer than the audio after muxing. While with "EVO -> mkvmerge" in my case the video was shorter than the audio after muxing. Does that make any sense to you?
madshi is offline  
Old 26th April 2007, 13:19   #310  |  Link
delacroixp
Emperor building empire
 
delacroixp's Avatar
 
Join Date: Mar 2007
Location: ZAR
Posts: 674
@Mosu

Quote:
Originally Posted by Mosu View Post
What I don't like and what I will likely not implement is this:

"always rename the muxed file to something like 'filename.mux.mkv" -- This would probably introduce one unneccessary step for a lot of users: removing the ".mux" in the output file name. If the source files are already named correctly then the destination file should be as close to the same name as possible.
Agreed

Is it possible to set the "Output filename" to something along the lines of ' c:\*.mkv ' ... where '*' is the original video filename (less the extension).
After that ' c:\MuxedMovies\*.mkv ' and even ' c:\MuxedMovies\*.mux.mkv ' or simply ' *.mux.mkv ' becomes a possibillity... depending on user preference...
I encode a lot of video-only MKV encodes (AutoMKV) and mux in the audio/subtitles manually and even knowing which is the final mux is sometimes usefull.

A default setting is all good.



Pascal


*** NOTE ***
I guess this is one of those 3-pillars of tank building problems... firepower vs protection vs mobility ... there is no 'one' solution...
In the case of MkvMerge you choose ... either to rename, relocate or delete... a single path that is satisfactory most of the time...
__________________
DualRomeEPYC . Storinator

Last edited by delacroixp; 26th April 2007 at 15:56. Reason: Adendum
delacroixp is offline  
Old 26th April 2007, 13:27   #311  |  Link
bob0r
Pain and suffering
 
bob0r's Avatar
 
Join Date: Jul 2002
Posts: 1,337
@Mosu

GREAT GREAT GREEEAT WORK!

I demuxed Superstorm.E01.2007.BBC-HD.1080p.H.264.AC3.5.1.ts 8.04GB (even Haali's latest pre gdsmux.exe failed on this)

I demuxed to .h264 and .ac3, muxed 5 minutes then play .mkv to set audio delay in MPC, then muxed the whole thing. Everything went OK!

Now..... i can not wait for .ts support, same as Haali, get ready for Hell!
bob0r is offline  
Old 26th April 2007, 14:10   #312  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by madshi View Post
Ah ok. Thanks!

What about EVO parsing? Are there timecodes in EVOs? If so, does mkvmerge make use of those timecodes? Because when I feed a h264 EVO to mkvmerge, sync is lost, too.
EVOs and VOBs may contain timecodes, but mkvmerge does not use them. VOBs are really cool things, you know... For example there are a lot of files out there in which the timecodes simply reset in the middle of the file.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.

Last edited by Mosu; 26th April 2007 at 14:14.
Mosu is offline  
Old 26th April 2007, 14:15   #313  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Mosu View Post
EVOs and VOBs contain timecodes, and those are used for the video portion, but not for audio streams.
Hmmmm... Then I think there's probably a bug somewhere in mkvmerge, cause sync is definitely lost with the h264 Equilibrium EVO. I've tried to create the MKV by dropping the EVO into mkvmerge and only muxing the video track. The audio track was demuxed externally. The audio track is in sync, when directly playing the EVO + external audio track through the Haali filters with Media Player Classic. But the sync is lost when throwing the EVO into mkvmerge. I'll upload a h264 test EVO for you.
madshi is offline  
Old 26th April 2007, 14:30   #314  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
I'll just call it a missing feature that'll be implemented one day. The thing is... Timestamps in EVOs are optional. Meaning that for e.g. the Departed trailer there are 3600 video frames and only 315 MPEG PS packets have a timestamp. I'm not sure how I should re-create the timestamps for the missing frames, nor am I sure how I can actually tell which timecode belongs to which frame, especially with the kind of caching mkvmerge does in order not to slow down too much.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 26th April 2007, 14:41   #315  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Yeah, agreed. If you intentionally don't make use of VOB/EVO timecodes (yet), then that's not a bug.

VOB files with resetted timecodes in the middle of the file were probably originally two separate VOB files which were just joined. If you search through the internet about how to join VOB files, some people claim you just need to join the binary files without any further changes. And funnily many splitters seem to cope with such joined VOB files quite well. But it's probably technically incorrect to join VOB files that way.
madshi is offline  
Old 26th April 2007, 15:29   #316  |  Link
delacroixp
Emperor building empire
 
delacroixp's Avatar
 
Join Date: Mar 2007
Location: ZAR
Posts: 674
@madshi

Quote:
Originally Posted by madshi View Post
Yeah, agreed. If you intentionally don't make use of VOB/EVO timecodes (yet), then that's not a bug.

VOB files with resetted timecodes in the middle of the file were probably originally two separate VOB files which were just joined. If you search through the internet about how to join VOB files, some people claim you just need to join the binary files without any further changes. And funnily many splitters seem to cope with such joined VOB files quite well. But it's probably technically incorrect to join VOB files that way.
I often use copy /b *.* filename.VOB though it's probably a little archaic given modern file specifications...



Pascal
__________________
DualRomeEPYC . Storinator
delacroixp is offline  
Old 26th April 2007, 23:46   #317  |  Link
bob0r
Pain and suffering
 
bob0r's Avatar
 
Join Date: Jul 2002
Posts: 1,337
@Mosu

I have some good news!

To my supprise, i captured something of BBC-HD tonight, and everything was changed, they fixed AR signalling (old bbc.ts = mpc saying: 1964 x 1080, new bbc.ts = mpc saying: 1920 x 1080). The bitrate is set a bit lower too (hopefully encoder update to compensate for quality )

Now, muxing with Haali's gdsmux.exe stalled at 87%, i have had more files doing this, hopefully Haali can fix this.
So i demuxed the .ts to .ac3 and .h264.
Load them into your latest mkvtoolnix, and voila a proper working The.Quatermass.Experiment.2005.BBC-HD.1080p.H.264.AC3.2.0.mkv on my HDD.

Good job!

EDIT:
Haali's next splitter release, will be able to mux the BBC-HD.ts files directly to .mkv also, Haali has fixed 2 issues that prevented muxing.
Now lets hope i can create some more dirty .ts files!!

Raw .ts mux directly to .mkv, split with timecodes and boom, result file there, is .mkv actually getting workable???

Last edited by bob0r; 27th April 2007 at 09:38.
bob0r is offline  
Old 27th April 2007, 16:54   #318  |  Link
delacroixp
Emperor building empire
 
delacroixp's Avatar
 
Join Date: Mar 2007
Location: ZAR
Posts: 674
@bobOr

Quote:
Originally Posted by bob0r View Post
EDIT:
Haali's next splitter release, will be able to mux the BBC-HD.ts files directly to .mkv also, Haali has fixed 2 issues that prevented muxing.
Now lets hope i can create some more dirty .ts files!!

Raw .ts mux directly to .mkv, split with timecodes and boom, result file there, is .mkv actually getting workable???
I'm sure that's just plain evel... we'll have to rename you ' Dr Evil '...


Pascal
__________________
DualRomeEPYC . Storinator
delacroixp is offline  
Old 28th April 2007, 21:27   #319  |  Link
DreckSoft
Registered User
 
Join Date: Mar 2002
Posts: 117
Unfortunately the new release is still unable to mux Casino Royale. Still get distorted video.
DreckSoft is offline  
Old 29th April 2007, 16:36   #320  |  Link
bob0r
Pain and suffering
 
bob0r's Avatar
 
Join Date: Jul 2002
Posts: 1,337
You sure thats not the decoder's fault?
CoreAVC 1.3 does exactly that here... (1.2 works fine)
bob0r 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 18:07.


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