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. |
5th March 2018, 08:59 | #5121 | Link | ||
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Thanks Mosu for the quick fix. Works nicely here...
And a few words in defense of TSDoctor: Just for fun I installed a more than 5 year old version (1.2.xxx) of the Doctor and repeated the test. Result was exactly the same. So if you insist that TSDoctor creates broken files then it has been doing this for a very very long time. And so far I am not aware that anyone has ever complained about such broken files. @mkver Quote:
And if you do not know why anyone uses TSDoctor at all, just download the trial version and throw some corrupted broadcast captures at it. From the first page of the manual: Quote:
Cheers manolito |
||
5th March 2018, 09:30 | #5122 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
I didn't say TSDoctor is buggy, I said that if it didn't increase the continuity counter in this case, then it would be buggy. It does increase it, though, and therefore isn't buggy. What it is doing is simply curious: creating TS packets without any payload in it. Such packets could simply be skipped, making the file smaller.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
5th March 2018, 09:55 | #5123 | Link | ||
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Quote:
and Quote:
Cheers manolito Last edited by manolito; 5th March 2018 at 09:58. |
||
5th March 2018, 15:03 | #5124 | Link |
Registered User
Join Date: May 2016
Posts: 197
|
It seems that the specs agree with TSDoctor about this after all; but given that the existence of packets falsely claiming to contain payload is very strange to say the least and given that the release mkvmerge version worked with the original file I presume that these packets were created by TSDoctor (maybe because it thinks that some players don't like variable bitrate?). And even if one wants constant bitrate (which is incompatible with the goal of removing filler data) one could do so by inserting packets that not even claim to have a payload.
And yes, I know that ProjectX doesn't really support H.264. But I used it just to check the continuity counters and other things at the transport stream layer and it can do this even with unsupported tracks. But let's not derail this thread any more. If you want to continue to talk about this, let's do it via PM. |
7th March 2018, 16:17 | #5127 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
It works just fine. If you have problems, then please post the actual command line used, like sneaker_ger has said.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
7th March 2018, 16:38 | #5129 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
Yes, look at the menu: Multiplexer -> Show command line (Visualizza linea di comando)
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database |
7th March 2018, 17:07 | #5130 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,542
|
Tried again. It indeed works. I was mislead from gMKVExtractGUI that doesn't show delay as it does for audio. Is there any way to find srt (sub) delay from muxed mkv?
__________________
@turment on Telegram |
7th March 2018, 17:10 | #5131 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
|
Subtitles are a sparse stream, which means there really is no inherent "delay". Audio and Video typically always start right at time 0, and any difference here can be considered a "delay".
Subtitles only start when there is actual text to be shown, so any information of how much you delayed it during muxing is essentially lost - because it just gets baked into the timstamps of the subtitles.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
7th March 2018, 17:13 | #5132 | Link | |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,542
|
Quote:
__________________
@turment on Telegram |
|
15th March 2018, 17:43 | #5135 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
@hubble4 Nothing has changed. The installer doesn't set a file association for.mtxcfg. You'll have to do that yourself.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
15th March 2018, 18:02 | #5136 | Link |
Matroska find' ich toll
Join Date: Apr 2008
Posts: 1,370
|
I have nothing changed on my system. I remember me to set a "system-path" for the mtxcfg. I override the old files from the new versions zip file.
From version 19 on, my mtxcfg's don't start the MTX. I will check my system, thanks for your reply. EDIT: All OK now, it was a path issue. Last edited by hubblec4; 15th March 2018 at 18:12. |
17th March 2018, 09:40 | #5138 | Link |
Registered User
Join Date: May 2016
Posts: 197
|
mkvmerge cuts at what it considers to be keyframes (e.g. if you manipulate the keyframe flag of a Matroska SimpleBlock or void the reference fields of a BlockGroup, it thinks that this is a keyframe and allows you to cut the stream at this position). If the source file of the HEVC track is "framed" (Matroska or mp4), then things like the keyframe flags will be reused; if not, mkvmerge will analyze the bitstream and a quick search found this place in the code that indicates that a BLA frame without a recovery_point SEI message won't be considered a keyframe.
|
26th March 2018, 19:35 | #5139 | Link |
Matroska find' ich toll
Join Date: Apr 2008
Posts: 1,370
|
Hi Mosu
I have some questions about mtxcfg file and JSON identify. In an mtxcfg file exists more then one "type"-object. A "type"-object("type": 22 (for m2ts)) is used for a file and it is the same value like in JSON identify "container_type" Code:
"container": { "properties": { "container_type": 22, "is_providing_timestamps": true }, "recognized": true, "supported": true, "type": "MPEG transport stream" }, In mtxcfg exists for each track also a "type"-object ("type": 0 for DTS-HD Master Audio) but in JSON identify the "type"-object is a string (video,audio etc). Code:
{ "codec": "DTS-HD Master Audio", "id": 1, "properties": { "audio_channels": 6, "audio_sampling_frequency": 48000, "language": "eng", "number": 4352, "program_number": 1, "stream_id": 4352 }, "type": "audio" }, How can I determine the right value for an mtxfcg track "type"-object with info from JSON identify? Could you add this info? I know, then are two "type"-objects present. Why exists so many same named objects with different usage? Best regards hubble |
Thread Tools | Search this Thread |
Display Modes | |
|
|