Prevue Guide Forums

AriX wrote:

swest77 wrote:Thanks kindly! Any reason why you included non-virgin copies of curday.dat and nxtday.dat, though? Not that I'm worried you "did anything" to them; just thinking about the possibility of any cached data having been flushed by PG from them if they're from a "used" ADF.

No, he's saying that the only data that could have possibly changed on a modified ADF is those two files, and that all the others would be the same... He's just asking you why you want the other files in addition to those two, since the other ones are all the same.

Oh! Sorry, LocalH. My mistake. "the only two that should be different from the original image" sounded like "copies are not from the unmodified ADF".

And as far as the reason I asked for all of them: was just too stupid/lazy to figure out how to unpack them under Winblows myself. And since others here had that ability right at their fingertips, well...

AriX wrote:

swest77 wrote:@Ari - Yes, during the beta period, the vertically windowed MPEG feed ran on another transponder, separately from the horizontally-windowed analog feed for the Amigas. Basically two different incompatible Prevue Guide systems/infrastructures overlapping in time.

Cool Do you think that before the TV Guide rebrand, the NT platform they were working on was Prevue branded? Would be cool to have that prototype software :O

Yes, and yes it would.

By the way, anyone have any insight into what exactly TV Guide Around Town and Prevue Around Town were, and how they played unique ones in different locations?

MPEG-2 transport streams can contain multiple program streams. See http://www.lyngsat.com/galaxy12.html for examples.

Well, I was going to make a video showing off some of this new stuff for YouTube, but I'm having problems getting WinUAE to output anything more than a 5.5KB AVI with nothing in it. I don't want to use anything other than lossless compression, so I tried HuffYUV (well, ffdshow's HuffYUV encoder) and raw uncompressed video, with no results. I've gotten video out of WinUAE in the past, I wonder what I'm doing wrong.

Cool discovery tin! I also noticed that the grid stopped every now and then, a feature which I thought had been removed after the TVG rebrand.

swest77 wrote:

By the way, anyone have any insight into what exactly TV Guide Around Town and Prevue Around Town were, and how they played unique ones in different locations?

MPEG-2 transport streams can contain multiple program streams. See http://www.lyngsat.com/galaxy12.html for examples.

Supposedly they had this during the Amiga ages too, though...

LocalH wrote:Well, I was going to make a video showing off some of this new stuff for YouTube, but I'm having problems getting WinUAE to output anything more than a 5.5KB AVI with nothing in it. I don't want to use anything other than lossless compression, so I tried HuffYUV (well, ffdshow's HuffYUV encoder) and raw uncompressed video, with no results. I've gotten video out of WinUAE in the past, I wonder what I'm doing wrong.

Attached settings work for me.

The problem is my pathetic 2 GHz single core can't keep up.

With compressed video, my CPU is driven beyond the pale.

With uncompressed video, its ATA interface is solid bottlenecking.

Either way, the emulator can't keep the software running at full speed. The scroll is slow, the clock is slow, etc. Upon playback, the video still plays at normal speed (i.e. scroll speed and time clock progression is accurate), though because everything happened in slow motion during record, my typing looks incredibly fast.

Guess it's best to capture with a fully modern quad core fireball PC.

Video demo (though using ffdshow XVID codec instead of uncompressed -- can't upload 200 MB for a few seconds of video, now can I? ): http://www.megaupload.com/?d=XLYWNEPS

Edit: Incidentally, am also using (under chipset, if this makes any difference) Full ECS, [x] NTSC, (x) Cycle-exact.

Well, you can help your situation by disabling cycle-exact - this software doesn't seem to use any weird assembly optimization, being coded in C. I also recommend that you set line mode to Normal - the screen will look half-height, but that's because you're seeing the individual fields. This will avoid the situation where doubled mode gives you 60fps but there is still combing since the Amiga is running in an interlaced mode. You can use a scripting language called AviSynth in conjunction with something like VirtualDub to weave the fields back together into frames.

LocalH wrote:Well, you can help your situation by disabling cycle-exact - this software doesn't seem to use any weird assembly optimization, being coded in C.

That part of the whole equation is beyond my Amiga knowledge, so thanks. Done.

I also recommend that you set line mode to Normal - the screen will look half-height, but that's because you're seeing the individual fields. This will avoid the situation where doubled mode gives you 60fps but there is still combing since the Amiga is running in an interlaced mode. You can use a scripting language called AviSynth in conjunction with something like VirtualDub to weave the fields back together into frames.

Ah, AviSynth, how I dread learning to use thee. What you say would work, however I suspect it would only look pretty if one used 4:4:4 lossless, or at the very least, 4:2:2 compressed capturing. 4:2:0 compressed capturinng already looks like shit when capturing raw computer graphics on account of the 50% vertical/horizontal chroma resolution, and interlaced 4:2:0 makes things worse by giving you effectively 60 luma movements/second but only 30 chroma movements/second when the recording is watched on an interlaced display device (due to scanline interleaving into what are really progressive frames running at half the field rate) ... which sometimes also creates problems with fields not having the correct chroma. Anyway, if this were captured at 4:2:0 without WinUAE's line doubling, then, if I'm picturing this correctly in my mind, one would be trading away the mismatched luma/chroma frame rate for even uglier vertical chroma resolution (per encoded frame, vertical lines 1 and 2 -- actually scanlines 1 and 3 -- would share chroma). Then when you go to do what you're saying, (hopefully with nearest neighbor scaling from 704x240 to 704x480! ), a second dose of 4:2:0 would become inevitable, averaging actual scanlines 1 and 2's color, but then 3's and 4's, and 3's being 1's ... well color would start looking mighty smeared vertically I think. (If I'm wrong here, note it's because my head is starting to explode. )

Anyway, if video quality is at stake, keeping things 4:4:4 (or at least 4:2:2) for the initial encode would solve all the vertical/temporal chroma issues by simply avoiding them.

PS - Along with eliminating cycle-exact and ditching line doubling, things got just fast enough to almost keep up. Looks like I'd still need a faster machine yet to capture on. No big deal though: I'll just watch your videos.

swest77 wrote:Anyway, if this were captured at 4:2:0 without WinUAE's line doubling, then, if I'm picturing this correctly in my mind, one would be trading away the mismatched luma/chroma frame rate for even uglier vertical chroma resolution (per encoded frame, vertical lines 1 and 2 -- actually scanlines 1 and 3 -- would share chroma). Then when you go to do what you're saying, (hopefully with nearest neighbor scaling from 704x240 to 704x480! ), a second dose of 4:2:0 would become inevitable, averaging actual scanlines 1 and 2's color, but then 3's and 4's, and 3's being 1's ... well color would start looking mighty smeared vertically I think. (If I'm wrong here, note it's because my head is starting to explode. )

Anyway, if video quality is at stake, keeping things 4:4:4 (or at least 4:2:2) for the initial encode would solve all the vertical/temporal chroma issues by simply avoiding them.

Well, I won't really be doing any vertical scaling (only horizontally, with bilinear filtering, to preserve a fairly accurate Amiga pixel aspect ratio), I'll just be weaving the individual fields together, and I will be using 4:4:4 (I plan to download the actual HuffYUV codec instead of using ffdshows, and I am upgrading from the 2.0.something beta I had previously downloaded on this machine a long while back, to the release 2.1.0, hopefully the two combined will allow me to capture video). If you use HuffYUV and configure it to use RGB colorspace instead of YUY2 or YV12, then it is lossless, and it's a very fast codec that just might bring you back into the realm of capturability (is that even a word? lol).

There is another lossless codec out there called Lagarith, but I'm not that well-versed with it. I do understand it to be significantly slower, but produces smaller files, so whichever is your primary bottleneck would determine whether to use HuffYUV or Lagarith.

Edit: And STILL a 5.5KB AVI. I hope it's not an incompatibility between WinUAE and either Windows 7 or the fact that it's a 64-bit OS. I have proper 32-bit codecs installed, and I'm not using the preliminary 64-bit WinUAE beta, although I do have it...damnit. I may have to wait until I can get the software onto my A2000 and capture from it onto a DVD recorder (yay for yummy Y/C goodness with my SuperGen 2000S ). I'll be doing that anyway, but if I can't get this to actually output the AVI, then that'll be my only option.

Running in E-UAE in Arch Linux:

http://wlair.us.to/remote/prevue/

[2011-08-29T23:39-0500] Update: Updating URI

woddfellow2 wrote:Running in E-UAE in Arch Linux:

http://wlair.us.to/prevue/

I lost the game. :/