Forum Archive Home -> Digital TV / DVB / HDTV -> HDTV recordings: 1920x1088 vs. 1920x1080 lines.. [SOLVED]
| HDTV recordings: 1920x1088 vs. 1920x1080 lines.. [SOLVED] | ||||||||
| vhelp posted 2008 Aug 22 20:37 | ||||||||
| [SOLVED] -- I was using vfapi when I should have been using dgdecode/mpeg2source to process MPEG's.
I don't know, but after working with these HDTV sources put out by my Pinnacle PCTV Pro stick and its recording software, I"ve been trying to deal with an issue that I thought I raised a question on in previous discusisons elsewhere on this forum, but my memory is not at its best considering how swampped I've been over these 14 days of the Olympic games. Anyway. The issue is with the decoding of the obtained PS MPEG-2 's from the PCTV Pro stick. I am using DGIndex (various vers) and after processing to a .d2v project, I am getting reported outputs of 1920x1088 even though (in some versions) the info details report 1920x1080 during processing. And when I export out to VFAPI or AVISynth script using the info() function, they each report with 1920x1088 pixel resolution. So it would seem that I do have those 8 extra lines of pixels. I think my memory is trying to come back and tell me that someone did hint what the issue might be. But, after working with the these MPEG sources, I've been noticing that there's this gray bar at the bottom of the mpegs, but I dismissed it on account of being too swamped with deadlines and things. So, this evening, I decided to put some time into this problem and consult google, and this is what I found out: --> grayline with mpeg2source by lexor; Dec 10, 2005 The hint in that discusion seems to lean toward it being the PS MPEG-2 decoder engine -- the one installed by the Pinnacle PCTV Pro stick, I think. If that be true then there should be an update from Pinnacle or else perhaps another mpeg decoder (hacked or other) might be available to fix this. However, in the link above, there is a tool posted that hacks the mpegs to fix this problem. I haven't actually tested it, nor have I read that discussion completely, (I will, after I finish this post) but I think it might work for the time being. Download hack tool: fix1088.exe 132kb -- a command line tool. Other HDTV cards might also suffer from this grayline at the bottom thing, and this tool might help those, as well. -vhelp 4839 | ||||||||
| jagabo posted 2008 Aug 22 21:22 | ||||||||
| Yes, a lot of devices produce 1088 lines (because it's mod16). Some decoders (CoreAVC for example) have the option of forcing them to 1080 lines. | ||||||||
| vhelp posted 2008 Aug 24 22:35 | ||||||||
I did a quick what-if scenario and dropped one of the mpeg's (a small one) into virtualdub and it did report a 1920x1080 pixel resolution and no graybar in sight. So, it seems to be a problem with the software tools as they decode/process using mod16 algorthms, as would seem the case with the version dgindex I was using. I ran a few calculations to see what common resolutions (height) would suffer from this issue (with these mod16-based tools) in the listing below: 30.00 --> 1.33AR --> 720x480 div 16 17.00 --> 2.35AR --> 640x272 div 16 22.50 --> 1.78AR -> 640x360 div 16 33.75 --> 1.78AR -> 960x540 div 16 45.00 --> 1.78AR --> 1280x720 div 16 67.50 --> 1.78AR -> 1920x1080 div 16 In an effort to test this mod16 issue, I threw in a few of my recently uploaded 640x360 mpeg clips of the games and I found that they too would suffer the mod16 error when I loaded it into dgindex. I have several versions but not the latest. So I'll assume that this issue has been fixed in later versions. I don't know the links to those so I couldn't test to see if it was fixed. However, loading them into virtualdub decodes the clips without the mod16 error. So, its good to know that this issue can be fixed in those tools. -vhelp 4844 | ||||||||
| jman98 posted 2008 Aug 25 05:03 | ||||||||
| I record HDTV signals directly from my cable box via firewire and bypass all capture cards. Any 1080i video I have recorded is actually 1920x1088. The point is that it might not be the card doing this but it might be simply how broadcasters are sending the signal. | ||||||||
| Nelson37 posted 2008 Aug 25 09:00 | ||||||||
| Also dealing with memory issues but I recall that this was a variable from the original broadcast. The patch solution was much like the "header trick" for resolution issues, some softwares ignore the 1088 value and some choke on it.
The main problem was that progs that did not like the number would re-encode when authoring, which was basically not needed. | ||||||||
| vhelp posted 2008 Aug 25 19:52 | ||||||||
| [UN-RESOLVED] -- you have to manually crop the pixels.
Hi guys. I will search google to see if there is an update to dgindex and see if this issue has been cleared up. When it comes to mpeg videos, I much prefer to work inside dgindex on them. I suppose I could crop off the 8 pixels but, as simple a step that is, that would be one more step to the chain of events, and I already have too many at this point. If I find an update, (and it resolves the issue) I'll post it up here for consistancy sake. Until then, see you around. EDIT: Well, unfortunately, there were no fix.. cropping seems to be the only way of aleaviating the problem, though that feature in dgindex was disabled, so you have to do it in post -- avisynth or virtualdub. -vhelp 4846 | ||||||||
| edDV posted 2008 Aug 26 02:10 | ||||||||
Everything I use shows 1080 lines. How are you measuring? | ||||||||
| jman98 posted 2008 Aug 26 05:00 | ||||||||
Both the Teco Bit Rate Viewer and Ulead DVD MovieFactory 6 report my video as being 1920x1088. In fact, I first noticed the problem because Ulead kept insisting on re-encoding my video when trying to produce HD DVD even though I checked the option that said "Don't encode compliant sources". I suppose it could be a header issue where the header reports 1088 but the video is actually 1080. Not sure. | ||||||||
| MozartMan posted 2008 Aug 26 06:48 | ||||||||
jman98, I don't know what cable box you use, but I get 1920x1080i (and 1280x720 on some channels) files from Comcast Motorola DCT-3416. Something wrong with your setup.
Bit Reate Viewer doesn't work on HD .TS files. Here is the guide on how to transfer video from cable box to PC in original quality via Firewire: http://home.comcast.net/~exdeus/stbfirewire | ||||||||
| jman98 posted 2008 Aug 26 08:02 | ||||||||
OK, first of all, I really don't care if you think something is "wrong in my setup". I'm just using standard drivers to capture via firewire, but you know what? I really don't care, not at all, that I have this problem because I can work around it. Second, I never said I was feeing TS files into Teco. I edit with VideoReDo to remove commercials and save as MPEG-2 program streams (Ulead barfs on TS and frankly, it's just easier for me to work with PS). Guys, I'm just reporting what I'm getting in my captures. That's all I'm doing. I'm not looking for "you don't know what you're doing" type posts. If you don't like what I said, that's YOUR problem. I'm just reporting what I'm getting and I can work around it and I'm not looking for help. The link is how I did my captures but again, I can work around it so I don't really care, not even a little, that I have this issue. | ||||||||
| MozartMan posted 2008 Aug 26 08:28 | ||||||||
Oh man! 1. Nobody said "you don't know what you're doing". 2. If you really don't care why the hell do you post here? 3. Good luck to you man! Adios. | ||||||||
| vhelp posted 2008 Aug 27 19:55 | ||||||||
| Actually, to settle this mod16 vs. whatever thing, one could review the source code to dgindex and see where it utilizes mod16 algorithms, but good luck in that, especially if it uses pre calculated table or equations as they are harder to follow, else worse case, the routine could be in libraries that dgindex calls. But, for those who are c++ savy, it might be worth a look-sees and settle this 1088 vs. 1080 problem.
-vhelp 4854 | ||||||||
| neuron2 posted 2008 Aug 27 23:32 | ||||||||
| The latest version of DGIndex should handle this. It should pop up a window asking if you want to treat the video as 1080 instead of 1088.
If that is not happening, please post a link to an unprocessed source stream sample. I know the DGIndex code pretty well, so I can give you a definitive answer if you give me a source stream. | ||||||||
| vhelp posted 2008 Aug 27 23:55 | ||||||||
| Been using various versions in the 1.4.x's range, then later searched google and found v1.5.2 which is what I've been using this past week, from this link:
--> http://neuron2.net/dgmpgdec/dgmpgdec.html I must still have an older version. Thanks for looking into this problem over here :) -vhelp 4857 | ||||||||
| neuron2 posted 2008 Aug 28 00:18 | ||||||||
| 1.5.2 is the latest version. Is it OK with 1.5.2?
If not, where is the sample? | ||||||||
| vhelp posted 2008 Aug 30 09:15 | ||||||||
| Good morning..
Sorry I haven't responded sooner. I"ve been away from my home computer, and my work computer is constantly being blocked for outside usage, including being able to upload -- rapidshare; megaupload; and a few others are no-no's for me, and they are even blocked from my view. Our employer is just too vigalent about these things. And, I can't find anything that is 10 MB or less in size that I might be willing to upload over dialup. So I'm in a pickel as to how to get you a test sample. For now, I'll try and answer your question in further details. And I just wanted you to know that there is no urgency to have a resolution right away. Its just that I spotted this problem and thought I'd share it and see if there was a solution to it already. Thanks.
I have tried versions in the 1.4.8 range and 1.4.9x ranages, and the same problem. And after D/L'ing the 1.5.2 version, the same problem occurs, whether 640x360* or 1920x1080, they all output the same issue. In dgindex, there are two ways I open mpegs.. by the clunky way of File\Open\.. or, by dragging them to the window. I prefer the drag way because of the way I work. * the 640x360 are my own encodes from TMPGenc, not from the Pinnacles recording softare. So, it would seem that it is not tied to Pinnacle as I was getting around to. Maybe the two recording (mpeg) types of these are similar in attributes and are missing something in the specs or format that other mpegs (by other tools, etc) have and that DGIndex have no problems with. The other thing I noticed -- maybe it will help you figure out whats going on. I find that whenever I do work with the 1080 sources from my pinnacle recording software, the bottom 8 pxel line is gray. But, when I work with my own encoded mpegs by TMPGenc, the botton 8 pixel line is black. Hmm... Thanks for all the help on this matter, plus the enhancements you've made on dgindex :thumbs_up: -vhelp 4858 | ||||||||
| neuron2 posted 2008 Aug 30 11:19 | ||||||||
| I can't do anything without a sample. I just need a single GOP. 1-2MB should be fine. As long as it's enough to show a picture in DGIndex. | ||||||||
| jagabo posted 2008 Aug 30 11:42 | ||||||||
| I have version 1.5.0 RC5 of DgIndex and I don't see any "extra" data around non-Mod16 frames. I just tested a 480x360 encode with TMPGEnc Plus and DgIndex showed exactly 480x360 pixels. Does DgIndex rely on any external filters like MPEG splitters and decoders? Could those be a source of vhelp's problem?
I know that some image compression schemes have an encoded frame size and a "valid" frame size. So an image may be encoded with a frame size larger than the valid image data (so as not to have to special case the edges). Does MPEG have such a concept? | ||||||||
| neuron2 posted 2008 Aug 30 13:59 | ||||||||
| DGIndex is totally self contained.
Yes, MPEG can specify the coded size and the display size. If vhelp would simply post a sample stream, we can easily figure out what is happening. | ||||||||
| vhelp posted 2008 Aug 30 14:36 | ||||||||
| wow.. I jumped up out of my bed (was napping on the problem) with an idea :idea:
@ jagabo I think we can all help each other out, actually. Since I can't upload files over dialup, would be willing to consider encoded (with TMPGenc) an video in 640x360 pixels and then upload it. You can test your's out with DGIndex, too, if you want. But if you upload this video, I can test it out on both my pc's and see if I get the same problem. If I do (and you don't) then we are both correct with our theory that it is a codec and/or libirary thing that is causing the confusion. This would help me out because I can at least download a 10MB or so file in almost no time. My upload speeds is in the order 1.2kb times, and I would have white hair by then. I would be greatful, thank you. . . . Otherwise, here's what I have so far in my own trials.. Testing with DGIndex 1.5.2 using 640x360 pixel videos I had been using 1.5.2 on my Windows XP Home edition computer and thought that maybe the issue is with that computer. But after several test encodes on my WIN98 computer, that is not the case there, either. I tested with 1.4.3 and 1.4.9 etc., and they all produce the same thing on the win98 computer, too. The following were based on a quick encode in TMPGenc as the 720x480 test source encoded back a few years ago from my Polaroid DRM-2001G dvd recorder over a 480i component output. So don't worry about imperfections you might see. Thanks. 
* BEFORE: virtualdub output -- Crl+1 -- screen output capture 
* AFTER: TMPGenc -> TMPGenc -> DGIndex 1.5.2 -> VFAPI -> virtualdub Ctrl+1 -> output -> .jpg Thanks everyone :) -vhelp 4863 | ||||||||
| vhelp posted 2008 Aug 30 14:45 | ||||||||
| @ neuron2
I'm sorry I can't satisfy your requirements. I did try encoding a short clip, and thought great, I can finally get some answers, but the clips I fed into 1.5.2 would not completely encode to a .d2v file because of some GOP issue -- but it would process perfectly in older versions, even with 8 frames, and still demostrate the x8 pixel problem, using only a 210kb mpeg. Sounds pretty stupid, I know, but it worked. But you are only interested in the 1.5.2 aspects. Oh well. AT least I tried. -vhelp 4864 | ||||||||
| neuron2 posted 2008 Aug 30 14:58 | ||||||||
| Aha, seems to be limited to VFAPI.
I've duplicated it with VFAPI serving but not with Avisynth serving. I'll see what I can do about it, but out of interest, why are you using VFAPI instead of an Avisynth script? | ||||||||
| neuron2 posted 2008 Aug 30 15:00 | ||||||||
| ||||||||
| jagabo posted 2008 Aug 30 15:15 | ||||||||
| Here's a little 640x360 MPG file from TMPGEnc Plus:
macbeth.mpg | ||||||||
| vhelp posted 2008 Aug 30 16:51 | ||||||||
Oh. Thanks jagabo.. for trying.
* BEFORE: macbeth.mpg -> DGIndex 1.5.2 -> VFAPI -> virtualdub Ctrl+1 -> output -> .jpg 
* AFTER: DGindex -> macbeth.d2v -> avisynth -> virtualdub Ctrl+1 -> output -> .jpg :thumbs_up: hmm.. it looks like my huntch was correct, (that the problem would still be there) and I was right. Anyway. It seem that neuron2 hit on the problem right away -- vfapi. Moving forward I will definately be using avisynth via "dgdecode.dll" / mpegsource() on these mpegs. Still, I use vfapi for various projects and I would like to see a resolution. But I put no pressure on the developer to rush anything with respect to vfapi. I'm just glad that we solved the mystery behind the problem. My thanks to everyone, I'm so happy again :lol: -vhelp 4867 | ||||||||
| jagabo posted 2008 Aug 30 17:10 | ||||||||
| I thought VFAPI had been abandoned. It looks like it hasn't been updated in six years. | ||||||||
| neuron2 posted 2008 Aug 30 17:16 | ||||||||
Here, I'll try again. Why do you need to use VFAPI for these projects? | ||||||||
| jagabo posted 2008 Aug 30 17:25 | ||||||||
Is the coded size always mod16? | ||||||||
| neuron2 posted 2008 Aug 30 18:11 | ||||||||
| Yes, you always have to have an integral number of macroblocks. | ||||||||
| vhelp posted 2008 Aug 30 18:46 | ||||||||
You know, I'm not gonna bullshit around the bush on this.. old habbits die hard :nod: ..and I'm still gonna use it. I'm not concirned with the impact in speed it has over avisynth. But given all the nonsense I went through with these HD sources, I have to admit that its time for a little bit of change in some of my workflow habbits. And I've already started on it, by including the two script functions for dealing with mpegs. But don't get me wrong, I've been using avisynth for quite some time and in all kinds of video projects. Its just that with the recent broadcast of the Olympic games in HD, the old habbit thing got stompped on, and the rest you know is history :) I hope I've (finally) answered your question, otherwise, thanks for putting up with me and my stuberness, -vhelp 4868 | ||||||||
| neuron2 posted 2008 Sep 01 14:33 | ||||||||
| OK, I looked over the code and decided it is not worth doing anything about, as there is a simple workaround. I added the description of the workaround to the VFAPI help file:
"An MPEG file may have a display size that is not an integral number of macroblocks (i.e., multiples of 16 for width and height). When you open such a file through MPEG2Source() using an AVS script, a Crop() filter is automatically applied to reduce the frame size from the internal coded size (which is an integral number of macroblocks in both directions) to the display size. This is NOT done when serving a D2V with VFAPI. You can instead make an AVS script that uses MPEG2Source() and open that AVS script in the VFAPI Converter instead of the D2V file." | ||||||||
| Ripper[47] posted 2008 Oct 13 13:15 | ||||||||
| Hi, everyone. Sorry about my english, it is not very good, but I don't know another place to ask my question. I have downloaded an HDTV-movie, but it plays with freaking grey line in the bottom.
Anyway, VLC Player plays this movie just fine, without any grey line. But I want to watch it with Media Player Classic! It's Fight_Club.1080i.HRT.ts  
SAMPLE, 7.25Mb. Could anyone tell me, how to remove this grey line without re-encoding original video? | ||||||||
| jagabo posted 2008 Oct 13 14:06 | ||||||||
| MPCHC plays it with no gray border at the bottom. | ||||||||
| Ripper[47] posted 2008 Oct 14 03:35 | ||||||||
| jagabo
Hmmm... I have MPCHC v1.1.0.0 and gray line is stilll here. =( | ||||||||
| jagabo posted 2008 Oct 14 07:16 | ||||||||
| I'm using MPCHC 1.1.604.0. But I run my desktop at 1920x1080 so maybe the graphics card is cutting off the extra 8 lines?
I also played the file with mplayer2.exe (WMP 6.4), WMP 11, KMPlayer, and VLC. None of them showed a gray bar at the bottom of the frame, either full screen or windowed. | ||||||||
| Ripper[47] posted 2008 Oct 16 13:44 | ||||||||
| I have downloaded MPCHC 1.1.604.0, but this grey line is still in the picture!!!
Anyway, I was looking for some advice about how I can re-mux video (without any re-encoding) that I could play it with any player I like. | ||||||||
| Ripper[47] posted 2008 Oct 18 08:40 | ||||||||
| Could anyone help me please?! | ||||||||
| poisondeathray posted 2008 Oct 18 09:48 | ||||||||
| jagabo was suggesting that it might be something on your system causing it, not the video itself since he didn't have the problem with any player - so re-muxing the video probably won't help
e.g. check your graphics card drivers & settings, if you have any external filters for decoding, try disabling them. Try changing renderers on MPC. You may want to check graphstudio to see what splitter/filters are being used | ||||||||
| jagabo posted 2008 Oct 18 11:18 | ||||||||
| You might try DVDPatcher. | ||||||||
| Ripper[47] posted 2008 Oct 26 05:47 | ||||||||
Well, according to diskussions on russian forum, some people have that problem and some do not. Anyway, here is my preferences: 
I am using ffdshow video decoder and video mixing renderer 9 (renderless) Which of my settings are wrong?
Thanks! This is very similar to something, that I was looking for, but it dose not cropping picture, it just doing change height from 1088 to 1080. Grey line is still visible. Is any software that I can CUT OFF this 8 pixels of grey line? | ||||||||
| jagabo posted 2008 Oct 26 08:38 | ||||||||
Sure, but you will have to reencode the whole movie. Use any editor/encoder that allows you to crop the frame. I just ran a test with DgIndex, AviSynth, and HcEnc -- no problems. | ||||||||
| Ripper[47] posted 2008 Oct 26 17:36 | ||||||||
| jagabo
oh no! To save original picture quality - is my "prime directive". I can't believe, there is no software to insert cropping options in video or in container (avi, mkv, mpg, ts, m2ts, etc.)... | ||||||||
| jagabo posted 2008 Oct 26 19:07 | ||||||||
| I tried your 1920x1088 sample again today and this time I did get the gray line at the bottom of the frame (with MPCHC). I used DVDPatcher to change the resolution to 1920x1080 and the modified copy plays without the gray line. | ||||||||
| poisondeathray posted 2008 Oct 26 19:19 | ||||||||
I didn't test your sample specifically, but in general there a few ways to do this for playback, and 1 for "container" formatting 1) You can do it for playback in KMPlayer (pan&scan=>screen offset=>select pixels) 2) You can playback an .avs script in a directshow player e.g. MPC
3) Do it through ffdshow postprocessing on playback (e.g. checkmark crop function) 4) You can do it with .mkv container ("--cropping <TID:left,top,right,bottom>" in the command line using mkvmerge), but not all players will acknowldege it | ||||||||
| Ripper[47] posted 2008 Oct 27 15:37 | ||||||||
| O, thank you, jagabo, I tried DVDPatcher one more time and now it works!!! =)
By the way, I have some 1080p movie trailers and they are playing with grey line in the bottom. But they have H.264 codec and 1:2.35 aspect ratio. For example, new trailer to "Watchmen (2009)": http://wbads-02.vo.llnwd.net/e1/wbmovies/watchmen/video/WatchmenS ... T_1080.mov Any ideas, how to remove this line? | ||||||||
| jagabo posted 2008 Oct 27 16:17 | ||||||||
| For h.264 I use CoreAVC Pro which has an option to crop 1088 to 1080. | ||||||||
| Ripper[47] posted 2008 Oct 27 17:30 | ||||||||
| Yes, I know it, but many people take files from my computer, so I can't tell them all to install coreAVC and activate this option.
I am looking not for way to play file normally, but way to FIX file, that it could play normally with any player. | ||||||||
| jagabo posted 2008 Oct 27 19:16 | ||||||||
| I'm not aware of any equivalent to DVD Patcher for h.264 encoded files. |
Login/Register to our forum to be able to post here.