Trimmed "smart rendered" video larger than source

johnmeyer wrote on 12/23/2013, 3:58 PM
I used Vegas to trim (cut) about half of the video from a few dozen MJPEG 24 fps progressive videos from a Moultrie "trail camera." I used the MainConcept MJPEG codec and rendered the result. Vegas showed "no recompression required" during the entire render, indicating it was smart rendering the result.

However, despite having edited out about half of the material, the resulting single AVI file was almost twice the size as the sum of the original files. I was expecting it to be half the size.

I did the same thing in VirtualDub using its "direct stream copy" option (their word for smart rendering) and got the same result.

What am I missing?

P.S. If you haven't yet discovered the joys of trail cameras, they are pretty clever devices designed to be strapped to a tree for three months at a time and, on one set of batteries, take pictures or videos, both day and night, of anything that moves in front of the camera.

Comments

TheHappyFriar wrote on 12/23/2013, 4:32 PM
My first guess would be that the compression Vegas/Virtual dub is using is a lot lower then the source material.
johnmeyer wrote on 12/23/2013, 4:50 PM
My first guess would be that the compression Vegas/Virtual dub is using is a lot lower then the source material.That could be true if it wasn't "smart rendering." The whole idea of that concept is that the bits that make up each frame are simply copied from the source to the output file. The bits that are used to create the frames which have been deleted are not copied. The resulting file should be smaller.

I'm going to do more testing ...
PeterDuke wrote on 12/23/2013, 8:45 PM
Does MediaInfo show any signifcant differences? Otherwise you have broken the law (matter can neither be created nor destroyed).
PeterDuke wrote on 12/23/2013, 8:48 PM
I am also reminded of Dr Who's Tardis that is bigger on the inside than the outside.
farss wrote on 12/23/2013, 8:50 PM
The "no recompress" only refers to the vision. Perhaps the original contained no audio or compressed audio and the output file contained one or more audio streams.

Also from memory some codecs can create output with lots of null data. In this case the exact same frames could be being packed into a bigger container with lots of empty space.

Just guessing...

Bob.
johnmeyer wrote on 12/23/2013, 11:15 PM
[I]Also from memory some codecs can create output with lots of null data. In this case the exact same frames could be being packed into a bigger container with lots of empty space.[/I]That is exactly what it feels like.

Mediainfo reports the same bitrate, field order, PAR, and resolution. The fact that it happens both in Vegas and in VirtualDub makes me think it is something specific to motion JPEG.

I'll keep digging ...
John_Cline wrote on 12/24/2013, 4:40 AM
Shot in the dark; are Vegas and Virtual Dub adding an audio track where there was none in the original file?
kairosmatt wrote on 12/24/2013, 9:23 AM
I've never done any scientific testing, but I've had the same experience with smart rendering AVIs (specifically cineform and raylight).

Could audio be significantly different enough to warrant the size difference???

kairosmatt
kairosmatt wrote on 12/24/2013, 9:46 AM
Nope I was wrong!

I just did some tests smart rendering raylight and there are some very slight differences, but nothing like what I remember. I smart rendered different parts together and tried switching around the file so it was the same length but in a different order, and its still within a few hundred bytes.

Raylight is intraframe, so there should be no issues with cutting in the middle of a long GOP.

I will have to look in my archives, I had some very large files that I had divided into usable regions and smart rendered and remembering being surprised that the folder with the smaller clips was larger than the full files. Its ispossible that I had done that with a different version of Vegas but unfortunately I won't be able to tell.

kairosmatt
johnmeyer wrote on 12/24/2013, 9:47 AM
Interesting ideas about the audio. What you are saying is that "smart render" may only apply to the video. Going from some form of compressed audio to PCM would certainly account for the difference.

I'm not at my main computer, but just tried a similar lossless trim on an old computer. This time it worked like I expected. That means it must be a MJPEG configuration issue. I'll report back when I've got it figured out.
johnmeyer wrote on 12/24/2013, 11:39 AM
I've copied a Mediainfo report below. The first section is for an original, un-trimmed file, and the second is for the same file after about 1/2 second was trimmed.

The obvious difference is the "Overall bit rate" in the "General" section. These do not match. However the bitrate shown in the "Video" section match exactly. Also, when I do the direct stream copy, the operation is virtually instantaneous, even on large files. This indicates that no rendering is being done.

I'll be interested if someone has some ideas about this. 

General

Complete name                    : E:\Trail Camera Tests\MFDC0541.AVI

Format                           : AVI

Format/Info                      : Audio Video Interleave

File size                        : 8.54 MiB

Duration                         : 9s 958ms

Overall bit rate                 : 7 194 Kbps



Video

ID                               : 0

Format                           : JPEG

Codec ID                         : MJPG

Duration                         : 9s 958ms

Bit rate                         : 11.2 Mbps

Width                            : 1 280 pixels

Height                           : 720 pixels

Display aspect ratio             : 16:9

Frame rate                       : 24.000 fps

Color space                      : YUV

Chroma subsampling               : 4:2:2

Bit depth                        : 8 bits

Scan type                        : Progressive

Compression mode                 : Lossy

Bits/(Pixel*Frame)               : 0.505

Stream size                      : 13.3 MiB



Audio

ID                               : 1

Format                           : PCM

Format settings, Endianness      : Little

Format settings, Sign            : Signed

Codec ID                         : 1

Codec ID/Hint                    : Microsoft

Duration                         : 9s 942ms

Bit rate mode                    : Constant

Bit rate                         : 128 Kbps

Channel(s)                       : 1 channel

Sampling rate                    : 8 000 Hz

Bit depth                        : 16 bits

Stream size                      : 155 KiB (2%)

Interleave, duration             : 42 ms (1.00 video frame)

=================================================================================

General

Complete name                    : E:\Trail Camera Tests\MFDC0541 - Trimmed.avi

Format                           : AVI

Format/Info                      : Audio Video Interleave

File size                        : 12.4 MiB

Duration                         : 9s 167ms

Overall bit rate                 : 11.3 Mbps

Writing library                  : VirtualDub build 30009/release



Video

ID                               : 0

Format                           : JPEG

Codec ID                         : MJPG

Duration                         : 9s 167ms

Bit rate                         : 11.2 Mbps

Width                            : 1 280 pixels

Height                           : 720 pixels

Display aspect ratio             : 16:9

Frame rate                       : 24.000 fps

Color space                      : YUV

Chroma subsampling               : 4:2:2

Bit depth                        : 8 bits

Scan type                        : Progressive

Compression mode                 : Lossy

Bits/(Pixel*Frame)               : 0.505

Stream size                      : 12.2 MiB (99%)



Audio

ID                               : 1

Format                           : PCM

Format settings, Endianness      : Little

Format settings, Sign            : Signed

Codec ID                         : 1

Codec ID/Hint                    : Microsoft

Duration                         : 9s 167ms

Bit rate mode                    : Constant

Bit rate                         : 128 Kbps

Channel(s)                       : 1 channel

Sampling rate                    : 8 000 Hz

Bit depth                        : 16 bits

Stream size                      : 143 KiB (1%)

Interleave, duration             : 44 ms (1.05 video frame)

Interleave, preload duration     : 500 ms
johnmeyer wrote on 12/24/2013, 12:15 PM
Over in the doom9.org forum, someone has suggested the problem may be due to duplicate frames in the source file. It turns out the source file does indeed have lots of duplicate frames, although I haven't yet figured out if that is the problem.

Here is a link to an original 10-second video from my Moultrie M990-i trail camera:

Deer Video (24 fps)

Tim L wrote on 12/24/2013, 3:04 PM
I know little about any of this, but it is curious that the original file claims a file size that is less than the size of the video stream. The second file has a file size that is close to that of the video stream plus the audio.

File size : 8.54 MiB
Duration : 9s 958ms
Overall bit rate : 7 194 Kbps

Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 9s 958ms
Bit rate : 11.2 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.505
Stream size : 13.3 MiB

So maybe the original recognizes duplicate frames, and keeps only one copy of each in the file? Again, I know little about this, but always welcome the opportunity to learn something...