I’m muxing* down the final versions of my Othello project video, and came across an unexpected result:
The vid is 720x480, the audio is .wav files placed in the VSE, format is FFMPEG with Xvid as the video codec and MP3 the audio codec, both at default settings for those codecs. Xvid is configured for Quality 3.0.
The audio mixed down to a single mono file by Audacity ~ 4.6Mb
A mixdown out of the Blender Audio panel (mono converted to stereo, identical channels, no compression) ~ 8.8Mb, about what’s expected.
What isn’t expected is that Blender outputs a final muxed file (audio + video) that weighs 6.7 MB
Virtual Dub, using the same resources and settings (at least as far as I can match them), except that the audio is mono, produces a final mux of only 2.6 MB. There is no discernible difference in quality of either audio or video between the two.
I don’t think the extra audio track from FFMPEG should make that much diff in file size, especially after MP3 compression.
Any ideas what might be the cause of the file size difference?
“mux” = multiplex, technojargon for the process of combining audio & video in sync.
I would guess somehow a lower frequency 48khz down to 32khz, but dont know why? Could it be making a virtual mono (1 channel encoded then played to the other channel) rather than stereo which has 2 discreet channels (whether different or not).
Image source for VDub was a .PNG image sequence written from the Blender Compositor. The FFMPEG was exactly the same Compositor file set for multiplexed output. Compositor image sources were .PNG & .TGA images, stills + .PNG image sequence. Audio sources in all cases were .wav files – 2 tracks placed in the VSE for FFMPEG output (track1 = voice, track 2 = music), and a mix of the same track files out of Audacity for use in VDub. The .WAV originals are 44.1 KHz 16-bit PCM.
Flowpaths:
Stills (titles & credits) + fully rendered image sequence (.PNGs) --> Compositor
Compositor --> fully comp’d image sequence; comp i.s. + .wav audio --> VDub mux’d .AVI, mono
Compositor + VSE (audio) --> FFMPEG mux’d .AVI, stereo (identical data in both channels)
Xvid & MP3 are output codecs for both VDub & FFMPEG versions.
I popped both the Blender FFMPEG version & the VDub version into mediainfo, got some interesting results.
In the Blender-output FFMPEG version the video stream weighs in @ 5.5Mb, or 85% of file size. Audio is 828Kb – the audio is stereo with identical data in each track, so a single audio track should weigh in at half that, or around 414Kb.
In the VDub-output version, the video stream is 2.22Mb (89%), Audio 206Kb (mono).
Seems that VDub is significantly more efficient in processing the media streams in terms of final size, even using the same codecs. I am assuming that the codecs used by both Blender and VDub are the same, but some of the mediainfo data makes me wonder. For the audio, it says that the Blender output uses MPEG Audio, Version 1, Layer 3, while the VDub output uses MPEG Audio, Version 2, Layer 3. Different MP3 codecs being used?
For video, I know I have only a single Xvid codec installed (went through quite a cleanup during my last update of the codec), and when I open the Configuration panel in either Blender/FFMPEG or VDub, all the specs are exactly the same. Yet mediainfo reports a great deal more data about the VDub video stream than what it shows for the Blender/FFMPEG version, and some differences in the data that is common to both.
The upshot seems to be that if final file size is a critical factor for your production workflow, you’d be better off using Virtual Dub to multiplex your audio and video than going through Blender’s FFMPEG option. Both provide good quality results, but VDub is apparently a lot more efficient at compression.
If you are on Windows it would be possible to encode via your system installed XVid codec via the AVI Codec option in the render panel, not sure if that’s in 2.5 for Windows users, I’m on Linux so don’t know, but is in 2.49b.
That would allow you to test Blender to XVid system codec rather than Blender to FFMPEG XVid implementation?
Or have I misunderstood, although you say one XVid codec installed? Is this the one from their site? + FFMPEG installed or are you encoding out via VDub to FFMPEG XVid?
Evidence is circumstantial but I think Blender is using the same Xvid codec as VDub, at least for the AVI codec format option – when I adjust the Xvid configurations in VDub (say the Quality setting), these changes are reflected in the AVI codec configuration panel in Blender as well, without making an explicit change there.
If the FFMPEG format option uses a separate Xvid codec, then it isn’t as efficient as my system-installed version. AFAIK it’s not possible to configure the Xvid codec using the FFMPEG format option in the same way it is using the AVI codec format option, so it’s hard to tell. My assumption was that the Xvid configured for use by the AVI codec option would also be used by the FFMPEG option – why should it not?
I would use the AVI codec format option (with system Xvid) if it could multiplex a/v, but in 2.49b, FFMPEG is the only option that does that.
chipmasque. I encoded out a bit of a video edit I’m working on tonight as a test via 2.49b with ffmpeg xvid and did the same with VDub + Xvid 1.2.1 codec from their site which I had installed, on Linux using Wine.
source was .png image sequence + 16bit PCM wav
As the Xvid 1.2.1 codec has far more encode options exposed compared to blenders encoding panel I just went on overall bit rate and compared.
If the FFMPEG format option uses a separate Xvid codec, then it isn’t as efficient as my system-installed version.
I got identical file sizes (within a few bytes) and exact percentage split between audio & video report via mediainfo. FFMPEG writing app listed as Lavf52.31.0 & Xvid as XviD 1.2.1 (UTC 2008-12-04). Obviously one test is far from conclusive.
Evidence is circumstantial but I think Blender is using the same Xvid codec as VDub, at least for the AVI codec format option – when I adjust the Xvid configurations in VDub (say the Quality setting), these changes are reflected in the AVI codec configuration panel in Blender as well, without making an explicit change there.
Assume XviD 1.2.1 non FFMPEG?
My assumption was that the Xvid configured for use by the AVI codec option would also be used by the FFMPEG option – why should it not?
They are two different codecs?. I think ffmpeg does a standard mpeg4 and flags it as XviD.
I would use the AVI codec format option (with system Xvid) if it could multiplex a/v, but in 2.49b, FFMPEG is the only option that does that.
Nexyon has implemented various audio encoding options in 2.5, have you checked it out to see if there is more options available?
Not using 2.5 consistently at present, too many 2.4x projects to finish up first, and I’m a bit leery of alphaware for anything but test cases (been burned before).
In terms of the files size difference I experienced, it could be a matter of bit rate settings, and a difference in the audio codec configuration. I’m not familiar enough in depth with all the possible settings in the configuration options, so I tend to go with defaults for most of them except Xvid’s Quality value. My feeling is that the defaults with VDub and those with Blender/FFMPEG (in 2.49b) may be different enough to account for a files size difference, but it was the magnitude of the difference that was surprising.
Hi, I’ve been swamped lately so it appears that I’m late for the party. Here’s a few notes: #1 .audio issues: You say that:
MP3 specs in VDub: 32Kbits/s (4KB/s), 22.050 KHz. mono MP3 specs in FFMPEG: bitrate 128; Audio sequencer (Blender Audio tab) @ 44.1 KHz
This is a big difference though. 32 kbps is 4KB/sec and 128kpbs is 15,63 KB/sec, which gives a ratio of 3,91 (and that without even taking into account the sampling rates). So the encoded audio output from Blender is bound to be about four times as big compared to the VDub audio output. This is indeed confirmed by what you report in a later post:
In the Blender-output FFMPEG version the video stream weighs in @ 5.5Mb, or 85% of file size. Audio is 828Kb – the audio is stereo with identical data in each track, so a single audio track should weigh in at half that, or around 414Kb. In the VDub-output version, the video stream is 2.22Mb (89%), Audio 206Kb (mono).
The ratio of 828/206 is about 4, and thus it makes sense that the audio output from Blender is roughly four times as big. It appears that the audio settings are not matched and this explains the difference in the size of the audio files. What it does not explain, though, is the large difference in size between the two video streams, to which I will turn next. #2. video issues: I’m on linux and I don’t have the time right now to run any tests with VDub in VirtualBox. In the past I have experimented with video encoding using various tools. It is very difficult to match the settings, especially if the software apps use profiles which are not customizable (e.g. in your case, what does ‘‘quality 3.0’’ mean?) I remember encoding the same img seq using the same video codec and getting markedly different file sizes. As you’ve already discussed, it’s not always easy to determine which version of the codec is being used. For example, I get different results from using ffmpeg from the cl compared to the ones I obtain with Blender’s ffmpeg. Also afaik in Blender you don’t have a two-pass encoding which can also lead to reduced file sizes but it would take more time to complete. Last, for me the main issue is what you mention about ‘‘no discernible differences’’ between the two files. If you’re pretty sure that there are no differences then I’d go for the smaller file size for both distribution and streaming purposes.
Thanks for the info, blendercomp. Of the two streams, the audio was less of a mystery to me because I realized the bitrates differed and one was stereo & the other mono, though I wasn’t aware how much the bitrate affects encoding/file size. Part of the reason I use defaults so much is I’m a bit ignorant of what many of the settings do.
In Xvid, “Quality 3.0” is the value I most often use for the property labeled “Target quantizer,” with the slider scale being labeled “Highest quality” (lower numbers) and “Smallest size.” It essentially sets the compression ratio vs. output image quality. The same setting is often labeled “Quality” in other codec/compression scheme contexts, so that’s how I label it as well.
One thing I find confusing (another reason for my using defaults) is that in the FFMPEG option there are fields for settings in the Video tab, but I’m not all that clear on whether they apply to the Xvid codec or to some suite of FFMPEG parameters, or both. Codec configuration takes a different form using the AVI codec option, so that lack of consistency tends to muddle the already less-than-crystal-clear waters.
The whole issue is more academic than a critical production problem in this case, since for my purposes either output file would do, so using the smaller just makes sense. But if an all-Blender production workflow is a goal, then it’d be helpful to have all the efficiencies available with other tools like VDub. If it’s matter of settings, then identifying them is useful, and if it’s a matter of codec implementation, then it might be worth having the dev team look at the issue.
