I am having the following problem:
When I want to have an uncompressed raw video output using the AVI RGB format, I have to use AviSynth to fix the resulting video later, as I get a turned 180 degrees and flipped horizontally output.
I have made a picture montage side by side attached to this message so you can see much better the resulting output.
I use a a set of commands as follow:
How can I avoid this and get the output with the same orientation as the video source?Code:ffmpeg -i input -pix_fmt bgr24 -vcodec rawvideo output.avi
Is there is something wrong in the command line?
Should I have to add some filter parameters using ffmpeg?
For now, I am using for fixing the output the following AviSynth commands ...
But sincerely, I would like that ffmpeg could render the output rightly without extra "post-production" tricks.Code:Turn180() FlipHorizontal()
Please, have a look at the picture montage I have attached here.
Thank you very much in advance for your reply.
+ Reply to Thread
Results 1 to 20 of 20
Last edited by mapg; 14th Apr 2019 at 20:28.
Thank you jabago for your reply.
Yes, you are right, the solution is simpler, it's a vertical flip. We doesn't need to turn 180º and then a horizontal flip.
Thanks again for your kind reply and solution.
Last edited by mapg; 14th Apr 2019 at 22:29.
If I remember correctly, it's common for raw video files to be stored bottom to top. So you may have problems with other software if you store top to bottom.
Thanks for the note jabago.
I am not sure. I have used Adobe Premier or After effects or Virtual Dub to generate uncompressed (raw) RGB AVI files and the output is always normal.
This is heritage from Microsoft Windows, DIB map coordinate for 0,0 is right bottom as such many 80's/90's pixel formats use this coordinate system.
Left bottom and upwards, perhaps mistake,
Anyone has an idea why someone would decide to start a processes from bottom of a frame? These formats are meant to go on screen, not for storage, so is that a reason?
goes back to analog tv. picture was scanned bottom line, skip a line up, scan next one up, to the top then repeated from the bottom with the skipped lines the first time through.--
"a lot of people are better dead" - prisoner KSC2-303
Also some algorithms are designed to work in reversed direction for example http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0120.html
I don't know, I struggle to imagine it working backwards with better efficiency,
for example regular flow, pointer shows start and then data follow, say a line is given by x resolution x byte per sample, or to keep whatever is discussed RGB distribution, like BGR32, it could be 32bit values that contain four 8bit numbers , not sure how OP's BGR is packed though,
it can be read like,
load 32bit pack value, get color values,
B = value & 0xFF
G = (value >> 8) & 0xFF
R = (value >> 16) & 0xFF
A = (value >> 24) & 0xFF
then pointer moves 32bits further to read other 32bit value, why backward procedure would be any easier, not that it is any importance ...
Analog scan is a sort of modified form of a Lissajous curve https://www.google.com/url?sa=t&source=web&rct=j&url=https://en.m.wikipedia.org/wiki/L...KZCN-_alZ2eLs0.
It starts at the top center and goes diagonally right & down but looping back invisibly during the horizontal blanking intervals till it gets to the bottom right and then loops back up (invisible, vertical blanking) to the top left and repeats the whole process again until it gets to the bottom center and then loops up to begin the cycle all over again. Of course, the start could equally be considered the odd scan or the even scan, depending on when you decide to start.
The "skipping" exists due to the fact that on alternate scans you are starting from a different point, and there is a gap between lines due to diagonality of not just the visible lines but also the blanking lines.
So, top to bottom, left to right. That doesn't answer the question either.
I could see where some might use a COORDINATE system with positive values moving up bottom left to top right, but that still doesn't account for this strangeness.
I already mentioned that Adobe Premiere Pro, Adobe After Effects or Virtual Dub write the raw AVI RGB video file output as the input is, not flipped. And to be honest, I have used many times Virtual Dub to fix what ffmpeg does. I don't mean that ffmpeg is wrong, I am sure you are right and DIB map coordinate for 0,0 is placed at right bottom coordinates, but ... shouldn't be this rectified today to save us time adding extra processes to fix something so strange?
Last edited by mapg; 15th Apr 2019 at 20:35.
I've never heard of any display that scanned bottom to top. I posted an example of how interlaced CRT displays scan:
Of course, in the animated GIF the angle of the scan is highly exaggerated and the lines are much thinner than they would really be on a 7 line interlaced display. And the persistence is much longer than on a real CRT.
Here's a great Youtube video using a high speed camera (hundreds of thousand of frames per second) to show the picture being drawn on a CRT TV:
Last edited by jagabo; 15th Apr 2019 at 20:39.
Once again - nowadays memory is no problem but in 80's situation was different thus if some algorithms can perform processing in-place (i.e. without separate buffer) with this kind of data organization then it may be preferred over normal coordinates - there is no speed impact (as incrementing or decrementing is same in CPU cycles, and for block transfers it can be optimized to hide eventual penalty). BMP image format for example use this coordinate as native.
In raster scanning, the beam sweeps horizontally left-to-right at a steady rate, then blanks and rapidly moves back to the left, where it turns back on and sweeps out the next line. During this time, the vertical position is also steadily increasing, but much more slowly.
The tilt in the scan lines is imperceptible – it is tiny to start, and is dwarfed in effect by screen convexity and other modest geometrical imperfections. Even on the rare truly-flat computer monitors such as the Zenith Flat Tension Mask, the effect was too small to see
To obtain flicker-free pictures, analog CRT TVs write only odd-numbered scan lines on the first vertical scan; then, the even-numbered lines follow, placed (interlaced) between the odd-numbered lines. This is called interlaced scanning. (In this case, positioning the even-numbered lines does require precise position control; in old analog TVs, trimming the Vertical Hold adjustment made scan lines space properly. If slightly misadjusted, the scan lines would appear in pairs, with spaces between.)--
"a lot of people are better dead" - prisoner KSC2-303
Vapoursynth calles it COMPATYUY2 and it is packed in 2byte values as YU,YV,YU,YV ...
Vapoursynth uses COMPATBGR32, which is compatible with VirtualDub RGB. In Avisynth it is called RGB32. It is interleaved with just one plane, array of data.
VD plugins could be used in Vapoursynth or Avisynth.
Now there is a question why original VD author was still using that. But perhaps same again, backward compatibility.
And I forgot, that COMPATBGR32 is flipped also, same again, most likely, compatibility reasons. Because of VirtualDub? Just guessing here.
Last edited by _Al_; 16th Apr 2019 at 11:51.
BMP can be either bottom to top or top to bottom:
The default is bottom to top, but if the height field is negative the image is stored top to bottom.
I suspect the real reason bottom to top was used is because engineers are used to dealing with graphs where values typically increase from left to right, and from bottom to top -- it had nothing to do with hardware architecture. The reason it was reversed for video has to do with hardware architecture: that's the way the image is stored in video memory.
Last edited by jagabo; 16th Apr 2019 at 14:28.
For many systems with acceleration local graphic memory may be not available directly to programmer, instead directly accessing memory graphic is accessible as pixel coordinates and all address translation is performed by HW. This is general trend from half of 80's (NEC uPD7220 or TI TMS9918).
btw check with Windows 3.0 if both BMP versions are supported - i doubt on this
Last edited by pandy; 16th Apr 2019 at 16:58.
Vertical (and Horizontal) Hold has more to do with syncing the internal oscillator circuits that time V & H sweeps to match the timing of the incoming signal, as those in the tv were, for a long time, free-running without any autocorrective triggers/flags.
Note also, that they go on to refer to "pixels" in the context of an analog signal, which is totally wrong, as analog signals are CONTINUOUS, whereas it is digital that is DISCREET. It is only the display mask in modern analog CRT TVs where the holes in the mask are discreet that they seem to be referring to.
Last edited by Cornucopia; 16th Apr 2019 at 20:31.