[ralph844]

Hi forum!

I'm running Kodi 16.0 RC3 on a Ubuntu 14.04 box (AMD A10 7700K APU) and I'm struggling with HDMI 14.a frame packing support. Looking at the source code it seems to me that everything is in place to sent a frame packing signal to my projector but it seems to me that I'm missing some bits and pieces.
What I did so far:
- added a modeline to xorg.conf so that xrandr is reporting a 1920x2205 mode:

Code:

$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DFP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 2210mm x 1250mm
   1920x1080      60.0 +   50.0*    59.9     24.0     50.0     60.1     24.0     60.0  
   1920x2205      24.0 +   24.0  
   1776x1000      50.0     59.9     24.0     50.0     60.0  
   1680x1050      50.0     60.0     59.9     24.0     24.0  
   1400x1050      60.0  
   1600x900       50.0     59.9     24.0  
   1280x1024      60.0  
   1440x900       50.0     59.9     24.0  
   1280x960       60.0  
   1280x768       59.9  
   1280x720       50.0     60.0     59.9  
   1024x768       60.0  
   1152x648       50.0     59.9  
   800x600        60.3  
   720x576        59.9     50.1     50.0  
   720x480        60.1     60.1     59.9  
   640x480        59.9  
DFP2 disconnected (normal left inverted right x axis y axis)
DFP3 disconnected (normal left inverted right x axis y axis)

- tried all Kodi 3D playback options / no success
- when running my desktop in 1920x2205 is was able via bino to playback a 3D test sequence which was projected correctly in 3D by my projector

What am I missing here?

Thanks for your help!

[Nelbert]

ffmpeg doesn't currently support MVC (the second half of your 2205) so ignores it and just plays in 2D........

One of the devs currently working on supporting MVC on intel cpus (as in decoding via the CPU's API where supported instead of via ffmpeg).

That's my primitive ape understanding anyway.

[AndyFurniss]

Not sure I would say "ignores the second half", ffmpeg just plays it as it is = 2160x1920 which contains the 2 1920x1080 images.

To work with HDMI/TV these need to be split and in between padded with black lines to make up to 2205.

It's possible with CPU heavy ffmpeg filters using ffplay or mpv-

https://github.com/mpv-player/mpv/issues/1945

Edit: though now I've actually tested I see it doesn't actually pad with black lines - it just leaves part of the old image there - maybe it doesn't matter, maybe it does - I don't have 3D kit to test.

[AndyFurniss]

Mhh, I really ought to check things before posting random links, so as well as not doing black pad the command only produces 2204 (as the source is 420 and you can't have odd numbers with that).

The 2204 vs 2205 is easily fixable - just convert to 422 (format=pix_fmts=yuv422p,.....) but it loads the cpu even more possibly only single threaded as well.

[ralph844]

For now I'm actually looking only to "persuade" Kodi to generate a 3D frame packing signal.
Looking at the source code everything seems to be in place:

When adding a new resolution to an internal list Kodi is automatically taking care of the 45 lines gap between the two images:

xbmc/settings/DisplaySettings.cpp:422

Code:

void CDisplaySettings::AddResolutionInfo(const RESOLUTION_INFO &resolution)
{
  CSingleLock lock(m_critical);
  RESOLUTION_INFO res(resolution);

  if((res.dwFlags & D3DPRESENTFLAG_MODE3DTB) == 0)
  {
    /* add corrections for some special case modes frame packing modes */

    if(res.iScreenWidth  == 1920
    && res.iScreenHeight == 2205)
    {
      res.iBlanking = 45;
      res.dwFlags  |= D3DPRESENTFLAG_MODE3DTB;
    }

    if(res.iScreenWidth  == 1280
    && res.iScreenHeight == 1470)
    {
      res.iBlanking = 30;
      res.dwFlags  |= D3DPRESENTFLAG_MODE3DTB;
    }
  }
  m_resolutions.push_back(res);
}

And there are other methods which take the 45 lines gap (iBlanking) in account when calculating frame buffer coordinates.

But the questions is: what other settings/options are required to enable this output mode?

[wsnipex]

afaik this is Direct3D = windows only.

[fritsch]

D3DPRESENTFLAG_MODE3DTB

Those are used on more than windows platforms - one should reword / refactor those. It's the same with our interlaced flags.

[AndyFurniss]

Maybe re-coding and playing the new file is the way to go - there are complications though.

ffmpeg seems to be more or less liberal about 420 with odd lines depending on what filters are used. libx264 won't take 420 with odd line number - it will take 422. I am assuming progressive here, interlaced 420 needs 4 line groups (16 internally for x264 IIRC).

If you wanted to make a "correct" 2205 with black pad x264 re-encode of something that ffmpeg currently decodes 2160 -

Code:

ffmpeg -i bbb_sunflower_1080p_30fps_stereo_abl.mp4 -vf format=pix_fmts=yuv422p,'split[a][b]; [a]crop=1920:1080:0:0[ac]; [ac]pad=1920:2205[ap]; [b]crop=1920:1080:0:1080[bc]; [ap][bc]overlay=0:1125:format=yuv422' -c:a copy -c:v libx264 x264-422-1920x2205.mp4

I notice that with current kodi set to use vdpau on my amd it will try to use h/w decode which doesn't work, so vdpau needs disabling.

Maybe some h/w can do 422 x264 - maybe mine can "in theory", I don't know. (I do know it can hypothetically do 10 bit h264). I don't know what OPs kaveni can do, mine is tonga.

So with kodi using s/w decode the file will play, kodi doesn't do 422 but will get ffmpeg to convert to 420 and in this case ffmpeg is liberal and produces 2205 420. I only tested by eye shrunk down on a 1080p monitor, I assume kodis gl yuv -> rgb will also be good/accurate enough fullscreen when faced with 2205.

Something like mpv would do 422 -> rgb direct. For radeon si there is a bug where vdpau (display not decode) offers 422 but it actually gets kludged to something that looks like 420, so mpv/mplayer would need to use their gl outputs for best results.