VideoHelp Forum
+ Reply to Thread
Results 1 to 16 of 16
Thread
  1. Member
    Join Date: May 2014
    Location: Vienna
    Search PM
    Hi there!

    I got 2 copies of an mkv encoding and would like to find out which one is the "good" original.
    I've let both of the copies first run through
    Code:
    mkvmerge -o /dev/null input.mkv
    and since this didn't print anything that would have hinted on which one of the files is the good one afterwards through
    Code:
    ffmpeg -v error -i input.mkv -f null -
    but this also didn't give any errors on neither of the 2 versions.

    Here is the difference shown by a hex-edit-comparator (vbindiff):
    Click image for larger version

Name:	Screenshot from 2014-07-21_x.png
Views:	133
Size:	290.3 KB
ID:	26518

    Does anybody know of any other way to check the files? I am absolutely certain that they are copies of the same encoding and should be bit-equivalent so one of those versions must be damaged. I am trying to find out which one to delete and which one to keep.
    Last edited by kaefert; 24th Jul 2014 at 05:40. Reason: [SOLVED]
    Quote Quote  
  2. Could it be they were muxed using a different muxer, or different version of a muxer?

    I'd just open each with MKVMergeGUI and remux them as new MKVs. If MKVMergeGUI doesn't offer any warnings or errors there shouldn't be any problems.

    You could try having a look with MediaInfo (switch to either text or html view for detail) or even run them through Bitrate Viewer.
    Quote Quote  
  3. Member Cornucopia's Avatar
    Join Date: Oct 2001
    Location: Deep in the Heart of Texas
    Search Comp PM
    Extremely rare that an MKV would be an original. Either one or both could be 2nd generation, or later. IOW, you'll never really know for sure.

    Scott
    "When will the rhetorical questions end?!" - George Carlin
    Quote Quote  
  4. I am absolutely certain that they are copies of the same encoding and should be bit-equivalent so one of those versions must be damaged.
    If you multiplex a raw h.264 stream two times with mkvmerge the output will be different.
    (Only the extracted raw h.264 streams of those two files should match, but they will probably not match the raw input file. )
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  5. Member
    Join Date: May 2014
    Location: Vienna
    Search PM
    I guess I didn't say it clear enough. I've got two copies of one file. I know they should be exact copies with no reencoding and no repacking the stream into a new container, simply copie with a file manager. Now somehow they are not the same, and now I'm trying to find out which one is the one that got damaged.

    In general, for a "blackbox" binary file this of course is impossible without having a checksum of the known good file to compare against.

    But since the file is an mkv video container with one h264 stream and 5 aac streams inside I thought I should be able to find out with video processing tools. The ones I've tried yet and that have given the same output for both "copies" are mkvmerge & ffmpeg (details see first post) and also mediainfo.

    @hello_hello Thanks for the hint with the Bitrate Viewer, I'm gonna try that now and report my findings in an hour or so.
    Quote Quote  
  6. Member
    Join Date: Mar 2008
    Location: United States
    Search Comp PM
    Can you even assume that the "original" is the "good" one?
    You could right click the files/properties and check the creation date.

    Was one of these files copied from the other, or were they both copied from a third file?
    Quote Quote  
  7. Member dphirschler's Avatar
    Join Date: Aug 2001
    Location: Kennesaw, GA - USA
    Search Comp PM
    Could both be the same, only one might have a compressed header. In other words, the mkv container might be the only difference. Try extracting the streams and comparing those instead.

    Darryl
    Quote Quote  
  8. Member
    Join Date: May 2014
    Location: Vienna
    Search PM
    @davexnet sadly, I don't know

    @dphirschler my hexeditor screenshot shows a difference with a length of 304 bytes at an Adress 0xE86C4CC0 which translates to ~3718MB though since the address space only allows for 4GB (8 hex digits) and the file is larger than that, this address needs to be interpreted as the result of modulo 4GB. Even so, this proves that the difference is not within the header.

    The difference shown in the vbindiff screenshot is the only difference and both files have exactly the same length.

    I could not yet find a bitrate scanner for Linux that truly scans the file. I've found a few that give bitrates but I guess they've taken those from metadata since the result is always shown instantaneously.
    Quote Quote  
  9. Member
    Join Date: Mar 2008
    Location: United States
    Search Comp PM
    If this "bad" copy was the result of copy/paste using Windows Explorer or similar tools, maybe you should run a CHKDSK.
    If you're getting this kind of corruption, you may have bigger issues than a bad video file.
    Quote Quote  
  10. Running mkv validator (http://www.matroska.org/downloads/mkvalidator.html) might show up some problems on one of the files.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  11. Member
    Join Date: Oct 2004
    Location: Freedonia
    Search Comp PM
    Time spent to manually watch videos and determine if there is a problem - somewhere between 1 and 2x the length of the video. Assuming 1st video copy is OK, he'll have to watch it all the way through to confirm that plus if he finds an error in the second, he can stop watching once he finds it. Reverse the procedure if the 1st video has a problem (ie. stop watching 1st video and watch 2nd all the way through to confirm it's OK).

    Time spent asking questions for a miracle answer that means he doesn't have to watch the video - 2 days and counting because he has yet to find the miracle answer he seeks.
    Quote Quote  
  12. Member
    Join Date: May 2014
    Location: Vienna
    Search PM
    thanks for the hint with the mkvalidator. downloaded and built it, ran it on both version though only got a few warnings and those where the same for both "copies"

    WRN0C2: The timecode of the Cluster at 1656835956 is not incrementing (may be intentional)
    WRN0C2: The timecode of the Cluster at 4033828443 is not incrementing (may be intentional)
    WRN0C2: The timecode of the Cluster at 4116794453 is not incrementing (may be intentional)
    WRN0C2: The timecode of the Cluster at 4287650359 is not incrementing (may be intentional)
    WRN0C2: The timecode of the Cluster at 5628687571 is not incrementing (may be intentional)
    WRN0D0: There are 5430 bytes of void data........................................
    I've also extracted the raw streams of the matroska container and found that the part where the difference is is fully contained within the stream #0 which is the video h264 stream.
    Now what I needed would be a way to link the data segmet to the frame (since its only ~300 bytes) it belongs to and maybe try to inspect the frame for any damage.
    Quote Quote  
  13. Calling mkvinfo (-g for GUI) and enabling all the options under 'Options' might help with finding more details.
    Comparing the output of:
    Code:
    mkvinfo -C "Path to file"
    for the two files (using some editor which can compare two files) might also help.

    If you know some programming you could also parse the raw video files and compare them.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  14. Member
    Join Date: May 2014
    Location: Vienna
    Search PM
    Originally Posted by jman98 View Post
    Time spent to manually watch videos and determine if there is a problem - somewhere between 1 and 2x the length of the video. Assuming 1st video copy is OK, he'll have to watch it all the way through to confirm that plus if he finds an error in the second, he can stop watching once he finds it. Reverse the procedure if the 1st video has a problem (ie. stop watching 1st video and watch 2nd all the way through to confirm it's OK).

    Time spent asking questions for a miracle answer that means he doesn't have to watch the video - 2 days and counting because he has yet to find the miracle answer he seeks.
    well maybe you can't imagine but actually the last 2 days I did not only wait for your brilliant post but also did a lot of other work. but even if watching the video twice would be quicker, I would not learn anything from it, I prefer this approach thank you.

    Also the ~300 bytes damage that seem to exist within the video stream will probably be hard to notice by watching since the damage seems not to be in a fatal spot - otherwise the reencoding attempt (ffmpeg see first post) would already have failed.
    Quote Quote  
  15. In Windows you could open both videos in AviSynth, subtract one from the other, then test the output for non-blank frames.
    Quote Quote  
  16. Member
    Join Date: May 2014
    Location: Vienna
    Search PM
    @jagabo wow! thats a brilliant idea! gonna try that tomorrow (and I don't need windows for that, either I'll use wine or avxsynth directly

    update: @jagabo --> how do I test the output for non-blank frames?

    difference script:
    LoadPlugin("C:/Program Files (x86)/AviSynth 2.5/plugins/ffms2-2.20-icl/x86/ffms2.dll")
    here = FFVideoSource("here.x264")
    there = FFVideoSource("there.x264")
    return Subtract(here,there)
    update2: yayyy found it it was frame 48319, which I found by encoding the diference with x264 and looking at the encoder output:

    [34.4%] 48291/140581 frames, 49.59 fps, 13.80 kb/s, 3.31 MB, eta 0:31:01, est.size 9.64 MB
    [34.4%] 48304/140581 frames, 49.58 fps, 13.80 kb/s, 3.31 MB, eta 0:31:01, est.size 9.64 MB
    [34.4%] 48317/140581 frames, 49.58 fps, 13.80 kb/s, 3.31 MB, eta 0:31:00, est.size 9.64 MB
    [34.4%] 48321/140581 frames, 49.57 fps, 14.05 kb/s, 3.38 MB, eta 0:31:01, est.size 9.82 MB
    [34.4%] 48334/140581 frames, 49.57 fps, 14.05 kb/s, 3.38 MB, eta 0:31:01, est.size 9.82 MB
    [34.4%] 48347/140581 frames, 49.57 fps, 14.05 kb/s, 3.38 MB, eta 0:31:00, est.size 9.82 MB
    this increase in bitrate told me that there was something non empty between 48317 and 47321
    Last edited by kaefert; 23rd Jul 2014 at 19:51.
    Quote Quote