Issue with some AVC streams extracted from BR by makemkv

[wolfgar]

Kevin reported that AVC streams extracted from BR discs with the utility makemkv exhibit some artifacts : Refer to this post and this one I have a sample video to share privately if anyone wants to have a look (for devs, it is in the video folder I share with you) A first look at the AVC stream shows there are a lot of SEI blocks regarding Pic timing and buffering period compared to streams that are played fine in general but I am totally unsure it is the root cause...

(Note that in general all BR iso I have tested simply work fine and that imx6 is able to play AVC streams with very high bitrates, for instance )

[jazzboME]

I'm the Kevin that reported this issue. I only see this on some of my bluray rips which I'm creating with MakeMKV directly from the discs. More often than not, the files do play fine on my cubox-i4pro. But with 5 titles, and a sample of which is referenced above, I get the digital artifacts and uneven playback.

The only common ground I can find with the files that exhibit these artifacts are that mediainfo displays the following info:

Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 2 frames
Format settings, GOP                     : M=1, N=10
Codec ID                                 : V_MPEG4/ISO/AVC

The files that play correctly seem to have:

Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : V_MPEG4/ISO/AVC

But I don't know if that is helpful at all, or why the GOP settings and "2 frames" would make a difference. Otherwise I can't find any other common ground between the movies that don't play -- one of the files I have a problem with is only 27.9 Mbps for a bitrate, where as I have ones as high as 36.8 that play absolutely fine.

If needed, I can also provide other video samples from other films with the same problem.

[czfyfj]

This has been an issue for me as well. I converted one of the mkv files to an mp4 using Xmedia recoder (copying the video stream, not converting), and the artifacts show up in the mp4 as well. So, it looks like the problem is in the AVC stream (or at least doesn't have anything to do with the mkv container).

Any ideas?

[koying]

For info, this seem to be not chipset specific. I've seen reports of those "artefacts" with plain MakeMKV rips on a number of different chipsets.

Those reports suggest the same file works on a their internal player, though. Could it be an ffmpeg demux issue?

[czfyfj]

Not sure what other chipsets may be affected. These same files work fine on my generic intel PC running OpenElec. I am going to try the files on a FireTV in the next day or so.

[jazzboME]

Also in a thread on the solid-run site, see http://www.solid-run.com/community/topic1196.html it's pointed out that this has been happening with files not created by makemkv as well.

Also with my test file mentioned above it plays fine on my relatively old MacBook.

[wolfgar]

OK, unfortunately, it seems that the issue follows the AVC stream whatever the container is according to previous reports. I will try to run unitary tests to be sure there is no problem with the way we invoke the VPU for these streams and I will log an issue at freescale if odds are high it has to do with a VPU bug (well at least a bug in its firmware)

[koying]

Nevermind, XBMC issue: https://github.com/xbmc/xbmc/pull/5042

[wolfgar]

Thanks a lot for pointing it chris !

[wolfgar]

I just created the PR : At the end it was neither the demuxer neither the stream itself... Thanks again Could you merge the pending PR by tomorrow please ?

[wolfgar]

79 is merged so issue is solved : I close it...

[jazzboME]

So I just tried this patch with the sample file mentioned above and while the situation is better I don't see the problem is solved. It is much, much better, but not solved.

Playing the sample I gave wolfgar still shows the green effect at 11-12 seconds, and visual horizontal tears from 51 seconds until the end.

Can someone confirm the sample plays correctly with the patch on a cubox-i on their system?

[koying]

Yes, looks like there is an additional case, which is not handled correctly even by ffmpeg. See inside the comments of the am PR for an additional patch from me that you can test to see if it solves your problem.

[jazzboME]

I just started another build with your additional patch, and i'll try both my test file and your MJ file from that PR when I get home tonight.

Thanks.

[wolfgar]

OK I reopen the issue by the time your sample plays perfectly

[jazzboME]

So I tried the patch from @koying in the linked PR and it worked. Both test files play correctly now, and I tried a few other movies I had with the same issue.

I don't know if we need to have any concerns about the other issues brought up in the PR (such as changing aspect ratio), but I would say this fixes the issues I was having.

[wolfgar]

perfect ! thanks for reporting PR created to be merged #82

[jazzboME]

So, there may be a problem... on a whim, I tried some other files and certain of my mkv files that worked before, they no longer work. (Incredibly it is usually the mkv from handbrake that I created so I could play the film because of the problems I got before!)

The symptom is that I click play and the movie starts but it as if xbmc doesn't realize there is video, I can hear the sound, the time starts, but I never see the movie... nor does the menu go away. Just a gray box behind the menu.

Can someone else try it and see if they see the same thing or not?

[wolfgar]

damn I merged the patch and tested 3 files and it was OK so I created the PR Following your post I have just tested 5 additional files : 4 out of these 5 new files have the same issue you describe I have closed the PR as it would break too much stuff as it

[koying]

Damn, too. Thanks for testing. Could you share a sample of of a video which failed with patch #2, please.

[wolfgar]

Sure : This sample for instance has the issue

[koying]

Does it? Bugger. I'm pretty sure I tested this one on another SoC and it was ok, so it might be imx6-specific...

[koying]

Could you test with this, please

From 410c2ea96ad8e19337e50a7f42f028fb6ecc8add Mon Sep 17 00:00:00 2001
From: "Chris \"Koying\" Browet" <cbro@semperpax.com>
Date: Fri, 18 Jul 2014 19:26:51 +0200
Subject: [PATCH] FIX: fixup h264 bitstream; the whole prepend thing is causing
 problems

---
 xbmc/utils/BitstreamConverter.cpp | 12 ++++++++++--
 xbmc/utils/BitstreamConverter.h   |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xbmc/utils/BitstreamConverter.cpp b/xbmc/utils/BitstreamConverter.cpp
index db5d479..20287d7 100644
--- a/xbmc/utils/BitstreamConverter.cpp
+++ b/xbmc/utils/BitstreamConverter.cpp
@@ -646,6 +646,7 @@ pps:
   m_sps_pps_context.sps_pps_data = out;
   m_sps_pps_context.size = total_size;
   m_sps_pps_context.first_idr = 1;
+  m_sps_pps_context.idr_sps_pps_seen = 0;

   return true;
 }
@@ -678,8 +679,12 @@ bool CBitstreamConverter::BitstreamConvert(uint8_t* pData, int iSize, uint8_t **
     if (buf + nal_size > buf_end || nal_size < 0)
       goto fail;

-    // prepend only to the first type 5 NAL unit of an IDR picture
-    if (m_sps_pps_context.first_idr && (unit_type == 5 || unit_type == 7 || unit_type == 8))
+    // Don't add sps/pps if the unit already contain them
+    if (m_sps_pps_context.first_idr && (unit_type == 7 || unit_type == 8))
+      m_sps_pps_context.idr_sps_pps_seen = 1;
+
+      // prepend only to the first access unit of an IDR picture, if no sps/pps already present
+    if (m_sps_pps_context.first_idr && unit_type == 5 && !m_sps_pps_context.idr_sps_pps_seen)
     {
       BitstreamAllocAndCopy(poutbuf, poutbuf_size,
         m_sps_pps_context.sps_pps_data, m_sps_pps_context.size, buf, nal_size);
@@ -689,7 +694,10 @@ bool CBitstreamConverter::BitstreamConvert(uint8_t* pData, int iSize, uint8_t **
     {
       BitstreamAllocAndCopy(poutbuf, poutbuf_size, NULL, 0, buf, nal_size);
       if (!m_sps_pps_context.first_idr && unit_type == 1)
+      {
           m_sps_pps_context.first_idr = 1;
+          m_sps_pps_context.idr_sps_pps_seen = 0;
+      }
     }

     buf += nal_size;
diff --git a/xbmc/utils/BitstreamConverter.h b/xbmc/utils/BitstreamConverter.h
index d3ad346..f6f5312 100644
--- a/xbmc/utils/BitstreamConverter.h
+++ b/xbmc/utils/BitstreamConverter.h
@@ -182,6 +182,7 @@ protected:
   typedef struct omx_bitstream_ctx {
       uint8_t  length_size;
       uint8_t  first_idr;
+      uint8_t  idr_sps_pps_seen;
       uint8_t *sps_pps_data;
       uint32_t size;
   } omx_bitstream_ctx;
-- 
1.8.1.2

[wolfgar]

It seems all good chris The sample from kevin is correct (no green screen nor artefact) and the files that were not properly played are now correct...

Thanks I will update the PR and reopen it...

[jazzboME]

I won't be able to test it on my machine until tonight, but it sounds good if all the files are playing now.

Thanks Chris for your work on this.

[koying]

If the patch ends up to be ok for everybody, don't hesitate to mention it in the XBMC PR. There is some resistance to even acknowledge the issue, there ;)

[wolfgar]

@jazzboME : Can I close the issue from you point of view ?

[jazzboME]

Yes, you can close it. I didn't get a chance to test the patch until just now, but all of the files I've tried have worked just fine.

Thanks again to both of you for working on this.

[wolfgar]

Thanks a lot for your feedback Good that this annoying bug is solved, I close the issue for good that time ;)