audio is out of sync after conversion with ffmpeg

[gil900]

Hello.
i have a problem with this ffmpeg conversion Comman:
-r 25 -i <Input> -vcodec libx264 -preset medium -crf 15 -c:a copy <Output>.avi

the problem is that the audio is out of sync
in the original video is fine.

i don't know why it is happen...

What do I need to in the command?

Please help me!

[poisondeathray]

what kind of sync issue ? constant or progressively worsening ?

what does mediainfo say about the source and output files ? (view=>text)

[gil900]

what kind of sync issue ? constant or progressively worsening ?
what does mediainfo say about the source and output files ? (view=>text)

I think progressively...

and this:

General
Complete name : D:\Debut\Untitled13.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 22.8 GiB
Duration : 1h 9mn
Overall bit rate : 46.9 Mbps

Video
ID : 0
Format : Lagarith
Codec ID : LAGS
Duration : 1h 9mn
Bit rate : 46.2 Mbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 4.459
Stream size : 22.4 GiB (98%)

Audio
ID : 1
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 1h 9mn
Bit rate mode : Constant
Bit rate : 705.6 Kbps
Channel(s) : 1 channel
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 350 MiB (2%)
Alignment : Aligned on interleaves
Interleave, duration : 45 ms (1.14 video frame)

[Chris K]

I think x264 with PCM audio in a AVI is a very bad combination.

Try to convert as x264 with aac audio in a mp4 container.

[gil900]

I think x264 with PCM audio in a AVI is a very bad combination.

Try to convert as x264 with aac audio in a mp4 container.

This is called "escape from the problem"
I'm not that guy ..

I solved the problem.
The problem arose because the -r 25.

But I must add that to solve the problem described here:
https://forum.videohelp.com/threads/354729-problem-in-sony-vegas-with-FFmpeg-x264-conve...51#post2229251

And I know that without this Solution for sony vegas, the problem with the audio does not occur.

So I decided to reverse (go back) and solve the first problem with sony vegas without the "-r 25".
Through playing with the settings by:
http://www.encoding.com/advanced_configuration_options_for_the_libx264_video_codec

I found that if I add a low -g number like 1, then everything is fine.
for example:

-i <Input> -vcodec libx264 -g 1 -preset medium -crf 15 -c:a copy <Output>.avi

[poisondeathray]

I found that if I add a low -g number like 1, then everything is fine.
for example:

-i <Input> -vcodec libx264 -g 1 -preset medium -crf 15 -c:a copy <Output>.avi

This suggest your problems are b-frame and AVI container playback related . There can be many problems using b-frames with AVI container . This was mentioned in one of your other threads . Besides "b-frame decoder lag", there can be green frames, black frames, and/or other decoding issues

Using a GOP size of 1 means intra only (I frame only) . This significantly reduces any compression efficiency advantages , easily worse than 1/2 probably more

A better solution would be to use a different container , or at least no b-frames with a larger GOP length (I + P frames only). Otherwise why compress it at all ? Use lagarith. The whole point of compression is to reduce the filesize and keep some quality

[Mephesto]

PDR, it's not the B-frames that cause sync issues in AVI but B-pyramid. Storing B-frames in AVI is trivial with hacks but there's no way to use B-frames as references without a gap of frames at the beginning (the number chosen for B frames) so you gotta interleave the audio, don't use B-pyramid or don't use AVI.

[El Heggunte]

This suggest your problems are b-frame and AVI container playback related.

OR, equally possible, related to the deficiencies of ffmpeg's muxers.

Me neither is a big fan of H.264-in-AVI , BUT if someone wants the damn thing so badly , he/she should do it in the best way, i.e.,

1st) encode only the video,

2nd) then add the audio ;

FWIW, komisar's builds of x264 include a properly-written AVI muxer. avc2avi is another option too.

http://komisar.gin.by/

[gil900]

I found that if I add a low -g number like 1, then everything is fine.
for example:

-i <Input> -vcodec libx264 -g 1 -preset medium -crf 15 -c:a copy <Output>.avi

This suggest your problems are b-frame and AVI container playback related . There can be many problems using b-frames with AVI container . This was mentioned in one of your other threads . Besides "b-frame decoder lag", there can be green frames, black frames, and/or other decoding issues

Using a GOP size of 1 means intra only (I frame only) . This significantly reduces any compression efficiency advantages , easily worse than 1/2 probably more

A better solution would be to use a different container , or at least no b-frames with a larger GOP length (I + P frames only). Otherwise why compress it at all ? Use lagarith. The whole point of compression is to reduce the filesize and keep some quality

I do not know what you're talking about .. I have no problems ..
When I try to solve problems, I do a lot of tests and experiments on parts of the video that is often very bad. And with these settings, I had no problems.

What I noticed, it's a bit affects compression level .. But not significantly.
I Compress a 34GB video file to 8GB.

So in the end, everything works as it should ..

I hope that your theory would not come true for me ..

[poisondeathray]

PDR, it's not the B-frames that cause sync issues in AVI but B-pyramid. Storing B-frames in AVI is trivial with hacks but there's no way to use B-frames as references without a gap of frames at the beginning (the number chosen for B frames) so you gotta interleave the audio, don't use B-pyramid or don't use AVI.

The linear sync issues might be, but the frames out of order (thus causing sync issues), black and green frames are b-frame related, regardless if pyramid is used or not

Also it REALLY depends on what decoder is being used. Some are very prone to these multitude of problems, others are immune

It's just a bad idea to use AVI with b frames . Too many problems

[poisondeathray]

I do not know what you're talking about .. I have no problems ..
When I try to solve problems, I do a lot of tests and experiments on parts of the video that is often very bad. And with these settings, I had no problems.

What I noticed, it's a bit affects compression level .. But not significantly.
I Compress a 26GB video file to 8GB.

So in the end, everything works as it should ..

I hope that your theory would not come true for me ..

I frame only in AVI is fine - you won't get those other b frame issues mentioned above, but compression is severly affected .

You measured filesize at a given CRF, but you did not measure quality directly (e.g. with eyes, or metrics like SSIM/PSNR) . Trust me, Intra only will severly affect your compression easily >50% worse . Stated another way, if you looked at the 8GB file and looked at the quality, it could be ~5-6GB with the same quality if you used long GOP, b-frames.

[gil900]

I do not know what you're talking about .. I have no problems ..
When I try to solve problems, I do a lot of tests and experiments on parts of the video that is often very bad. And with these settings, I had no problems.

What I noticed, it's a bit affects compression level .. But not significantly.
I Compress a 26GB video file to 8GB.

So in the end, everything works as it should ..

I hope that your theory would not come true for me ..

I frame only in AVI is fine - you won't get those other b frame issues mentioned above, but compression is severly affected .

You measured filesize at a given CRF, but you did not measure quality directly (e.g. with eyes, or metrics like SSIM/PSNR) . Trust me, Intra only will severly affect your compression easily >50% worse . Stated another way, if you looked at the 8GB file and looked at the quality, it could be ~5-6GB with the same quality if you used long GOP, b-frames.

I did not understand your last sentence (it's because my English)
But I checked what you said.

I looked directly at the original video and at the compressed with on sony vegas (while in the preview i set the Highest preview Settings)
and i did not sow any change in the quality.

EDIT:
When I looked much more closely , I saw that only the very low noise affected.
But affected for good . the very low noise disappeared in the Compressed video..
End Edit

and i was wrong when i said that i compressed if from 28GB to 8GB.
It was the at first 34GB and compressed to 8GB.

and the Compression speed is at least 48FPS with the 64 bit FFmpeg.exe version!

[poisondeathray]

I do not know what you're talking about .. I have no problems ..
When I try to solve problems, I do a lot of tests and experiments on parts of the video that is often very bad. And with these settings, I had no problems.

What I noticed, it's a bit affects compression level .. But not significantly.
I Compress a 26GB video file to 8GB.

So in the end, everything works as it should ..

I hope that your theory would not come true for me ..

I frame only in AVI is fine - you won't get those other b frame issues mentioned above, but compression is severly affected .

You measured filesize at a given CRF, but you did not measure quality directly (e.g. with eyes, or metrics like SSIM/PSNR) . Trust me, Intra only will severly affect your compression easily >50% worse . Stated another way, if you looked at the 8GB file and looked at the quality, it could be ~5-6GB with the same quality if you used long GOP, b-frames.

I did not understand your last sentence (it's because my English)
But I checked what you said.

I looked directly at the original video and at the compressed with on sony vegas (while in the preview i set the Highest preview Settings)
and i did not sow any change in the quality.

EDIT:
When I looked much more closely , I saw that only the very low noise affected.
But affected for good . the very low noise disappeared in the Compressed video..
End Edit

and i was wrong when i said that i compressed if from 28GB to 8GB.
It was the at first 34GB and compressed to 8GB.

and the Compression speed is at least 48FPS with the 64 bit FFmpeg.exe version!

I don't know how to explain it another way, but this point is important for you to understand.

Intra severely limits compression efficiency (percieved quality is worse at a given bitrate) . In other words, you could have used a smaller filesize for similar or better quality if you used long GOP; OR you need much higher bitrates and filesizes for similar qualilty IF you use Intra.

In most usage scenarios, you tend to use low to middle bitrates for general use. Intra only is only suitable for very high bitrates relative to content complexity . It's not suitable for general use compression and end delivery formats. It's more for near lossless intermediates

Maybe some pictures and examples will help you to understand . These were 1280x720 8Mbps 2pass encodes . Both same enocoding settings, except 2nd used intra . Note this is a b-frame for the long GOP encode (the lowest quality frame), an I-frame to I-frame comparison would have shown even bigger difference






In most situations and conditions, that "50% worse" is probably very conservative estimate. I would say more close to 1/2 the size with similar quality when using long GOP with b-frames with x264

You are using CRF rate control, so you don't know what the end bitrate will be until it's done. It's only a "rough" estimate of "quality" , but if you run a CRF encode vs. CRF using intra, the intra enocde should be signifcantly larger

When I looked much more closely , I saw that only the very low noise affected.
But affected for good . the very low noise disappeared in the Compressed video..

But don't you see this is a "bad" way of doing things ? You spend all this time doing this restoration, you would get better results denoising it with filters than allowing an encoder to make decisions to "denoise" it.

[gil900]

But don't you see this is a "bad" way of doing things ? You spend all this time doing this restoration, you would get better results denoising it with filters than allowing an encoder to make decisions to "denoise" it.

the point is that i am not going to spend time

Because I wrote a small program/script that make all of this part(recording and then compression) while I sleep or not at home.

This is the main idea - not to spend time. use more time that was unusable before the script..
Until now everything has evolved as I wanted.

and i don't care about how it done.
the point is that if this "bad way" working faster so it is good for me.

But you can relax. I did not plan to use the encoder as a filter. I any case I'll use VB's filters and AVISynth

can you just send me a sample video so i will test it myself?
i need a sample that you thing that can defeat this settings..
I just also prefer to check myself

EDIT:
but this is high resolution. It does not represent the videos I work with.
The videos I work with are - 720x576 @ 25FPS @ YUY

[poisondeathray]

The point isn't about time, it's about compression efficiency and quality

It doesn't matter if the example was HD; the compression concepts are the same for SD. Intra (GOP size of 1) will severely limit compression efficiency. This even applies to other formats like MPEG2, XviD, etc... not just AVC (or x264 encoder)

Intra is not suitable for end delivery format

If you're happy with intra, fine. I'm just saying you probably can get 1/2 the filesize AND better quality. If you didn't care about filesize, then just keep lagarith. Don't encode it again

[gil900]

The point isn't about time, it's about compression efficiency and quality

It doesn't matter if the example was HD; the compression concepts are the same for SD. Intra (GOP size of 1) will severely limit compression efficiency. This even applies to other formats like MPEG2, XviD, etc... not just AVC (or x264 encoder)

Intra is not suitable for end delivery format

If you're happy with intra, fine. I'm just saying you probably can get 1/2 the filesize AND better quality. If you didn't care about filesize, then just keep lagarith. Don't encode it again

This part I did not understand before.
So if that's what you mean,can i get a command for FFmpeg For such conversion?

Difficult for me to understand the FFmpeg ..
But I must do this through the a command because my software will do this part.
It takes me time to make a FFmpeg command with good settings..

Thank you

Edit:
I checked these settings on HD video..

There is no difference.

Maybe you are using an older version of ffmpeg?

In any case, you understand more than I do .. So i will heppy if you will give me a better command...

[poisondeathray]

The point isn't about time, it's about compression efficiency and quality

It doesn't matter if the example was HD; the compression concepts are the same for SD. Intra (GOP size of 1) will severely limit compression efficiency. This even applies to other formats like MPEG2, XviD, etc... not just AVC (or x264 encoder)

Intra is not suitable for end delivery format

If you're happy with intra, fine. I'm just saying you probably can get 1/2 the filesize AND better quality. If you didn't care about filesize, then just keep lagarith. Don't encode it again

This part I did not understand before.
So if that's what you mean,can i get a command for FFmpeg For such conversion?

Difficult for me to understand the FFmpeg ..
But I must do this through the a command because my software will do this part.
It takes me time to make a FFmpeg command with good settings..

Thank you

The point of the last few posts is don't use -g 1.

Do you understand that the examples above used 2pass 8Mbps ? You are using CRF rate control. The reason 2pass was used, so the comparisons could be done on even terms. "apples to apples comparison". It was to illustrate a point that using Intra (-g 1 in ffmpeg) is detrimental to compression efficiency. Both tests ended up with same filesize because filesize = bitrate x running time . With CRF encoding, you don't know what filesize or bitrate you will end up with, but if you did some tests on your own CRF vs. CRF with -g 1, the -g 1 encode will be significantly larger . To do CRF testing you have to do fractional CRF value encodes until the filesize is equivalent e.g. 15.1, 15.2, 15.5, - this method is much more difficult to do testing

The earlier posts were warning you about b-frames in AVI (terrible choice, many problems with different kinds of software and hardware compatibility issues) , that's a different topic. Trust me, many many people have issues with this. Just do a search , it's common issue, especially with programs like NLEs. The green/black frame and misordered frame problem is common. You can safely use b-frames with other containers like mp4 or mkv . In fact , try your original commandline with output.mkv instead of output.avi

[poisondeathray]

Edit:
I checked these settings on HD video..

There is no difference.

Maybe you are using an older version of ffmpeg?

In any case, you understand more than I do .. So i will heppy if you will give me a better command...

Then there must be problem with your comparison . These are well known established FACTS in the video world for 15-20 years ever since MPEG2 days. The only point where Intra quality is better than long GOP with the same settings, is at extremely high bitrate range (relative to content complexity) ie.. near lossless settings . That's why it's never intended for general purpose usage

[gil900]

yes i know that CRF is a variable bitrate but i don't know why it is problem..
and i sorry but i stiil don't understand what the -g 1 Does ..
All I know is that it solves the problem.

[poisondeathray]

yes i know that CRF is a variable bitrate but i don't know why it is problem..
and i sorry but i stiil don't understand what the -g 1 Does ..
All I know is that it solves the problem.

Likely -g 1 "solves" it because there are no b-frames . But in doing so it creates other "problem" - namely poor compression efficiency. It's not a problem is you don't care about filesize. (But if you didn't care about filesize, just keep the lagarith....) The underlying original audio sync problem is likely b-frames in AVI container . You can use b-frames, long gop and get better compression efficiency if you used other container... (ffmpeg wont mux pcm in mp4, but ffmbc will)

intra means IIIII - there are no P frames or B frames

long gop means something like IPBBB


ffmpeg input.avi -vcodec libx264 -preset medium -crf 15 -acodec copy output.mkv

or if you want mp4, use ffmbc
ffmbc input.avi -vcodec libx264 -preset medium -crf 15 -acodec copy output.mp4

[gil900]

yes i know that CRF is a variable bitrate but i don't know why it is problem..
and i sorry but i stiil don't understand what the -g 1 Does ..
All I know is that it solves the problem.

ffmbc input.avi -vcodec libx264 -preset medium -crf 15 -acodec copy output.mp4
Likely -g 1 "solves" it because there are no b-frames . But in doing so it creates other "problem" - namely poor compression efficiency. It's not a problem is you don't care about filesize. (But if you didn't care about filesize, just keep the lagarith....) The underlying original audio sync problem is likely b-frames in AVI container . You can use b-frames, long gop and get better compression efficiency if you used other container... (ffmpeg wont mux pcm in mp4, but ffmbc will)

intra means IIIII - there are no P frames or B frames

long gop means something like IPBBB


ffmpeg input.avi -vcodec libx264 -preset medium -crf 15 -acodec copy output.mkv

or if you want mp4, use ffmbc
ffmbc input.avi -vcodec libx264 -preset medium -crf 15 -acodec copy output.mp4

ok thanks.. i will use the mp4 format because mkv not good not for sony vegas and not for VirtualDubMod

i tried this:
ffmbc input.avi -vcodec libx264 -preset medium -crf 15 -acodec copy output.mp4

and i get this error:

FFmbc version 0.7-rc8
Copyright (c) 2008-2013 Baptiste Coudurier and the FFmpeg developers
Input #0, avi, from 'D:\Debut\example2.avi':
Duration: 00:00:15.92, bitrate: 33452 kb/s
Stream #0.0(und): Video: lagarith, yuv420p, 720x576p, 25.00 fps
Stream #0.1(und): Audio: pcm_s16le, 44100 Hz, 1 channels, s16, 705 kb/s
[libx264 @ 00000000003ec310] using SAR=1/1
[libx264 @ 00000000003ec310] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[libx264 @ 00000000003ec310] profile High, level 3.0
[libx264 @ 00000000003ec310] 264 - core 130 r2274 c832fe9 - H.264/MPEG-4 AVC codec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=15.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
[mp4 @ 00000000002fc030] track 1: could not find tag, codec not currently supported in container
Could not write header for output file #0

[poisondeathray]

Not sure, why that error message, it would suggest audio compatibility issue with MP4 and ffmbc muxer. 0.7rc7 works with PCM in MP4 ; maybe something changed in the new version ?


EDIT: weird... I can't get it to work either now... what's interesting is it can rewrap pcm into mp4 from a mov container, but cannot do it while encoding ?

http://forum.doom9.org/showthread.php?t=166749

[gil900]

Not sure, why that error message, it would suggest audio compatibility issue with MP4 and ffmbc muxer. 0.7rc7 works with PCM in MP4 ; maybe something changed in the new version ?


EDIT: I know why - for some reason it won't allow direct output, but will allow remuxing into MP4 container with PCM

I tried an older version ..
I even tried 32-bit.

I get the same error ..

[poisondeathray]

Not sure why, if you look at the other thread above, it works re-wrapping PCM into MP4 (but I guess only from a quicktime MOV)

You can use MKV, or if you want compatibility with editors, its better to use transport stream (but larger overhead)

[gil900]

Okay.
Anyway, thanks for the help.

I could not see myself significant damage to the quality of the video with the settings I reached them.
So I think I'll use them ..

You said several times that I get a big file with these settings and if that so i Should keep the lagarith compression.
But I'm afraid you did not understand the file i got is not too large.

In fact, after these settings (yes, with -g 1) I get an 8GB instead of 34GB file.
It is compressed by 76.47%. 8GB is only 23% of the original size.
and the compression speed is excellent(I never dreamed compress on 50fps speed)


It's true that somehow we can cromress more ..
but then it will be unsupported in sony vegas or VB..
mkv is not an option because i am not going to mess with streaming to other softwer

[poisondeathray]

I could not see myself significant damage to the quality of the video with the settings I reached them.
So I think I'll use them ..

It's not "damaging" ; it's poor compression. The filesize is much larger than it has to be . At a given bitrate that is low, it does become damaging as shown in the screenshots above.

If you're driving a car, the (poor) analogy is poor gas milelage, lots of L/km

You said several times that I get a big file with these settings and if that so i Should keep the lagarith compression.
But I'm afraid you did not understand the file i got is not too large.

In fact, after these settings (yes, with -g 1) I get an 8GB instead of 34GB file.
It is compressed by 76.47%. 8GB is only 23% of the original size.
and the compression speed is excellent(I never dreamed compress on 50fps speed)

I said if you didn't care about filesize, keep the lagarith file. If you want decent compression, don't use intra encoding

OK , but did you compare without -g 1 ?

Here is a quick test with a SD DVD, just 1000 frame sample using CRF encoding.

-crf 15
14.1MB

-crf 15 -g 1
27.5MB

2.8Mb/s vs. ~5.5Mb/s . A quick visual check shows they are roughly the same quality. That's about 1/2 the size. Your test would probably give 4-5 GB instead of 8GB . "not too large" is subjective, but 2x the filesize is definitely significant

For these reasons, intra isn't used as a end delivery format (maybe an intermediate, but not something you deliver or embed in a webpage) . It's not good enough compression

It's true that somehow we can cromress more ..
but then it will be unsupported in sony vegas or VB..
mkv is not an option because i am not going to mess with streaming to other softwer

It is supported in vegas, MP4 is supported in VB and flash, but with AAC audio as chris pointed above. BUT - there are problems with open source muxers (such as ffmpeg) and PCM in MP4 (other programs , hardware muxers e.g. from cameras use it no problem)

[gil900]

OK , but did you compare without -g 1 ?

yes, not with big files.. only small files.

i know what you say to me.
and i sow those results on my eyes.

Indeed, this is make it to be poor compression..

but it solve this:

in sony vegas Without having audio sync problem.

2.8Mb/s vs. ~5.5Mb/s . A quick visual check shows they are roughly the same quality. That's about 1/2 the size. Your test would probably give 4-5 GB instead of 8GB . "not too large" is subjective, but 2x the filesize is definitely significant

For these reasons, intra isn't used as a end delivery format (maybe an intermediate, but not something you deliver or embed in a webpage) . It's not good enough compression

It is supported in vegas, MP4 is supported in VB and flash, but with AAC audio as chris pointed above. BUT - there are problems with open source muxers (such as ffmpeg) and PCM in MP4 (other programs , hardware muxers e.g. from cameras use it no problem)

I agree with you.
Bring me a better command for FFmpeg or whatever that make better compression almost without affecting quality. And it will work in sony vegas and VirtualDubMod.

Until now I have no something better in my hand ..

So if you have a better command so i will happy to receive it.

[poisondeathray]

Bring me a better command for FFmpeg or whatever that make better compression almost without affecting quality. And it will work in sony vegas and VirtualDubMod.

Until now I have no something better in my hand ..

So if you have a better command so i will happy to receive it.

Well nothing except AVI container will work directly in vdubmod

A compromise is to use no bframes (sequence would be IPPPPP)

-bf 0 in ffmpeg

ffmpeg input.avi -vcodec libx264 -preset medium -crf 15 -bf 0 -acodec copy output.avi

This way you avoid the b-frames in AVI problems, but at least still have some P frames to help with compression


But what is the intended goal? Why would you want to re-import into vegas ? Isn't all the editing done? Is this for viewing or other reason (intermediate file)?

[gil900]

Bring me a better command for FFmpeg or whatever that make better compression almost without affecting quality. And it will work in sony vegas and VirtualDubMod.

Until now I have no something better in my hand ..

So if you have a better command so i will happy to receive it.

Well nothing except AVI container will work directly in vdubmod

A compromise is to use no bframes (sequence would be IPPPPP)

-bf 0 in ffmpeg

ffmpeg input.avi -vcodec libx264 -preset medium -crf 15 -bf 0 -acodec copy output.avi

This way you avoid the b-frames in AVI problems, but at least still have some P frames to help with compression


But what is the intended goal? Why would you want to re-import into vegas ? Isn't all the editing done? Is this for viewing or other reason (intermediate file)?

Test Failed:

But what is the intended goal? Why would you want to re-import into vegas ? Isn't all the editing done? Is this for viewing or other reason (intermediate file)?

Tape recording as much as possible and then work on most of them at one stage.

It speeds up the process significantly.

[poisondeathray]

Would you mind uploading that video sample ? If you don't want it public you can PM me

I don't understand why you don't work on the lagarith files in vegas ?