Video Player
Rayman
Posts: 14,738
It works!
Source code attached.
More info and program to create video is here: http://www.rayslogic.com/Propeller2/P2Video/P2Video.html
Source code attached.
More info and program to create video is here: http://www.rayslogic.com/Propeller2/P2Video/P2Video.html
zip
142K
Comments
But maybe just ok
I found it was easier when I did my video player in TAQOZ to grab frames from the original video, maybe initially as png, and then convert them to 320x240 BMPs on the PC that results in a 76kB frame. Then I joined those frames together in one file with a BMV extension on the SD card.
That way I can read them in fast enough into a separate buffer, flip them, and even double up the pixels and lines for full 640x480 at 30fps. There was enough time to have both double pixel and original with the position of the original 320x240 window anywhere superimposed over the larger 640x480 screen. btw, my SD routines can read at around 3MB/s at 300MHz.
However, I just had a quick dabble on TAQOZ and measured some speeds.
First off I execute just the .SPEEDS part of the full .DISK report.
TAQOZ# .SPEEDS --- *** SPEEDS *** LATENCY......................... 503us,250us,250us,268us,250us,307us,312us,296us, SECTOR.......................... 647us,407us,405us,423us,406us,463us,463us,451us, BLOCKS.......................... 3,148kB/s @300MHz ok TAQOZ#But is that really > 3MB/s? So I find a bmp I can open and just check the header first
Yep, that certainly looks like a bitmap file. Now I will time opening that file and normally I would say "VIEW MCQUEEN" but to time it I just break it down this way.
That's great, what was the file size?
I'll use the Forth, and calculate the average transfer rate over the time it took.
Only 2.5MB/s, but that was finding and opening the file etc. Once a video file is open I only need to read in a frame at a time so I will simply time that part of it using the full 640x480x8 BMP file. Essentially the SDRDS routine requires the starting sector, in this case the open file starting sector can be returned with @FILE. Then a destination in memory and I choose the BMP area which has some room for the header, then the palette and bitmap data, and then of course the number of bytes. Let's time that operation and calculate the effective read speed.
So that lines up nicely with what .SPEEDS reports and viewing the bmp actually involves reading just the header first, determining the offset to the palette and bitmap data, and then reading in the data offset to the BMP memory so that the start of the palette in the file ends up at the fixed start of the palette in memory after which I do a quick vertical flip which takes about 10ms. (BMV files don't need this alignment step).
The BMV video just uses lots of sequential 320x240 bmp frames.
So, how do you do it?
I’d like to see how you do that...
3mb/s would make it much nicer...
' Read bytes in from SPI to memory ' SPI>BUF ( dst cnt -- sum ) (46,121 cycles) SPIRX wrfast #0,b mov b,#0 .L0 rep #5,#8 ' 8 bits outnot sck ' clock (low high or low high) rcl r1,#1 ' shift in msb first (first dummy zero) outnot sck nop testp miso wc ' read data from card rcl r1,#1 ' last bit wfbyte r1 djnz a,#.L0 jmp #DROPJust retesting that speed.
If you're using a sortof-custom file format anyways, why not just flip the frames before/while encoding? 10ms seems pretty long to me.
It can also do the vertical flip...
That 10ms is for viewing any random 640x480 bmp image but the bmv file doesn't need it and besides, the bmv frames are much smaller at 320x240.
This is the one line that reads the bmv frame backwards into memory after the frame is loaded and the palette is setup. (It takes about 1ms)
Since the frame is not the same size as the display it can't just block move the whole frame in one go anyway, so there is no advantage in having it flipped beforehand.
a 640x480x8bpp Slide Show with audio should be easily doable.
You could, for example, learn about doing things with your P2 using your P2...
Could probably extend to 1080p using HyperRam...
Here's the challenge - FULL SCREEN VIDEO (from SD) IS IMPOSSIBLE!
I expect that will be possible with SD mode access to SD cards at standard VGA resolution. Maybe there could be some very lightweight compression techniques that could be used (with multiple COGs) to improve the resolution when reading from the SPI mode SD cards too, if pre-processed accordingly beforehand. Eg Perhaps 4:2:2 expansion could be done on the fly with multiple COGs if the input format is already in a good state for doing this work?
Playback from external memory with double buffers may help eliminate tearing as well, and you could sync the flip on a frame boundary. You can construct one frame while displaying another (which you can't do in hub RAM) at VGA resolution.
If there isn't a buffer it involves exchanging top and bottom and moving inwards to the center (or vice versa).
While Secure Digital mode is licensed, there is a 4-bit SD mode that could be made use of, but do we have enough information on that for us to write a driver? I'd like to but that also means I have to have another SD card socket connected in 4-bit mode which I could do on my P2LAB.
I was able to achieve SD mode reads in my own dedicated FPGA engine implementation on the P1V using snippets of data sheets, code samples, scoped timing info etc I dug up online, but it is hard to locate all required information in one place unless you were to signup to become a member of SD org or whatever you need to do. You can get the basic command overview in the publically available pdf's you can locate online. How easily it translates over to P2 instructions and streamer commands and how many COG's you may need I'm not sure. It would still be useful to have some HW around for people to experiment with, with all 4 DAT lines connected.
Well it's a reminder for me while I finalize some new artwork to have the extra full-size SD card slot connected up using all its pins so we have the option of 4-bit mode. Of course I would arrange the 4-bit data in order but probably P48 up though as P32 has HyperRAM.
Ok, I won't say anything more about it here, so I will take a look at it on the other thread. I also happen to have my clock generator available so I can generate the same clock with a controlled phase.
Looks like this:
typedef struct P2V_HEADER { //Some of this is just for future use. This plus wav and bmp headers will be dumped into the first 512 Byte sector char PIFF[4]; // PIFF Header Magic header unsigned long p2_videotype; //Type of video (1=regular,2=presentation) unsigned long p2_framerate; //frame rate unsigned long p2_numFrames; //# of frames in video unsigned long p2_width; //width of video unsigned long p2_height; //height of video unsigned long p2_bitsperpixel; //bpp of video (has to be 8?) unsigned long p2_NumOfChan; // Number of channels 1=Mono 2=Sterio unsigned long p2_SamplesPerSec; // Sampling Frequency in Hz unsigned long p2_SamplesPerFrame; //# audio samples in each frame, should be= (Samples/sec)/(Frames/sec) unsigned long p2_VideoBlocks; //#512 Byte sectors in each image unsigned long p2_AudioBlocks; //#512 Byte sectors in each audio sample between images unsigned long p2_WavHeaderOffset; //offset to wave header in this block unsigned long p2_BmpHeaderOffset; //offset to bmp header in this block (just first 54 bytes) unsigned long p2_TitleOffset; //offset to Title string unsigned long p2_DescriptionOffset; //offset to Description string }p2v_hdr;Looks like this (see attached):
Regarding video compression: I think I've brought it up before, but back in the 90s, Cinepak video compression was used to play low-res, low FPS videos off single-speed CD-ROM with the contemporary double digit MHz CPUs. I wonder if that scales to the P2 with high speed SD.
Wondering if P2 can do that in real-time ...
Meanwhile, I’m having trouble getting audio perfect... think I need bigger buffers..