HDTV: 1080i or 1088i, which is it ??? .. (SOLVED)

[vhelp]

Evening guys.

Ok.. Since I'm getting NBC during this short window of January/February, I wanted to record as
much 1080i HDTV content as possible to work with. I was hoping to do a deinterlace comparison
or something, but then I came across this slight issue with this resultion..

I thought it was 1080i, but my captured HD video (PCTV Pro) is giving me a finished 1088i video
source. The channel is NBC-30, a Connecticut station that I am able to capture -- or should I
say, record

I guess the question should be, "why did they add 8 pixels ?"

Aspect Ratio:

--> 1920 / (16/9) = 1.778 = 1080i
--> 1920 / 1080 = 1.778

* 1.778 = rounded

-vhelp 4513

[jagabo]

The engineers weren't thinking when they specified 1080i -- 1080 isn't a multiple of 16. The broadcast MPEG stream is often 1920x1088. Crop 4 lines off the top and bottom.

[MozartMan]

I am getting 1920x1080 from cable box to PC via firewire using CapDVHS without re-encoding, original broadcast quality.

vhelp,

Search Google for HDpatch. It will patch 1088 to 1080.

[vhelp]

You guys posted when I was revising my initial post

MozartMan, (with respect to HDTV) 1920x1080i is new to me because I could never
capture this from my HD on account of the gloab's position/axis or something domb sh_t
like that. I have a window of Jan/Feb to receive these other channels, though I'm only able
to get NBC at the moment. I guess I have a few more days before I start getting PBS, etc

Anyway..

The report resolution of 1088 is from DGIndex. I also export to a pseudo avi via VFAPI because
I like to do most of my editing in virtualdub.. ie, deinterlace and noise reduction, etc. Anyway.
So, it looks like this source (as received by my HD card) is an actual/phisical 1088 pixels and
not a miss-read or false value -- I'm assuming that this HDpatch is to correct that flaw -- However,
as jagabo suggested, its prob easier to crop the pixels to get a proper aspect ratio, though not that
it really matters at this point -- with such a large resolution, that is -- who cares. Thanks for
the patch suggestion though.

Its funny how the video is so evenly laid out.. (there is no uneven black on either of the top/bot
sides) and I was trying to get a decent deinterlace and so I settled with a 960x544, but this
seemed to result in a slightly blurry look. So, I may look into cropping a little off and seeing if
that improves the video a bit. I don't need such a large 1920 pixel resolution.

-vhelp 4514

[jagabo]

There should be little visible difference when resizing from 1920x1080 or 1920x1088 to 960x544.

Are you deinterlacing before resizing? If not, that would be a problem.

[MozartMan]

vhelp,

Here is instructions from AVS forum:

What Is HDPatch Used For?

HDPatch can be used, primarily, to solve two problems in the Movie Factory 5/VideoStudio 10+ HD-DVD workflow (other uses are outlined below):

1. 1088 files: many streams from various sources are encoded with a vertical resolution of 1088 (i.e. 1920x1088 or 1280x1088). MF5/VS10+ does not recognize this as a valid HD-DVD resolution and will attempt to re-encode these streams. HDPatch will modify the stream headers to correct the resolution, changing the 1088 to 1080. Once "patched," Movie Factory 5/VideoStudio 10+ should process the stream without re-encoding. And don't worry - you're not losing 8 pixels of video. Those extra 8 pixels are usually gray filler.

To use this feature:

1. Process your .ts, .tp or .m2t file with VideoRedo to convert transport stream to program stream.
2. Run HDPatch. Select your converted program stream video by clicking on the "..." box at the end of the "File:" line. In the browser, find the file you converted.
3. In the menu select Preset>Fix1088.
4. Select the "Patch Stream" button at the bottom.

The patch should be virtually instantaneous. Your file is now ready for normal processing in Movie Factory 5.

http://www.avsforum.com/avs-vb/showthread.php?t=705146

[jagabo]

I fail to see how HDPatch will be of any use in vhelp's situation.

[vhelp]

MozartMan, my friend. Thank you for pointing that out. I think its now clear to me.
Your nudging got me to realizing and thinking about my HVR-1600 patch I wrote some time
ago when I used to use that card -- I no longer use it. I wrote a patch that corrected the
recorded MPEG PS which allowed various mpeg editor tools to open and work with them.
(the benefit of my hvr-1600 patch** tool was that there was no need to re-write a new file)
Those (glitchy) files came out like that only if you used Hauppauges wintv200 software.

** I could prob do something similar for my PCTV Pro source files.

So, I'm thinking that if I can do what I did for the HVR-1600, then I could prob do the same
thing for the PCTV Pro, too. I'm gonna look into this sometime this week. Its just for my own
little personal challenge. Thanks again.

-vhelp 4515

[vhelp]

Hi jagabo, Sorry. I was responding to the topic while you wrote your latest. And I was
sort of iterating what MozartMan noted. There might be some wheight to this 1080i vs. 1088i
glitch in some of our captured HD video source.

If the MPEG stream is being improperly labled as 1088 and our usual mpeg decoder/processors
re-builds the source by restreaming (aka, pseudo avi, etc) then this could mean that our sources
are being stretched later on down the chain.. ie, our (mpeg) decoder engine would make 1088
pixel resolutions instead of the actual 1080 pixel resolution consiquentially tainting our videos.

I don't know, I'm just theorizing at the moment

-vhelp 4516

[jagabo]

If the MPEG stream is being improperly labled as 1088 and our usual mpeg decoder/processors
re-builds the source by restreaming (aka, pseudo avi, etc) then this could mean that our sources
are being stretched later on down the chain.. ie, our (mpeg) decoder engine would make 1088
pixel resolutions instead of the actual 1080 pixel resolution consiquentially tainting our videos.

If DGIndex tells you it's 1088 and VirtualDub loads it as such, you can be pretty sure that's what your source is.

[vhelp]

Hmmm... and now that I think about it, I'm gonna dig around that hvr-1600 patch tool I wrote
some time ago and run my pctv pro hd videos through them to see if that does anything. You
see, a while back because I didn't have 1920x1080i receivable channels I could not test my
patch tool with them and the hvr-1600, but someone had a sample clip from a PBS channel
and I D/L'ed it and ran it through my patch tool and the video was finally able to play with
anything I threw at it. The purpose of my hvr-1600 patch tool was to patch the 'header'
part with a set of new values.

-vhelp 4517

[jagabo]

Another thing to consider: a 1080i broadcast may have started out as 720p or HDV (1440x1080) so may not be as sharp as one might expect.

Here's 960x540 sample I made from a 1920x1080i MPEG TS file someone uploaded once:

MPEG2Source("E:\Misc\1920x1088 High Definition.d2v")
LeakKernelDeint(order=1)
LanczosResize(960, 540)

[vhelp]

Ok. I just wanted to apoligies to everyone for what seems to have been an error on my
part. I was using DGIndex v1.4.3 (because its the only version that works on my XP Home
computer with VFAPI plugin -- the latest versions just don't) and it was reporting the
1088 pixel resolution.

Remembering how my test run with VideoReDo reported 1080i..

When I ran it through the DGIndex v149rc2, it reported the proper 1080 pixel resolution.
So, the improper reading was on account of an older version decoder I guess.

Thanks everyone. It was an interesting discussion, though

-vhelp 4518