Lossless Video

[dark_guard]

I've noticed that when reencoding already compressed video it helps to convert them to a lossless codec before enoding, such as huffy, because it helps reduce artifacts and improves quality? My question is, which lossless codec is the best to use for this? Uncompressed RGB/YCbCr, huffyuv, or huffyuv via ffdshow (if that makes a difference)? Thanks.

[poisondeathray]

because it helps reduce artifacts and improves quality?

Impossible.

Lossless means visually identical. There is no difference between different lossless codecs in terms of visually quality. The differences lie only in the compression, speed of processing, and compatibility with different applications

For example, Lagarith is slower to compress than HuffYUV, but offers better compression (smaller filesize). There are several others you can use: e.g. MLC, x264 lossless mode

Another example, HuffYUV has compatibility issues with certain versions of Premiere Pro (often get weird color artifacts)

You input colorspace may have some bearing on what method you choose, because changing colorspaces is not lossless.

[dark_guard]

Impossible.

Lossless means visually identical. There is no difference between different lossless codecs in terms of visually quality.

That's not what I meant. I'm talking about converting an already compressed video. I know that converting it to huffy before reencoding reduces artifacts because I've done it before. I was encoding in vp7 and I got a video with artifacts, but after I tried again, by converting the original to huffy and then vp7 the artifacts went away. I figured that's because the vp7 encoder was having trouble working with the weird compression that the video was compressed with before. So if uncompressing a video makes it easier on the encoder, I figured that it would also compress better as well since the encoder has more leverage to do what it wants. Is that true, and if so, which lossless codec is the best? Should I just go with the one that gives me the biggest file size?

You input colorspace may have some bearing on what method you choose, because changing colorspaces is not lossless.

But if I keep the colorspace the same throughout then no worries, right?

[poisondeathray]

The problem with your example is VP7 is not lossless

An analogy would be converting an audio file to flac vs. converting it to mp3; flac is lossless, mp3 is not. So of course you will get lower quality or aritfacts with the lossy format

If you keep the same colorspace as your input, you should be fine. e.g. if you have a h264 .mkv in YV12, but convert to uncompressed RGB you will get quality loss from the colorspace conversion, and even more loss if you convert from the RGB to some YV12 format again.

Again, there is no difference in the visual quality between lossless codecs. The difference only lies in 1) compression (filesize), 2) speed of processing, and 3) compatibility. The visual quality is - by definition - lossless. You should choose not by what's "best", because there is no "best." Choose by what meets your objectives factoring in criteria 1,2 and 3.

[dark_guard]

The problem with your example is VP7 is not lossless

My only goal is to change the compression because I don't like what the original file was compressed with. Are you saying that it would be better to go "compressed->vp7" than "compressed->uncompressed->vp7"?

Again, there is no difference in the visual quality between lossless codecs. The difference only lies in 1) compression (filesize), 2) speed of processing, and 3) compatibility. The visual quality is - by definition - lossless. You should choose not by what's "best", because there is no "best." Choose by what meets your objectives factoring in criteria 1,2 and 3.

Again, I'm worried that those 3 things will affect how the vp7 compression engine will do its job.

Bear with me here - there's a reason I'm posting in the newbie forum. :P Thanks for your patience.

[poisondeathray]

Why the fixation with VP7? Does your project require you to use VP7? It isn't lossless, so you make things worse quality.

Are you saying that it would be better to go "compressed->vp7" than "compressed->uncompressed->vp7"?

There is no quailty difference between these two methods if you did things correctly and use the same settings. You only waste time in using an extra step.

Converting to a lossless intermediate might be useful if you were doing some intermediate editing or filtering, otherwise I see no reason for the extra step

I think you might be hung up on the term "uncompressed". If you keep the same colorspace, it is visually identical to the "compressed" input, except many times larger. It does not recover the original source before the compression (unless the original source was compressed with lossless compression). I'm guessing what you have as input is compressed with lquality loss, not the original source.

The artifacts or poor quality you experienced with your vp7 example might also be from using the wrong settings, low bitrate or using a poor decoder for your "compressed source". You would need to give more information

[dark_guard]

Why the fixation with VP7? Does your project require you to use VP7? It isn't lossless, so you make things worse quality.

This is for optimizing videos for youtube. I've tested out a few samples where I upload the original video, and the same video compressed in vp7, and the vp7 ends up looking better than the original, presumably because the compression is better. As far as vp7 is concerned, it simply looks the best on youtube. I've tested out vp7 against x264 using the "insane" preset on megui which took like a day to compress. The vp7 ended up looking better, and compressed in a very short amount of time - I only did one pass. And no, this was not because of my inability to conduct an experiment. I kept all the variables the same except for the type of compression.

You only waste time in using an extra step.

But are you sure about that? Because like I said before, it helped me avoid artifacts. I've yet to do a test to see if it improves quality. My question here though, is which kind of codec accomplishes the most "decompression", if you will.

I think you might be hung up on the term "uncompressed". If you keep the same colorspace, it is visually identical to the "compressed" input, except many times larger. It does not recover the original source before the compression (unless the original source was compressed with lossless compression).

New question. When you encode a video, does the encoder decompress the file before encoding it? Because if so, then yes, I agree that it's just a waste of a step.

The artifacts or poor quality you experienced with your vp7 example might also be from using the wrong settings, low bitrate or using a poor decoder for your "compressed source". You would need to give more information

The settings and bitrate were the same for both of those "methods". What do you mean by "using a poor decoder for your 'compressed source'"?

[poisondeathray]

I've tested out a few samples where I upload the original video, and the same video compressed in vp7, and the vp7 ends up looking better than the original, presumably because the compression is better.

It can never look better than the original. Even using a lossless encode only looks the same. It can only look worse when re-encoding using a lossy codec (assuming no filtering).

Are you uploading in such a way that Youtube doesn't re-encode? You used to be able to, if you kept it under 350kbps and use some other tricks. It might be in your previous testing that you slipped through the re-encoding process with some files that met the criteria

Also 99.9% of the time x264 is better than VP7, especially at low bitrates in my testing and many others can confirm this. It is also much faster if you use decent settings (you don't need to use insane settings). VP7 is noticeably slower, and doesn't scale as well with with more cores (VP7's multithreading implementation is worse)

But are you sure about that?

I'm 100% sure about the intermediate step. If your testing involves Youtube, it usually re-encodes thus your testing methods might need some revision. You can test it by playing it back yourself on your PC and see that this is the case. Or you can ask another question "How Do I Get Better YouTube Videos?" which is different than what you had been asking, because of the YouTube process. There are several other threads that deal with this topic if you search.

When you encode a video, does the encoder decompress the file before encoding it? Because if so, then yes, I agree that it's just a waste of a step. What do you mean by "using a poor decoder for your 'compressed source'"?

You have to decode the video to "see" the information in the input file that is fed into the encoder. If your decoder is faulty, then you might get artifacts. An example is using ffdshow and libavcodec to decode WVC-1 content. There have been document cases where artifacts occur. Another example that has been fixed is h264 paff stream decoding with libavcodec, which also used to give artifacts. There are many more examples that illustrate this.

[manono]

I agree 100% with poisondeathray. Using lossless as an intermediate step only adds to the overall time to get the end result and has nothing to do with any supposed improvement in video quality or lack or artifacts. I make an intermediate lossless AVI (Lagarith) quite often, and do it because I have a slow filter chain and making the lossless AVI saves time when eventually encoding for MPEG-2 using multiple passes.

Nor do I understand this desire to use VP7. YouTube itself recommends the use of XviD or DivX AVI, although there's nothing wrong with H.264 with AAC audio. I guess VP7 is OK, but I would dispute any claim that it's the best format in which to upload videos for YouTube. Do you have any YouTube links of 2 videos you've uploaded that you encoded using different methods?

And YouTube reencodes everything these days.

[dark_guard]

It can never look better than the original. Even using a lossless encode only looks the same. It can only look worse when re-encoding using a lossy codec (assuming no filtering).

Again, I understand this, but it in fact does look better than the original once it passes through youtube's encoders.

Are you uploading in such a way that Youtube doesn't re-encode? You used to be able to, if you kept it under 350kbps and use some other tricks. It might be in your previous testing that you slipped through the re-encoding process with some files that met the criteria

I don't believe that's possible - YouTube reencodes all videos now.

I'm 100% sure about the intermediate step. If your testing involves Youtube, it usually re-encodes thus your testing methods might need some revision. You can test it by playing it back yourself on your PC and see that this is the case.

I do the following:
1) Download the .flv files from youtube.
2) Capture the same frame of both videos in a .bmp image.
3) Put those two images in different layers in a document on photoshop so that I can toggle the visibility of each.

In my tests, vp7 has always produced more detailed video than x264.

Nor do I understand this desire to use VP7. YouTube itself recommends the use of XviD or DivX AVI, although there's nothing wrong with H.264 with AAC audio. I guess VP7 is OK, but I would dispute any claim that it's the best format in which to upload videos for YouTube. Do you have any YouTube links of 2 videos you've uploaded that you encoded using different methods?

I've deleted the links, but I'd be willing to test a sample with anybody who's interested. If I'm not doing it the best possible way I'd like to know about it.

You have to decode the video to "see" the information in the input file that is fed into the encoder. If your decoder is faulty, then you might get artifacts. An example is using ffdshow and libavcodec to decode WVC-1 content. There have been document cases where artifacts occur. Another example that has been fixed is h264 paff stream decoding with libavcodec, which also used to give artifacts. There are many more examples that illustrate this.

Ah, ok. So it's the vp7 decoder's fault then? I should still decompress to lossless to avoid artifacts though, right?

[poisondeathray]

So it's the vp7 decoder's fault then? I should still decompress to lossless to avoid artifacts though, right?

Not necessarily, I'm just suggesting possible explanations. It might be that your VP7 implementation doesn't accept your input file format correctly, but accepts a lossless intermediate properly. e.g. if you are using Flix Pro, it doesn't accept all kinds of input. You haven't provided enough information to discern this.

Everything I have said is valid for encoding for the PC, but once you add YouTube into the mix, it changes the analysis. I'm not sure what process they are doing, but it would make sense if you uploaded a high quality video that even if they re-encode it would look better than if you uploaded a crappy video. If this is the case, I stand by statement that x264 provides better quality than VP7, 99.9% of the time. (This is not to say VP7 is bad, on the contrary it's very good, but just takes too long). I am more than willing to show many head-to-head examples to demonstrate this is the case. (actually 99.9% might be generous, I haven't come across 1 situation where VP7 provides better quality output at the same bitrate)

If you think the intermediate step somehow makes it look better (I seriously doubt it, even with YouTube in the mix), feel free to do so - but it makes absolutely no sense. Here's why: The final encoder in your sequence of events on your PC "sees" the exact same thing whether it's the original input file or a lossless equivalent to that input file. Therefore, you should get the identical file if you've used the same settings. This means you upload the same file to YouTube, which sees the same thing!

You seem convinced of this. Perhaps the YouTube in the mix does something different, or you have a better insight into YouTube? If you are certain that your process has been consistent , I would love to see some examples

[dark_guard]

Not necessarily, I'm just suggesting possible explanations. It might be that your VP7 implementation doesn't accept your input file format correctly, but accepts a lossless intermediate properly. e.g. if you are using Flix Pro, it doesn't accept all kinds of input. You haven't provided enough information to discern this.

I was using virtualdub. One thing I should mention though with that artifacts case. I didn't actually get artifacts in the vp7 video, I only got artifacts after the vp7 video was uploaded to YouTube.

If you think the intermediate step somehow makes it look better (I seriously doubt it, even with YouTube in the mix), feel free to do so - but it makes absolutely no sense. Here's why: The final encoder in your sequence of events on your PC "sees" the exact same thing whether it's the original input file or a lossless equivalent to that input file. Therefore, you should get the identical file if you've used the same settings. This means you upload the same file to YouTube, which sees the same thing!

I believe you, I was just under the faulty assumption that the encoder had better data to work with since I avoided artifacts that one time. I myself didn't test my hypothesis.

You seem convinced of this. Perhaps the YouTube in the mix does something different, or you have a better insight into YouTube? If you are certain that your process has been consistent , I would love to see some examples

The only thing I'm convinced of is VP7's superiority for YouTube. As mentioned, I'd also like to see whether others can duplicate my results or whether I'm just doing something wrong.

[poisondeathray]

One thing I should mention though with that artifacts case. I didn't actually get artifacts in the vp7 video, I only got artifacts after the vp7 video was uploaded to YouTube.

The only thing I'm convinced of is VP7's superiority for YouTube. As mentioned, I'd also like to see whether others can duplicate my results or whether I'm just doing something wrong.

I'm still not convinced, especially if YouTube re-encodes everything. One possible explanation is YouTube's process might handle importing VP7 differently than h264, for example. I doubt it. Logically, if you upload a higher quality video, you should get a higher quality video on YouTube compared to the situation where you upload a low quality video.

The answer might lie on what you are doing for your encoding on the PC. In your "tests" are you using the same bitrate? (ie. is the filesize the same between the uploaded VP7 version and h264 version)? What about viewing the respective videos on the PC before uploading? It might be that your are not optimizing your settings.