60 fps video using SIDE 2

[leech]

Ah, you've got that backwards, my 1080p version of the episode is 1.2GB in size. after doing the earlier mencoder you mentioned, the video was 14.4 GB, so much larger, and VLC couldn't play it.

 

I'll give the conversion a try later when I get home. Really want to show off an Atari 8bit playing Firefly...

[a8isa1]

oh yeah. the raw video file (.MOV in example) is really big. 10X bigger than the source file, at least. That's when the source is 720p or lower resolution. All conversions are getting downscaled to 160x192, but that's YUV raw frames. At 60 (or 50) fps it's a lot of data.

Edited September 6, 2017 by a8isa1

[leech]

Hmm, maybe what we should come up with is a handbrake profile for ripping 8bit movies? Should work in both Windows / Linux / iFruit.

[Mathy]

Hello guys

 

Maybe this is what leech is trying to say, but....

 

If a movie is converted to "8 bit Atari", does this result in 25/30 full pictures per second? Why use 50/60 pictures, the Atari only shows 25 or 30 per second?

Or are only the changes stored? Since picture #2 overrides picture #1, it would/should be possible to store only the differences between picture #2 and picture #1 in picture #2.

 

Sincerely

 

Mathy

[leech]

Nope, all I was trying to figure out was why a 1080p video converted into a 160x192 video was so huge! And asking if anyone has tried to create a handbrake profile so if I wanted to do a direct DVD/Bluray rip to this Atari format, it'd be pretty much just clicking on a few buttons and waiting.

 

I work with a bunch of nerds and I think showing this off to them would make them a bit happy. I already sent the link to one of the guys I work with and he was mightily impressed.

[phaeron]

If a movie is converted to "8 bit Atari", does this result in 25/30 full pictures per second? Why use 50/60 pictures, the Atari only shows 25 or 30 per second?

Or are only the changes stored? Since picture #2 overrides picture #1, it would/should be possible to store only the differences between picture #2 and picture #1 in picture #2.

 

The player requires full frame rate (50/60) for two reasons: it has no frame repeating capability, and the audio is interleaved with the video. Repeating frames to run at a lower frame rate would require more complex audio buffering. There is a benefit to running at 50/60 even if the source material is only 24/25/30Hz: the encoder does temporal dithering, changing the dither pattern each frame. This is not feasible at lower frame rates since the flicker would be objectionable.

 

The stream is not delta encoded, it's all full video frames. There's no time to do that -- ANTIC is literally reading each frame straight out of the IDE port. Remember, the video runs at 509KB/sec. There's no time to do anything with the data, because it's coming in faster than the 6502 can process it.

 

A whole movie will indeed take an awful lot of space for conversion. 160x192 in YV12 at 59.92Hz takes 2.7MB/sec, or 165MB/min. It is possible to run pipes to avoid having to store the intermediate streams, so that everything goes through memory and all that comes out is the final video. The final output will still take 31MB/minute. But hey, now you know why video and audio compression are necessary.

[Poison]

is possible to add some functions to the player? such as forwarding, pause, repeating, jump (for example) over 500 frames ? When I convert full movie (2 hours) or more parts of some sitcom I still must watch it from begin

[Wrathchild]

Literally there is very little time to do anything else but there is some hope.

Last year I'd asked phaeron when considering if an engine to fit around the Dragon's Lair video was possible and the reply was:

"The problem with opening up CPU time is that the player needs to write to AUDF1+WSYNC on every scanline in order to handle streaming audio. That having been said, there's about 47 scanlines in NTSC where the player is just pushing samples from a buffer and waiting for the next frame, so that's enough to run simple game logic. If you can get the game logic simple enough, simply run the transition test on every frame and drive it off a state machine for the branch points. If you need more complex game logic, then consider writing a VLIW bytecode interpreter where the interpreter runs a handful of the same generic opcode every frame, like: IF variable[branch] THEN variable[dst] = (variable[src] AND and_value) + add_value. The trick is to make the PC one of the variables so stores and conditional stores serve as jumps and branches. Running the same generic instruction allows the timing to be kept consistent, which is important to avoid a 50/60Hz hum in the audio output."

[+Philsan]

 

Video file: https://www.dropbox.com/s/28gmoc1fab3xr52/Philsan_Goldrake.img?dl=0

[+mytek]

 

Wow the quality looks really good. Can you post the video file (perhaps a shared file in DropBox)?

 

- Michael

[+Philsan]

 

Wow the quality looks really good. Can you post the video file (perhaps a shared file in DropBox)?

 

- Michael

Done!

[+mytek]

Done!

 

Either I'm missing a well hidden download link or perhaps you forgot to add it .

 

I'm away from my stuff for the weekend so whatever the situation is, no rush.

 

- Michael

[+Stephen]

 

Either I'm missing a well hidden download link or perhaps you forgot to add it .

 

I'm away from my stuff for the weekend so whatever the situation is, no rush.

 

- Michael

Link is in post #209

[+mytek]

Link is in post #209

 

I must have gotten distracted by the video, but now I see it. Thanks Stephen, and thanks Philsan for posting it .

 

- Michael

[flashjazzcat]

Is there any way we could get the frame size including audio down to 8192 bytes? I realize this would upset the tool chain somewhat, but if we could fit each frame into sixteen sectors, we could put the video files into a FAT partition with an 8KB cluster size. The player could then build a table of sector offsets prior to commencing playback, and the player would just need to pull sector numbers from the list instead of bumping the sector number by 17 each frame.

 

Thoughts?

[phaeron]

Don't have the source in front of me right now, but IIRC the main frame is 128 bytes per 3 rows. No time during active display to change the format of those rows, but cutting off 12 scans should do it.

 

Playback on standard 4K clusters would also work as long as the file was defragmented. The Contig.exe utility can be used to defragment a single file on Windows.

[jmccorm]

Literally there is very little time to do anything else but there is some hope.

Last year I'd asked phaeron when considering if an engine to fit around the Dragon's Lair video was possible and the reply was:

 

"The problem with opening up CPU time is that the player needs to write to AUDF1+WSYNC on every scanline in order to handle streaming audio. That having been said, there's about 47 scanlines in NTSC where the player is just pushing samples from a buffer and waiting for the next frame, so that's enough to run simple game logic."

 

I own a Dragon's Lair, so this is something I can chime in on:

 

You're in good company! Dragon's Lair has been ported, at last count, to 36 platforms.

Some thoughts...

 

1. A scene is comprised of a video, and one or more decision points. A correct decision may simply allow the video to continue to play normally, but sets the stage yet another decision window. Or a correct decision may allow the video to play out before switching to the next scene. An incorrect video is a death scene (which should decrement lives and possibly GAMEOVER, or go to a rebirth and branching point depending on progression).

 

2. When the video changes (bad player move, sometimes a correct player move, the player failed to make a move, or the player made it until the end of that video sequence), stop the video. You have all the time in the world to fully run any game logic you like. The real arcade would blank the screen for a number of frames as the Laserdisc player would seek to the next clip [unless the next scene was immediately next on the disc].

 

3. Before you load a new video, set up all the structures for the available decisions, times, and options in advance so that it is very easy for your code to evaluate each decision point and move onto the next one. Again, you should have all the time in the world to do this.

 

4. Decide if you are going to buzz or flash on an input that is invalid but is not deadly (like the arcade does) Also for the "boop" when a user makes a good decision.

 

5. In the main game loop, if there is no player input, then there is no game logic to evaluate, except to see if the clock has expired (triggering a missed decision or the end of a scene). Simple! If you do have user input to process, and you can't can't completely process everything in one frame, I seem to think that the arcade wasn't always so immediate, either.

 

6. If you're not decoding the exact game structure and data from ROMs, then be sure to visit the Dragon's Lair Project to get an idea for scene sequencing, walkthrough (deadly inputs, correct inputs, and inputs which buzz) at which points on what scene, scores. They should be a good overall resource.

 

7. If you get things totally working, consider repeating with the Dragon's Lair Enhancement ROM behavior which uses the same laserdisc, but look and feels a lot better than the original arcade ROMs. They consider it to be redistributable if you include their text file.

 

Hope this helps. If you've got a full video player and a relatively small number of cycles each frame to handle logic, I think that Dragon's Lair could work out almost perfectly on the Atari 8-bit.

[a8isa1]

Phaeron, I can't even pretend that I fully understand how your movie player works but it seems to be able to do "any point, any color".

 

Would it be possible to adapt the player to display static images?

 

To be able to access a catalog of images would be preferable to just a slide show.

[phaeron]

No need, it's just APAC with alternating mode 9 and 11 lines -- plenty of software to author and view already. The video player just adds streaming audio and changing the entire framebuffer every frame. For a static image you can just load the required ~16K of data through DOS.

[+CharlieChaplin]

If you want to display original APAC images, attached are some viewers. But there are many variations of Gr. 9 +11 pictures besides APAC, e.g. AP-2, AP-3, APP, PZM, DGP, ESC, 256, COL+LUM, BGP, BGA and many others. (And all of these Apac / Gr. 9+11 variations do have their own viewer.)

 

The viewers have been tested under DOS 2.5 and Turbo-DOS XL/XE, however on the disk image you will find MyDOS, so you have to test yourself if they work fine there (and if some of them do support subdirs or not). Most APAC viewers do require the extender *.APC or *.APA to display the pictures, for some the extender does not matter...

 

ApacVw.zip

Edited May 19, 2018 by CharlieChaplin

[Lastic]

Noob observation here, first off once again, amazing what has been done on this 8 bit hardware.

 

I've ran all the examples in Altirra and was flabbergasted .

 

I don't own any SIDE (1/2) or MyIDE device , only the AVGcart and UnoCart with my PAL 130XE.

 

When I boot up the MOVPLAY.XEX on the AVG Cart , it throws the IDE command error: D1D1 D1D1D1D1 obviously but when I boot it on the UnoCart (nothing else attached) it is ready for playback and the LED activity indicates that it tries to load something.

 

Could this mean it would be possible to use the UnoCart somehow ?

[flashjazzcat]

Could this mean it would be possible to use the UnoCart somehow ?

Not with the existing UNO cart MCU firmware. I'm working on firmware which allows use of the SD card as a general purpose APT hard disk (via U1MB or a version of the SIDE driver), but I doubt even this will provide sufficiently low seek latency for Avery's movie player. You need a true IDE device, i.e. SIDE, XEL-CF, Incognito, etc.

[+CharlieChaplin]

Well,

 

AVFplay, a great videoplayer, became available for the AVG-cart. with firmware update 15. Now AVG cart. can also play these 50fps (PAL) or 60fps (NTSC) videos.

 

I have downloaded all videos from this thread and played back all PAL videos on my 800XL computers. Looks like all videos use Gr. 9+11 (APAC or similar) for 256 colours. While 256 colours are really nice, the 80x96 pixel (or 80x100 pixel) resolution is quite low...

 

Would be cool to also have some videos with less colours, but therefore higher resolution, e.g.

 

1) Gr.15 PAL-blending with up to 16 colours (4 col. x 4 lum., e.g. RGBB for red, green, blue and black each with 4 lum.) or

2) for the good old b+w movies we could use Gr.9+Gr.9 or HIP (greyscales only!) for 16 - 31 greyscales;

3) think CIN, which is Gr. 15 (4 lum) combined with Gr. 11 (16 colours) could give good results and up to 64 colours for cartoons and animes, whereas

4) Gr. 15 (4 dark lum.) combined with Gr. 10 (col.) for up to 36 colours or

5) the other way around Gr. 15 (4 col.) combined with Gr. 10 (8 dark lum.) for up to 32 colours could be used for some movies...

6) maybe other modes also ?

 

But most of all, the modes 1) - 5) can work with 160x200 (160x240) pixels and thats a "much" higher resolution than the currently used Gr. 9+11 mode. Thinking of that converted b+w Laurel & Hardy video, the 256 colour mode is a little overkill here, grayscales would be enough and for some cartoons or animes we could surely live with less colours but higher resolution ?!?

[Wrathchild]

I haven't contributed here for a while, so here's PAL and NTSC videos of something over 20 years old now

Some sneak peeks:

 

 

 

 

 

 

half_life_ntsc.zip

half_life_pal.zip

[Guest]

okay, am getting a couple of errors

 

half_life_pal.zip

half_life_pal.zip: unknown method in half_life_pal.img

half_life_pal.zip: no files to extract

 

half_life_ntsc.zip

half_life_ntsc.zip: unknown method in half_life_ntsc.img

half_life_ntsc.zip: no files to extract