Recode results just Suck

V7Goose

New member
Any resizing of my TiVo files just produces TERRIBLE results! I am using 619a. I cannot say if this works any differently than other recent releases. since I totally gave up on VRD about a year ago after running into horribly unacceptable PQ issues when cropping or resizing most files. I have just recently started testing it again, hoping you had improved the code. All I can says is that it is still absolutely terrible, for several reasons.

My source file for this testing is a 5 minute clip of a standard definition recording from TCM on a digital channel. Here is the program information:
File: Name : C:\Users\Public\Videos\VRD edited\Man in a Cocked Hat test defalt.tivo
Size : 0.105 GB
Duration : 00:04:58.16
Mux type : TiVo
Video: Encoding : MPEG2
VideoStreamID : xE0
Frame rate : 29.97 fps
Encoding size : 704 x 480
Aspect ratio : 4:3
Header bit rate : 15.000 Mbps
VBV buffer : 224 KBytes
Profile : Main@Main
Progressive : Prog or Int
Chroma : 4:2:0
Bit rate : 2.521 Mbps
Audio Stream: 1 (Primary) Codec : AC3
Format : DVD VOB
Channels : 2.0
Sub stream id : x80
Bit rate : 192 Kbps
Sampling rate : 48000
Sample size : 16 bits​

Note the Header bit rate of 15.00 Mbps and Bit rate of 2.521 Mbps. The PQ of this source is excellent. But if I make ANY changes in the Save as dialog that cause a recode, the results are unacceptable. I do not have any problems if I simply edit one of these files and save it without a recode, but if I make any changes that require a recode, it gets ugly. I have tested with the MPEG2 TiVo and MPEG2 Program Stream profiles, and the results are the same. Here are just a couple of examples:

TEST 4. Saved with all defaults except resize Letterbox to Widescreen (Intelligent Recode Quality Mode defaults). The resulting file size is just slightly smaller than the source, but the PQ results are really nasty. Program info:
File: Name : C:\Users\Public\Videos\VRD edited\Man in a Cocked Hat test defalt (04).tivo
Size : 0.092 GB
Duration : 00:04:58.15
Mux type : TiVo
Video: Encoding : MPEG2
VideoStreamID : xE0
Frame rate : 29.97 fps
Encoding size : 704 x 480
Aspect ratio : 16:9
Header bit rate : 2.646 Mbps
VBV buffer : 224 KBytes
Profile : Main@Main
Progressive : Prog or Int
Chroma : 4:2:0
Bit rate : 2.192 Mbps
Audio Stream: 1 (Primary) Codec : AC3
Format : DVD VOB
Channels : 2.0
Sub stream id : x80
Bit rate : 192 Kbps
Sampling rate : 48000
Sample size : 16 bits
TEST 8. Saved with resize Letterbox to Widescreen (Intelligent Recode Bitrate Mode with default values). The resulting file size is TWICE as big as the source, but the PQ results are actually a bit worse! Program info:
File: Name : C:\Users\Public\Videos\VRD edited\Man in a Cocked Hat test defalt (08).tivo
Size : 0.210 GB
Duration : 00:04:58.15
Mux type : TiVo
Video: Encoding : MPEG2
VideoStreamID : xE0
Frame rate : 29.97 fps
Encoding size : 704 x 480
Aspect ratio : 16:9
Header bit rate : 7.000 Mbps
VBV buffer : 224 KBytes
Profile : Main@Main
Progressive : Prog or Int
Chroma : 4:2:0
Bit rate : 5.217 Mbps
Audio Stream: 1 (Primary) Codec : AC3
Format : DVD VOB
Channels : 2.0
Sub stream id : x80
Bit rate : 192 Kbps
Sampling rate : 48000
Sample size : 16 bits​

TEST 10. Saved with resize Letterbox to Widescreen, Force Recode, Resolution 720x480, Avg Bitrate 5100, Max Bitrate 9500. The resulting file size is still MUCH larger than the source, but the PQ results are still a bit worse! Program info:
File: Name : C:\Users\Public\Videos\VRD edited\Man in a Cocked Hat test defalt (10).tivo
Size : 0.179 GB
Duration : 00:04:58.15
Mux type : TiVo
Video: Encoding : MPEG2
VideoStreamID : xE0
Frame rate : 29.97 fps
Encoding size : 720 x 480
Aspect ratio : 16:9
Header bit rate : 9.500 Mbps
VBV buffer : 224 KBytes
Profile : Main@Main
Progressive : Prog or Int
Chroma : 4:2:0
Bit rate : 4.440 Mbps
Audio Stream: 1 (Primary) Codec : AC3
Format : DVD VOB
Channels : 2.0
Sub stream id : x80
Bit rate : 192 Kbps
Sampling rate : 48000
Sample size : 16 bits​

TEST 12. Saved with absolutely no changes except Force Recode. The resulting file size is FIVE TIMES larger than the source, and the PQ results are finally acceptable, but hardly worth the space! Program info:
File: Name : C:\Users\Public\Videos\VRD edited\Man in a Cocked Hat test defalt (12).tivo
Size : 0.512 GB
Duration : 00:04:58.15
Mux type : TiVo
Video: Encoding : MPEG2
VideoStreamID : xE0
Frame rate : 29.97 fps
Encoding size : 1920 x 1080
Aspect ratio : 4:3
Header bit rate : 18.000 Mbps
VBV buffer : 1194 KBytes
Profile : Main@High
Progressive : Prog or Int
Chroma : 4:2:0
Bit rate : 13.017 Mbps
Audio Stream: 1 (Primary) Codec : AC3
Format : DVD VOB
Channels : 2.0
Sub stream id : x80
Bit rate : 192 Kbps
Sampling rate : 48000
Sample size : 16 bits​
 
Last edited:

Dan203

Senior Developer
Staff member
This is most like a side effect of resizing and not recoding. The original file is 704x480 and you say it's letterboxed. Which means that the actual resolution of the picture itself is 704x396. When you crop it and save it back to 704x480 it's taking that 704x396 picture and stretching it to 704x480, meaning it's having to create 84 vertical lines of resolution which did not previously exist. Our resizing routine is not very robust for increasing resolution. Throw in the fact that you're recoding at the same bitrate for a now bigger picture, using a single pass encode, and the problem is compounded even further.

As for what you can do about it... If the only reason you're recoding is to remove the letterbox then I'd say skip that and leave it as-is. You can't create resolution that doesn't exist, so you're not adding anything to the video by removing the letterbox. If you're recoding for another purpose, such as switching to H.264, then try lowering the resolution to match the crop. (horzRes/16*9 = vertRes)

Dan
 
Last edited:

Danr

Administrator
Staff member
Please create a small clip of a small section of the source of about 1-2 minutes long and save it WITHOUT recoding. The upload it to our FTP and we will check it out.

UPDATE: The original source file is pretty small, 100 MB so just upload the whole thing. If you send us the TIVO file, please include your media access key in the email, but we would prefer an un-recoded MPG.

FTP instruction at the top of the forum (please don't forget to send the email).
 
Last edited:

MrVideo

Active member
Which means that the actual resolution of the picture itself is 704x396.
Actually, it is worse than that. It is 704x360. 16x9 is 75% of 4:3 vertically.

First, convert to real 4:3, which is 640x480, since 720/704x480 is non-square. Divide 640 by 16 to get the pixels needed horizontally and then multiply that by 9 to get what it takes to display it vertically. That is 360.

The 396 would be if 704x480 was square pixel, but it isn't.

So, the bump to create anamorphic widescreen 16:9 from 4:3 letterbox is even worse than you thought. Going from 360 lines to 480 lines add 120 lines of non-existant material, or a third of the 480 lines need to be "created." In most cases that is going to look like crap, pure and simple.

I believe that the AVISynth tools do a better job of that. Still, the results are not pretty.

As noted, don't bother. Better yet, dump SD and go HD.
 

V7Goose

New member
Uploading clip now

Thanx Dan (and Dan), I'm uploading a test mpg clip now. Will send an email as soon as it gets done.

And while I appreciate the ideas and knowledge from all on trying to find the cause and solution for these problems, a little less smugness might help if you do not have all the facts. I know that MrVideo is very knowledgeable in many things, but he is way off base for this particular problem.

First of all, the picture quality problem of which I speak is absolutely NOT related to trying to stretch the source picture to create resolution where it does not exist. How do I know? Simple - I also tested many times with the same clip and just leaving the actual displayed video the identical size (e.g., Standard to Pillar box). I have also saved the clip with absolutely no changes to the output options except changing the Left and Right dimensions in the Sizing dialog box to -10 - this simply squeezes the picture just a tad and saves it as a 4:3 clip, just like the original. And the PQ is still ruined. So while I agree with Dan203 that this is a side effect of resizing, it seems to have absolutely nothing to do with trying to add vertical lines.

I certainly know that you cannot create resolution that does not exist, BUT, the problem we have here is a specific problem with VRD. I normally convert all the 4:3 Letterboxed videos to 16:9 by simply capturing the component outputs from my TiVo as h.264 with excellent PQ (considering the SD source material). The Tivo S3 and THD boxes do a very good job of zooming the letterboxed pictures without introducing macroblocking, jaggies or other artifacts (but only on the component and HDMI outputs). So it is pointless to try and maintain that this just cannot be done with these particular files.

But when I have a source video that is letterboxed 1.66, I cannot zoom it with TiVo or it cuts off significant parts of the top and bottom of the frame. In those cases, it would be wonderful to use VRD to resize the same source file to 16:9 with top/bottom dimensions of +44 and left/right dimensions of -22. This is a wide screen pillar box 1.66 picture. But so far I have had very little luck trying to keep VRD from ruining the PQ in many of the videos. They are not all affected the same, but most have some problems, and a few are just trashed.

If the original TiVo high def boxes with anemic processors can produce good results in real time with virtually any source file, I fail to understand why VRD cannot do at least as good with big multi-core computers, gobs of RAM and unlimited time. So I remain optimistic that a solution is available.
 
Last edited:

MrVideo

Active member
I know that MrVideo is very knowledgeable in many things, but he is way off base for this particular problem.
Then I am confused by what you are doing, based upon what you have next.

As mentioned by the Dans, it seems that the software methods used to resize video are not the best. I personally cannot verify what re-encoded, resized, video looks like as I do not resize MPEG-2. All of my work these days is via H.264 and third party programs used within the AVISynth These third party tools have been out there for years.

First of all, the picture quality problem of which I speak is absolutely NOT related to trying to stretch the source picture to create resolution where it does not exist. How do I know? Simple - I also tested many times with the same clip and just leaving the actual displayed video the identical size (e.g., Standard to Pillar box). I have also saved the clip with absolutely no changes to the output options except changing the Left and Right dimensions in the Sizing dialog box to -10 - this simply squeezes the picture just a tad and saves it as a 4:3 clip, just like the original. And the PQ is still ruined. So while I agree with Dan203 that this is a side effect of resizing, it seems to have absolutely nothing to do with trying to add vertical lines.
I am really confused as to what you are trying to accomplish here. First off, letterbox video doesn't have pillar bars. 4:3 video inside of 16:9 video does.

You can't have no changes and yet apply a -10 sizing change. That is a change, period. Why are you applying a squeeze to the 704x480 video? 704x480 is non-square digital video and has info that indicates the aspect ratio it is supposed to be displayed at. Putting a squeeze on the video completely changes the aspect ratio. It is no longer 4:3

Instead of changing the video vertically, you are changing the video horizontally. It makes no difference if you are resizing vertically or horizontally, you are resizing a digital image. There are various ways of doing that. Some good, some not so good.

If the original TiVo high def boxes with anemic processors can produce good results in real time with virtually any source file, I fail to understand why VRD cannot do at least as good with big multi-core computers, gobs of RAM and unlimited time. So I remain optimistic that a solution is available.
I do not disagree that it is indeed possible to do decent resizing. I've seen a lot of various things people have done on the AVISynth forums. The results have been amazing. But what you are doing to the video, in some cases, leaves me perplexed.
 

V7Goose

New member
Then I am confused by what you are doing, based upon what you have next.
I understand - my bad. I'll try to clear it up. In my original post I did not go into the background, only tried to clearly show the specific details of the problem.

I am really confused as to what you are trying to accomplish here. First off, letterbox video doesn't have pillar bars. 4:3 video inside of 16:9 video does.
My original source is a 1.66 video letterboxed in a 4:3 broadcast (the 4:3 is clearly shown in the program info I included in my original post, but my testing was only for encoding results and had nothing to do with any particular resize). And "Standard to pillarbox" is one of the predefined resize options withing VRD. I takes a 4:3 video like I had, and simply fits it unchanged within a 16:9 display.

You can't have no changes and yet apply a -10 sizing change. That is a change, period. Why are you applying a squeeze to the 704x480 video? 704x480 is non-square digital video and has info that indicates the aspect ratio it is supposed to be displayed at. Putting a squeeze on the video completely changes the aspect ratio. It is no longer 4:3
Uh, the word "except" is actually quite important to my post. I said I made absolutely no changes EXCEPT the horizontal sizing change. That was to point out there WAS a change, but only that one change. As for "why" I applied a squeeze to that video, it was simply to test the results of a recode where VRD did not have to add or extrapolate ANY new pixels at all - by slightly horizontally squeezing the existing video, the resize function actually had more detail to start with than it needed in the output. This was simply to prove that the PQ problems I was seeing had nothing to do with trying to ADD resolution.

I apologize for not making it clear in my first post what I ultimately wanted - I was more focused on pointing out the problems I saw with VRD recoding. To make it clear now - I start with a 4:3 video containing a letterboxed 1.66 display that I want to expand to a 16:9 video with a pillar boxed 1.66 display (thus expanding the original widescreen letterbox AND pillarbox display to just reach the top and bottom of a wide screen TV, having only very narrow pillar bars).

I am aware of many other program options to play with video files (and I DO appreciate the suggestions), but frankly, I really don't think this simple task should require them. I already paid for VRD, and it offers resizing among its many options. I was hoping that they could solve the unacceptable results their program is producing with the current default settings.
 
Last edited:

MrVideo

Active member
My original source is a 1.66 video letterboxed in a 4:3 broadcast (the 4:3 is clearly shown in the program info I included in my original post, but my testing was only for encoding results and had nothing to do with any particular resize). And "Standard to pillarbox" is one of the predefined resize options withing VRD. I takes a 4:3 video like I had, and simply fits it unchanged within a 16:9 display.
Somewhere along the line I must have missed that the 4:3 had a 1.66:1 letterboxed image. That's OK, as it isn't much different than a 16:9 (1.78:1) letterboxed image. There is just a few more pixels in the the vertical resolution.

Now you are really confusing me. Your 4:3 SD video contains 1.66:1 video, letterboxed. That means it has black bars horizontally across the top and bottom of the image. If you do a "standard to pillarbox" function, you should end up with what is called a windowbox video. That means it will be a video image with black bars all around it.

That function is not meant for 4:3 videos that are not full frame, i.e., video not having video filling the 4:3 image frame. It is meant for those who need to transfer 4:3 video to 16:9 video and not create horizontally stretched video. Especially for those that will be editing together 4:3 video and 16:9 video into a single 16:9 video result.

Your 4:3 video has widescreen video embedded into it. That function is NOT the one to use. You need to do a custom conversion to fit the 1.66:1 into the 16:9 display.

Uh, the word "except" is actually quite important to my post. I said I made absolutely no changes EXCEPT the horizontal sizing change.
It is still an exception. It is a poor statement when it contains a contradiction. In this case you wouldn't state that you made absolutely no changes and then in the same breath say that you did. Your statement should have been that you made a single change to the original video and it was thus. Your statement was more like something that would come out one side of a politician's mouth, only to have the other side of the mouth declare otherwise.

[/quote]That was to point out there WAS a change, but only that one change. As for "why" I applied a squeeze to that video, it was simply to test the results of a recode where VRD did not have to add or extrapolate ANY new pixels at all - by slightly horizontally squeezing the existing video, the resize function actually had more detail to start with than it needed in the output. This was simply to prove that the PQ problems I was seeing had nothing to do with trying to ADD resolution.[/quote]

Exactly. There was a change. Just state the change.

Ah, but... using the "standard to pillarbox" function does change the pixel arrangement of the video. If I understand what you are doing, the final result is still a 704x480 video. When you tell VRD to use the function, the 704 horizontal pixels are squeezed to 528 pixels, then 88 pixels are added to each side for the 16:9 anamorphic widescreen aspect ratio. It does have to extrapolate pixels, as 176 pixels are removed from the original image, in order to add 176 (total) pixels of black to the sides.

To make it clear now - I start with a 4:3 video containing a letterboxed 1.66 display that I want to expand to a 16:9 video with a pillar boxed 1.66 display (thus expanding the original widescreen letterbox AND pillarbox display to just reach the top and bottom of a wide screen TV, having only very narrow pillar bars).
Ya, that is becoming clearer now. It means recoding both vertically and horizontally. A double whammy.

I'm guessing that there are about 386 pixels vertical for the 1.66:1 letterboxed image. My math could be wrong and needs to be verified. 1.66:1 is also 14.94:9. Enlarging the 386 pixels to 480 would mean that about 23 pixels need to be added to each side to keep the 14.94:9 aspect ratio within the 16:9 anamorphic widescreen 704x480 (non-square) container.

I already paid for VRD, and it offers resizing among its many options. I was hoping that they could solve the unacceptable results their program is producing with the current default settings.
Can't argue with that.

I'll be doing something similar in the future. But, I'll be taking 720x480 anamorphic widescreen and upconverting to 16:9 1080i MPEG-2. There is another but to this story. It will only be the closing credits of some of the material that I have in 16:9 MPEG-2 HD. It is to replace the network closing credit crap with the real closing credits, which are only available is SD. I don't need absolute perfection in this case. I suspect the text will be very readable, which is all I need.
 

Dan203

Senior Developer
Staff member
Do me a favor. Try setting the deinterlacer to "Smart" and see if that has any positive effect on the quality.

Dan
 

Danr

Administrator
Staff member
The deinterlacer isn't being used with this file, since both the source and the destination are interlaced to begin with. Actually, the source file is interlaced at the start shifts to progressive about 8-10 seconds in (at least on the test clip).

I got a really good output of your test file by using the attached profile. Here are my settings or you can just import the attachment into TVS via the Tools>Edit Profile.
Code:
Output mode: force record
Resolution: 720 x 480
Encoding mode: Double pass encoding   << Important
Avg Bit rate: 2500
Max Bit rate: 9500 <<<<< Also important

Set cropping to convert letterbox to wide screen.
The resizer, which handles the cropping and the conversion from 704 x 480, 4x3, to 720x480, 16x9, seems to be doing it's job quite well.
 

Attachments

V7Goose

New member
Deinterlace is Worse

Do me a favor. Try setting the deinterlacer to "Smart" and see if that has any positive effect on the quality.

Dan
ANY choice of deinterlace when outputting an MPEG2 file is MUCH worse than none. When I use the H264 TS profile, deinterlace improves the output considerably over the mpg results, but there are still major problems with it.
 

V7Goose

New member
Good Results

The deinterlacer isn't being used with this file, since both the source and the destination are interlaced to begin with. Actually, the source file is interlaced at the start shifts to progressive about 8-10 seconds in (at least on the test clip).

I got a really good output of your test file by using the attached profile. Here are my settings or you can just import the attachment into TVS via the Tools>Edit Profile.
Code:
Output mode: force record
Resolution: 720 x 480
Encoding mode: Double pass encoding   << Important
Avg Bit rate: 2500
Max Bit rate: 9500 <<<<< Also important

Set cropping to convert letterbox to wide screen.
The resizer, which handles the cropping and the conversion from 704 x 480, 4x3, to 720x480, 16x9, seems to be doing it's job quite well.
This produced good results for me, too. Quite interesting, as it is very similar to one of the tests I did originally, where I used TWICE that average bit rate and still got poor results (Test 10 in my OP), but I had used single pass encoding. I had been using double pass for almost everything, but after seeing another recent thread where double pass was actually producing WORSE results, I decided to start doing most testing with single pass to save time. I also assumed that if it was the default, it should produce acceptable results. Oh well, thanx for finding this.

I'll now test it on the full video, as well as some of the other problem videos I have found and let you know.
 
Last edited:

Danr

Administrator
Staff member
I had been using double pass for almost everything, but after seeing another recent thread where double pass was actually producing WORSE results
I don't recall this thread. However, as the average bit rate gets lower the advantages of dual pass become much more apparent. It's also advantageous to make the max bit rate as large as possible so that more bits can be allocated to the frames that need them the most. The 9.5 Mbps (9500) max bit rate will create a DVD compliant recode.

Let me know how the whole show recode goes, and I'll talk with DanH about changing the profile defaults to get better results out of the box.
 

V7Goose

New member
Feedback

I don't recall this thread. However, as the average bit rate gets lower the advantages of dual pass become much more apparent. It's also advantageous to make the max bit rate as large as possible so that more bits can be allocated to the frames that need them the most. The 9.5 Mbps (9500) max bit rate will create a DVD compliant recode.

Let me know how the whole show recode goes, and I'll talk with DanH about changing the profile defaults to get better results out of the box.
The thread where dual pass encoding was worse is here (particularly starting with post #12):
http://www.videoredo.net/msgBoard/showthread.php?t=28483

As for my current issue, the forced recode settings you provided seem to be doing well with all the files I have checked.

Here is a summary of the tests -

All of the old problem clips I had saved were for scenes where VRD had huge problems causing jaggies and complicated backgrounds produced shimmering or "phasing". The new intelligent recode mode with all defaults handled all of those problem clips just fine.

But the intelligent recode failed miserably on every single SD Turner Classic Movies file I fed it (recorded from digital FiOS channel on a TiVo HD) where there was any significant motion combined with a fair amount of detail in the scene. In all of these cases, the forced recode you suggested produced a picture about equal with the original, and adding Smart deinterlace actually reduced some vertical jitter that was occasionally visible in the original source (especially evident on subtitles).
 

Danr

Administrator
Staff member
ut the intelligent recode failed miserably on every single SD Turner Classic Movies file I fed it (recorded from digital FiOS channel on a TiVo HD) where there was any significant motion combined with a fair amount of detail in the scene. In all of these cases, the forced recode you suggested produced a picture about equal with the original, and adding Smart deinterlace actually reduced some vertical jitter that was occasionally visible in the original source (especially evident on subtitles).
In addition to what Dan203 said, the Intelligent Recode defaults to single pass and a fairly low maximum bit rate. As I mentioned in my earlier post, these video really benefited from a two pass encoding with a high maximum bit rate.
 

MrVideo

Active member
All of the old problem clips I had saved were for scenes where VRD had huge problems causing jaggies and complicated backgrounds produced shimmering or "phasing". The new intelligent recode mode with all defaults handled all of those problem clips just fine.

But the intelligent recode failed miserably on every single SD Turner Classic Movies file I fed it (recorded from digital FiOS channel on a TiVo HD) where there was any significant motion combined with a fair amount of detail in the scene. In all of these cases, the forced recode you suggested produced a picture about equal with the original, and adding Smart deinterlace actually reduced some vertical jitter that was occasionally visible in the original source (especially evident on subtitles).
Correct me if I am wrong,as I am going by memory instead of reading all of the previous posting.

IIRC, the source of your videos are SD channels, that get upconverted to HD by your digital recorder. You are then downconverting back to SD.

That is not a good source of video. Doing SD -> HD -> SD introduces all kinds off errors.

The SD -> HD will produce those jaggies that you see are caused by converting 480 vertical pixels to 1080 and 720 horizontal pixels to 1440 (if converting to 1080i). A common problem upconverting produces the vertical jitter that you are complaining about. You can see that with the professional upconverters that are used to upconvert SD programming, including ads, to 720p or 1080i, for HD broadcast. It comes with the territory.

It is best to stay with SD all through your process, or get HD channels and convert that video to SD.
 

V7Goose

New member
Not Correct

Correct me if I am wrong,as I am going by memory instead of reading all of the previous posting.

IIRC, the source of your videos are SD channels, that get upconverted to HD by your digital recorder. You are then downconverting back to SD.

That is not a good source of video. Doing SD -> HD -> SD introduces all kinds off errors.

The SD -> HD will produce those jaggies that you see are caused by converting 480 vertical pixels to 1080 and 720 horizontal pixels to 1440 (if converting to 1080i). A common problem upconverting produces the vertical jitter that you are complaining about. You can see that with the professional upconverters that are used to upconvert SD programming, including ads, to 720p or 1080i, for HD broadcast. It comes with the territory.

It is best to stay with SD all through your process, or get HD channels and convert that video to SD.
You are not correct. These files have never been upconverted to anything. They are recorded from a digital SD channel on my HD TiVo. The resolution of these files was shown and discussed in those previous posts you do not want to read. I am taking the raw file straight off the TiVo and feeding it into VRD. Whatever artifacts and visual defects that are seen in the VRD output are either there in the original broadcast (in which case it should be visible when the file is played by the TiVo) or introduced by the VRD processing.
 

MrVideo

Active member
You are not correct. These files have never been upconverted to anything. They are recorded from a digital SD channel on my HD TiVo. The resolution of these files was shown and discussed in those previous posts.
Just needed to make sure. Even though you said 720x480, the part that stuck in my mind was the HD TiVo. Somehow that insinuated that the recording on the device was an upconvert.

If you have an HD TiVo, why not capture the HD version of the channel and work with that?
 
Top Bottom