a.k.a. How to make a video I downloaded from TikTok/Twitter not to look like crap here.
So, this is something I learned the hard way, and I decided to share it with you all. Especially videos from TikTok look awful here if you don't re-encode them.
There's this Tumblr help page about posting videos that says
Well, I downloaded Handbrake and these are the presets you'll see
You most definitely don't want to use General -> HQ 720p30 Surround, because it adds two audio tracks, and I'm not sure if it's even Tumblr compatible. Fast or Very Fast 720p30 should be ok to use.
If you're using other video editors/tools, the main point seems to be that you are using
H264 encoder with Main profile (or Baseline profile if you want to play safe) and level = 3.1
MP4 file/container
FPS, audio format and video resolution don't seem to matter so much but probably better to use recommended/most used values/formats, i.e.
FPS = 30
Audio format = AAC LC
Video resolution = 720p (but avoid upscaling). 720p is the best for videos downloaded from TikTok/Twitter, but if you're uploading your own videos with good picture quality and bitrates, 1080p should be fine also.
In my (still ongoing) adventure to re-encode all the videos on my Jellyfin server to AV1 in order to save space, Iâd like to present you all with the biggest success Iâve had yet:
A 19.06GB folder has been condensed to 9.2GB. 10 whole gigabytes saved by just getting my computer toasty for a few days. Absolutely amazing.
thinking about that time I was re-encoding a bunch of movies and for some reason it had a tiny muted sped up window of the footage. so I just had American psycho, muted, playing at like 10x speed, in a tiny window, on my computer
Hello everyone! This post is going to describe the way in which I export and encode my video work to send it over the Internet and archive it. Iâll be talking about everything Iâve discovered over the past 10 years of research on the topic, and Iâll be mentioning some of the pitfalls to avoid falling into.
Thereâs a tremendous amount of misguided information out there, and while Iâm not going to claim I know everything there is to know on this subject, I would like to think that Iâve spent long enough researching various issues to speak about my own little setup that Iâve got going on... itâs kind of elaborate and complex, but it works great for me.
(UPDATE 2020/12/09: added, corrected, & elaborated on a few things.)
First rule, the most golden of them all!
There should only ever be one compression step: the one YouTube does. In practice, there will be at least two, because you canât send a mathematically-lossless file to YouTube... but you can send one thatâs extremely close, and perceptually pristine.Â
The gist of it: none of your working files should be compressed if you can help it, and if they need to be, they should be as little as possible. (Because letâs face it, itâs pretty tricky to keep hours of game footage around in lossless form, let alone recording them as such in the first place.)
This means that any AVC files should be full (0-255) range, 4:4:4 YUV, if possible. If you use footage thatâs recorded with, like, OBS, itâs theoretically possible to punch in a lossless mode for x264, and even a RGB mode, but last I checked, neither were compatible with Vegas Pro. You may have better luck with other video editors.
Make sure that the brightness levels and that the colors match what you should be seeing. This is something you should be doing at every single step of the way throughout your entire process. Always keep this in mind. Lagom.nlâs LCD calibration section has quite a few useful things you can use to make sure.
If youâre able to, set a GOP length / max keyframe range of 1 second in the encoder of your footage. Modern video codecs suck in video editors because they use all sorts of compression tricks which are great for video playback, but not so efficient with the ways video editors access and request video frames. (These formats are meant to be played forwards, and requesting frames in any other order, as NLEs do, has far-reaching implications that hurt performance.)Â
Setting the max keyframe range to 1 second will mildly hurt compressability of that working footage but it will greatly limit the performance impact youâll be putting your video editorâs decoder through.
A working file is a lossless file!
Iâve been using utvideo as my lossless codec of choice. (Remember, codec means encoder/decoder.) It compresses much like FLAC or ZIP files do: losslessly. And not just perceptual losslessness, but a mathematical one: what comes in will be exactly what comes out, bit for bit.
Download it here:Â https://github.com/umezawatakeshi/utvideo/releases
Itâs an AVI VFW codec. In this instance, VFW means Video for Windows, and itâs just the... sort of universal API that any Windows program can call for. And AVI is the container, just like how MP4 and MKV are containers. MP4 as a file is not a video format, itâs a container. MPEG-4 AVC (aka H.264) is the video format specification youâre thinking of when you say âMP4âł.
Hereâs a typical AVI VFW window, you might have seen one in the wild already.
In apps that expose this setting, you can hit âconfigureâ and set the prediction mode of utvideo to âmedianâ to get some more efficient compression at the cost of slower decoding, but in practice this isnât a problem.
Things to watch out for:
Any and all apps involved must support OpenDML AVIs. The original AVI spec is 2GB max only. This fixes that limitation. Thatâs normal, but make sure your apps support that. The OpenDML spec is from the mid-90s, so usually itâs not a problem. But for example, the SFM doesnât support it.
The files WILL be very large. But they wonât be as large as theyâd be if you had a truly uncompressed AVI.
SSDs are recommended within the bounds of reasonability, especially NVMe ones. 1080p30 should be within reach of traditional HDDs though.
utvideo will naturally perform better on CGI content rather than real-life footage and I would not recommend it at all for real-life footage, especially since youâre gonna get that in already-compressed form anyway. Do not convert your cameraâs AVC/HEVC files to utvideo, itâs pointless. (Unless you were to do it as a proxy but still, kinda weird)
If youâre feeling adventurous, try out the YUV modes! They work great for matte passes, since those are often just luma-masks, so you donât care about chroma subsampling.
If you donât care about utvideo or donât want to do AVIs for whatever reason, you could go the way of image sequences, but youâll then be getting the OS-level overhead that comes with having dozens of thousands of files being accessed, etc.
Theyâre a valid option though. (Just not an efficient one in most cases.)
Some of my working files arenât lossless...
Unfortunately we donât all have 10 TB of storage in our computers. If youâre using compressed files as a source, make sure they get decoded properly by your video editing software. Make sure the colors, contrast, etc. match what you see in your âground truthâ player of choice. Make sure your âground truthâ player of choice really does represent the ground truth. Check with other devices if you can. You want to cross-reference to make sure.
One common thing that a lot of software screws up is BT.601 & BT.709 mixups. (Itâs reds becoming a bit more orange.)
Ultimately you want your compressed footage to appear cohesive with your RGB footage. It should not have different ranges, different colors, etc.Â
For reasons that I donât fully understand myself, 99% of AVC/H.264 video is âlimited rangeâ. That means that internally itâs actually squeezed into 16-235 as opposed to the original starting 0-255 (which is full range). And a limited range video gets decoded back to 0-255 anyway.
Sony/Magix Vegas Pro will decode limited range video properly but it will NOT expand it back to full 0-255 range, so it will appear with grayish blacks and dimmer whites. You can go into the âLevelsâ Effects tab to apply a preset that fixes this.
Exporting your video.
A lot of video editors out there are going to ârenderâ your video (that is to say, calculate and render what the frames of your video look like) and encode it at the same time with whateverâs bundled in the software.
Do not ever do this with Vegas Pro. Do not ever rely on the integrated AVC encoders of Vegas Pro. They expect full range input, and encode AVC video as if it were full range (yeah), so if you want normal looking video, you have to apply a Levels preset to squeeze it into 16-235 levels, but itâs... god, honestly, just save yourself the headache and donât use them.
Instead, export a LOSSLESS AVI out of Vegas. (using utvideo!)
But you may be able to skip this step altogether if you use Adobe Media Encoder, or software that can interface directly with it.
Okay, what do I do with this lossless AVI?
Option 1: Adobe Media Encoder.
Premiere and AE integrate directly with Adobe Media Encoder. Itâs good; it doesnât mix up BT.601/709, for example. In this case, you wonât have to export an AVI, you should be able to export âstraight from the softwareâ.
However, the integrated AVC/HEVC encoders that Adobe has licensed (from MainConcept, I believe) arenât at the top of their game. Even cranking up the bitrate super high wonât reach the level of pristine that youâd expect (it keeps on not really allocating bits to flatter parts of the image to make them fully clean), and they donât expose a CRF mode (more on that later), so, technically, you could still go with something better.
But what Iâm getting at is, itâs not wrong to go with AME. Just crank up the bitrate though. (Try to reach 0.3 bits per pixel.) Hereâs my quick rough quick guideline of Adobe Media Encoder settings:
H.264/AVC (faster encode but far from the most efficient compression one can have)
Switch from Hardware to Software encoding (unless youâre really in a hurry... but if youâre gonna be using Hardware encoding you might as well switch to H.265/HEVC, see below.)
Set the profile to High (you may not be able to do this without the above)
Bitrate to... VBR 1-pass, 30mbps for 1080p, 90mbps for 4K. Set the maximum to x2. +50% to both target and max if fps = 60.
âMaximum Render Qualityâ doesnât need to be ticked, this only affects scaling. Only tick it if you are changing the final resolution of the video during this encoder step (e.g. 1080p source to be encoded as 720p)
If using H.265/HEVC (smaller file size, better for using same file as archive)
Probably stick with hardware encoding due to how slow software encoding is.
Stick to Main profile & Main tier.
If hardware:Â quality: Highest (slowest)
If software:Â quality: Higher.
4K: set Level to 5.2, 60mbps
1440p: set Level to 5.1, 40mbps
1080p: keep Level to 5.0, 25mbps
If 60fps instead of 24/30: +50% to bitrate. In which case you might have to go up to Level 6.2, but this might cause local playback issues; more on "Levelsâ way further down the post.
Keep in mind however that hardware encoders are far less efficient in terms of compression, but boy howdy are they super fast. This is why they become kind of worth it when it comes to H.265/HEVC. Still wonât produce the kind of super pristine result Iâd want, but acceptable for the vast majority of YouTube cases.
Option 2: other encoding GUIs...
Find software of your choice that integrates the x264 encoder, which is state-of-the-art. (Again, x264 is one encoder for the H.264/AVC codec specification. Just making sure thereâs no confusion here.)
Handbrake is one common choice, but honestly, I havenât used it enough to vouch for it. I donât know if the settings it exposes are giving you proper control over the whole BT601/709 mess. It has some UI/UX choices which I find really questionable too.
If youâre feeling like a command-line masochist, you could try using ffmpeg, but be ready to pour over the documentation. (I havenât managed to find out how to do the BT.709 conversion well in there yet.)
Personally, I use MeGUI, because it runs through Avisynth (a frameserver), which allows me to do some cool preprocessing and override some of the default behaviour that other encoder interfaces would do. It empowers you to get into the nitty gritty of things, with lots of plugins and scripts you can install, like this one:
Once youâre in MeGUI, and it has finished updating its modules, you gotta hit CTRL+R to open the automated script creator. Select your input, hit âFile Indexerâ (not âOne Click Encoderâ), then just hit âQueueâ so that Avisynthâs internal thingamajigs start indexing your AVI file. Once thatâs done, youâll be greeted with a video player and a template script.
In the script, all you need to add is this at the bottom:
This will perform the proper colorspace conversion, AND it does so with dithering! Itâs the only software I know of which can do it with dithering!! I kid you not! Mode 7 means itâs doing it using a noise distribution that scales better and doesnât create weird patterns when resizing the video (I would know, Iâve tried them all).
Your script should look like this, just 3 lines
LoadPlugin("D:\(path to megui, etc)\LSMASHSource.dll")
The colors WILL look messed up in the preview window but thatâs normal. Itâs one more example of how you should always be wary when you see an issue. Sometimes you donât know what is misbehaving, and at which stage. Always try to troubleshoot at every step along the way, otherwise you will be chasing red herrings. Anyway...
Now, back in the main MeGUI window, weâve got our first line complete (AviSynth script), the âVideo Outputâ path should be autofilled, now weâre gonna touch the third line: âEncoder settingsâ. Make sure x264 is selected and hit âconfigâ on the right.
Tick âshow advanced settings.â
Set the encoding mode to âConst. Qualityâ (thatâs CRF, constant rate factor). Instead of being encoded with a fixed bitrate, and then achieving variable quality with that amount of bits available, CRF instead encodes for a fixed quality, with a variable bitrate (whatever needs to be done to achieve that quality).
CRF 20 is the default, and itâs alright, but you probably want to go up to 15 if you really want to be pristine. Iâm going up to 10 because I am unreasonable. (Lower is better, higher numbers means quality is worse.)
Because weâre operating under a Constant Quality metric, CRF 15 at encoder presets âfastâ vs. âslowâ will produce the same perceptual quality, but at different file sizes. Slow being smaller, of course.Â
You probably want to be at âslowâ at least, there isnât that much point in going to âslowerâ or âveryslowâ, but you can always do it if you have the CPU horsepower to spare.
Make sure AVC Profile is set to High. The default would be Main, but High unlocks a few more features of the spec that increase compressability, especially at higher resolutions. (8x8 transforms & intra prediction, quantization scaling matrices, cb/cr controls, etc.)
Make sure to also select a Level. This doesnât mean ANYTHING by itself, but thankfully the x264 config window here is smart enough to actually apply settings which are meaningful with regards to the level.
A short explanation is that different devices have different decoding capabilities. A decade ago, a mobile phone might have only supported level 3 in hardware, meaning that it could only do main profile at 30mbps max, and if you went over that, it would either not decode the video or do it using the CPU instead of its hardware acceleration, resulting in massive battery usage. The GPU in your computer also supports a maximum level. 5.0 is a safe bet though.
If you donât restrict the level accordingly to what your video card supports, you might see funny things happen during playback:
Itâs nothing that would actually affect YouTube (AFAIK), but still, itâs best to constrain.
Finally, head over to the âmiscâ tab of the x264 config panel and tick these.
If the command line preview looks like mine does (see the screenshot from a few paragraphs ago) then everything should be fine.
x264 is configured, now letâs take care of the audio.
Likewise, âAudio Inputâ and âAudio Outputâ should be prefilled if MeGUI detected an audio track in your AVI file. Just switch the audio encoder over to FLAC, hit config, crank the slider to âsmallest file, slow encodeâ and youâre good to go. FLAC = mathematically lossless audio. Again, we want to not compress anything, or as little as possible until YouTube does its own compression job, so you might as well go with FLAC, which will equal roughly 700 to 1000kbps of audio, instead of going with 320kbps of MP3/AAC, which might be perceptually lossless, but is still compressed (bad). The added size is nothing next to the high-quality video track youâre about to pump out.Â
FLAC is not an audio format supported by the MP4 container, so MeGUI should have automagically changed the output to be using the MKV (Matroska) container. If it hasnât, do it yourself.
Now, hit the âAutoencodeâ button in the lower right of the main window. And STOP, do not be hasty: in the new window, make sure âno target sizeâ is selected before you do anything else. If you were to keep âfile sizeâ selected, then you would be effectively switched over to 2-pass encoding, which is another form of (bit)rate control. We donât want that. We want CRF.Â
Hit queue and once itâs done processing, you should have a brand new pristine MKV file that constains lossless audio and extra clean video! Make sure to double-check that everything matchesâtake screenshots of the same frames in the AVI and MKV files and compare them.
Now all youâve got to do is send it to YouTube!
For archival... well, you could just go and crank up the preset to Placebo and reduce CRF a little bitâOR you could use the 2-pass âFile Sizeâ mode which will ensure that your video stream will be the exact size (give or take a couple %) you want it to be. You could also use x265 for your archival file buuuut I havenât used it enough (on account of how slow it is) to make sure that it has no problems anywhere with the whole BT.601/708 thing. It doesnât expose those metadata settings so who knows how other softwareâs going to treat those files in the future... (god forbid they get read as BT.2020)
You can use Mediainfo (or any player that integrates it, like my favorite, MPC-HC) to check the metadata of the file.
Good luck out there!
And remember to always double-check the behaviour of decoders at every step of the way with your setup. 99% of the time I see people talk about YouTube messing with the contrast of their video, itâs because they werenât aware of how quirky Vegas can be with H.264/AVC input & its integrated encoder.
So I've been experimenting with current-gen video codecs to try and replace x264 in my current workflow. I recorded a bunch of lossless test clips that contain various challenging things for video encoding; grain, concentric lines, red text, etc⊠and have been doing various re-encodes of these and recording the metrics.
Here's a status report I DM'd my friend, because someone here might find it interesting/useful. Also it's a VP8 WebP because it's funny and Tumblr doesn't support HEIC or AVIF.
Video Transcoding: An Essential Process for Content Distribution Across Multiple Platforms
What is Video Transcoding
It refers to the process of converting a video file from one format or codec to another. This allows video files captured or encoded in one format to be played back on devices that support different formats. Transcoding is necessary because video formats have different technical specifications for things like resolution, frame rate, audio channels and compression standards.
Need for Video Transcoding
The need for transcoding arises because videos today need to be consumed across a wide variety of platforms like smartphones, tablets, desktops and streaming devices. However, not all devices or platforms support the same video formats. While a high-resolution movie may play fine on a high-end desktop, the same file may be too large for a mobile device with limited processing power and storage. Transcoding allows video content distributors to create optimized versions of a video tailored for specific devices or networks.
Some key reasons why transcoding is required include:
- Device and Platform compatibility: As mentioned earlier, different devices have varying support for video formats. Transcoding ensures the video can play on the target device.
- File size optimization: Transcoding to lower resolutions and bitrates helps reduce file sizes, important for streaming over cellular networks or for devices with limited space.
- Encoding optimizations: Transcoding allows re-encoding videos using optimal encoder settings, codecs and profiles best suited for the target environment.
- DRM restrictions: Video Transcoding may need to be converted to formats that support Digital Rights Management (DRM) for distribution through licensing platforms.
- Subtitle/Closed caption embedding: Non-burned subtitle/caption streams can be burned into the video during transcoding.
Transcoding Workflow
A typical video transcoding workflow would involve the following basic steps:
1. Import and Analysis: The source video file is imported into the transcoding system which then analyses key attributes like resolution, frame rate, audio/subtitle streams etc.
2. Profile Mapping: The analyzed data is mapped to pre-defined transcoding profiles configured for various target device classes or bitrate tiers.
3. Transcoding: The source file is transcoded to the appropriate target format(s), resolutions and encoding parameters as per the matched profile using CPU/GPU transcoding.
4. Optimizations: Additional optimizations may be applied like deinterlacing, denoising, ad insertion etc.
5. Quality Check: Random transcoded clips can be checked for quality issues using automated or manual review.
6. Delivery/Distribution: The transcoded files are delivered to various streaming servers, packaged for OTT/VOD platforms or downloaded directly for local playback.
Transcoding Formats and Codecs
Some common formats generated during transcoding include:
- MP4: A popular wrapper format generated at lower resolutions for platforms like iOS, Android, Roku etc. H.264 video with AAC audio is common.
- MPEG-2 Program Stream (M2PS): Used for distribution to set-top boxes and cable/satellite systems.
- Flash Video (FLV/F4V): Used for progressive download and streaming delivery to desktop browsers.
- Microsoft Smooth Streaming (MSS): An adaptive bitrate format optimized for Silverlight/HTML5 delivery.
- HLS: A standard HTTP Live Streaming format for OTT on mobile/desktop with H.264/AAC.
- DASH: An ISO-standard dynamic adaptive format popular for premium OTT with H.264/AAC or HEVC/AAC.
Popular codecs used include H.264, H.265/HEVC for video compression and AAC, MP3 for audio. Selecting the right codecs and container depends on the target audience and delivery network.
Get more insights on Video Encoding
For Deeper Insights, Find the Report in the Language that You want.
French
German
Italian
Russian
Japanese
Chinese
Korean
Portuguese
Priya Pandey is a dynamic and passionate editor with over three years of expertise in content editing and proofreading. Holding a bachelor's degree in biotechnology, Priya has a knack for making the content engaging. Her diverse portfolio includes editing documents across different industries, including food and beverages, information and technology, healthcare, chemical and materials, etc. Priya's meticulous attention to detail and commitment to excellence make her an invaluable asset in the world of content creation and refinement.
