timvideos / HDMI2USB-litex-firmware

A version of the HDMI2USB firmware based around LiteX tools produced by @Enjoy-Digital (based on misoc+migen created by @M-Labs)
https://hdmi2usb.tv
BSD 2-Clause "Simplified" License
143 stars 70 forks source link

Figure out what the contents of `gateware/encoder/vhdl/header.hex` is #297

Open mithro opened 7 years ago

mithro commented 7 years ago

What is this file? How was it made? etc....

akhil-123 commented 6 years ago

'gateware/encoder/vhdl/header.hex' specifies the initial content of a memory block rambyte in the file (https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/encoder/vhdl/JFIFGen.vhd) , that is, the initial values for each address. One can see the initializing of memory block in - https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/encoder/vhdl/JFIFGen.vhd Where "initial $readmemh("header.hex", mem) " initializes the memory. Now this memory is assigned to q and ram_bytes in the JFIFGen.vhd(https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/encoder/vhdl/JFIFGen.vhd) is assigned to q.
So basically header.hex is basically initializing the the memory. Process for creating hex file is as follows: We compile Verilog to RTL netlists, then synthesize Verilog to EDIF, then place and route EDIF to produce HEX files that can be loaded into an FPGA. So this hex file might be created in the same way.

GitHub
timvideos/HDMI2USB-litex-firmware
HDMI2USB-litex-firmware - A version of the HDMI2USB firmware based around LiteX tools produced by @Enjoy-Digital (based on misoc+migen created by @M-Labs)
GitHub
timvideos/HDMI2USB-litex-firmware
HDMI2USB-litex-firmware - A version of the HDMI2USB firmware based around LiteX tools produced by @Enjoy-Digital (based on misoc+migen created by @M-Labs)
mithro commented 6 years ago

@akhil-123 Yes, we understand what readmemh() does in Verilog. What we don't understand is the contents of this file. See the title of this bug.

I think this is probably something like a JPEG header or something?

akhil-123 commented 6 years ago

This header.hex file is a JPEG/JFIF file (minimal file format which enables JPEG bitstreams to be exchanged between a wide variety of platforms and applications) in which the contents are as follows:

  1. At the starting of file we can see the values FF and D8 which is the start of image marker(SOI).
  2. After that in the 3rd and 4th line FF and E0 are written indicating a JFIF App0 application marker.
  3. The next two bytes 00 and 10 tell us the APP0 sgement length followed by the five byte values 4Ah 46h 49h 46h 00h (JFIF).(If these values are found, the SOI marker (FFh D8h) marks the beginning of a JFIF data stream).
  4. The next two bytes 01 01 indicate the version of JFIF specification.
  5. Next three bytes indicate Units, Xdensity and Ydensity( unit of measurement used to describe the image resolution). Since Unit field is 00 it indicates that take the measurement as pixel aspect ratio = Ydensity:Xdensity. Xdensity and Ydensity are the horizontal and vertical resolution of the image data, respectively. Unit field is followed by two bytes of Xdensity and 2 bytes of Y density.
  6. Now line 19 and 20 indicate Xthumbnail (Horizontal pixel count of the following embedded RGB thumbnail) and Ythumbnail (Vertical pixel count of the following embedded RGB thumbnail).
  7. Lines 21 and 22 have values FF and C0 indicating the start of frame (Indicates that this is a baseline DCT-based JPEG, and specifies the width, height, number of components, and component subsampling ). Now in the whole file wherever we found the values mentioned below they indicate following things
    • FF , C4 together one after another defines a huffman table.( lines - (178 and 179) , (211 and 212), (244 and 245), (427 and 428) ,
    • FF , DB together one after another defines a quantization Table.(lines - (40 and 41) , (109 and 110) ,
    • FF , DA together one after another defines the start of scan.( Begins a top-to-bottom scan of the image)(lines 610 and 611)

But In the header.hex file i could not find the EOI (end of image) marker which is FF D9. I think it should be present in the file.

mithro commented 6 years ago

@akhil-123 Would you be interested in writing up a small Python program which uses the either struct module or struct support in the ctypes module (probably combined with the hexfile module) to read/write this data?

akhil-123 commented 6 years ago

Yeah, I will try my best to finish it as soon as possible.

mithro commented 6 years ago

@akhil-123 No hurry!

FYI You should come and join us in our IRC chat room [irc://irc.freenode.net/#timvideos] if you haven't already! A web based client is available here.

akhil-123 commented 6 years ago

can u increase the description on what these read and write operations should do ?