The videos I encode at work use loads of cross dissolves, which I know are bad for interframe compression, but I'm wondering whether I can help the process by forcing I-frames on the cross dissolves on my encode (I edit in FCP 4.5 and encode the MPEG-2 with Compressor). I read about this practice in a book, but I've never used it before, and I couldn't find any reference to it in this forum. This makes me suspect it's a suspicious practice, but I haven't been able to find another solution to my block cross dissolve problem.

Will forcing I-frames on my MPEG-2 encode make cross dissolves smoother at low bitrates? If so, on which frame or frames should I force an I-frame: the start of the dissolve, the center point or somewhere else entirely?

I would also appreciate other possible solutions to the problem.

you are creating mpeg2 for a dvd? there shouldn't be any blockiness on cross-dissolves at all... assuming that you are working with dv-sourced material, it sounds like you really need to get yourself a pro-level encoder... something that does two-pass variable bit rate encoding, to begin with.

beyond that, i'm not sure how forced i-frames fit into a dvd bitstream requirement.

Thanks for the reply Dan. I am creating MPEG-2 for DVD from DV source material, and I am using the 2-pass VBR best mode in Apple Compressor. Would you consider that a pro-level encoder? I'm not particularly impressed with DVD Studio Pro, and it's part of that package, but it does have 2-pass VBR, and I found that BitVice, the supposedly better software-only Mac encoder, had only marginally better quality but took twice as long to encode. Would I be better off encoding on a PC with something like Procoder, even if I'm generating my content in FCP? I think a hardware encoder is out of our price range, by the way.

As for the blocky cross-dissolves in MPEG-2, I see them all the time on satellite TV (especially apparent on fades to and from black) and on poor-quality DVDs. I'm trying to make my DVDs better than this, and I read in Compression for Great Digital Video by Ben Waggoner that forcing keyframes can help in compressing cross dissolves. FCP allows me to put compression markers in my timeline that force I-frames in Compressor when I encode. You say that practice doesn't fit into a DVD bitstream requirement, so is that just a worthless feature? I am lost on this one.

i simply don't know if forced i-frames are fully legal in an mpeg2 dvd bitstream, because it's going to change the gop length, for one thing... so perhaps the question should be, what are the gop restrictions for a dvd bitstream?

afaik, there is only a maximum gop frame number of either 15 or 18(pal vs. ntsc), i don't know of any minimum numbers... so the next question would be, how does forced i-frames affect the total bitrate? what would it take to push your encode over the max legal bitrate?

i have never encoded mpeg2 with the apple compressor... what are your vbr settings? i typically use ~4.7-5+ mbps average, ~8+ mbps max... if your average vbr is set for something like 2.5 mbps, you are asking for trouble.

no question that your encoder choices would be far better on a pc, but there are still alternatives... for instance, do you have access to a dvd desktop recorder? my neighbor has an early sony unit that does a pretty good job of burning dvd's; so you could burn in real-time, then rip the mpeg back to your hard drive and author the dvd with it... be sure and check the availability of ac3.

satellite tv could be a worst-case scenario for mpeg2, because i believe that it uses long gop.

I don't think forcing I-frames changes the GOP length. At least in the encoders available for Mac, the GOP length is fixed, and in theory forcing an I-frame just makes a single GOP less efficient. I typically encode at 5-7 mpbs avg. and 7.5 max, by the way.

But if you think forcing I-frames is a poor option, is there an encoder you would recommend that runs on Windows XP? We do have once decent Windows machine at our office, and if it would help our quality then I would be willing to learn the gamma correction settings.

forcing i-frames will definitely shorten the gop length, by definition, no way around it... you are putting in the i-frame before it's due to go in, because there is a place on the timeline that needs it... you could force i-frames every 3rd frame, for instance, which would result in very short gop's that are far less efficient, but with better picture quality as the result.

another way to look at it is that i-frames should probably be automatically inserted at scene changes by the encoder(??), which would result in shorter gop's most of the time anyway.

i think that it should work, why not export a short section of video that includes a tough dissolve, maybe 4-5 minutes long, and start forcing i-frames to see what looks the best? i'd like to hear how it works out.

gamma differences between computing platforms is not an issue, because the video is intended for use on ntsc monitors, not computers.

if budget is an issue, you could buy an old copy of premiere 6.5 off of ebay or somewhere, to encode your mpeg2, because it comes with the mainconcept encoder.

Dan, you're right - testing is the best idea, and I will do it this week. Thanks for your help, and I will post my results for you later.

I understand that gamma differences between platforms shouldn't matter for NTSC, but gamma handling differences between MPEG encoders definitely matter. Without tweaking the gamma settings, encodes from the same DV source material from Compressor, MainConcept and BitVice (all on the Mac) look radically different (for example, MainConcept encodes darker and less contrasty video with the default gamma settings). I actually did do this test. I read an explanation of it once on the BitVice site, and I think it has something to do with Apple's DV codec, but I can't remember for sure. I tried encoding something short on ProCoder once from my Apple DV source, and I got a result similar to MainConcept on the Mac. Maybe this is not an issue with non-Apple DV codecs as the source, but because I edit in FCP I have to deal with it.

maybe there were gamma changes, but i just didn't notice it at the time? the thing is, those dv codec differences should only come into play when the footage has to be rendered, i.e., transistions and titles... otherwise, it's just a wrapper for the picture information inside... there are software tools that'll "change" the dv codec really quickly, it's not re-writing the entire dv file.

i had read some bad press about the apple dv codec awhile back, but i thought that apple had fixed it?? so many ways to go wrong in this business, lol! changing the gamma anywhere in the chain is going to increase the encoding time, especially if you do it at the dv level, before it gets exported to the mpeg encoder... try to find a workflow where you can avoid it.

According to the BitVice user's guide, the Apple DV codec changes luma values when it renders from YCbCr to RGB and vice-versa (I'm guessing this is what you are talking about with renders), and BitVice apparently changes everything to RGB when it encodes. BitVice has a DV Luma Correction option that compensates for this. MainConcept on the Mac must do this as well because the results I got with that were similar to BitVice with the luma correction off. It's annoying, but it's consistent so it just requires figuring out the correct gamma correction/luma correction settings in the encoder one time.

I just realized that I also saw this effect yesterday when I exported a couple of stills from my FCP timeline and brought them back in as TIFFs. The luma values changed in certain ranges. It was barely noticeable on my NTSC monitor, but it was obvious on my computer's LCD in the FCP canvas. I'm going to have to learn a lot more about this now. I thought, like you said, that the DV codec was just a wrapper that just takes the information from the tape directly. But I read Graeme Nattress's article about chroma sampling a while ago (http://www.kenstone.net/fcp_homepage/chroma_investigation_nattress.html) and it says that the Avid DV codec automatically smooths the chroma channels. Apparently some of these DV codecs are sneakily doing work in the background.

thanks for the link to that article, it's an interesting read... i think that's probably advantageous only when you are doing transitions, titles, etc.... i'm not sure that i'd want to take the hit that comes with completely re-encoding all the footage on the timeline.

i did try working with the avid program a few months ago, i think that it did seem to re-encode the dv footage that i imported(?), so what you are saying makes sense... but the majority of dv codecs definitely do not do that.

you could probably capture in the raw dv format? or maybe set up a different dv codec as the program default in fcp?

Dan, you have probably long forgotten about this thread, and obviously I didn't keep up with doing the tests the week of my original post, but I ran into the problem with dissolves again today, and that finally motivated me to do the tests. I found that when keeping bitrate, GOP structure and encoding mode constant, inserting a compression marker anywhere during a 1-second fade up from black eliminated ugly artifacts during the fade. But I also found that adding noise reduction in my chroma channels (I did this in Compressor) or using a closed GOP instead of open GOP could give me the same result at similar bitrates. Oddly enough, when I had the problem the first time, I was using a closed GOP.

My conclusion: forcing I-frames with compression markers works to eliminate some artifacts, but my problems are most likely caused by quirks with my material at certain bitrates in Compressor. I do think that forcing I-frames could be a good technique when I run into truly difficult-to-encode material, but taking another pass at the encode is probably an easier solution most of the time.

EDIT: Almost forgot - FCP won't allow use of third-party codecs, so I am stuck with the Apple DV codec unless I switch software. This is a major annoyance in FCP for some people who work at higher bitrates.

that is pretty interesting info... i don't understand the gop thing, but then i'm not really a compressionist either :-/ i wonder if you could use some apple lossless codec for just the section that's troublesome.

The videos I encode at work use loads of cross dissolves, which I know are bad for interframe compression, but I'm wondering whether I can help the process by forcing I-frames on the cross dissolves on my encode (I edit in FCP 4.5 and encode the MPEG-2 with Compressor). I read about this practice in a book, but I've never used it before, and I couldn't find any reference to it in this forum. This makes me suspect it's a suspicious practice, but I haven't been able to find another solution to my block cross dissolve problem.

Will forcing I-frames on my MPEG-2 encode make cross dissolves smoother at low bitrates? If so, on which frame or frames should I force an I-frame: the start of the dissolve, the center point or somewhere else entirely?

I would also appreciate other possible solutions to the problem.

Forcing I-frames and manually adjust bitrate possible with cinemacraft encoder pro, but if you can move your *.mov on PC. Forcing I-frames
good feature when you need make precision chapter or layer break point.