DVDA: Why recompress a 3 minute SD video?

TLF wrote on 9/24/2008, 8:26 AM
I was experimenting using angles in DVDA 5.0.

I had two versions of a 3 minute film - one black and white, one colour - and one AC-3 audio track.

Why did DVDA insist in recompressing both video streams although the project was just 300MB?

It doesn't recompress when there are no angles.

There is probably a good reason, but I can't figure out what it is!

Comments

megabit wrote on 9/24/2008, 8:33 AM
Maybe your video was progressive (and other than 24p)?

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

TheHappyFriar wrote on 9/24/2008, 10:28 AM
it's always rendered multi-angles as far as I know. I think it needs to do it for the multi-angle vob file.
TLF wrote on 9/24/2008, 10:29 AM
No. Both were rendered using the built-in DVDA Template for PAL 4:3 footage. The only difference is one video was Black and White.

Very odd...
TheHappyFriar wrote on 9/24/2008, 11:06 AM
so it was two seperate videos, not one video with multiple angles?

that is strange. it could of been to high a bitrate or something else off. when it wants to recompress you can see what it's recompressing from/to when you use the optimize feature.
TLF wrote on 9/24/2008, 11:17 PM
The to videos were identical, except one was colour and the other black and white.

In DVDA I created a single movie such that the B&W video was the main stream, and the colour one could be accessed as a different angle.

DVDA wanted to recompress although the project was just 300MB.

To check that there wasn't a problem with the videos themselves, I created a DVD with a menu that allowed either the colour of B&W video to be played, but WITHOUT any angles.

In this case, there was no recompression.

So the video streams are good; but for some reason when angles are used, DVDA wants to recompress. I guess it's something to do with total bitrate for a given 'track'; and multiple angles all contribute to that 'track'.
darkframe wrote on 9/25/2008, 3:48 AM
TLF,

TheHappyFriar is right I'd say. I'm having a bit of an explanation following but please forgive me, English is not my native language and additionally I'm simplyfying the matter rather than going into too much detail.

For multi-angle some special encoding specifications must be met. Beware, I'm not sure whether the following is a 100% true but as far as I know multi-angle parts/clips need to be encoded with CBR rather than VBR. As far as I've analysed VOBs (I've written an own demuxer so am quite deep into it) I see a good reason for CBR. Actually I've not yet found any multi-angle title using VBR but who knows.

In the DVDVideo world a sector within a VOB will always have 2048 Bytes, whether it's video, audio or subtitles. On a DVD (no multi-angle, no subtitles and the like) you'll find a VOB structure like this (V = video, A = audio, both in blocks of 2048 bytes):

V V V V V V V A A V V V V V A V V A A etc.

On a multi-angle title you'll find something like this (V1 = angle 1, V2 = angle 2, A = audio):

V1 V2 V1 V2 V1 V2 A A A A V1 V2 etc.

Well, it's not exactly like this but might give you the idea. Normally you'll find all data for a full frame of V1 (depending on the total data amount), followed by all data for the same frame (rather position in time) in V2, eventually followed by some more data for additional video frames of both angles before the first audio portion shows up.

The problem with VBR now would be that e.g. the first frame of V1 will most likely have a different size than the first frame of V2 (and this is likely to continue with all frames of both clips). That would make it hard if not impossible for the VOB muxer to interleave the audio correctly as when it is in synch with e.g. V1 it might not necessarily be in synch with V2 when using VBR. With CBR this won't happen as the total size of all data for e.g. frame 1 of V1 will be similar to the total data size of frame 1 of V2 and so on.

Furthermore, changing of angles can only be done correctly on an I-Frame as only an I-Frame is containing a full image of the footage. With VBR there could be remarkable differences between the positions of the "same" frames of the two angles within the VOB, hence you would note a jump forward or backward when changing angles.

Therefore I'd say that you might give it a try to encode your clips using CBR beforehand (all settings for both clips should be exactly the same) and see how DVDA reacts in this case. It still might need to re-compress for a different reason though (project settings or whatsoever).

Cheers

darkframe
Steve Mann wrote on 9/25/2008, 10:32 PM
Is it re-encoding or preparing?
bStro wrote on 9/26/2008, 5:02 AM
From the DVDA manual / online help:

"Any title that contains multiple video tracks will be recompressed when you prepare your project so the main video and the alternate angles can be combined into a new video file. To avoid recompression artifacts (and unnecessary processing time), use AVI files for your multiangle video titles."

Rob
TLF wrote on 9/26/2008, 5:37 AM
Thank you bStro.

But there appears to be a bug/problem here. When I prepare an AVI file from the imported VOBs, the DVD produced by DVDA have the incorrect field order!

But at least I know why the files re being re-compressed.
TheHappyFriar wrote on 9/26/2008, 5:56 AM
I use avi's when doing multi-angle, double check the render properties of the AVI & the DVDA project. I've never had bad field order.

I think uncompressed AVI's render faster then DV AVI's in DVDA too.