Hot answers tagged

8

tl;dr: Since Youtube reencodes all videos regardless of the upload format, it really isn't that important. Just export your video with a high bitrate to preserve quality. Also see my answer here regarding quality loss caused by Youtube. Long answer: Each reencoding of a video to a compressed format lowers the quality. Usually, that means you'll lose quality ...


5

YouTube will re-encode whatever you give it. VP9 is currently too slow to encode. So the best choice is to either: Give it the original footage, or if it is not accepted by YouTube or is too big to upload, then... Re-encode to H.264 ffmpeg ffmpeg will accept just about any input and will provide a great quality output. Development is very active, so it ...


4

Rotate without re-encoding You can add rotation metadata: ffmpeg -i input.3gp -c copy -metadata:s:v rotate=90 output.3gp -c copy will enable stream copy mode, so it will just re-mux instead of re-encode. Player and device support for the rotate metadata may vary, so your player or device may not actually rotate the video. If that is the case you may ...


4

MP4 isn't an ideal format for intermediate saves. If you know you'll be re-opening the file, save it as losslessly as practicable, and use MP4 only for the final output. That said, depending on the encoder and settings you probably don't lose much if anything on subsequent saves. MP4 and similar codecs work by decimating the higher frequencies (details, ...


4

Although @stib's advice is sound, I disagree with "to get an appreciable size reduction you would have to throw away a lot of quality". Cameras have to compress on-the-fly, so they use constrained baseline mode, which is to say, they skip most of the tricks that H.264 codec uses to efficiently compress videos. If space isn't a pressing concern, keep them as-...


4

No, because it's content dependent. Video with high motion contains more information than a nearly still scene does. Hence it takes more bits to encode.


3

You can use ffmpeg, a free command-line tool, to do this: Without letterboxing, NTSC wide pixel-aspect ffmpeg -i input.mp4 -vf "scale=720x480,setdar=16/9" -r 30000/1001 -c:v libx264 -crf 20 -c:a aac -movflags +faststart output.mp4 With letterboxing, NTSC 4:3 pixel-aspect ffmpeg -i input.mp4 -vf "pad=1920:1440:0:180,scale=720x480,setdar=4/3" -r 30000/...


3

I would get as far away from EE as possible. Using the x264 tool, and mp4box, you can convert and segment out the files which are ready to be streamed to any dash compatible players. Especially since you mentioned using batch scripts, this is a great solution I think. This is a good guide: http://www.dash-player.com/blog/2014/11/mpeg-dash-content-generation-...


3

The fourth stream apparently is a CEA-608 subtitle stream, which during the days of analog television signal transmission was caption data embedded within the video data. Apparently FFmpeg can extract it but can't mux it to a new container. As for stripping only the audio, MP4Box may be of help.


3

You can only estimate the bitrate as proportion of your crop. If you have 30,000 Kbps for 1920*1080 pixel, then for 1080*1080 pixel this would mean 16,875 Kbps. If there is more complexity inside the crop region than outside, I would even increase the target bitrate further. However, if your videos are not that long and not intended for streaming I wouldn't ...


3

Judge based on the quality rather than the bitrate value. Use CRF mode encoding and if the quality isn't what you can accept, decrease the CRF value. ffmpeg -i "%%a" -s 3840x2610 -c:v libx264 -crf 18 -acodec copy D:\%%~na.mp4


3

Short answer is No. Longer answer is, it depends. If you're encoding a file, then generally the output is the duration of the input, unless there's speed change or trim filters or -ss, -to, -t options applied. For a live input, FFmpeg will stop the encode when it encounters EOF on the input, so unless you know that, you won't know the output duration. For ...


2

Maybe someone will chime in with an app suggestion that directly fulfills your need, but here's a temporary workaround - a bit convoluted, but should work. Create two folders A and B. Set folder A as the destination folder in the encoder. Apply a suffix to all the output files being generated, something innocuous like ENC e.g. Clip2015-09-25-23232-ENC.mov -...


2

Yes, MPEG-2 video is stored as YCbCr, but video editing programs (like Cinelerra) convert the samples to RGB for processing during editing. That range is 16-235. From Wikipedia on YCbCr Analog YPbPr from analog R'G'B' is derived as follows: To get a YUV output in the 16-235 range, the input RGB is also limited.


2

In strict mathematical terms, no. In terms of maintaining an acceptable image quality, yes. If you use CRF 18 and a preset like ultrafast now, you should be able to get a smaller acceptable file with preset veryslow later on.


2

You can't avoid the re-encode. They do this to be sure that every video they serve is in a standardized format, resolution and bitrate. It would be inefficient and risky to vet all diverse set of incoming files to check if they meet all their parameters, some of which are not easily available to set or tweak at the user's end.


2

Strictly speaking, fourcc is the codec ID used by Microsoft. It has been adapted for use with many other formats, thus making it seem like a standardized ID format, but it's not. ffmpeg, in particular, seems to only consider XDCAM standard MPEG2 for inclusion in MOV. From the source code: else if (track->enc->codec_id == AV_CODEC_ID_MPEG2VIDEO) ...


2

I not sure if I understood your question correctly, but CasparCG would be a common solution to overlay graphics (or anything else) to a video feed. http://www.casparcg.com Or, if you want to do this in software, take a look at the liquidsoap library: http://liquidsoap.fm/doc-svn/video.html


2

You need to convert the codec used to encode the video to something that the players you are trying to use support. MPlayer supports a wider range of codecs than many players. To allow you to view the video in other players you need to transcode the video using an application like ffmpeg. The command below will provide the conversion you need: ffmpeg -i ...


2

Looks like MP4 won't skip the edts boxes when creating MP4s. You should transcode to MPEG-TS and feed that into mediafilesegmenter ffmpeg -i in.mp4 -<transcoding options> -vbsf h264_mp4toannexb out.ts


2

There is a hardware-accelerated VP8 encoder recently released by the University of Milan. Source and standalone binary for 64-bit Linux and compute 3.5, 5.0 and 5.2 capable NVidia GPU cards available at https://github.com/Italtel-Unimi/libvpx They say they have integrated the code into libav libs i.e. FFmpeg, but this hasn't been pushed into the FFmpeg ...


2

You can calculate the maximum total bit rate that would fill the storage: 30GB ≈ 30,720 MB ≈ 245,760 Mb 10 hours = 600 minutes = 36,000 seconds 245,760 / 36,000 ≈ 6.83 Mb/s You need to encode to a video bit rate less than that maximum to account for the audio and any overhead. Plus, you probably want to leave some space free on the storage. I'd say that ...


1

Yes. Every time you "save" video in video-editor, you will re-render it with codec. Most codecs lose some video information for compression. So, every time you will lose some more information.


1

I can answer your first question. At the same bitrate and transcoding from an 8-bit source 10-bit HEVC is better than 8-bit HEVC, because it hardcodes dither. https://gist.github.com/l4n9th4n9/4459997 I am still unsure, whether that makes 12-bit HEVC transcodes superior to 10-bit, thats why I ended up here.


1

it seems to me that you are trying to overwrite an existing file. Try to change the name from your file (Test 1.mov) to something different and that is not already used on your Exports folder. Let me know if it worked. Cheers!


1

As mentioned by @Mulvya, I think the issue is the "slow" preset. One option is encoding a compressed stream that is also lossless. For example, the x264 encoder can do this using "-preset ultrafast -qp 0". This will probably result in failing your 3rd requirement (compatibility), but since it's lossless, you can transcode later onto cheap spinning disks. ...


1

You can strip most of the metadata off your files using ffmpeg: ffmpeg -i oldfile.mp4 -c copy newfile.mp4 This will copy the first audio and video streams to a new mp4.


1

The first problem you have to solve is whether the flickering you see is part of your animation or part of the video encoder. If you have bad normals in your faces, you'll see a flicker. ProRes 422HQ produces a video file that's both low enough of a bitrate that most modern (post 2008) hardware can play without dropping frames, as well as high enough of a ...


1

My earlier answer still holds in general. Additional advice I can provide is to try higher CRF values and use the veryslow preset. ffmpeg -i input.mov -c:v libx264 -crf 23 -preset veryslow -c:a copy -c:d copy -map 0 compressed.mov You can also mimic a constrained quality mode by setting ffmpeg -i input.mov -c:v libx264 -crf 21 -preset veryslow -maxrate ...


1

If it's just a matter of which FOURCC to assign, and not the codec, then choose MP4V since it has broader compatibility, and the tag can always be changed later, using a tool like ffmpeg i.e. ffmpeg -i input.avi -c copy -map 0 -vtag DX50 tagged.avi



Only top voted, non community-wiki answers of a minimum length are eligible