A 6common format is 3 bytes per pixel (red, green, blue).
+ Reply to Thread
Results 31 to 48 of 48
It gets trickier with high bit depths. 10 bit RGB is 30 bits of information per pixel. But it may be stored as 16 bits per primary (48 bits total). The bits can be left justified or right justified.
Then there are stride issues. The frame may be padded to align the data on byte, word, long, double boundaries.
Last edited by jagabo; 24th May 2022 at 07:25.
I want a free book lol or any online freely available website about multimedia ,to understand more about multimedia and its encoding decoding
Last edited by Anonymous543; 24th May 2022 at 07:56.
For uncompressed RGB formats, the minimum stride is always the image width in bytes, rounded up to the nearest DWORD. You can use the following formula to calculate the stride:
stride = ((((biWidth * biBitCount) + 31) & ~31) >> 3)
Nice, i wasnt aware about that BMP worked like that
I guess it's because i never used bmp format to store raw video before, lucky me that i did not need to dig too deep into directshow, i guess they use it a lot there
Last edited by emcodem; 24th May 2022 at 10:49.
Just a short example, as a programmer we can easily generate video, all we need to do is to set the RGB values of the pixels at the places we like them to be this and that color. Most simple to just write one byte per pixel, leading us to generate a so called RGB24 raw image.
This batch let us use this batch to generate one frame of 16x16 pixels, each pixel having 3 bytes which carry the RGB values.
Note that using batch language we can only write ascii characters instead of raw bytes to file, so the actual raw values for each pixels are (look up some ascii table to see what i mean):
The resulting color will be brown and all pixels will have the same color for start, we write 256 pixels.
@echo off setlocal set PIXELBUFFER=RGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGB del c:\temp\1.rgb24 :loop >>c:\temp\1.rgb24 ( echo|set /p=%PIXELBUFFER% ) set /a written=%written%+1 if %written% lss 1 goto loop
Now we feed some encoder with the generated data and encode it to something that you can play in some media player. As the file is just a bunch of bytes without any container, we need to tell our decoder how to interpret the input data. As i wrote 256 pixels above, i tell the decoder that i want it to assume 16x16 resolution. And of course we also need to tell the decoder which pixel format we have, in our case simple rgb24.
ffmpeg -f rawvideo -pix_fmt rgb24 -s 16x16 -i c:\temp\1.rgb24 c:\temp\out.mp4
OK, this way we generated a video with a single frame. If you want more frames all you have to do is to write more pixel data into 1.rgb24 file.
Compress rather than encode, yes. You can for example .zip your video data, or use x264/x265 in lossless mode.
Anonymous543GuestI though you were interested in learning how compression works? Write your own encoder/decoder.
after that i guess encoding comes in place for its compression like RGB => YUV and saving some bytes
But am still confused how can I turn an image sequence in to video with audio insync..
Image should not loss quality while it turns into video..
It's like i wanna make a program that packs image set + audio into archive like zip with some metadata like..how many frame per second to play etc.
And also a player program that reads that archive and it's metadata for playback.
eg. lets say you start with those YUV to RGB converted 289 PNG images from the earlier post
Using FFV1 you save about 1/3 bandwidth on that example. The more similar the images, the more you save. The more different the images, the less you save. But temporal compression should always yield smaller results than the sum of PNG images (there might be some edge cases like exact duplicate frames, where lagarith "null frames" compresses better)
289 image png sequence 535MB
zip archive compression 535MB
Last edited by poisondeathray; 25th May 2022 at 10:32.
Yes, and as an extreme example, if you were to have an image that never changed throughout, your 289 png images would probably be >289x the size of a Lagarith video with null frames. Of course, if that were the case, you would probably be thinking, "why would I need 289 png images, then", and you would be right.
But in the real world, you WILL have changes when you animate images (kind of the point).
Good luck with coming up with an encoder/compressor and decoder/decompressor on your own though - they are complex enough that it took teams of (video & engineering & programming) highly educated and talented people years to come up with the ones we use right now.
You asked about syncing: to do it properly requires a master clock and timestamps for equivalent packets of data in the video and audio streams, so they can be matched for playout.
Last edited by Cornucopia; 25th May 2022 at 10:50.
Any one explain about BMP images
in which programing language is written in? and how it works?
can i draw pixel images with programing languages?
BMP images can be created in almost any language. Using one with support for Windows GDI and Directshow, and low level byte/bit manipulation, may help (C variants for example). Create a 2D array of pixels. Create the associated header (structures that describe the data). Fill them out and save them.
python or C or perhaps other languages, not sure, can use opencv module. You have raw rgb in an array an you manipulate image using very fast algorithms or pre set up utilities. Even using python, when manipulating with an image, is very fast because pixels are not addressed one by one by python but by those algorithms in C using numpy
opencv also loads an image (into numpy array) and saves new image (jpg., png) so you do not need to go technical about headers etc.
Last edited by _Al_; 1st Jun 2022 at 08:56.