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. |
24th March 2019, 11:52 | #321 | Link | |
Registered User
Join Date: May 2016
Posts: 197
|
Quote:
|
|
28th March 2019, 16:08 | #322 | Link | |
Registered User
Join Date: May 2007
Posts: 29
|
Quote:
Using "sync -r" before each test, remuxing a 60GB UHD movie in command line mode takes 1872s on the Areca, 2053s on the SSD (its cache is full and slows it down) and 523s on the QNAP! With the GUI, the Areca takes 350s. The GUI on the QNAP takes 420s. These are completely reproducible results. The command line is almost as fast as the GUI over a 10Gbs networked NAS, but almost 6 times slower on a Sata or SAS hard drive (the Areca RAID is seen by Windows like a single SAS drive). Thoughts? |
|
29th March 2019, 03:47 | #324 | Link | |
Registered User
Join Date: Oct 2013
Posts: 205
|
Quote:
The file number 20 was the one with this issue. However I managed to figure out the correct delay to insert: 6350 ms. I checked at the beginning and after 58 minutes and now it's 100% OK. Not sure what went wrong before. The audio stream I was trying to correct the sync (to be added in my Matroska video) is AC3: Format : AC-3 Format/Info : Audio Coding 3 Commercial name : Dolby Digital File size : 352 MiB Duration : 1 h 49 min Overall bit rate mode : Constant Overall bit rate : 448 kb/s Audio Format : AC-3 Format/Info : Audio Coding 3 Commercial name : Dolby Digital Duration : 1 h 49 min Bit rate mode : Constant Bit rate : 448 kb/s Channel(s) : 6 channels Channel layout : L R C LFE Ls Rs Sampling rate : 44.1 kHz Frame rate : 28.711 FPS (1536 SPF) Bit depth : 16 bits Compression mode : Lossy Stream size : 352 MiB (100%) Service kind : Complete Main Info about the MKV: https://pastebin.com/U4beAwL1 |
|
29th March 2019, 05:32 | #325 | Link |
Registered User
Join Date: May 2016
Posts: 197
|
1. This is actually not all the data I wanted, because it doesn't tell me anything about the first few timestamps of Matroska file. Use mkvinfo -s -r <output log> <Matroska file> for this; only the first few (say, the first second) of timestamps is of interest here.
2. And you used the elementary stream during determining the offset? Not the stream remuxed into Matroska or so? (Seeking in elementary streams that don't provide timestamps is a PIA, so it is often not instantaneous.) |
29th March 2019, 10:25 | #326 | Link | |||
Registered User
Join Date: Jan 2019
Location: Antarctica
Posts: 74
|
Hello, not sure if this has been brought up or not. I wanted to bring an issue that I wanted to clarify or just ignore. I made a post on mkvtoolnix page a few months ago asking about this but was told to come here instead to ask my question. Not sure if I should also post this on HEVC's thread as well?
I use an older version of mkvmerge (prefer simple gui then the new one) and also tried the latest portable of version 32.0.0 "Astral Progressions" 64 bit and both still got the same results. My issue is concerning HEVC's implementation of the code when viewed in Media Info. It's "total-frames=". As I cut frames with Avisynth then append them together to fix problematic scenes, however, when muxing I would receive these messages only on HEVC. Quote:
Quote:
When appending then muxing them together regardless of how many frames there are in total now it'll only go by the first mkv cut (ex: frames 0, 4003) and will display that under media info ignoring the appended frames added. Quote:
Hopefully devs know what I am talking about concerning this and clue me in. Last edited by dREV; 29th March 2019 at 10:36. Reason: so it's not widewide screen |
|||
29th March 2019, 11:12 | #327 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
You can ignore this in this case as long as the rest of the x265 settings are identical. It's not an issue. The "encoding settings" line you see in MediaInfo is x265's custom "SEI". It's only for information, not part of any standard. Mkvmerge will never alter it in any way. The bitrate on the other hand is taken from Matroska statistic tags (when present) which are in fact updated when appending.
When appending mkvmerge compares the header data of both tracks. When they are not identical it displays a "warning" that there might be a problem. It doesn't actually check whether or not the files are compatible in any meaningful way. Last edited by sneaker_ger; 29th March 2019 at 11:15. |
29th March 2019, 15:04 | #328 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
This is my experience,too, using H.264 streams.
I often add 5 seconds of blank video with silent audio to the beginning and the end of my converted MKV files, and as long as I create the "Silence" file with exactly the same settings as the movie then MKVMerge has no complaints. But recently I noticed that after replacing x264.exe with a newer build I do get these warnings about the codec's private data not matching. The weird thing is that the lengths are identical so I really do not see any mismatch. The combined file plays perfectly, but just to be on the safe side I reencoded the "Silence" file using the newer x264 build, and the warnings disappeared. |
29th March 2019, 21:41 | #332 | Link |
Registered User
Join Date: May 2016
Posts: 197
|
I actually meant the accumulated CPU time, i.e. for the whole remuxing, not at a single instant in time. If the average CPU utilization is the same in both cases, but the CLI version uses it longer, then that would be really strange.
|
30th March 2019, 05:17 | #333 | Link | ||
Registered User
Join Date: Jan 2019
Location: Antarctica
Posts: 74
|
Quote:
Quote:
I think I tried updating to the newer ones but I think MeGUI couldn't use it since I'm using an old version (ver 2525) in order to still use .h264 streams via DGI as lsmash takes a bit longer to index. Last edited by dREV; 30th March 2019 at 05:48. Reason: extra quote |
||
30th March 2019, 09:24 | #335 | Link | |
Registered User
Join Date: May 2007
Posts: 29
|
Quote:
If you know a tool to measure the accumulated time of a process, I'll make the measurement. Anyway, I have decided to replace my DAS by another NAS, more powerful with a 20Gbs aggregated Ethernet link, so the problem will be soon moot I hope. |
|
30th March 2019, 11:17 | #336 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
For reasons I don't understand, when x264 is writing directly to MKV, or you're appending MKV's, the warning is more likely to occur. I've never understood why sometimes I can extract the raw h264 streams from each MKV to be appended (after MKVToolNix produced the codec private data warning), append the raw streams, and if the encoder settings were identical sometimes that'll make the codec private data warning go away, even if --stitchable wasn't used. I'm happy to learn why... should anyone would care to explain. Cheers. PS. I'm using x264 core 155 r2901 7d0ff22 (with 32 bit MeGUI), as last time I tried to upgrade it, the newer x264 wouldn't run on XP. Is that still the case with the latest version? Last edited by hello_hello; 30th March 2019 at 11:23. |
|
30th March 2019, 12:36 | #337 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Mkvmerge displays a warning if "CodecPrivate" element of 2 (or more) mkv files you wish to append aren't identical. "CodecPrivate" is an element of a Matroska container. So if you append 2 raw H.264 streams there is no "CodecPrivate". So there is no warning. The underlying problem remains the same, though.
Note that x264cli behaves a bit different depending on how you output: to .mkv: H.264 headers (SPS/PPS) only at beginning of file to .264: SPS/PPS at every keyframe The latter can mitigate problems when appending files with different headers because the decoder can always access the correct PPS/SPS. Note that not using --stitchable doesn't necessarily make files incompatible. But I think it is indeed a good idea to activate in case you want to make editing later. Last edited by sneaker_ger; 30th March 2019 at 12:41. |
30th March 2019, 12:48 | #338 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Quote:
I never used the --stitchable parameter in x264 because at the time when I created this "Silence" clip I used the same x264 build which was used for the movie conversion. The warning started to appear after I updated x264 to a newer build. For the movie conversion the parameters were absolutely identical. So I believe that every new build probably creates different "private data" even when identical parameters are used. Maybe mkvmerge should be a little less strict when it issues this warning... Cheers manolito Last edited by manolito; 30th March 2019 at 12:56. |
|
30th March 2019, 14:01 | #339 | Link | |
Registered User
Join Date: Jan 2019
Location: Antarctica
Posts: 74
|
To the HEVC developers.
I also did a test by doing two different frames. Cutting one with (0, 1) and the other with (2, 900) and the info showed total frames= 899 so I wanted to know what the documentation means by Quote:
Didn't know you use XP. I'm on Windows 7 so I see why I am not expiriencing the same issue as you're going through. Last edited by dREV; 30th March 2019 at 14:08. Reason: forgot quote |
|
30th March 2019, 14:03 | #340 | Link | |
Registered User
Join Date: May 2016
Posts: 197
|
Quote:
(This is not a perfect benchmark: If a process takes (say) 10 % of a core's CPU time, then after 10s the CPU time will be 1s higher -- regardless of whether your CPU is currently running at its maximum/default frequency or not.) |
|
Tags |
matroska |
Thread Tools | Search this Thread |
Display Modes | |
|
|