[FFmpeg-trac] #3133(avcodec:open): Incompatibilities beween ffmpeg 2.0.2 and 2.1 exposed via XBMC

FFmpeg trac at avcodec.org
Fri Jan 10 17:28:10 CET 2014

#3133: Incompatibilities beween ffmpeg 2.0.2 and 2.1 exposed via XBMC
             Reporter:  EricV        |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  important    |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  vdpau        |               Blocked By:
  regression                         |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |

Comment (by FernetMenta):

 Replying to [comment:68 heleppkes]:
 > IMHO the problem is here, in line 1043.
 > All the fields in m_hwContext are no longer set since the patch, so the
 XBMC code can't read them.
 > The original patch in itself makes total sense, since you want to store
 per-picture information with the picture.
 > I am however confused how this is implemented in XBMC, or why it was
 done this way.
 > How i read the current VDPAU function API, you would put such an
 implementation inside the "render" or "render2" callback in the
 "m_hwContext" (how the variable is called in XBMC)
 > So unless I'm missing something, XBMCs implementation is kinda...wrong.
 > What they should do is merge their "FFDrawSlice" into their "Render"
 function, and stop accessing m_hwContext.info/bitstream*.
 > I may be missing a bit of information on the why this was done, but this
 seems to be the current state from my point of view.

 The issue with the Render function is that it does not provide private
 data like AVCodecContext.opaque. IMO it's useless to pass VdpDecoder, it
 may be invalid at the time Render is called (due to display lost).

Ticket URL: <https://trac.ffmpeg.org/ticket/3133#comment:71>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list