Lossless giving me odd frames

[ExSphere]

Lately I seem to get this little bug when I render out of premiere. I set it to lagarith lossless codec and hit render, but when it's done the lossless has some odd frames that pop up that usually look like this.


The whole video doesn't look like that, just bit's of it. So I decided instead of rendering it into a lossless I will just set it to "none" the file size will be bigger, but it get's rid of the odd frames. But, since it's not a lossless file, it wont go straight into zarxgui. So I have to put the "none" file into vdubmod and re - render it into a lossless, then throwing it into zarxgui. By rendering it twice like that my quality get's knocked down a notch.

compared to how it looked only being rendering once

So my question is if there is anyway for me to get rid of the odd frames when I render out of premiere with lossless. Or, is there a way for me to throw a "none" file into zarxgui without rendering it again and losing video quality.

[Kariudo]

Unless you have cs4, chances are that it's just premiere sucking at exporting.
Uncompressed should work in zarx just fine (it's just opening the video in a script isn't it?)

Another option is to get debugmode frameserver, which will let you do the rendering with vdub/mod or some other program instead of having to deal with premiere

[LittleAtari]

Export as an Image sequence. Use the new zarxgui or avisynth to load said PNG sequence. Add the needed audio in and yay ^^

EDIT: You could also just toss the premiere file into AE and export it out of there.

[Scintilla]

If your version of Premiere has a "Recompress" option in the export settings, either check it and select "Always", or uncheck it.

[Qyot27]

Also, Lagarith might just hate you. It's had problems with error frames appearing on transcoding in the past. I learned very quickly not to give TMPGEnc Lagarith-encoded files, when I still used TMPGEnc. Switched to ffvhuff and the problems went away completely.

Try exporting in HuffYUV (if you must have RGB-mode video) or ffvhuff (if YV12) if you want speed and respectable lossless compression, or FFV1 (for RGB, YUY2, YV12, and so on) if you're really pressed for size. HuffYUV has on its own encoder, ffvhuff and FFV1 are contained in ffdshow's VFW interface ('ffvhuff' is what you get when you set the HuffYUV encoder in ffdshow to use YV12 - you can also use the adaptive huffman tables option for even more added benefit).

I will just set it to "none" the file size will be bigger, but it get's rid of the odd frames. But, since it's not a lossless file, it wont go straight into zarxgui. So I have to put the "none" file into vdubmod and re - render it into a lossless, then throwing it into zarxgui.

Wait, what? 'None' = Uncompressed video. It is lossless (and indeed, I saw no quality issues between the two screenshots). And there shouldn't be any reason Zarx264GUI can't handle it (or heck, x264 itself now that it can parse files using AviSynth's source filters).

[ExSphere]

I will just set it to "none" the file size will be bigger, but it get's rid of the odd frames. But, since it's not a lossless file, it wont go straight into zarxgui. So I have to put the "none" file into vdubmod and re - render it into a lossless, then throwing it into zarxgui.

Wait, what? 'None' = Uncompressed video. It is lossless (and indeed, I saw no quality issues between the two screenshots). And there shouldn't be any reason Zarx264GUI can't handle it (or heck, x264 itself now that it can parse files using AviSynth's source filters).

They are both uncompressed data, but zarxgui will only accept YV12 data. ( sorry, im actually explaining this on a different computer than me own, so im trying to remember everything. ) And yea, the quality in screen shot's doesn't look too different, but it is there. You can notice it a lot more when it's in motion and a lot of my beta tester's have mentioned it to me. And I don't think it's lagarith itself, since when I render out lagarith in vdub I never get those issues. But I think I might just be out dated with amvapp and im due for a re download. So i'll give that a shot.

Thanks for all the help guys

[Qyot27]

They are both uncompressed data, but zarxgui will only accept YV12 data. ( sorry, im actually explaining this on a different computer than me own, so im trying to remember everything. ) And yea, the quality in screen shot's doesn't look too different, but it is there. You can notice it a lot more when it's in motion and a lot of my beta tester's have mentioned it to me. And I don't think it's lagarith itself, since when I render out lagarith in vdub I never get those issues. But I think I might just be out dated with amvapp and im due for a re download. So i'll give that a shot.

Thanks for all the help guys

Colorspace conversions (if only like 1 or 2, not 30) shouldn't make any visible impact unless you have eyes like an electron microscope. And colorspace conversions don't cause motion artifacting in any instance I know of - that screenshot was labeled mp4, are you sure you're not comparing a low-bitrate H.264 or Xvid copy, mayhaps?

But from that, I'm guessing Premiere's internal colorspace handling is the problem, which is what the Recompress option solves. It forces Premiere to keep to RGB24 (or RGB32?) at all times, and not try to screw with shortcuts. And if Premiere is doing everything in RGB internally, and you have Lagarith set on YV12, you're still forcing Lagarith to do a colorspace conversion anyway - doing it after-the-fact with AviSynth and Uncompressed files won't make a difference, since Lagarith's colorspace conversion routines are from AviSynth, if I remember correctly.