AVC1 playback on Vero

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: http://paste.ubuntu.com/10780256/ 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): http://paste.ubuntu.com/10784828/ <- here, compared two times the profile in the older version).

Okay Here is bit of level set.

With the latest diff

  1. my sample avc1.mp4 - works fine
  2. my rtsp stream - works fine
  3. @fritsch 's sample - sample.mp4 fails with log

Sorry didn’t have enough failure lines in the log. http://paste.osmc.io/kesahixuno

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.

Aarg! I did notice when applying the patch, I guess c/p somwhere got me too! okay now comparing level == 30. all three clips work.

Cool. Thanks for improving kodi - that will go into kodi with: IMX: Several fixes screenshot, deint of progressive, minors by fritsch · Pull Request #6878 · xbmc/xbmc · GitHub

no worries i am @vajonam on github too :smiley: I have posted another sample with a different issue thread is here

@sam_nazarko can you please include this patch http://paste.ubuntu.com/10784828/ that fixes this issue! Thanks

This patch has already been included in our latest internal test build and I can confirm that it fixes hardware decoding of an AVC Baseline@L3.1 file of mine that was experiencing the same issue. (The one that I posted the mediainfo for earlier in this thread)

So this will be included in RC2.