Alignment (which is not unusual) is alreday done for all codecs: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecIMX.cpp#L866
I am building kodi quite reliable in my toolchain on a x64 host. I would set that Prio 1 in your roll out process, cause flashing everytime a clean environment with all packages / libs uptodate and versioned is not easy.
And no: the vero, cubox, rpi2, whatever with sdcard is slow as hell when it comes to compiling - I would not even try that without having an esata drive attached.
Out of curiosity, what is considered slow?
Everything is relative I guess, however building Kodi natively on Pi2 takes a little bit over 1 hour (stock OC).
First time, with the OSMC build script, it takes about 2 hours (toolchain and depends).
There are some reasons I don’t like the cross compile approach:
I personally use userspace chroot to build ARM stuff and it works great. With ccache I can build kernels or Kodi in about 2hr and 50 mins respectively. This is fast enough for us.
The chroot environment means we can isolate depends for each build (no funny linking, always guaranteed to track dependencies properly). This uses QEMU (set up via procfs if we are on a non-native target), otherwise its ignored. For Kodi builds, I use actual ARM hardware and an NFS mount for my working tree. This gets very good results and stops QEMU from breaking the build (it does not handle pthreads well // at all – so Java / git etc gets problematic, but we can git clone before chroot and farm Java out to native).
@miappa: You really build on your sdcard? Where -j4 or something would hang the whole process cause of the parallel reads and writes?
Yeah, what works and fits the workflow is okay 
I have only tested it a couple of times, and I am to lazy to setup a proper “build box” just for testing purposes.
But it does work (no issues so far), and if I were to compile something just one time I wouldn´t bother doing anything else.
thanks that helps. just ran into the QEMU git problem… meanwhile over on the vero… the build continues…
The WMV patch won’t help. The decoder lib as is now, needs rework (the blob) - you will end up with black screen only. The other file with the 587 workaround might have more luck for you.
WMV3 is also disabled in e.g. gstreamer library.
Finally got my kodi build to finish on my sdcard on my vero. This fixes my problem, and the iMX-h264 codec works fine on this profile, both locally and while playing a remote RTSP Stream.
Should I submit a PR? with the diff?
The remote rtsp stream is most likely something else (debuglog, please) - or did that also not work before? We had this codition added, cause tv recordings iirc made sever trouble. You can submit the patch to osmc and then get it tested in the distribution, then we will see on this forum if users get issues with specific content.
Edit: I found that sample, please test it with your “changed” version: https://dl.dropboxusercontent.com/u/55728161/sample.mp4
If you ship it, ship this one: Ubuntu Pastebin which reverts the commit, that introduced it. Get the above sample running / detected, then we can push it upstream.
@vajonam: Also please link me a sample of yours, that works (after your change and did not before), use ffmpeg to cut it or simply dd (make 100% sure, no reencoding is done). Then I can have a look.
@fritsch Here is the sample, that was falling back to ff-h264, that now works correctly sample that didn’t work prior to the change
the remote rtsp stream was the same problem, it had an error about profile 578 and fell back to software.
You sample doesn’t work, here is the log for that failure on sample.mp4
Thx, let’s see if we can differentiate between those two. I think it’s CABAC related, but we will see.
The one from me is Baseline: 3.0 - yours is Baseline 3.1 - so that could already work. Check one of your rtsp streams please and see which baseline you get with those.
That was it: see NEWER VERSION Now both work.
Edit (link updated, wrong c/p)
Here is the output playing the RTSP stream. on the codec info it shows “Constrained Baseline” but not the level/version of it. Here is the log
Please revert your change and add the one from above, then we will know. It will print the level.
Lol - I had to update again (sorry was a long day at work): Ubuntu Pastebin ← here, compared two times the profile in the older version).
Okay Here is bit of level set.
With the latest diff
Please use the update patch - all of the files should work now - I had a simple typo in the old version. Make sure you have the one where m_hints.level == 30 is compared.