ffmpeg: bgr24 rawvideo => Output Turned 180 Degrees & Flipped Horizontally

[mapg]

Hi everyone,

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:

ffmpeg -i input -pix_fmt bgr24 -vcodec rawvideo output.avi

How can I avoid this and get the output with the same orientation as the video source?

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 ...

Turn180()
FlipHorizontal()

But sincerely, I would like that ffmpeg could render the output rightly without extra "post-production" tricks.

Please, have a look at the picture montage I have attached here.

Thank you very much in advance for your reply.

Mapg

[jagabo]

The image is upside down. That's a common problem -- some formats save bottom to top, others top to bottom. Just use -vf "vflip" in ffmpeg or FlipVertical() in AviSynth.

https://ffmpeg.org/ffmpeg-filters.html#vflip
http://avisynth.nl/index.php/Flip

[mapg]

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.

Best regards,
Mapg

[jagabo]

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.

[mapg]

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.

[pandy]

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.
https://docs.microsoft.com/en-us/windows/desktop/gdi/device-independent-bitmaps

[_Al_]

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?

[aedipuss]

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.

[pandy]

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?

Perhaps memory conservation? Decompression could be performed on place (no separate buffer required).
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

[_Al_]

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 ...

[Cornucopia]

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.

No it wasn't.

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.

Scott

[mapg]

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.
https://docs.microsoft.com/en-us/windows/desktop/gdi/device-independent-bitmaps

I see, good finding, but ... does it make sense today? I cannot find any software that output the resulting image flipped vertically if the source has a normal orientation.

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?

[jagabo]

I've never heard of any display that scanned bottom to top. I posted an example of how interlaced CRT displays scan:

https://forum.videohelp.com/threads/334839-interlace-help/page7?highlight=crt+center+s...an#post2083644

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:

https://www.youtube.com/watch?v=3BJU2drrtCM

[pandy]

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.

[aedipuss]

http://wiki.gis.com/wiki/index.php/Raster_scan

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

vertical position increases on each scan line and

Interlaced scanning

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.)

[poisondeathray]

I cannot reproduce the issue with a 4:2:0 source, or RGB source , when viewed with different software - mpchc , potplayer, vlc, vdub, avisynth etc....

What was your source, and how were you viewing it ?

[_Al_]

I see, good finding, but ... does it make sense today?

That is why I asked also, but it looks like, as pointed out, mostly from historical reasons. Like that mentioned BMP image is structured that way. Also it looks like those formats are also packed style, values are interleaved. Not planar videos with separate plane arrays (R,G, B or Y,U,V, or just Y planes). Pixel values are packed in a so called DWORD , 32bit value that contains four 8bit values. Similar like interleaved format YUY2 (YUYV) but those could be packed in some other style. 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.

[jagabo]

BMP can be either bottom to top or top to bottom:

https://en.wikipedia.org/wiki/BMP_file_format#Pixel_array_(bitmap_data)

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.

[pandy]

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.

Depends on video hardware - many video HW may be really unusual... storing video in line with programmer coordinates may be beneficial for modern memories where burst (block) transfers are preferred (and supported by HW).

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

[Cornucopia]

http://wiki.gis.com/wiki/index.php/Raster_scan

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

vertical position increases on each scan line and

Interlaced scanning

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.)

Their knowledge is faulty in both respects. Broadcast analog (there might be exceptions with specialty scientific equipment) has always scanned top to bottom, in all 3 major systems. It's actually a number that references "vertical deflection" (similarly the horizontal) compared to dead center in an electron beam scanning gun, but it starts with a negative vector offset and then grows. You also skipped the part where it says the signal is going "downhill".
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.

Scott