Debunked: MH17 Video Timestamped before the crash, and other timeline issues

Mick West

Administrator
Staff member
Summary: YouTube video creation date seemed to be on the day before the crash, however tests show YouTube subtracts a day from the mp4 creation date of all videos uploaded, so the video was actually uploaded six hours after the crash.

Details:

MH17 crashed on July 17th, 2014, shortly after 13:20 (UTC) 16:20 local Ukraine time (UTC +3 Eastern Europe Summer Time)

Flightradar24.com_-_Live_flight_tracker_2014-07-21_10-18-22_2014-07-21_10-19-03.jpg


The initial Malaysia airlines statement said:
External Quote:

Media Statement 1: MH17 Incident

Malaysia Airlines confirms it received notification from Ukrainian ATC that it had lost contact with flight MH17 at 1415 (GMT) at 30km from Tamak waypoint, approximately 50km from the Russia-Ukraine border.

Flight MH17 operated on a Boeing 777 departed Amsterdam at 12.15pm (Amsterdam local time) and was estimated to arrive at Kuala Lumpur International Airport at 6.10 am (Malaysia local time) the next day.
This is an erroneous use of the term GMT for British local time, which is currently British Summer Time (BST) which is UTC+1. It's a common mistake. GMT is actually always UTC, but British people often use the term GMT for both.

A video was uploaded to Youtube by the Ukranian Intelligence Service. Dated July 17th.



Russian blogger "gmorder" downloaded the mp4 version of this video from YouTube, then uploaded it to the russian file-sharing site RGhost.net, and looked at what RGhost.net reported as the "creation_time", which showed up as 2014-07-16 19:10:24. The day before the crash.

gmorder_Zaplanirovannoe_sbitie_kukrami_boinga._RASPROSTRANYaEM_2014-07-21_10-46-39_2014-07-21_10-46-41.jpg


In order to investigate what happened, I took a ten second video of the http://time.gov web site, which shows the local time (Pacific Daylight Time, UTC-7) (atached MVI_1246.MOV), . I set the date on my camera to 2015, so the time-stamps could easily be distinguished. I then uploaded this to YouTube.

(I accidently shot it in slow motion, but it does not change the timestamp at all)

The time there is 09:15 PDT, or 16:16 UTC.
It then downloaded the .MP4 of this video from YouTube, using the DownloadHelper plugin for FireFox (attached, MVI_1246_TimeStamp_Test.mp4). I then uploaded both files (original from camera, and downloaded from youtube) to Rghost.net:

http://rghost.net/private/57018999/32c2df8356e8c644ccd198532286a6f5

MVI_1246.MOV__RGhost__file_sharing_2014-07-21_10-54-45_2014-07-21_10-55-12.jpg


http://rghost.net/private/57020524/f406ba4ec3a2e7aa56cc2591c99ce988

MVI_1246_TimeStamp_Test.mp4__RGhost__file_sharing_2014-07-21_10-55-37_2014-07-21_10-55-48.jpg


Note the original file is dated 2015-07-21 16:15:09, the correct camera time in UTC (with the year changed for easy identification). The YouTube converted file is dated 2014-07-20 16:17:15, this is the correct time that the video was uploaded, but ONE DAY EARLIER in UTC.

So, this process is somehow removing one day from the actual time. It's not clear here if it's YouTube, or the RGhost system.

This means that the Ukranian Intelligence Service video was actually uploaded to YouTube on 2014-07-17 19:10:24. UTC. Six hours after the crash.
 

Attachments

Last edited:
Seems like date/time conversion is a very frequent source of error. When I examine the converted MP4 in MP4 Explorer, I get:

Windows_7_1_-_Parallels_Desktop_2014-07-21_13-14-00_2014-07-21_13-14-05.jpg

July 20th, 04:17:15 UTC, which is now 36 hours before I actually created it.

Similarly the Ukraine video gives:
Windows_7_1_-_Parallels_Desktop_2014-07-21_13-16-22_2014-07-21_13-16-31.jpg


(this is the English Language version, uploaded after the Russian one).

I suspect this is a display coding error, they are using 12 hour format internally, the 08:32 time above should be 08:32 PM, or 20:32.

However the error is consistent with both files, and again puts the Ukraine SSU file YouTube upload time at about six hours after the crash.
 
Last edited:
Getting a bit more technical. I used the command line tool mp4file (part of the open source mp4V2 library) To dump the files:

mp4file --dump MVI_1246_TimeStamp_Test.mp4
Gives:
Code:
"MVI_1246_TimeStamp_Test.mp4": Dumping meta-information...
"MVI_1246_TimeStamp_Test.mp4": type ftyp (ftyp)
  "MVI_1246_TimeStamp_Test.mp4": majorBrand = mp42
  "MVI_1246_TimeStamp_Test.mp4": minorVersion = 0 (0x00000000)
  "MVI_1246_TimeStamp_Test.mp4": <table entries suppressed>
"MVI_1246_TimeStamp_Test.mp4": type moov (moov)
  "MVI_1246_TimeStamp_Test.mp4": type mvhd (moov.mvhd)
   "MVI_1246_TimeStamp_Test.mp4": version = 0 (0x00)
   "MVI_1246_TimeStamp_Test.mp4": flags = 0 (0x000000)
   "MVI_1246_TimeStamp_Test.mp4": creationTime = 3488717835 (0xcff19c0b)
   "MVI_1246_TimeStamp_Test.mp4": modificationTime = 3488717835 (0xcff19c0b)

The creationTime and modificationTime are the same there, and the numbers are found in the actual raw MP3. (Stored in the Quicktime movie "atom" format)
MVI_1246_TimeStamp_Test.mp4_2014-07-21_15-37-23_2014-07-21_15-39-00.jpg
qt_l_095.gif_329490_2014-07-21_22-54-02_2014-07-21_22-54-23.jpg


The time code is in "Mac Timestamp" format, which is the number of seconds since midnight Jan 1st 1904. There's an online converter here:
http://www.epochconverter.com/epoch/mac-timestamp.php

This gives the time as GMT: Sun, 20 Jul 2014 16:17:15 GMT, proving that the incorrect time stamp is embedded in the file downloaded from YouTube. Hence the error is in YouTube's conversion process.

The Ukrainian SSU video gives:
Code:
"SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": Dumping meta-information...
"SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": type ftyp (ftyp)
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": majorBrand = mp42
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": minorVersion = 0 (0x00000000)
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": <table entries suppressed>
"SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": type moov (moov)
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": type mvhd (moov.mvhd)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": version = 0 (0x00)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": flags = 0 (0x000000)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": creationTime = 3488387532 (0xcfec91cc)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": modificationTime = 3488387532 (0xcfec91cc)

Converting the timestamp gives us:
GMT: Wed, 16 Jul 2014 20:32:12 GMT, consistent with what we see above, one day before the actual upload.

What is the source of this error? I suspect it's an "off by one" error. Quite likely the programmers did the time conversion by converting to (or from) UNIX epoch time, which is the number of seconds since Midnight Jan 1st 1970. So they do it by subtracting the number of seconds between 1904 and 1970. This might have been calculate off by one by either adding a leap year, or by counting Jan 1st twice. The error would be 1 day in seconds, so 86,400 seconds.

Wolfram Alpha gives the difference as:
http://www.wolframalpha.com/input/?i=number of seconds between jan 1 1904 and jan 1 1970
24107 days, or 2082844800 seconds

But this is the type of number that seems easy to calculate by hand. The number of days is just (1970-1904)*365 plus the number of leap years (as each leap year has one extra day).

How many leap years, well, you can easily image a programmer doing (1970-1904)/4 = 16.5, so 16. But that misses the fact that 1904 is a leap year, so now you are off by one day.
 
Last edited:
Great comments. I've also observed the internal operational activities of YouTube; the one I spent time on was the view counter and compared against time. The view counter does fluctuate variably higher or backwards (nonsensically) over time. I have not nailed down exactly their protocols, but if this thread or others need the information; I will retrieve and pass along.

A similar area of interest I have had is monitoring many internal operations, including program changes, at FB. I might be able to provide additional data. A quick point with FB, as it relates to this thread, when looking at time for file properties and uploads, don't forget to observe the SERVER utilized. For example, when FB traffic becomes burdensome; users are redirected to servers in different locations, including international. One server I observed for some time was Ireland (I was being diverted there). Yes, we can draw many possible reasons why.

EXECUTIVE SUMMARY:
We all should make sure when we're evaluating time stamps, to also consider the transmission location against the receiving server's location. Don't let this aspect slip through the cracks. I hope that helps in a small way, now or in the future. Oh and of course (I would suspect from the talent/membership herein, time authenticating protocols from the OS and manipulations to internal pc clocks are a given).
 
Getting a bit more technical. I used the command line tool mp4file (part of the open source mp4V2 library) To dump the files:

mp4file --dump MVI_1246_TimeStamp_Test.mp4
Gives:
Code:
"MVI_1246_TimeStamp_Test.mp4": Dumping meta-information...
"MVI_1246_TimeStamp_Test.mp4": type ftyp (ftyp)
  "MVI_1246_TimeStamp_Test.mp4": majorBrand = mp42
  "MVI_1246_TimeStamp_Test.mp4": minorVersion = 0 (0x00000000)
  "MVI_1246_TimeStamp_Test.mp4": <table entries suppressed>
"MVI_1246_TimeStamp_Test.mp4": type moov (moov)
  "MVI_1246_TimeStamp_Test.mp4": type mvhd (moov.mvhd)
   "MVI_1246_TimeStamp_Test.mp4": version = 0 (0x00)
   "MVI_1246_TimeStamp_Test.mp4": flags = 0 (0x000000)
   "MVI_1246_TimeStamp_Test.mp4": creationTime = 3488717835 (0xcff19c0b)
   "MVI_1246_TimeStamp_Test.mp4": modificationTime = 3488717835 (0xcff19c0b)

The creationTime and modificationTime are the same there, and the numbers are found in the actual raw MP3. (Stored in the Quicktime movie "atom" format)
MVI_1246_TimeStamp_Test.mp4_2014-07-21_15-37-23_2014-07-21_15-39-00.jpg
qt_l_095.gif_329490_2014-07-21_22-54-02_2014-07-21_22-54-23.jpg


The time code is in "Mac Timestamp" format, which is the number of seconds since midnight Jan 1st 1904. There's an online converter here:
http://www.epochconverter.com/epoch/mac-timestamp.php

This gives the time as GMT: Sun, 20 Jul 2014 16:17:15 GMT, proving that the incorrect time stamp is embedded in the file downloaded from YouTube. Hence the error is in YouTube's conversion process.

The Ukrainian SSU video gives:
Code:
"SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": Dumping meta-information...
"SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": type ftyp (ftyp)
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": majorBrand = mp42
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": minorVersion = 0 (0x00000000)
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": <table entries suppressed>
"SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": type moov (moov)
  "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": type mvhd (moov.mvhd)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": version = 0 (0x00)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": flags = 0 (0x000000)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": creationTime = 3488387532 (0xcfec91cc)
   "SSU_radio_interception_of_conversations_between_terrorists_Boeing-777_plane_crash.mp4": modificationTime = 3488387532 (0xcfec91cc)

Converting the timestamp gives us:
GMT: Wed, 16 Jul 2014 20:32:12 GMT, consistent with what we see above, one day before the actual upload.

What is the source of this error? I suspect it's an "off by one" error. Quite likely the programmers did the time conversion by converting to (or from) UNIX epoch time, which is the number of seconds since Midnight Jan 1st 1970. So they do it by subtracting the number of seconds between 1904 and 1970. This might have been calculate off by one by either adding a leap year, or by counting Jan 1st twice. The error would be 1 day in seconds, so 86,400 seconds.

Wolfram Alpha gives the difference as:
http://www.wolframalpha.com/input/?i=number of seconds between jan 1 1904 and jan 1 1970
24107 days, or 2082844800 seconds

But this is the type of number that seems easy to calculate by hand. The number of days is just (1970-1904)*365 plus the number of leap years (as each leap year has one extra day).

How many leap years, well, you can easily image a programmer doing (1970-1904)/4 = 16.5, so 16. But that misses the fact that 1904 is a leap year, so now you are off by one day.
Thanks Mick for information. An area I've been wanting to study....
 
Great comments. I've also observed the internal operational activities of YouTube; the one I spent time on was the view counter and compared against time. The view counter does fluctuate variably higher or backwards (nonsensically) over time. I have not nailed down exactly their protocols, but if this thread or others need the information; I will retrieve and pass along.

A similar area of interest I have had is monitoring many internal operations, including program changes, at FB. I might be able to provide additional data. A quick point with FB, as it relates to this thread, when looking at time for file properties and uploads, don't forget to observe the SERVER utilized. For example, when FB traffic becomes burdensome; users are redirected to servers in different locations, including international. One server I observed for some time was Ireland (I was being diverted there). Yes, we can draw many possible reasons why.

EXECUTIVE SUMMARY:
We all should make sure when we're evaluating time stamps, to also consider the transmission location against the receiving server's location. Don't let this aspect slip through the cracks. I hope that helps in a small way, now or in the future. Oh and of course (I would suspect from the talent/membership herein, time authenticating protocols from the OS and manipulations to internal pc clocks are a given).

-----------------

I will slow down with my responses, because after reading Mick's comments; it's fairly evident that there is some very quality analysis herein. TIME IS OF THE ESSENCE for me, but that's no excuse for jumping in too quickly.
 
Nikolay Kozitsyn confirms that it is him speaking in the taped phone conversation.

See from 6:44



See from 1:49 for Kozitsyn recording.

 
Last edited:
Back
Top