cfair

Gang,
I’ve posted bunches of photos over the past few years and they seem to help.

I was just thinking that for some things - like carb adjustments, or throttle switches, or maybe some repair operations a short GoPro movie might be helpful.

What are the size and / or time limits on clips and what is the preferred format? I can’t imagine this site wants a bunch of 4K clips and attendant file sizes, but what are the preferred resolutions, lengths, and file sizes?

I’m _not_ talking about YouTube links, I’m talking about directly uploading video clips here from my computer, presumable after editing and optimizing for viewing here.

Guidelines, limits & suggestions most welcome.
Thanks in advance,
Chris

Koda

I don't think this site supports direct video attachment, nor should they. You would need to do what you are not talking about, or get your own domain.

For instance, here is a clip of a Stanley Steamer taking the hill at the Newport Hill Climb in 2009 that I have hosted on my own domain and linked here.

http://www.landofjohn.com/misc/MVI_0142.avi which opens another window with the video, or it should, when clicked. I don't how to get it to set itself up like a youtube video in the forum post.

Koda

You can do clickable links with the link button, too, same video.

Vintage Chief

Have you read the How To Post images thread? I provide documentation on file sizes for any files (both videos & images). Additionally, review my comments regarding file types and formatting - in particular attempting to post cam files, direct video files etc. The site clearly indicates the only acceptable file formats.

Vintage Chief

See my comments regarding video files and cam recorders on this thread.

Troubleshooting Pictures/Images

Vintage Chief

You can only upload files which are specified as acceptable file extensions - no others are allowed. Generally speaking camcorders, webcams, etc. record in proprietary formats. The user can choose to save the recorded file in another format if the device provides for that capability. If not, the end user must convert the file to an acceptable format (with the appropriate file extension).

Vintage Chief

Remember a “link” is just that - nothing more than a link. It is defined by a URL (Uniform Resource Locator) - nothing more than a pointer to the location of a file located somewhere. Nothing mysterious about links. When you point someone to a link (URL), the file is ‘rendered’ at the location where the file is stored. It is viewable via a compatible browser which must be capable of rendering the file in your browser. This is one reason certain sites either are or are not compatible with IE, Edge, Firefox, Mozilla, Chrome, etc.

cfair

VC,
Happy to abide by site rules. I’ll review the rules again, I must have missed the file formats parts and related advice.

Was just looking for a way to add additional content that some people might find useful. I’ve gotten a few good reactions to maintenance photos I posted, so I was thinking video would be the next educational frontier.

Summing up, links to external video sites are inbounds, but direct video file uploads are likely too proprietary & too large to be acceptable?

Genuinely appreciate your advice & guidance
Chris

Vintage Chief

Hey Chris - They're not rules - per se. They're simply a listing of acceptable file formats, sizes & recommendations. You will most likely gain a better understanding if you read Troubleshooting Pictures/Images.
I wasn't attempting to dissuade you from posting videos - to the contrary, post away. Folks will generally find videos very useful and I'd encourage you to do so.

To address your two statements:

(1) "Links to external video sites are inbounds". A link isn't an inbound anything - it's nothing more than a link (pointer) whose content is located at some location. Nothing more & nothing less - simply a link to the location of the content. Just like the link I posted above "Troubleshooting Pictures/Images". In that case I embedded the link into the statement "Troubleshooting Pictures/Images" via the Link (Ctrl+K) icon:


I could have, instead, simply provided the URL link location: https://classicoldsmobile.com/forums...images-145167/
You might think of a link (URL=Uniform Resource Locator) as a reference located on a page of written text. The author of the page of text references a particular piece of information and provides a small superscript number located after the text. The reference superscript number is a link to the location of where the information was actually obtained - that original information is not located within the confines of the article but instead located elsewhere.

(2) "Direct video file uploads are likely too proprietary & too large to be acceptable". This site (CO), ClassicOldsmobile.com is owned by Internet Brands, who also owns a plethora of other websites. Internet Brands developers write (code) & develop the pages for all of their websites - they establish many factors regarding every page inclusive of the rules which facilitate what an end-user (either a member or a guest) can & cannot perform on any of their websites. The CO site is not optimized to accommodate (in particular 'store') large video files such as FB, YouTube, Twitter, Vimeo, etc.

Regarding the first portion of your statement: Adobe originally developed & employed a (open standard) proprietary file extension (.pdf) just as most companies developed their own proprietary formats & file extensions. Eventually Adobe submitted their proprietary format to the ISO (International Organization for Standardization) committee and the .pdf format (and file extension) became an ISO open standard. Adobe Acrobat Reader, however, is proprietary (but freeware), meaning you must employ Adobe Acrobat Reader to open a .pdf file. Depending on the version of Adobe Acrobat, an end-user can edit, convert, etc. .pdf files. The freeware version allows limited reading capabilities, the paid versions are far more robust. When a website allows certain types of files to be "uploaded", they generally list the file extensions which an end-user is allowed to upload. There is a tremendous amount of overhead involved in uploading, storing and rendering video files. Internet Brands (alone) has made the decision to allow only specific file formats to be uploaded. Certain of these files are in fact proprietary others are not. The majority of file formats are allowed.

File sizes cannot exceed certain sizes & I have listed the general acceptance sizes for nearly all files I have encountered on the CO site. In general, any file size of any format (file extension) cannot exceed 10MB.

It isn't so much the file formats are proprietary (or too proprietary) as much as the types of files which meet or do not meet certain ISO standards (based upon their history and uniform acceptance on the Internet). Again, however, video files (primarily) involve tremendous overhead. Internet Brands makes the decision which files are allowed to be uploaded and those which are excluded.

Regarding several statements you made comment to i.e. editing, quality, preferred resolutions. You may have noticed (or not) when you upload a basic image to CO you cannot manipulate the image during the upload process or any time thereafter. Again, CO is not optimized for any type of file storage (and in particular rendering operations); therefore, you can't change the orientation (rotate, crop, edit, mirror image, etc). This all must be accomplished prior to the upload. Again, CO is not optimized as a file storage site providing capabilities to edit and/or render files - instead, strictly to store acceptable files & nothing more. There are many manufacturers of video recorders and video recording equipment - and, each basically has their own proprietary formatting capabilities (i.e. GoPro, and many others). These companies invest large amounts of $$ to provide quality (or not) videos - they manipulate/optimize the bitrate(s) of the captured videos, streaming capabilities, editing capabilities, etc. They generally provide the end-user with the ability (or not) to manipulate the video recording features - highly proprietary & it is these features which are competitive among the various manufacturers. The size of the files captured by these devices are a function of the many variables employed to create the file(s). I know you and most end-users are going to think (assume) I'm only talking about things like my iPhone, or Android, or GoPro, etc. But there exists hundreds of various proprietary formats from the simple iPhone/Android to professional studio equipment - they all create a file based upon their proprietary information. Those files will be exceedingly large for the best quality files - on the order of tens to thousands of times larger than a normal file size. Then, they run a compression routine for rendering, viewing, etc. The end-user is generally allowed to control the bitrate of the captured file(s) and/or the rendered file(s) - again, proprietary. However, most manufacturers of video capturing devices allow the end-user to save the file or export the file to a more common format i.e. .avi, .mpg, .mpeg, .mp3 etc. During these conversions from one format to another certain quality features are often (generally) lost. These features (or not) determine how the video is not only viewed (by a Browser, another compatible video recorder, etc.) but also the rendering of the file based upon it's compression routine. For the most part, end-users on the CO site are not going to involve themselves with this type of information/knowledge specifics. In the end, keep it as simple as possible, but remember there is very limited capabilities to video storage & rendering on the CO site.

The below file extensions are allowed to be uploaded simply because they are the most common (basically ISO) standards widely accepted on the Internet capable of being rendered/streamed/viewed by common Browsers and the devices on which Browsers are deployed.

Valid file extensions: apk avi bin bmp cfg csv doc docx ecu efi gif gsc hex hpl hpt html jpe jpeg jpg mov mp3 mpeg mpg msl msq pdf png pps psd rar table tun txt vex wav wmf wmv xls xlsx xml zip

If you have any questions don't hesitate to ask. Good Luck!

cfair

Norm
Many thanks for the tips & encouragement. This advice was exactly what I needed.

I'm 57, but have been around computers since the days of the Hollerith card & 5mb disk drives the size of 7 stacked LP records. File manipulations, storage, URL's all make sense to me. These days, my daily driver is a dual boot Mac (Win10/Mojave) and have some Raspberry Pi's running linux for my home network. When the garage is cold & damp, I play with computers & networks much the same way as I do with Oldsmobiles.

Before I upload photos to CO, I reformat them from iphone high resolution (crazy high - 4032 x 3500 or something) in Preview in my Mac to 1024x768 @72DPI. That seems to work as a good optimization between detail in the image that's helpful & overkill on file size.

Since that's been working well, I thought I'd shoot a few minutes of video - maybe on the Mid-60's Perfect Circle Cruise unit, or quadrajet modifications, or that goofy '66 Big car kickdown switch & edit it down in iMovie or Final Cut. I'm no George Lucas, but with luck will post something of interest in next few weeks. From the list above it looks like .mpeg or .gif would have the widest playback ability. If I recall .mov is pretty Mac-specific, as .wmv and .wmf are to Windows.

Since you're in the know, would native HTML5 as a file format be better than all of that alphabet soup for video playback? I haven't kept up on the HTML5 spec, but am I right that it has some video capabilities that well eventually render (ha) all those other formats obolete? If playback is one of the, it would seem the most open, friendly one to write the footage out to after editing.

Many thanks again
Chris

Vintage Chief

Chris - Certainly html5 (now on version html5.3) is an exceptional text file format for incorporating the many attributes html5 offers for both audio & video website presentation. Based on W3C & WHATWG recommendations & stipulations html5 must contain complete backward compatibility with all previous html versions. What this means, to me anyways, is this. While html5 (the new Living Standard) contains many new features (elements which define/support audio/video, APIs running in JavaScript, CSS, many more), content written in any previous html version will still be rendered via html5; albeit, backwards compatibility. I'm not a web developer by ANY means of the imagination. However, recognizing a website can render both audio & video without the kludge of end-user application requirements necessary to visualize website content is the new Living Standard. Much like Adobe ditched Flash (requirement).

From what I gather, the best sites on the Internet (and those contained within corporate domains) are running html5. Since html5 is such a rich website text file format, I believe its future implementation will create less burdensome application requirements on client software since website servers will able to serve up extremely rich html5 content (in particular audio/visual).

I should note (which may be obvious) if an end-user reaches an html5 website but the html website is serving up content written to a previous (non-html5) version, the end-user would still require the .api applications to run on the end-user's device, but they would still be backwards compatible - simply not rendered in html5 format.

cfair

Norm,
Quite right. Thanks Adobe for flash. And goodbye. Long ago I created some animations in it before animated GIFs were a thing. It worked, but then all the security problems started cropping up. It was past time for it to be laid to rest.

I’ll dig around and see what recent recommendations are for best filetypes, compression algorithms, and resolutions for broad web acceptance (i.e. playability / readability) in 2021.

Looks like my move will be to record some video content, edit it down to lower res, then test compression algorithms & file containers to be sure it shows correctly and is of a size CO can share.

There’s a real explosion of video content these days for teenagers, I just need to catch up on what they’re using to fuel it. No reason us carbureted, analog old fogies can’t share our content the same way.

With GIF being an accepted format for CO, do you suppose that includes animated GIFs? That might be a good alternative to mpeg for 10-30 second clips of stuff this target audience would recognize.

Fun to connect the old cars to the digital world. I use an old iPad mounted on sticky Velcro in my garage to store & show my ‘66 CSM, ‘66 Fisher Body Manual, 65-66 Assembly Manual and related material at eyeball height. Much easier than digging through those 4” books. Great for finding torque values, bulb wattages and fuse amperage ratings.

Much as I love the CSM and Fisher Body Manuals from long ago, they were written assuming you could just go get a Kent-Moore special tool or wacky little GM part when something broke. Now we’re lucky to find some of the really weird parts every 2-3 years on EBay for princely sums. All these decades later one of the things that stands out about old Olds is that they were built to be repaired & maintained. With a little care and cleaning, most of what stops working can be made to work again. Assuming someone can guide you on what to do.

Perhaps I can help fill in the knowledge here & there.

Anyway thanks for your guidance. As time permits I’ll start getting into short videos related to repairing & servicing arcane, little documented parts.
Chris

truckman5000

This was a long read.

All I can say is.
I've tried to post videos also. I've done everything, they don't load to this site...
I have an issue with my car, I made a post....will not load...I made a you tube video and it wouldn't link up. I spent 4 hours in this.
it's not double or easy...im 36yld..so ...idk
But with that said, I just figured out my issue myself

Koda

I just toss files on my domain and people can stream or DL from there. Domains are CHEAP. I pay 4 bucks a month.

cfair

Tried a few shots at uploading an mpeg4 file at various sizes from 5mb to 40mb.

No joy.

I'll bang on it a bit from here. My guess is that low res. video <720p or lower can be written under 5mb limit if you keep the time under 1 minute.

Cheers
cf

cfair

Oh - looks like it uploaded. I got no echo. Can somebody fire this up and see if it works?

THanks
Chris

Koda

I see two versions of the same video about the throttle linkage. Nice presentation style.

cfair

Koda,
This was a test of a fairly raw video. Guess it worked. Great that 2 minute video can be compressed to <5mb. That’s amazing to me.

The mpeg files won’t play on my iPad as a stream. But it does work as a download the go into the “Files” app and play through VLC.

Now I need to go back and figure out what I did & what the limits are.

Thanks for the style points, I used to get paid to present technical stuff to non-techies.

With luck I’ll get better at narrating & editing. That’s the time consuming part.

Cheers
cf

Vintage Chief

Chris - Both files (above) you uploaded are identical. At first you thought (as you stated) they didn't upload, but they did, in fact.

They'll appear as an 'attachment'. All files on CO appear as attachments. I make this point simply to point out all files (attachments) are stored in a back-end DB. A file (any file) is not embedded on a page on the CO website. A file (any type) is an 'element' on the page. The 'element' is nothing more than a link to the location of the file (stored in the back-end DB). I hope that makes sense. I also point this out since you can begin to imagine the many types of websites which are 'optimized' for the playback of videos. If a video was embedded on a webpage, the webpage itself would be enormous (in size), for one thing, but it would be rendered exceedingly fast (depending on the codec used within the container). In reality, the CO website does a pretty fair job at the presentation layer but again it's not optimized for video playback. Just remember all files are located on all pages as links to the back-end DB and are not embedded within (on) the webpage itself. Images on the CO website are presented differently than videos. The end-user will see (or visualize) the image at the presentation layer, but a video will not be presented (visualized) at the presentation layer. This has more to do with the rendering of images versus the rendering of videos, industry standards & optimization of the website itself. We could write forever on this theme but I believe you have the basic idea. Therefore, as stated earlier, all files are stored as 'elements' contained within (on) a webpage. Images (on CO) are rendered at the presentation layer, videos are not - they appear as attachments. CO is set up (optimized) for images - not videos. I think you got it.

Regarding your own personal optimization of files for uploading to the CO site - well, understandably you're on your own with this one. One thing to remember is this. Video files (and the history of video files) are just a tad different than your basic image file. The nomenclature of video files (versus image files) is often used incorrectly or stated incorrectly regarding video files. Likewise, there is far more historical industry standard regarding image (e.g. .jpg, .jpeg versus .png, .ppt, etc.) files (for website presentation) than video files. Thought of this way it makes some sense. The 'preferred' image file for any website is the .jpeg file because of the ease in which .jpeg file can be rendered and presented - fast, minimal overhead, and viewable by 99.9999999999% of all web browsers. This makes the use of a .jpeg file the best for websites.

A video file is composed of two primary formats - the container format and the file format. The video (file format) is contained within the video container (video format). Confusing? Sorta, but have a look. The video (file) format is where the compression occurs for all aspects of a video. The file format is where the compression algorithms operate. The container format is where the assembled compression is housed (contained) and defined by the codec used to compile (run) the compression (and decompression). So, you have proprietary software (and/or hardware) which captures video (and audio) & compresses video & audio. The container takes care of packaging, transport, and presentation (based on industry standards - or not). When the video is presented (rendered) to the viewer on a website (as opposed to the device itself where the video was captured) two things (at a minimum) must occur: (1) The video file must be recognizable by common web browsers in order to present (render) the video file (a common container file format) to end-users; and, (2) the website (in this case CO) must be able to serve up (present) that particular container (codec) format. I hope I haven't confused you. Video files are a very serious departure from your everyday simple image files for websites. Albeit, there are certain (and serious) limitations regarding the presentation of videos on websites. You've been doing this long enough (I sense) to understand/realize the industry has made many beneficial departures from earlier days where nothing could be rendered (presented) to an end-user unless the end-user had the specific codec installed on their device; since, it is the codec which was (is) required to decompress the original file to make it viewable. Now, this is accomplished via the website & the browser interface (based upon new industry standards). You might consider how this all plays out with the new Living Standard of html5 - essentially removing the burden from the end-user (client) application to, instead, the website and the browser (html5).

The video you presented is quite clear with excellent audio. Which compression routine you apply against your original video is entirely up to you (of course), but remember the CO website must be able to render that routine (codec if you will) back to the CO end-user. Don't be surprised at some of the extraordinary compression routines you find on some video capturing equipment these days. You still have to remain <10MB for any file on CO. BTW, the information I provide(d) to the "How To" pages was obtained entirely from my own research. Apparently, nothing is (was) provided to any CO Moderator and/or CO Administrator. It was basically a hunt & peck effort on my part.

All communication between any two devices anywhere w/in the world operate on the universal (Pretty Damn Nice Titty SPA) packet formation. So, when you think about how the information flow operates, you might consider the Titty SPA. Titty SPA is my own manner of storing information in my grey matter vestibule. Read from bottom up - PDNTSPA (Pretty Damn Nice Titty SPA). We all have our own peculiar madness to recall things.

A = Application Layer
P = Presentation Layer
S = Session Layer
T = Transport Layer
N = Network Layer
D = Data Link Layer
P = Physical Layer

So, a 'packet' (this is what is sent and received on the Internet) is formed on your device. Each packet must contain the information contained within the TittySPA (including header information). Your application (file) is created at the top layer (the Application layer), your file (packet) is then assembled downward to contain information at the P>S>T>N>D>P layers. When your packet arrives (somewhere) and is read (somewhere) by any device, that packet must be read backwards up the layers now; since, it must be deciphered from it's original formation. I only mention this since you most likely get a sense of where we were at one point in time. When you created your video file, it was created using a codec which operated at the application layer. The codec must be able to decompress the original file to make it viewable (rendered) to the end-user. Some software/hardware applications still require the codec be installed on the end-user's device. The industry is moving away from placing this burden on the end-user and instead (html5 etc.) is placing the burden instead on websites (html5) and browsers. But packet formation remains the same. It all begins at the top layer (Application Layer) or ends at the top layer (Application Layer); depending on whether you're creating the packet or receiving the packet.

GOOD LUCK!

cfair

Norm,
Many thanks again for the detailed explanation & support. I was pretty sure I was pushing things here testing video, so please understand I have no expectations of accommodations or support from here. It’s just fun to know this works.

Sorry about the double post. When I didn’t get an file upload completion echo, I tried again. Feel free to delete the duplicate attachment.

For anyone following along, this was shot on an iPhone 10 as short .mov files. Narration was live this time. I Airdropped the phone clips to my Mac from the phone, then stitched the clips together in iMovie. Next was a little light editing in iMove. I finished up testing export formats in both iMovie & Handbrake for transcoding to something CO subscribers could read/see/hear/visualize.

The trick is transcoding & compressing native video to something CO-readable and CO-presentable. Once I have a good process I’ll post what I’m doing that works so others can replicate if they wish.

The big time suck is video editing which was done locally on my Mac before uploading. My rule of thumb is 1 minute of realtime video takes about an hour of editing. That’s why the voice narration timing on this was a little rough. I’m glad at least the sound quality was good. I also didn’t take time to put in text callouts identifying the parts as it runs along. That’s on my list of stuff to get good at so people have visual labels of parts and how they go together. Then of course, you can put music underneath to make it a little fancier & on & on.

As you say, video has long been an aim of the web, but the web’s roots go back to text files & emails among universities in the 70’s (or heck, ARPA/DARPA & Bell Labs) - not realtime moving pictures with sound. The fast moving plethora of video resolutions, file formats, Codecs, containers, etc is still kind of a mess to me, but it’s great to see it’s doable. I’ll have to fire up the attachment on my PC to see what Codec it’s reporting. That’ll give me clues for video attachment creation from here.

Style wise, I was thinking it’d be fun to do 60’s style narration & music like the old Olds ads John “Shorty” Powers did in ‘66. “Rocket action” & all that nostalgic stuff. That’s pretty far from my editing skills today though.

For now I’ll be happy if I can share a little of what I’ve learned here to help others with some of the more obscure parts of these old cars. Just about everyone here knows more about engines & brakes than me, I’ll probably concentrate on ancillary systems that don’t get much attention but can age & break - often with unobtainable parts.

For example, this little movie came about because I have a thing about gas pedal feel being just right. I wanted the switch-pitch transmission feature to work right, correct gas pedal height, correct throttle spring resistance, and transmission kickdown function. But the number 1 thing was complete carb opening when the pedal is on the floor without stressing the pot metal switch.

Cleaning, restoring & testing on the bench saved me hours of trial & error on the road. Once it was on the bench, it was easy enough to shoot a few clips & stitch them together.

Many thanks again for your guidance,
Chris

Vintage Chief

Chris - I suspect you’re using the MPEG-4 Part 10 (H. 264/AVC) codec, but I’d be interested in knowing what you used. I’m familiar with iMovie and several others but I’m clueless regarding Handbrake.

You’re rocking it. Nice work and write up.

cfair

For anyone following along, I posted another little movie here:

https://classicoldsmobile.com/forums...-157618/page2/

Shot with a GoPro, dragged and edited into iMovie. Output as small .mov file in the Mac. At 33mb, it was too big a file for uploading and too weird a format for CO users anyway. I used Handbrake to transcode the .mov to a preset called "DiscordTiny" and left the file suffix as .mpeg.

It uploaded, but I don't know if it works on anyone's computer/tablet/phone except mine.

If you have 2 minutes, fire it up and let me know if this method worked for you.

Moderators: if I'm being pushy here with file sizes and formats, please say the word and I'll stop.

Cheers
Chris

cfair

Here's another video test, that last one above seemed to have failed pretty badly.

This version was shot on GoPro, edited in iMovie then transcoded in Handbrake using the "Gmail Small H.264" presets.

If anyone's following along & has 2 minutes to spare, let me know if this works on your computer, phone, tablet or other device.

RetroRanger

On an ipad when i click your file i get 2 options download or play. When i click play it does not, when i download icant play it.