Shop OBEX P1 Docs P2 Docs Learn Events
Processing AVI, SWF, MPEG, or anything with propeller — Parallax Forums

Processing AVI, SWF, MPEG, or anything with propeller

rickszyrrickszyr Posts: 3
edited 2011-03-24 08:35 in Propeller 1
First, hello to everyone, i'm glad to see there's a big supporting community for this chip. I have worked with pics, for a very short time, and that's all my experience with microcontrollers.

I need to do something like what the title says, and was wondering if it was possible to do with this chip, for example, i want to create a video in my computer, and load it to an SD or directly to the properller, and play it on a simple 2" TFT screen.

Any guidelines, tips or hints?

Thank you in advance, and I hope I can contribute to the community some day :),

Rickszyr

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-03-22 21:26
    The Propeller doesn't really have the speed or memory to handle video files. There have been attempts to display sequences of bitmaps (.BMP) as video which did work, but the transfer rate from an SD card using the SPI serial interface is just barely high enough. Maybe someone else has some links.
  • rickszyrrickszyr Posts: 3
    edited 2011-03-22 21:31
    Mike, thank you for your fast reply/

    Do you know of any other "cheap" microcontroller that has this capabilities?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 21:51
    rickzyr:
    You should be able to due this with the aid of a large SRAM, or if you wish to code the refreshes and commands, SDRAM. I have used SDRAM in some projects using various low speed Microcontrolers, and you do not have to run 133MHz SDRAM that fast (you can get away with 1 Meg/sec burst rates, as long as you refresh often enough).
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 21:58
    Though if you must use an SPI device such as the SD cards you could boost the speed by using multiple devices and interleaving the data.
  • jazzedjazzed Posts: 11,803
    edited 2011-03-22 23:12
    User Dr_Acula demonstrated showing a nice video (reformatted) being read directly from an SD card.
  • RaymanRayman Posts: 14,877
    edited 2011-03-23 03:36
    To do a good job with video is just beyond the capabilities of Prop1 (without a lot of external hardware).
    But, I'm working on a Solomon based image co-processor (onboard jpg codec) for the Prop that will allow it to show high quality images or video on a 3.5" LCD (or other LCD).

    There are already Solomon solutions for the PIC.
  • rickszyrrickszyr Posts: 3
    edited 2011-03-23 10:58
    @davidsaunders,

    please explain a bit more?? I do not need to use an SD, but it would be useful, at least to load the video from it the first time. How would this work with an SDRam?

    @Rayman,

    Could you provide some examples? IE: what PIC, some samples of Solomon solutions, and also some websites with documentation or further info on the subject.

    Thanks
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 11:08
    With SDRAM, this depends on if you render the frames before loading them into the SDRAM or not. If not then use burst reads to load data into COG mem to be worked on (creating a single scan line of the output) and switch the function of two (or more) COGS so that this one displays the next scan line while the other reads in more data and generates the next scan line, or something similar. If it is already rendered than you can use the outputs from the SDRAM plus a line buffer to directly drive a resister DAC during a burst read. The second method is also a simple way to get around the BPP limits of a single cog video driver, and save pins on the Propeller (especially if you need the prop to do other things in the mean time).
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 11:13
    NOTE: With the second method you would be limited to the row length of the SDRAM for horizontal resolution, unless you want to due some dirty tricks to start a second SDRAM in a burst cycle in sync with the end of the first SDRAMs burst cycle. Also you would need to disable this output in the blanking periods, you would probably want to still use the Prop to generate the HSync and VSync pulses.
  • jazzedjazzed Posts: 11,803
    edited 2011-03-23 11:43
    davidsaunders wrote: »
    With SDRAM, this depends on if you render the frames before loading them into the SDRAM or not. If not then use burst reads to load data into COG mem to be worked on (creating a single scan line of the output) and switch the function of two (or more) COGS so that this one displays the next scan line while the other reads in more data and generates the next scan line, or something similar. If it is already rendered than you can use the outputs from the SDRAM plus a line buffer to directly drive a resister DAC during a burst read. The second method is also a simple way to get around the BPP limits of a single cog video driver, and save pins on the Propeller (especially if you need the prop to do other things in the mean time).
    @davidsaunders, I would appreciate it if you would write a driver for the GadgetGangster SDRAM board. If you create a driver that can display more colors simultaneously full screen than possible today using Propeller with complex bit-maps on a TV, I will send you a PayPal to cover the cost of the SDRAM board (not the PropellerPlatform motherboard). This "bar" is pretty high really, so make sure you understand the details while considering the proposal. A new thread may be necessary. You can PM me if you like.

    --Steve
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 12:49
    jazzed: (or any one).
    Do you have info on the capacitance, resistance of the lines on these boards? Or at least the maximum throughput from the SDRAM board? I am strongly considering this.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 12:50
    Though might have to wait a bit. It seems that Parallax is out of stock on the Gadget Gangster at this time, and I do not have one.
  • jazzedjazzed Posts: 11,803
    edited 2011-03-23 13:07
    davidsaunders wrote: »
    Or at least the maximum throughput from the SDRAM board? I am strongly considering this.
    Maximum throughput for the PropellerPlatform SDRAM board is about 5MB/s for 256 byte bursts.
    Check here for Propeller Platform http://gadgetgangster.com/find-a-project/56?projectnum=257
    Check here for SDRAM boards: http://gadgetgangster.com/find-a-project/56?projectnum=359
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 13:17
    Jazzed:
    Let me take some time to brush on NTSC and PAL video standards and then I will get back to you. Definitely seems possible. Hopefully I will be able to order these in the next couple of days (the Propeller Platform and SDRAM Module).
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 14:05
    Jazzed:
    Looking at the pin outs I think I could do this from a breadboard, and maintain 100% compatibility with the Propeller Platform (as there is nothing to the propeller platform, but an easy interface to the prop). I will be ordering the SDRAM Module as soon as I have the money to do so.

    I accept the challenge. Though I will pay for my own parts in this case. Thank you. I must admit some surprise when I first read your request, as I really did not think that any one still used NTSC/PAL for a display.
  • jazzedjazzed Posts: 11,803
    edited 2011-03-23 15:40
    davidsaunders wrote: »
    Jazzed:
    I accept the challenge. Though I will pay for my own parts in this case. Thank you. I must admit some surprise when I first read your request, as I really did not think that any one still used NTSC/PAL for a display.
    Good man :) Ok. If that's the way you like it, then I will not be obligated to redeem your purchase.

    For your driver to be a glorious success however, it must be MIT licensed and able to do better than the TV version of the driver described here and available in this Propeller zip package.

    The primary limit of that driver today is: it must use many duplicate tiles to fill the screen because of hub memory limits; your driver should not have duplicate tiles. So, every tile (screen area) must contain a different full-color image (up to 64 colors per tile). That driver also uses 1 COG to render the "mario" image and 3 COGS to draw sprites. I expect 2 COGs would be necessary to interact with SDRAM and render the background, so your solution should not exceed 5 COGs.

    I highly recommend your downloading the zip package and running the demo. That package could be a good framework for testing your driver.

    You should probably start another thread so the original poster can have their thread back.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2011-03-23 15:49
    jazzed wrote: »

    For your driver to be a glorious success however, it must be MIT licensed and able to do better than the TV version of the driver described here and available in this Propeller zip package.

    /me starts to sweat... Yup.. "Glorious Success" would be how I would describe it too. :)
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 16:00
    I started a new thread for this effort. It is titled "jazzed inspired NTSC/PAL Driver". Thank you for this challenge, It goes nicely with the other 2 Propeller projects I am working on (my VGA device, and the IDE).
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-03-23 19:53
    The Propeller doesn't really have the speed or memory to handle video files. There have been attempts to display sequences of bitmaps (.BMP) as video which did work, but the transfer rate from an SD card using the SPI serial interface is just barely high enough. Maybe someone else has some links.

    Would you believe that when it comes to SD read speed, propeller processing speed and the speed of the original movie, that the code is not too slow, not too fast, but just right?!

    http://www.youtube.com/watch?v=170HLfl6VfI&feature=feedu

    This is VGA but I am sure a TV version is possible.

    davidsaunders is a legend for accepting this challenge!

    Thinking in a broad sense, surely if we can pull data off an sd card fast enough to play a movie we can pull data off an external ram chip?

    And thinking more outside the square, see my recent post re experiments with "cogjects". These have the potential to free up lots of hub ram, and that means you can then use that ram for more video buffer space.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-23 20:00
    rickszyr:
    What kind of interface does the target TFT device provide?
  • RaymanRayman Posts: 14,877
    edited 2011-03-24 03:32
    Dr_Acula wrote: »
    This is VGA but I am sure a TV version is possible.

    It is possible, I did it a couple years ago:
    http://forums.parallax.com/showthread.php?116192-Prop-Video-Player-(now-with-audio!)&highlight=prop+video+player

    showed it at UPEW...
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-03-24 04:06
    Hey, nice work Rayman - you got audio working at the same time!
  • RaymanRayman Posts: 14,877
    edited 2011-03-24 08:35
    Dr_Acula, thanks.

    Actually, now that I think about it, if the idea is to display on a TFT with a controller chip with GRAM, then you can actually do a pretty good job.
    You just read the data from SD and put on GRAM. The hard part is doing it fast...
    I think with jazzed SDRAM and a TFT with 16-bit interface you could do a pretty good job.

    Still, this is uncompressed video data, which eats up memory fast. You can save uncompressed AV into a .avi file. I don't think it would be too hard to decode the AV stream, but I haven't tried that.
Sign In or Register to comment.