File size reduction about transform360

[boblaublaw]

Ffmpeg will recompress your input video using the settings specified on the ffmpeg command line, or defaults, if no settings are specified, as is the case with your command line. The problem here is that the defaults are too aggressive for the videos you are working with.

If you want to reduce the compression, you will need to specify one of several options to tell ffmpeg how aggressively to compress your video. This can be quite elaborate. I would suggest you begin with specifying a constant quantizer using the -crf argument which is documented here:

https://trac.ffmpeg.org/wiki/Encode/H.264

It is important to understand that ffmpeg supports many codecs and that this documentation is for h.264. Good luck!

[arianaa30]

Thank. Is there any options for ffmpeg to specify use the same parameters as the original video and not to compress?

And one more question: When I compare the two videos, it doesn't really look like they convert the equirectangular frame easily with splitting the frame into 6 regions, 4 in the middle 50%, bottom and top from the top 25% and bottom 25%, middle shift, and whatnots. Do they really just do this? The faces of cube do not really match such patterns in the original one! Seems like much more transforms have been done!

Here is my footage:

Here is how the simple splitting works:

[puffpio]

hey @arianaa30 wanted to bring up 2 points

1. there's not really a good way of ensuring the same quality as the original, as one doesnt really have a good idea of what the original was encoded at. you could do a "lossless" encode which would make sure the output is EXACT, but that would increase bitrate dramatically. if you want to encode something at high quality that tries to preserve the original but not go crazy on the bitrate, I suggest adding "-crf 18" to your command line
2. in your first post you used "max_cube_edge_length=512" as one of the settings, and stated your input video was 1440x960. For that input resolution the cube edge length of 512 is too large. it would be equivalent to upscaling the resolution of the video. to maintain the an equivalent resolution, try using "max_cube_edge_length=384"

[puffpio]

also, you're right, the reprojection is not as simple as cutting up the image into sections and distorting them. we actually reproject from equirectangular to spherical coordinates, and then project that onto a cube using a ray tracing-like algorithm

[arianaa30]

Thanks for the description. Yes, there should be some transforms involved because some cubes seem a bit rotated or something (a simple cut just over paint apps)

Also I notice there are some anti-aliasing and distortion removal when the middle left-most portion is attached to the right-most part. I did some tests and noticed if I just do it as is, there are some edging problem that needs to be smoothed:

[boblaublaw]

I'm familiar with your source video and the car just isn't pointed at the 0 degree axis. You could apply a rotation to fix this.

Your cube edges may be visible because the facebook transform filter and the player you are using are not aligned. You can specify the "expand_coef" on the command line to tell transform how much to scale the cube faces. The default is 101% scaling, you might try slight variations on that value.

[puffpio]

Yes, we default to a 1% buffer because you get some color bleeding between
cube very faces during the YUV to RGB conversion in hardware video decoding
engines
On Jun 14, 2016 10:48 AM, "J B" [email protected] wrote:

I'm familiar with your source video and the car just isn't pointed at the
0 degree axis. You could apply a rotation to fix this.

Your cube edges may be visible because the facebook transform filter and
the player you are using are not aligned. You can specify the "expand_coef"
on the command line to tell transform how much to scale the cube faces. The
default is 101% scaling, you might try slight variations on that value.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#13 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AALS3fBUl9b1Q_XERfwFEZR-EzXc-DN_ks5qLulPgaJpZM4I00Z3
.

[arianaa30]

@puffpio Thanks for your info. I was just trying to follow your suggestions. I was wondering how you calculate the proper cube-edge-length that you suggested 384 for 1440x960 one? (Actually my input was 1920x960). Now I have a 4k video 3840 x 2160. So I'm guessing the proper edge should be around 1000?!

btw, my ffmpeg doesn't recognize -crf command. Any other ways to keep the same quality?

[puffpio]

since we divide the video horizontally into fourths you can just divide the
horizontal resolution by 4 most of the time
in regards to CRF...try to get a version of ffmpeg with x264 compiled in

On Wed, Jun 15, 2016 at 5:45 PM, arianaa30 [email protected] wrote:

@puffpio https://github.com/puffpio Thanks for your info. I was just
trying to follow your suggestions. I was wondering how you calculate the
proper cube-edge-length that you suggested 384 for 1440x960 one? (Actually
my input was 1920x960). Now I have a 4k video 3840 x 2160. So I'm guessing
the proper edge should be around 1000?!

btw, my ffmpeg doesn't recognize -crf command. Any other ways to keep the
same quality?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#13 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AALS3W5WNwdRBKqkbk8bjA6NEpvwwDU6ks5qMJyOgaJpZM4I00Z3
.

[arianaa30]

Thanks!