AR flagging problems

[Justin123]

Hey guys, I'm in a real pickle.

I've demuxed some video streams from a Matroska file and have edited them in Sony Vegas
However when the video streams were demuxed the widescreen flagging was lost - from what I understand, and I had to edit the files as if they were 6:4 - square pixels) which is all well and fine. -I'm not concerned about this.

My problem is trying to set that 16:9 flagging after I've exported them. Even though the original video was 16:9 and the framesize 720:480 (something like that anyway) all the players and Sony Vegas read the demuxed stream as 6:4, and thus read my exported footage as 6:4 when I match the video input
I don't have the slightest clue on how to change the flagging - I know it was originally widescreen footage and nothing has been cropped, and I'm editing in square pixels.
As far as I am aware the only thing wrong with the demuxed streams and my rendered video as that the container flagging or something has been lost and a 6:4 AR is being used in it's place.

My current solution with the said Matroska files was be me frameserving the project and using Ripbot to encode them into x264 and then lastly using MKVmerge to remux the Mkv file at a 16:9 AR
This method works fine.

Though I have currently run into a problem; A friend needs to edit my footage and they don't have the resources or the know-how to deal with a matroska file. Basically I'm looking to set 16:9 flagging on my rendered footage whilst leaving it in an editable format for them. - sp if possible nothing like MKV
My two options would be either 'fixing' the source footage and replace the clips - then rendering it out to something like Xvid, or to just 'fix' the rendered footage

Can anyone please provide me with a solution?
Thank you for your time!

I've tried opening my remuxed MKV in virtualdubmod but when I export the file again the 16:9 flagging isn't there (Only changed the compression to Xvid)
So I pose another question, Which video codecs and containers support this flagging?

[poisondeathray]

The 6:4 AR is really 3:2 or 1.5. i.e. square pixels, because 720/480 = 1.5

What is your friend editing with? Many editors will have an interpret footage function to assume non square pixels on the footage

Many containers support AR flagging, avi, mp4, mkv. e.g. you could use yamb for mp4, or mpeg4modifier for xvid/avi. But whether or not an application will accept the flag is a different story...

You can encode the aspect ratio information into the stream as well. For a 16:9 720x480 NTSC video, you would use --sar 32:27. Even then, not all editors will accept it, some just assume 1:1 pixels

How did I get 32:27?

Display Aspect Ratio = Frame Aspect Ratio x Pixel Aspect Ratio
16/9 = 720/480 x 32/27

"pixel aspect ratio" is sometimes called the sample aspect ratio, or SAR. But they mean the same thing, the w/h of the pixels

[jagabo]

Regardless of what Vegas thinks of your source you can override the AR manually. Edit with a 16:9 project setting, override the AR of each source. Everything will come out right.

[Justin123]

Just to clarify the framesize is 704x480
I've posted the results of putting the 'before and after' demuxing of the video stream through MKV info, and looking through it they look identical and my vegas project settings
I'm starting to think that the footage itself wasn't really Widescreen footage to begin with. As when I use the widescreen template major cropping occurs, and the same thing happens if I use mpeg4modifier to set the PAR to 16:9...also Vegas interprets the video has having 1:1 square pixels when I select the 'match source video' button...so
I used mpeg4modifier to set/change the display flagging to 16:9 - it's all well and good for viewing on a player, but re-importing that file back into Vegas puts me straight back to square one (Side note, that isn't really related to my problem: when I set the 16:9 display AR flag it looked fine on my 1600x900 display, as in appeared as a widescreen, however on my latops' 1280x800 it doesn't)

I guess what I am looking to do now is 'cheat' vegas into thinking it is WS footage. Though I can't afford to crop out any of the video - The WS flagging, the original, and the one I give it when I remux the end file does not distort the footage in anyway, In fact without the flagging it looks quite horrible

You mentioned encoding the flag into the video stream. I'm not that familiar with command line utilities, much less how to go about what you've suggested...is this something I can do inside virtualdubmod?
If you wouldn't mind, could you walk me through the steps on how to do that? as I haven't used mencoder? or anything like that before. I'd really appreciate it.

----

I've attempted to do what jagabo said and set my project template to widescreen and just overide the AR of the source video, while it fixes the problem inside vegas, (The footage normally appears to be widescreen when previewed in the inbuilt DRAM preview) though regardless of how I render it out, and to what PAR it set it to it's still not a widescreen video when I export it, even after changing the render settings to make the PAR 1.2121 (To match the NTSC WS template)
What PAR is widescreen footage, because honestly the '1.2121' just confuses me

Thanks again for replying so fast...pity I couldn't do the same

video%20before%20demux.txt

after%20demux.txt

[jagabo]

Your screenshot shows the PAR set at 1.0 (square), not widescreen.

DAR = PAR * SAR

DAR = 1.2121 * 704:480

DAR = 1.2121 * 704/480

DAR = 1.2121 * 1.467

DAR = 1.778 ==> 16:9 widescreen

What container are you exporting (from Vegas) as? AVI doesn't support aspect ratios well. Individual video codecs inside the container can specify the PAR or DAR but many programs will not respect those flags.

[Justin123]

Yeah, that screen shot was just to show how vegas interpreted the footage

I was trying to export it as an .avi
You hit the nail on the head, the .avi container was causing all my AR problems.

Since .avi is out of the question, I'm at a loss as to what container/codec I should export my project to.
Many of the exporting options in Vegas for the other containers are very limited, and most don't even let me keep my current framesize or framerate (most are making me up the size to 720x480 @ 24-25-30fps)

I need your help again.
In your opinion what container would be best to export the video into along with the codec used to encode the video?
If you could point me towards an encoder, I'll just frameserve my project and encode the video outside of Vegas.

I'm looking for minimal quality loss while keeping the video at an acceptable size, whilst not being obscure enough to make Vegas not want to import it.
Normally I'd just encode it to x264 using Ripbot, but Vegas seems to be very hit and miss when it comes to importing the video file back into the suite (which is ultimately what I am trying to do)

The video is only around 30 seconds long, I've used some grain/film effects at the start, but the majority of the video is composed of hardcuts and some rotoscoping.

Thanks again for your time.

[poisondeathray]

If you want to change the interpretation in vegas, right click the asset in the clip bin. This will give you option to change AR for individual clips, not the global project properties as shown in your screenshot

If exporting is an issue, you can always export as almost anything, and re-wrap it with the AR values in the container. e.g. mkv.

Your choice of format depends on your goals, display device, etc.... You can use avisynth virtual file system (avfs) or sometimes makeavis to import virtually anything into vegas (it's like frameserving in instead of out with debugmode). However it comes with significant overhead (not as snappy editing, and if you used h.264, it's already sluggish to edit for most computers in an NLE). You could also re-encode to a lossless intermediate or uncompressed for re-importing

h.264 isn't meant to be re-edited, or re-imported. It's a final format goal. But it's basically the best choice for good quality at low file size.

You didn't answer the question on what you friend was using. As mentioned earlier, most NLE's have interpret footage settings.

[Justin123]

Thanks for letting me know about that, I stupidly began changing the PAR, clip by clip on the timeline (The things you do when it's way too early in the morning)

I can get vegas to treat the video as if it were widescreen, but even when I render it out at 1.2121 PAR the .avi container doesn't seem to adjust to the PAR change (some other containers did though)

Sorry, My friend (as far as I am aware) is also using sony vegas pro 8.0 (That's why I've been re-importing the rendered file to see how it behaves on their end.)
Hmm I never even thought of using avisynth scripts. Thanks! (Looks like I might just mux together an mkv file with the 16:9 AR flag and get my friend to import the avisynth file or something)

I'm pretty sure all they are going to do is concatenate my video with theirs. I'm not too concerned about the quality vs compression for this video, as it's only tiny. I'm more concerned about the bigger projects in the future, so if I can set up a plan now, I won't be hassled then. (Can't afford to be uploading huge files with bandwidth being expensive as it is here)
I guess I'll just play around with the codec and settings until I find something suitable.

If I were to re-wrap my video with the 16:9 values obtained in the mkv file when I re-import the video back into vegas will the flag still be set? I remember yesterday trying to encode the re-wrapped 16:9 flagged mkv file using virtualdubmod, but whenever I exported it the flag wasn't active - I most likely did something wrong no doubt. Still...
Is there a script I can run in vdubmod to force the flag to be recognised or something?

You've both been amazingly helpful, seriously Thank you so much for helping my thus far.

[jagabo]

Like I said, the AVI conainer doesn't really support aspect ratios. The ODML header has AR flags but I have never seen any program read or write those fields. Individual codecs can include AR flags within their private data but many players and editors will not pay any attention those flags. You have to switch to a container that explicitly supports AR settings and that Vegas accepts. Maybe MPEG program streams?

[poisondeathray]

I'm pretty sure all they are going to do is concatenate my video with theirs. I'm not too concerned about the quality vs compression for this video, as it's only tiny. I'm more concerned about the bigger projects in the future, so if I can set up a plan now, I won't be hassled then. (Can't afford to be uploading huge files with bandwidth being expensive as it is here)
I guess I'll just play around with the codec and settings until I find something suitable.

If all you were doing is joining, I would skip vegas and avisynth, which would re-encode and lose quality. You could join with mkvmerge or avidemux for example, assuming the clips were the same formats

If I were to re-wrap my video with the 16:9 values obtained in the mkv file when I re-import the video back into vegas will the flag still be set? I remember yesterday trying to encode the re-wrapped 16:9 flagged mkv file using virtualdubmod, but whenever I exported it the flag wasn't active - I most likely did something wrong no doubt. Still...
Is there a script I can run in vdubmod to force the flag to be recognised or something?

No. vdubmod doesn't support new .mkv spec. I would avoid using it.

No. Vegas almost always requires manual interpretation of files. It usually doesn't regard the mkv flag or any other flags. It usually has to be a standard type of video like DV, AVCHD etc..that it has presets for, in order for it to automatically accept AR flags.

It might accept AR info encoded into the stream (e.g. using --sar x:y in x264). I'll do a quick test and report back

EDIT: it does accept the --sar information if you mux it into a transport stream e.g. using tsmuxer and .m2ts. Transport streams add 5-7% overhead over .mkv or .mp4 containers. Even non-standard cropped, and weird AR combinations seem to work.

The --sar value would be 40:33 instead of 32:27 since you are using 704:480 (instead of 720:480)

16/9 = 704/480 x 40/33

You could still do the same thing, but make sure the --sar information is encoded into the stream, and whenever your friend or anyone else is going to edit, just remux with tsmuxer into .m2ts. (But it's almost easier just to right click and set the AR interpretation in vegas anyway...)

[Justin123]

Well they need to do a few other things like add transitions and etc to the video, so straight joining isn't quite what is needed - needs to be imported and double checked that it's synced properly anyway.

"It might accept AR info encoded into the stream (e.g. using --sar x:y in x264)." "The --sar value would be 40:33 instead of 32:27"
Sorry but I'm not sure how to add that --sar information and encode it. I've got the script up, but I'm lost when it comes to adding in that value. most of my attempts yield me an incorrect syntax error, or unexpected function after ''
Could you help me with the scripting please?

Alright at least the last thing I can do without any trouble