I've created a new video format, please include it in VLC
Posted: 28 Jan 2017 10:17
I am hoping the VLC developers will be willing to add the video container format I've created to VLC. Below is an explanation of the very simple video format.
My video format has the file extension BVF, which means Ben's Video Format. It has a VERY small header (smaller than any other video format including popular ones like AVI). It's a container format, not a codec or compression format. The tiny header contains only 9 fields. Note, that this is literally a VIDEO container (not a "video" file like AVI which can contain both video and audio streams), meaning that it has no audio capability (at least not in the current version of the format which is 1.0), and also note that it has no capability to hold compressed video (at least not yet). What it does have though is the ability to hold much higher bit depth than any other video format. It can use either 8 bits per color channel or 16 bits per color channel. In fact, I created this format specifically because no other video format that I could find could handle 16bits per channel image data, and I needed that capability for scientific raw data that had a high bit depth (specifically raw thermal data from a FLIR thermal imager), for which I needed to be able to store 16bit grayscale video frames.
Realizing though that I shouldn't be creating a container format only suited to scientific equipment, if I wanted it to become a mainstream video container format, I decided to make support both 16bit and 8bit per channel, and support up to 4 color channels, not just 1. Below is the full specification of this format.
Note that in all cases of multibyte values, the endianness is little endian (makes it easier to work with on Windows PCs, which is where I've been doing all of my software development).
Overall file structure:
Header
Frames
Header:
string FileID = "BVF " //Yes there is a space after the "BVF" here so as to make it occupy 4 bytes.
unsigned int32 Width
unsigned int32 Height
unsigned int16 NumberOfChans //Valid values are 1, 3, and 4 where the 4th channel is unused, as I don't intend to support alpha channel.
unsigned int16 BytesPerChan //Valid values are 1 and 2. //Even with 4 channels, 2 bytes per channel is allowed
unsigned int32 FrameCount
unsigned int16 FrameRateN //This is the numerator of the frame rate.
unsigned int16 FrameRateD //This is the denominator of the frame rate
unsigned int32 unused //This is unused in the current specification, but exists so that I can, at some later time, add more features to the container.
As you may have noticed, there is an unused field here (literally called "unused" in fact). This is version 1.0 (the current version, as of me writing this) of this container format, and for this version (which does not have an extended header, or any other features), the "unused" field shall remain 0. Any other value will indicate version 2.0 (who's specifications I've not even created yet). I'm not exactly sure how that field will be used yet, whether it will hold a file offset to an extended header (which will then hold values indicating what other features are present), or whether the "unused" field itself will be a flags field that will indicate which additional features are present (each of which might have their own header).
Note that in the current version, 1-color-channel video format does not mean paletteized color video. It means grayscale video (which can be either 1byte-per-pixel or 2bytes-per-pixel).
Also all 6 possible combinations of NumberOfChans and BytesPerChan are valid. Unlike some kinds of image formats where certain bitdepths are permitted only for certain numbers of color channels (only the most likely used combinations are valid), all 6 combinations are valid in this format. This means that a valid player must handle all 6 possible combinations.
Frames:
Raw video data goes here. The format of the frames is specified in the header. All frames are directly placed one after another. There's no frame header before each frame like in AVI files where each frame starts off with something like "00dc".
For 3 bytes per channel, the color channel order is R G B. For 4 bytes per channel, the order is R G B X, where X means unused (and should remain 0, though it doesn't have to as a valid player will simply ignore the 4th color channel). Note that this differs from the BMP and AVI color channel order which is B G R (for 3 channels) and B G R X (for 4 channels).
Unlike other video container formats (such as AVI), this format does not use an index. Because it (in its current version) does not support anything other than raw (uncompressed) RGB or grayscale video, there's no possiblity that each frame will have a different size. Instead, one can calculate the file offset of the video by simply knowing the current frame number, the number of color channels, and the number of bytes per color channel. Frames are numbered starting at 0. The calculation is as follows.
SizeOfHeader = 28
SizeOfFrame = Width * Height * NumberOfChans * BytesPerChan
OffsetToFrame = FrameNumber * SizeOfFrame + SizeOfHeader
So again, my request to the developers of VLC is for you to include BVF playback capability in a future version of VLC player.
My video format has the file extension BVF, which means Ben's Video Format. It has a VERY small header (smaller than any other video format including popular ones like AVI). It's a container format, not a codec or compression format. The tiny header contains only 9 fields. Note, that this is literally a VIDEO container (not a "video" file like AVI which can contain both video and audio streams), meaning that it has no audio capability (at least not in the current version of the format which is 1.0), and also note that it has no capability to hold compressed video (at least not yet). What it does have though is the ability to hold much higher bit depth than any other video format. It can use either 8 bits per color channel or 16 bits per color channel. In fact, I created this format specifically because no other video format that I could find could handle 16bits per channel image data, and I needed that capability for scientific raw data that had a high bit depth (specifically raw thermal data from a FLIR thermal imager), for which I needed to be able to store 16bit grayscale video frames.
Realizing though that I shouldn't be creating a container format only suited to scientific equipment, if I wanted it to become a mainstream video container format, I decided to make support both 16bit and 8bit per channel, and support up to 4 color channels, not just 1. Below is the full specification of this format.
Note that in all cases of multibyte values, the endianness is little endian (makes it easier to work with on Windows PCs, which is where I've been doing all of my software development).
Overall file structure:
Header
Frames
Header:
string FileID = "BVF " //Yes there is a space after the "BVF" here so as to make it occupy 4 bytes.
unsigned int32 Width
unsigned int32 Height
unsigned int16 NumberOfChans //Valid values are 1, 3, and 4 where the 4th channel is unused, as I don't intend to support alpha channel.
unsigned int16 BytesPerChan //Valid values are 1 and 2. //Even with 4 channels, 2 bytes per channel is allowed
unsigned int32 FrameCount
unsigned int16 FrameRateN //This is the numerator of the frame rate.
unsigned int16 FrameRateD //This is the denominator of the frame rate
unsigned int32 unused //This is unused in the current specification, but exists so that I can, at some later time, add more features to the container.
As you may have noticed, there is an unused field here (literally called "unused" in fact). This is version 1.0 (the current version, as of me writing this) of this container format, and for this version (which does not have an extended header, or any other features), the "unused" field shall remain 0. Any other value will indicate version 2.0 (who's specifications I've not even created yet). I'm not exactly sure how that field will be used yet, whether it will hold a file offset to an extended header (which will then hold values indicating what other features are present), or whether the "unused" field itself will be a flags field that will indicate which additional features are present (each of which might have their own header).
Note that in the current version, 1-color-channel video format does not mean paletteized color video. It means grayscale video (which can be either 1byte-per-pixel or 2bytes-per-pixel).
Also all 6 possible combinations of NumberOfChans and BytesPerChan are valid. Unlike some kinds of image formats where certain bitdepths are permitted only for certain numbers of color channels (only the most likely used combinations are valid), all 6 combinations are valid in this format. This means that a valid player must handle all 6 possible combinations.
Frames:
Raw video data goes here. The format of the frames is specified in the header. All frames are directly placed one after another. There's no frame header before each frame like in AVI files where each frame starts off with something like "00dc".
For 3 bytes per channel, the color channel order is R G B. For 4 bytes per channel, the order is R G B X, where X means unused (and should remain 0, though it doesn't have to as a valid player will simply ignore the 4th color channel). Note that this differs from the BMP and AVI color channel order which is B G R (for 3 channels) and B G R X (for 4 channels).
Unlike other video container formats (such as AVI), this format does not use an index. Because it (in its current version) does not support anything other than raw (uncompressed) RGB or grayscale video, there's no possiblity that each frame will have a different size. Instead, one can calculate the file offset of the video by simply knowing the current frame number, the number of color channels, and the number of bytes per color channel. Frames are numbered starting at 0. The calculation is as follows.
SizeOfHeader = 28
SizeOfFrame = Width * Height * NumberOfChans * BytesPerChan
OffsetToFrame = FrameNumber * SizeOfFrame + SizeOfHeader
So again, my request to the developers of VLC is for you to include BVF playback capability in a future version of VLC player.