4
$\begingroup$

I've used Blender to edit video, but can't find necessary settings for audio/video: my file becomes much bigger or smaller than it should. All what I did is removed about 5 seconds of audio. After render I feel difference in sound, its tone becomes more deep, and probably less in quality.
Original was: 262.8 MB. After rendering it became: 285.5 MB.
I tried to use H.264 video format, lossless output, FLAC audio format, in that case I get file with size of 1.4 GB.
I wanna know how to keep the same quality or at least what settings would be maximally close to original quality.
Properties of the original file:

  Duration: 00:02:43.50, start: 0.000000, bitrate: 12859 kb/s
    Stream #0.0(eng): Video: mjpeg, yuvj420p, 848x480, 12794 kb/s, 30 fps, 30 tbr, 30 tbn
    Metadata:
      creation_time   : 2014-05-16 18:00:29
    Stream #0.1(eng): Audio: pcm_u8, 8000 Hz, 1 channels, u8, 64 kb/s

Here's my rendering settings: enter image description here

$\endgroup$
  • $\begingroup$ You don't need to transcode just to chop off 5 seconds. In MJPEG, every frame is a keyframe, so you can cut at any point. (And with uncompressed 8bit PCM audio, again there are no frame boundaries to stop you cutting wherever you want). Of course, you might want to transcode to H.264, which you should be able to do visually transparently with about 1/10th the bit-rate (with x264 -preset slower or something). See trac.ffmpeg.org/wiki/Encode/H.264 $\endgroup$ – Peter Cordes Apr 3 '16 at 21:09
  • $\begingroup$ @Peter Cordes don't get what did you mean: "don't need to transcode". Then what should I do ? $\endgroup$ – R S Apr 3 '16 at 21:17
  • 2
    $\begingroup$ Use something that just copies the data you do want to keep. e.g. ffmpeg -s 5 -i my_camera_video.avi -c copy -t 10 cut.avi to copy 10 seconds of A/V starting at 5 seconds into the input file. -c copy means use the copy codec, which doesn't encode or decode, but just copies the still-encoded data, ensuring zero loss. Look around on the ffmpeg wiki I linked if you want to use ffmpeg. There are probably lots of frontends that can give you a GUI for it. (Leave out the -ss or the -t options if you don't want them.) $\endgroup$ – Peter Cordes Apr 3 '16 at 21:34
3
$\begingroup$

I wanna know how to keep the same quality or at least what settings would be maximally close to original quality.

The short answer is you can't; migrating to a codec will always result in a degradation of the nebulous term “quality.”

If one speaks of quantization quality, the source RGB will be degraded. If one speaks of a general “perceptual” quality, the source RGB will also be degraded.

Encoding is an extremely complex domain, with content of work factoring into the resultant encode, as well as many other subtleties.

Best advice for optimal perceptual encoded quality is to remember BINAE; Blender Is Not An Encoder. Use an appropriate tool such as FFMPEG to encode material.

Some additional complexities outlined here.

$\endgroup$
  • $\begingroup$ You technically can keep the quality of the source by encoding to a lossless output format, like the OP did here (modulo color-space conversions and chroma sub-sampling). If your input was lossy (like typical non-lossless h.264), the bitrate will be much higher (again, like the OP saw). IDK why the OP reports a change in the sound of the audio. That probably has nothing to do with encoding to FLAC, and everything to do with some other step. $\endgroup$ – Peter Cordes Apr 3 '16 at 21:05
  • $\begingroup$ You technically can not. You'll have to trust me on this. I've peeled apart enough codecs and colour transformations to state this unequivocally. Proper encodes are 8 bit and broadcast scaled, and even if you use an illegal full range, you are still locked in with 8 bits per channel and likely a YCbCr transform. That means you won't quantize back to the proper values, even if you an encode that no player can handle correctly. Even with a "lossless" RGB encode, you are still quantizing to 8 bits per channel, and that too isn't the same quality you are getting out of a Cycles render for example. $\endgroup$ – troy_s Apr 3 '16 at 22:00
  • $\begingroup$ The OP's source is already in yuvj420p (i.e. 4:2:0 with JPEG color ranges). You can losslessly transcode that. (But good point on the full-range issue. x264 has no problem with it, but you do need playback support). There are lossless codecs for most pixel formats. You can always store the video uncompressed, or gzipped, if 10bit per component lossless h.264 doesn't preserve all the information. It's not practical, but I never claimed it was always practical. Just that you can technically always avoid generation loss, with the right tools (which might not exist). $\endgroup$ – Peter Cordes Apr 3 '16 at 22:15
  • $\begingroup$ Part of the problem is the last time I examined scaling, there are three variants: the specification's 16-235/240 broadcast, full range 1-254 with 0 and 1 reserved, and nonstandard DSLR full range 0-255, which 99.95% of decoders fail to decode properly. The biggest issue is that quantization from RGB to YCbCr will always be lossy. Again, it just isn't feasible which is why everyone uses EXR inter-pipeline. $\endgroup$ – troy_s Apr 4 '16 at 1:18
  • $\begingroup$ Interesting, I wasn't aware there were two flavours of full-range. re:RGB: x264 can encode RGB into the three channels of an h.264 stream. It flags this with some metadata, which I think is nonstandard because the wikipedia article doesn't mention it. ffmpeg-based decoders can decode it, but I have no idea widespread support for this is. Most of what I do with video is for my own use. But like I said, you can always losslessly compress, even if it's just by gzipping some raw video (like OpenEXR can, according to wiki) $\endgroup$ – Peter Cordes Apr 4 '16 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.