Utah Drone video of UFO [Probably an insect]

[Ravi]

A few days ago, a youtube video was posted on Reddit r/UFO's showing an object flying by a drone, with the description:

I usually cover politics, but when Sam Chortek and Jimmy Chappie came to me with this exclusive UAP footage, I had to break the story. This video has never been seen by the public until now. The RAW FOOTAGE can be downloaded here: https://youtu.be/bVmGhxYrkug All Rights Reserved. 2019. For media inquires, contact BrianJosephHanley@gmail.com.

Content from external source

New links to the "raw" footage soon appeared: https://uploadfiles.io/epai0 is an example.

I made two screenshots, showing the object in "flight", it flys by from 2:33 to 2.35 approx.

[GALLERY=media, 103]1 by Ravi posted Jan 13, 2019 at 6:29 PM[/GALLERY][GALLERY=media, 105]3 by Ravi posted Jan 13, 2019 at 6:30 PM[/GALLERY]

Source: https://youtu.be/bVmGhxYrkug?t=152



Here is another video of it [that just highlights the alleged UAP/UFO]: Source: https://imgur.com/a/MEAgNQV


With these clear videos is I think we could do some calculations, or other advanced analysis?
I am tending towards cgi myself.

 

[Tha_Dude_Abidez]

There's alot of enhanced video's of this. I hope someone can figure it out. The RAW file is clearer in this:

The object enters view at 1:49. Be sure and play in HD

Here's some enhanced videos of the object:

Source: https://imgur.com/a/MEAgNQV


Source: https://imgur.com/a/QMQnFVw


Source: https://vimeo.com/311025833


and here is the original first video with commentary the guy put up. He sounds genuine and in the Youtube comments is active in answering questions etc:


I really hope someone can get to the bottom of this. Here is the Metadata. The time, date and location match to the uploaders claims:

File Name RAW FOOTAGE of UAP Sighting_ Beaver, Utah (October 18, 2016).MOV File Size 1235 MB File Type MOV File Type Extension mov Mime Type video/quicktime Major Brand Apple QuickTime (.MOV/QT) Minor Version 2014.2.0 COMPATIBLEBRANDS 0qt Movie Data Size 1295120164 Movie Data Offset 40 Movie Header Version 0 Create Date 2016:10:18 11:19:22 Modify Date 2016:10:18 11:19:22 Time Scale 60000 Duration 0:02:52 Preferred Rate 1 Preferred Volume 100.00% Preview Time 0 s Preview Duration 0 s Poster Time 0 s Selection Time 0 s Selection Duration 0 s Current Time 0 s Next Track Id 2 Gps Coordinates-Err 38 deg 15' 55.59" N, 112 deg 36' 44.11" W, 3.1 m Above Sea Level Speed X-Err +0.70 Speed Y-Err -0.20 Speed Z-Err +0.10 Pitch-Err +0.50 Yaw-Err +170.50 Roll-Err +2.50 Camera Pitch-Err +0.00 Camera Yaw-Err +171.90 Camera Roll-Err +0.00 Comment 0.9.198 Category v01.27.5134 Model FC550 Track Header Version 0 Track Create Date 2016:10:18 11:19:22 Track Modify Date 2016:10:18 11:19:22 Track Id 1 Track Duration 0:02:52 Track Layer 0 Track Volume 0.00% Matrix Structure 1 0 0 0 1 0 0 0 1 Image Width 1920 Image Height 1080 Media Header Version 0 Media Create Date 2016:10:18 11:19:22 Media Modify Date 2016:10:18 11:19:22 Media Time Scale 60000 Media Duration 0:02:52 Handler Class Media Handler Handler Type Video Track Handler Description DJI.AVC Graphics Mode srcCopy Op Color 0 0 0 Compressor Id avc1 Source Image Width 1920 Source Image Height 1080 X Resolution 72 Y Resolution 72 Compressor Name Dji AVC encoder Bit Depth 24 Video Frame Rate 59.94 Gps Coordinates 38 deg 15' 55.59" N, 112 deg 36' 44.11" W, 3.1 m Above Sea Level Speed X +0.70 Speed Y -0.20 Speed Z +0.10 Pitch +0.50 Yaw +170.50 Roll +2.50 Camera Pitch +0.00 Camera Yaw +171.90 Camera Roll +0.00 Avg Bitrate 59.9 Mbps Gps Altitude 3.1 m Gps Altitude Ref Above Sea Level Gps Latitude 38 deg 15' 55.59" N Gps Longitude 112 deg 36' 44.11" W Image Size 1920x1080 Megapixels 2.1 Rotation 0 Gps Position 38 deg 15' 55.59" N, 112 deg 36' 44.11" W Mime Type video/quicktime Category video Type quicktime Raw Header 00 00 00 20 66 74 79 70 71 74 20 20 20 14 02 00 71 74 20 20 00 00 00 00 00 00 00 00 00 00 00 00 4D 31 F7 2C 6D 64 61 74 00 00 00 02 09 10 00 00 00 20 06 00 0D 80 B8 92 FF F7 36 00 B8 92 FF F7

 

[Ravi]

As I do not believe objects can move that fast without a trace, and a bug I also find crazy, so it must be added imagery, cgi.

 

[purpleivan]

Actually I think it is just a bug.

Here's an animation I quickly did of a bug sized object (1cm across) moving at a bug like speed (about 7km/h) towards an approaching camera moving at drone like speed (30km/h). For the FOV I used that of the DJI Phantom Pro 4, the forward camera of which is listed as 50 degrees.

It's a bit rough, as it's late and I didn't have time to get the moving background added from the original video, or motion blur on the object, but I think it shows that a bug could be the source of the object in the video.

 

[jarlrmai]

I was going to try and do the same thing in Blender, I think people are confused by the fact that the scenery is moving so slowly, parallax strikes again.

 

[purpleivan]

Here's an image of the paths of the camera and bug I set up in my 3D scene.

 

[Ravi]

Good points, purpleivan. I was also thinking about this option. I think your recreation is a good example on how to prove an argument. I would not be able to do it this quick, so thanks.

 

[Nspekta]

Ive been following the different analysis out there on this video and just want to post this here.

So far, from my searching, no-one has been able to definitively prove this is CGI.. some showing how they could do a very rough version of it as a fake but even with the raw video files and metadata, I haven't found definitive proof that this is fake.
I also want to put these vids here for those who are convinced it is a bug. this one analysis video shows that that object goes behind the treeline way far back at the point where the object first appears... if this is the case, there is no chance it can be an insect as it would prove that the object does come out/over the mountain and goes below the treeline for a very short timeframe before zipping towards the drone.

Source: https://streamable.com/gusfk


and another enhanced version of the video: Source: https://vimeo.com/311025833


I am really trying to see if someone can prove, without a doubt, that this is CGI. IF not, as it appears, it could be a real video which then opens up a whole other can of worms, including WTF is it?!?!

Thoughts?

 

[deirdre]

this one analysis video shows that that object goes behind the treeline way far back at the point where the object first appears...

just watched your videos multiple times. It does not go behind the treeline. I can still see it


his spotlight there fades it out a bit, but it's still there. (i still think it's a bird because its wings move like a bird and it soars like a bird. but that's me.)

 

[Nspekta]

just watched your videos multiple times. It does not go behind the treeline. I can still see it
View attachment 35716

his spotlight there fades it out a bit, but it's still there. (i still think it's a bird because its wings move like a bird and it soars like a bird. but that's me.)

Thanks for reply. I see it disappear very quickly but that doesnt necessarily mean its that far out.. I'm still unconvinced on bird or bug.. I just dont see wings and it comes from so far back. I really wish i was good at video analysis lol

Here is another vid with some interesting filters.. to me, this shows that it is coming from a decent distance away. And I still dont see wings (not that they couldn't be there but I dont recognize them after watching this, the raw, and multiple analysis vids a ridiculously amount of times lol )

Source: https://youtu.be/Sfh90Jzs4js

 

[deirdre]

I see it disappear very quickly but that doesnt necessarily mean its that far out..

yea, it doesnt really mean much if it disappears anyway.. can you find the bright white butterfly in the lower left corner in this pic?


He is in there. (video will start when butterfly flitting about)

https://youtu.be/ibLFByRIlH0?t=224

We do have several threads on bugs (and pieces of fluff flying in the wind) close to the camera, that look like things further away. one thread i found quick is https://www.metabunk.org/debunked-denver-ufos-insects.t910/

I'll look for others tomorrow. With the fly vidoes in the above thread, if you change the backdrop (in your mind) to the OP (Opening post) video backdrop, it's easier to imagine that a bug nearby can look like it's far away.

 

[deirdre]

I just dont see wings

i only see what appear to be wing movement before it takes the big turn towards the camera. but that movement could just be a film artifact, the same way it (and my above butterfly) seem to disappear. hard to tell. Either way i dont see how it could be a spaceship because it's basically see through on the last frames before it flies out of frame, which is what happens with blurring but i doubt a big metal object can blur to see through.

On youtube if you use the > keys, you can move the vid frame by frame. this is the bug/bird/butterfly/fluff thing as it nears the camera. (which i think alone disproves cgi.. but i'm not familiar with making cgi really)

 

[deirdre]

I just dont see wings

yea i see wings on the bug in one of @Mick West 's contrail videos and i'm a bit unbelieving that i can see wings on a bug as its flying so must be a lighting camera thing.

Source: https://youtu.be/S5pP6naBcnY?t=100

 

[jarlrmai]

If the wings are lit up you'll see them as a sort of flashing very fast strobe light, they tend to catch the eye.

 

[DasKleineTeilchen]

and it comes from so far back

it just looks like, but it doesnt. if you move with 30km/h (as the drone does) forward and a small object (like a bug) comes directly at you and passes right at your eye (or the camera-lens), it will go from nearly invisible to huuuuuge in just seconds. think yourself on a bike or in a car...you dont see the fly/bug/whatever but right before it hits your eye (or windshild).

its not cgi nor a superfast craft, its just an insect as far as I can tell.

 

[prickly_don]

its not cgi nor a superfast craft, its just an insect as far as I can tell.

The linked YouTube video contains an analysis arguing that the object of interest cannot be a bug or a bird.

• [...]
• It shows that at one point, the object does become completely obscured by ridgeline vegetation (refer to frame 6510, or 1:48.30 of the released raw .MOV footage).
• [...]

[...]

Source: https://www.youtube.com/watch?v=4yRlWmk6p-w

 

[Mick West]

It shows that at one point, the object does become completely obscured by ridgeline vegetation (refer to frame 6510, or 1:48.30 of the released raw .MOV footage).

It does not show this. It shows that on one frame the object is not visible. But this appears to be because of noise and compression artifacts. Consider the three frames with the "hidden" one in the middle: (01:48:29-31, contrast enhanced)

 

[Mick West]

Here are the frames in question (from the raw footage, which is still h.264 compressed). The visibility seems entirely consistent with noise and compression

 

[prickly_don]

It does not show this. It shows that on one frame the object is not visible. But this appears to be because of noise and compression artifacts.

Let's suppose for a second that this is true. How peculiar is it that the compression algorithm chose just that one frame in which to selectively truncate the object from the scene, when it wasn't truncated from any of the frames immediately preceding or following it, especially ones where the object is considerably less visible than it is in frames 6509 and 6511 (frames 6482-6496, or 1:48.02-1:48.16)?

 

[Mick West]

Let's suppose for a second that this is true. How peculiar is it that the compression algorithm chose just that one frame in which to selectively truncate the object from the scene, when it wasn't truncated from any of the frames immediately preceding or following it, especially ones where the object is considerably less visible than it is in frames 6509 and 6511 (frames 6482-6496, or 1:48.02-1:48.16)?

It's not odd, it's moving down to into a region of slightly higher contrast/noise, which changes the equation.

And it does drop out in previous frames, like 1:48:12 (and 13)


And 1:47:52


The "hidden" frame is simply the last time it drops out, and hence the most noticeable.

 

[Gerard]

What if it's not an insect but a bird ?

Wing flapping could explain the apparent disappearance when its far away without the need to assume a sudden increase in noise between two frames with relatively strong signal.

During the turn it looks to me very much like a bird with a large wingspan (like a hawk or eagle).

Even in the final very blurred frame when it passes closest to the drone there seems to be a hint of winglike structure.

Sorry, I'd post stills of what I'm talking about but my video editing skills are a bit limited.

 

[prickly_don]

it's moving down to into a region of slightly higher contrast/noise

The concept of contrast is antithetical to that of noise, not similar. An area of low or no contrast is generally indistinguishable from one of high noise. This is the basis of an SNR (signal to noise ratio). I'm not sure what you're implying there.

As far as frames 6492 and 6493 (1:48.12 and 1:48.13), I would argue that no, it does not disappear. Here's frames 6489-6496 (1:48.09-1:48.16) inverted, looped forward and in reverse. To be honest, I can't really see it when the frames are moving forward either, but in reverse, the story changes. It's barely visible, but it's still distinguishable from background noise, and it actually perturbs the background directly behind it in a concentric manner. Frames 6492 and 6493 are problematic due to the object moving very little from one frame to the next.




The point I'm trying to argue here is that the object has far more contrast (i.e. visibility) during frames 6509 and 6511 than it does during frames 6489-6496. Consequently, the video codec would be far more likely to interpret the object as background noise during frames 6489-6496 than it would during frame 6510, seeing as how the object has reasonably high contrast with the background during the two frames adjacent to it (6509 and 6511). It is highly unlikely that the codec simply compressed the object out of that one frame, as surely, it would have opted to compress it out of 6489-6496 first.

 

[deirdre]

During the turn it looks to me very much like a bird with a large wingspan (like a hawk or eagle).

bugs have wings.

but looks like a bird to me too.


this ^ UFO believer is thinking it is a gyr falcon.

UFO PROOF
Published on Jan 21, 2019

SUBSCRIBE 11K
The utah drone ufo is nothing more than a gryfalcon

Content from external source

and he shows some gyr falcon footage, showing similar shaping.

 

[Mick West]

The concept of contrast is antithetical to that of noise, not similar. An area of low or no contrast is generally indistinguishable from one of high noise This is the basis of an SNR (signal to noise ratio). I'm not sure what you're implying there.

I never imply.

Consider white noise. It's high contrast.


Since the object is only 2-4 pixels at that point, it's not much different to the actual noise in the video.

It is highly unlikely that the codec simply compressed the object out of that one frame, as surely, it would have opted to compress it out of 6489-6496 first.

Codecs don't "opt" to compress things, it's based on an algorithm. In this case, it's the h.264 algorithm, which is quite complicated.

Spoiler: Complicated details

H.264/AVC/MPEG-4 Part 10 contains a number of new features that allow it to compress video much more efficiently than older standards and to provide more flexibility for application to a wide variety of network environments. In particular, some such key features include:

• Multi-picture inter-picture prediction including the following features:
  • Using previously encoded pictures as references in a much more flexible way than in past standards, allowing up to 16 reference frames (or 32 reference fields, in the case of interlaced encoding) to be used in some cases. In profiles that support non-IDR frames, most levels specify that sufficient buffering should be available to allow for at least 4 or 5 reference frames at maximum resolution. This is in contrast to prior standards, where the limit was typically one; or, in the case of conventional "B pictures" (B-frames), two. This particular feature usually allows modest improvements in bit rate and quality in most scenes.[citation needed] But in certain types of scenes, such as those with repetitive motion or back-and-forth scene cuts or uncovered background areas, it allows a significant reduction in bit rate while maintaining clarity.
  • Variable block-size motion compensation (VBSMC) with block sizes as large as 16×16 and as small as 4×4, enabling precise segmentation of moving regions. The supported luma prediction block sizes include 16×16, 16×8, 8×16, 8×8, 8×4, 4×8, and 4×4, many of which can be used together in a single macroblock. Chroma prediction block sizes are correspondingly smaller according to the chroma subsampling in use.
  • The ability to use multiple motion vectors per macroblock (one or two per partition) with a maximum of 32 in the case of a B macroblock constructed of 16 4×4 partitions. The motion vectors for each 8×8 or larger partition region can point to different reference pictures.
  • The ability to use any macroblock type in B-frames, including I-macroblocks, resulting in much more efficient encoding when using B-frames. This feature was notably left out from MPEG-4 ASP.
  • Six-tap filtering for derivation of half-pel luma sample predictions, for sharper subpixel motion-compensation. Quarter-pixel motion is derived by linear interpolation of the halfpel values, to save processing power.
  • Quarter-pixel precision for motion compensation, enabling precise description of the displacements of moving areas. For chroma the resolution is typically halved both vertically and horizontally (see 4:2:0) therefore the motion compensation of chroma uses one-eighth chroma pixel grid units.
  • Weighted prediction, allowing an encoder to specify the use of a scaling and offset when performing motion compensation, and providing a significant benefit in performance in special cases—such as fade-to-black, fade-in, and cross-fade transitions. This includes implicit weighted prediction for B-frames, and explicit weighted prediction for P-frames.
• Spatial prediction from the edges of neighboring blocks for "intra" coding, rather than the "DC"-only prediction found in MPEG-2 Part 2 and the transform coefficient prediction found in H.263v2 and MPEG-4 Part 2. This includes luma prediction block sizes of 16×16, 8×8, and 4×4 (of which only one type can be used within each macroblock).
• Lossless macroblock coding features including:
  • A lossless "PCM macroblock" representation mode in which video data samples are represented directly,[34] allowing perfect representation of specific regions and allowing a strict limit to be placed on the quantity of coded data for each macroblock.
  • An enhanced lossless macroblock representation mode allowing perfect representation of specific regions while ordinarily using substantially fewer bits than the PCM mode.
• Flexible interlaced-scan video coding features, including:
  • Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames, allowing 16×16 macroblocks in field mode (compared with MPEG-2, where field mode processing in a picture that is coded as a frame results in the processing of 16×8 half-macroblocks).
  • Picture-adaptive frame-field coding (PAFF or PicAFF) allowing a freely selected mixture of pictures coded either as complete frames where both fields are combined together for encoding or as individual single fields.
• New transform design features, including:
  • An exact-match integer 4×4 spatial block transform, allowing precise placement of residual signals with little of the "ringing" often found with prior codec designs. This design is conceptually similar to that of the well-known discrete cosine transform (DCT), introduced in 1974 by N. Ahmed, T.Natarajan and K.R.Rao, which is Citation 1 in Discrete cosine transform. However, it is simplified and made to provide exactly specified decoding.
  • An exact-match integer 8×8 spatial block transform, allowing highly correlated regions to be compressed more efficiently than with the 4×4 transform. This design is conceptually similar to that of the well-known DCT, but simplified and made to provide exactly specified decoding.
  • Adaptive encoder selection between the 4×4 and 8×8 transform block sizes for the integer transform operation.
  • A secondary Hadamard transform performed on "DC" coefficients of the primary spatial transform applied to chroma DC coefficients (and also luma in one special case) to obtain even more compression in smooth regions.
• A quantization design including:
  • Logarithmic step size control for easier bit rate management by encoders and simplified inverse-quantization scaling
  • Frequency-customized quantization scaling matrices selected by the encoder for perceptual-based quantization optimization
• An in-loop deblocking filter that helps prevent the blocking artifacts common to other DCT-based image compression techniques, resulting in better visual appearance and compression efficiency
• An entropy coding design including:
  • Context-adaptive binary arithmetic coding (CABAC), an algorithm to losslessly compress syntax elements in the video stream knowing the probabilities of syntax elements in a given context. CABAC compresses data more efficiently than CAVLC but requires considerably more processing to decode.
  • Context-adaptive variable-length coding (CAVLC), which is a lower-complexity alternative to CABAC for the coding of quantized transform coefficient values. Although lower complexity than CABAC, CAVLC is more elaborate and more efficient than the methods typically used to code coefficients in other prior designs.
  • A common simple and highly structured variable length coding (VLC) technique for many of the syntax elements not coded by CABAC or CAVLC, referred to as Exponential-Golomb coding (or Exp-Golomb).
• Loss resilience features including:
  • A Network Abstraction Layer (NAL) definition allowing the same video syntax to be used in many network environments. One very fundamental design concept of H.264 is to generate self-contained packets, to remove the header duplication as in MPEG-4's Header Extension Code (HEC).[35] This was achieved by decoupling information relevant to more than one slice from the media stream. The combination of the higher-level parameters is called a parameter set.[35] The H.264 specification includes two types of parameter sets: Sequence Parameter Set (SPS) and Picture Parameter Set (PPS). An active sequence parameter set remains unchanged throughout a coded video sequence, and an active picture parameter set remains unchanged within a coded picture. The sequence and picture parameter set structures contain information such as picture size, optional coding modes employed, and macroblock to slice group map.[35]
  • Flexible macroblock ordering (FMO), also known as slice groups, and arbitrary slice ordering (ASO), which are techniques for restructuring the ordering of the representation of the fundamental regions (macroblocks) in pictures. Typically considered an error/loss robustness feature, FMO and ASO can also be used for other purposes.
  • Data partitioning (DP), a feature providing the ability to separate more important and less important syntax elements into different packets of data, enabling the application of unequal error protection (UEP) and other types of improvement of error/loss robustness.
  • Redundant slices (RS), an error/loss robustness feature that lets an encoder send an extra representation of a picture region (typically at lower fidelity) that can be used if the primary representation is corrupted or lost.
  • Frame numbering, a feature that allows the creation of "sub-sequences", enabling temporal scalability by optional inclusion of extra pictures between other pictures, and the detection and concealment of losses of entire pictures, which can occur due to network packet losses or channel errors.
• Switching slices, called SP and SI slices, allowing an encoder to direct a decoder to jump into an ongoing video stream for such purposes as video streaming bit rate switching and "trick mode" operation. When a decoder jumps into the middle of a video stream using the SP/SI feature, it can get an exact match to the decoded pictures at that location in the video stream despite using different pictures, or no pictures at all, as references prior to the switch.
• A simple automatic process for preventing the accidental emulation of start codes, which are special sequences of bits in the coded data that allow random access into the bitstream and recovery of byte alignment in systems that can lose byte synchronization.
• Supplemental enhancement information (SEI) and video usability information (VUI), which are extra information that can be inserted into the bitstream to enhance the use of the video for a wide variety of purposes.[clarification needed] SEI FPA (Frame Packing Arrangement) message that contains the 3D arrangement:
  • 0: checkerboard: pixels are alternatively from L and R.
  • 1: column alternation: L and R are interlaced by column.
  • 2: row alternation: L and R are interlaced by row.
  • 3: side by side: L is on the left, R on the right.
  • 4: top bottom: L is on top, R on bottom.
  • 5: frame alternation: one view per frame.
• Auxiliary pictures, which can be used for such purposes as alpha compositing.
• Support of monochrome (4:0:0), 4:2:0, 4:2:2, and 4:4:4 chroma subsampling (depending on the selected profile).
• Support of sample bit depth precision ranging from 8 to 14 bits per sample (depending on the selected profile).
• The ability to encode individual color planes as distinct pictures with their own slice structures, macroblock modes, motion vectors, etc., allowing encoders to be designed with a simple parallelization structure (supported only in the three 4:4:4-capable profiles).
• Picture order count, a feature that serves to keep the ordering of the pictures and the values of samples in the decoded pictures isolated from timing information, allowing timing information to be carried and controlled/changed separately by a system without affecting decoded picture content.

 

[Whitebeard]

bugs have wings.

but looks like a bird to me too.
View attachment 35898

this ^ UFO believer is thinking it is a gyr falcon.

UFO PROOF
Published on Jan 21, 2019

SUBSCRIBE 11K
The utah drone ufo is nothing more than a gryfalcon

Content from external source

and he shows some gyr falcon footage, showing similar shaping.
View attachment 35899

And if it is a Gryfalcon, or similar, then that would account for the speed of the artifact. In level flight they can hit nearly 70mph, in a stoop they top out around 130mph. (source)

Therefore if the artifact is a bird in a shallow dive towards the drone moving at around 15-20mph, the closing speed would be anything upto 150mph, and something that small (they aint large birds) moving at that kind of relative velocity is just going to be blur on the footage.

 

[purpleivan]

As for the "bug or bird" question, I'm happy with either.

Even though I've suggested it's a bug and made my render to explain the object in the video based on that, fundementally a bird is just a larger, further, faster "bug" as far as explaining the video is concerned. Could be some kind of very fast, but likely quite rare bird, or a more common one that is smaller, slower, but also closer to the drone.

Bird or bug, the important thing is that they both provide a perfectly natural explaination of the object, without reaching for any kind of exotic source for it.

 

[HoaxEye]

Here’s one drone video “bird flash fast” for comparison Source: https://youtu.be/QRWrMFIYun4

Another one that appears to be a bird Source: https://www.youtube.com/watch?v=M1RoJMyPpq4

 

[Ravi]

I am still on CGI. The trajectory and behaviour of flight does not match with a bugs flight. The lastly posted "comparison video's" are entirely not identical to the Utah vid..

 

[purpleivan]

What specifically about the object's flight does not match the movement of a bug, or a bird for that matter?

The movement in my rendered video is a pretty close match to the OP drone video, and the movement of the objects in that was based on the likely size and speed of a drone and an insect.

Additionally the "bird flash fast" video has the same core characteristic as the OP drone video (the very quick whoosh past the camera), albeit at a different angle of movement relative to the camera/drone (greater vertical movement than the video in the OP).

 

[rdi72]

You know what they say about opinions. Don’t give opinions, give some proof it’s a bird or bug. No mumbo jumbo. Whatever it is, it’s actually faster near the end than when it begins, otherwise, someone could point this out. No flapping wings, too straight of a line after turn. I’m going to give my opinion since everyone else is giving theirs. It would have to be CGI if it’s not some vehicle or something we don’t know. Show decisive proof. The posters of the video have nothing to prove. I came here thinking I was gonna see an explanation. Like everywhere else, nothing.

 

[JFDee]

Don’t give opinions, give some proof

Providing an alternative explanation that is possible means that assuming a more exotic explanation is not exclusive.

In the context we have here, providing a plausible hypothesis is sufficient. The original explanation is hypothetical as well.
Now it's a matter of probability to decide which explanation is more likely correct.

 

[Whitebeard]

You know what they say about opinions. Don’t give opinions, give some proof it’s a bird or bug. No mumbo jumbo. Whatever it is, it’s actually faster near the end than when it begins, otherwise, someone could point this out. No flapping wings, too straight of a line after turn. I’m going to give my opinion since everyone else is giving theirs. It would have to be CGI if it’s not some vehicle or something we don’t know. Show decisive proof. The posters of the video have nothing to prove. I came here thinking I was gonna see an explanation. Like everywhere else, nothing.

Only by exploring EVERY possible expliantion, can you even start to give any kind of analysis.

As for 'no flapping wings', birds of prey in a stoop do not flap their wings. The wings are held close into the body, and any wing movement is minimal alteration of possition, just enough to control direction without loosing speed.

Pictures of stooping falcons




Whats more ' Whatever it is, it’s actually faster near the end than when it begins', is also evidence that tend towards the falcon hypothisis. as a falcon going into a stoop will turn 'slowly' (although still damn fast in comparrison to other birds, 70-80mph) using minimal wing movement the tuck the wings even closer to the body to accelarate towards its prey

 

[purpleivan]

You know what they say about opinions. Don’t give opinions, give some proof it’s a bird or bug. No mumbo jumbo. Whatever it is, it’s actually faster near the end than when it begins, otherwise, someone could point this out. No flapping wings, too straight of a line after turn. I’m going to give my opinion since everyone else is giving theirs. It would have to be CGI if it’s not some vehicle or something we don’t know. Show decisive proof. The posters of the video have nothing to prove. I came here thinking I was gonna see an explanation. Like everywhere else, nothing.

I believe that the video that I made demonstrates that the movement is consistent with a bug, or possibly a small bird if the speed and distance is increased. It's not mumbo jumbo, it's a simulation.

The object does not need to be "faster near the end" as this is simply the illusion of the apparent speed of the object getting greater, the closer it gets to the camera. My video has exactly the same effect and the object in it is moving at a pretty consistant speed. The appearance of it moving in "too straight of a line after the turn" is just the product of its rate of movement across the frame. With such a small number of frames of video where the object is very close to the camera, the movement appears straighter, as there is much less time for movement to take place (how much vertical movement would you expect in less than 1/4 of a second).

As for there being no discernable wings, if it's a bug then these would not be visible due to the very high rate at which they beat. In the case of the object in the OP video being a small bird, the object is very small in the frame (just 2-4 pixels) for most of the video, so again wings would not be discernable.

It is only in the last few frames that the object is close enough that bird wings might be seen, but the rapid movement across the frame, creates motion blur, that can remove detail such as beating wings.

Could it be CGI... sure. I could take my render set up, improve it by adding motion blur and better lighting, then slap it on top of some drone video. But that would take time, and someone to want to do it. What doesn't require any work or inclination is it being something natural like a bug or bird.

 

[Mick West]

Another similar drone video that might be the same type of thing
http://ufosightingshotspot.blogspot.com/2019/02/ufo-fastwalker-is-flying-from-mountain.html
Source: https://www.youtube.com/watch?v=sZxvevRK1eA

The drone video is right at the start

 

[Mick West]

In fact, there's a variety of similar videos on that site, all labeled "fastwalker"
http://ufosightingshotspot.blogspot.com/search?q=fastwalker


It seems like "fastwalker" is the 2019 equivalent of the "rods" of a decade or two earlier. A semi-random visual artifact that people started seeing once a certain technology got sufficiently widespread. For rods it was crappy digital cameras. For "fastwalkers" it's drones moving past a bird or a bug.

Motivated reasoning is going to keep people thinking these are 4,000 mph UFOs. What we need is a nice general purpose "fastwalker simulator" to demonstrate how each occurence happened.

We also need a better name than "fastwalker"

 

[jarlrmai]

They are just rods all over again from what I can see, just cameras on drones detecting them in videos this time rather than single images with motion blur.

Same thing, a moving object smeared by motion blur and made to look fast by being close to the lens.

We should be able to simulate it in 3d modelling software as long as we can simulate the camera motion blur.

 

[Whitebeard]

We also need a better name than "fastwalker"

U.S.B
(unidentifed speedy bird/bug?)

 

[Mick West]

U.S.B
(unidentifed speedy bird/bug?)

A tad prejudging though. I was thinking “zipby” and a specific “drone zipby” (as in something that zips by the camera).

Zipbys are the new rods.

 

[Trailblazer]

They are just rods all over again from what I can see, just cameras on drones detecting them in videos this time rather than single images with motion blur.

Same thing, a moving object smeared by motion blur and made to look fast by being close to the lens.

We should be able to simulate it in 3d modelling software as long as we can simulate the camera motion blur.

Or maybe some drone owners could deliberately fly through areas with swarms of insects, to capture some known bug footage to compare these things to?

 

[Ravi]

I am completely for any earthly explanation or CGI but the last responses in this thread more or less say "well it is bugs, so shut up". This is I think not the way we should tackle the problem. I thought we should explain things by proof using models and simulations that without doubt explain the video of the subject. No?