How can I make 4K mp4s?

As far as I know maximum H.264 resolution is 4096x2304.

Maybe Milk VR will allow for QuickTime output as MPEG-4 Video (not H.264) to work since I did manage on getting Adobe Media Encoder to output 4096x4096.

I renamed the .mov file to .mp4 file and it played back on my Mac but gave an error when I tried to play it back on the Note 4 in the Oculus 360 videos folder and Milk VR displayed black.

Sorry I couldn't be more help. I really hope it wasn't a typo on Samsung's part and 4096x4096 support is for H.265 encoded video.

You can use ffmpeg. It's a command line tool, it will output at 4096x4096 without any problem. I think even more, but I never tried.
But keep in mind that most players won't decode the file since it doesn't respect h264 standards, as I read somewhere.

I know this is an old thread but I have some new info that wasn't listed. If I use the x264 PRO plugin for Premiere Pro (purchased from http://www.x264pro.com/) and configure it to emit 3048x3048 @ 24 FPS and choose Level 5.1, the resulting stereoscopic 360 video will play back in Virtual Desktop on DK2, which uses the Windows H.264 decoder. I believe this is the best that can be done currently with H.264 - even at Level 5.2 you can't go above 3048x3048 resolution at a square aspect ratio, and you can't get this high with SBS 3D either. H.265 supports higher-res formats but is not yet widely supported. Gear VR is more limited in what it accepts, and I have sussed out exactly what its limitations are yet. Here is a little sample video with a single static image:

https://www.dropbox.com/s/6ur2h3qbmbgym ... 4.mp4?dl=0

I tried the built-in Premiere Pro CC H.264 encoder but it's not capable of rendering at this resolution. I haven't gotten ffmpeg working yet, although I tried it at 4096x4096.

EDIT: I got the x264 PRO plugin to encode 4096x4096 @ 60 FPS video with H.264, can see it here:

https://www.dropbox.com/s/6ntplf2d4xcwz ... 9.mp4?dl=0

All you have to do is create a sequence with the desired resolution and frame rate and then encode the sequence with "Match Source" checked. This will override its normal maximum resolution checks. However the resulting video seems pretty useless. Gear VR can't play it. Virtual Desktop can't play it. Vrideo downscales it to 2880x2880. Only regular 2D video players can play it. Lots of frustrating limitations.

Been playing around with resolutions for the last 2 days. For quadratic resolutions (used for 3D Video in an over/under arrangment) The Samsung S6 doesn't seem to be able to play more than a 2048x2048 video with h264 or h265 codec.
Been working with various encoders too (Adobe Media Encoder / Handbrake (Like this one more) ).

Has anyone played a higher quadratic resolution yet ?

Here's Samsung's official content specs for uploading to Milk VR:

In order to create a quality experience, there are several requirements for distributing your video on Milk VR.

Resolution: Minimum 4096x2048 (4096x4096 for stereoscopic)
Framerate: 23.976 to 60.00
Minimum Bitrate: 40,000Kbps (40Mbit)
Maximum Bitrate: for high motion, you can upload a higher bitrate, provided that you do not exceed the 25 GB file size limit.
Codec: h.264

MINIMUM for stereoscopic is a 4096x4096 h.264. Has anyone had any luck creating/uploading such a file to Milk VR?

Note that you can't actually play 4k reliably.
Carmack
Limit Gear VR panoramic videos to 3840x1920 resolution @ 30 fps. 4096x2048 and 4000x2000 are causing problems.

Hey, I was in the same boat and ended up learning the syntax of ffmpeg - a command line tool that will process pretty much whatever you throw at it. I end up rendering PNG or 100% quality JPEG sequences out of Adobe software and then turn them into MP4s with ffmpeg.

You can read more about my process in this "Making of Prismatic" article I published a few days ago: http://qubahq.com/2015/08/prismatic-bts/

Personally I managed to encode files up to 6k^2 but I know of people who process 8k^2 as well.

"QubaHQ" wrote:
Hey, I was in the same boat and ended up learning the syntax of ffmpeg - a command line tool that will process pretty much whatever you throw at it. I end up rendering PNG or 100% quality JPEG sequences out of Adobe software and then turn them into MP4s with ffmpeg.

You can read more about my process in this "Making of Prismatic" article I published a few days ago: http://qubahq.com/2015/08/prismatic-bts/

Personally I managed to encode files up to 6k^2 but I know of people who process 8k^2 as well.

Do you have any experience playing such a large file back on a GearVR device?

If so, does it run smooth? Or is this "Limit Gear VR panoramic videos to 3840x1920 resolution @ 30 fps" really the limit we are currently looking at for now?

Thanks

"andrewmatthews01" wrote:

"contempt" wrote:
If you have Adobe Creative Cloud you can use the Adobe Media Encoder CC 2014 (latest version but previous still works) to output an H.264 mp4 file. I send my renders from AE directly to AME using the "Composition" menu and choosing "Add to Adobe Media Encoder Queue".

edit: I've had great results outputting to 3840 x 1920 (4096 x 2048 videos stutter) as per Carmack's suggestion.

That's what I use as well. But as I said above, neither Adobe Media Encoder nor After Effects will render an h.264 with a vertical dimension over 2048. That's fine for mono 360 videos but for stereoscopic, you need to stack them which means you need to get the vertical resolution as high as possible.

(Milk VR announced that they will soon be accepting community-created content and they mentioned their max specs for 3D 360 videos is 4096x4096 h.264. So there's got to be a dang way to make such a thing!)

Hi Andrew, I had the same problem. Now I render out to apple quicktime prores 422 codec (animation would be good too) and then go to HANDBRAKE (it's free and open source) and experiment until I get playback on Gear VR :)

I render separate videos for left and right eye at 2160x1080 resolution. Then use ffmpeg to merge them into one over/under video with 2160x2160 resolution. File name needs to end with _TB and it runs well on Gear VR / Note 4.