On Mon, 24 Mar 2014 22:25:35 +0100 Luca Barbato <[email protected]> wrote:
> On 24/03/14 22:09, Rémi Denis-Courmont wrote: > > Le lundi 24 mars 2014, 21:53:35 Luca Barbato a écrit : > >> First friendly warning: please tone down two notches. > > > > I suggest you check your facts before you flame me then taunt me. > > Nobody is flaming you, just this kind of tone is not welcome. > > >>> If you keep a single pixel format regardless, the only way for the > >>> application to know the correct parameters is look at the last pixel > >>> format (i.e. software) in the list and second-guess libavcodec that this > >>> indicates the correct chroma type and pixel depth. This would be > >>> vomitively ugly, and it would forever lock libavcodec into offering only > >>> a single software output pixel format ever. Is that really what you want? > >> > >> It is actually what normally happens, as explained by Hendrik, Anton and > >> wm4. > > > > This is patently false. Look at get_pixel_format() from h264.c for yourself! > > The code in avconv_vdpau and mpv does the surface mapping based on the > global context (set by the very same application). > > VDA does the same. I think the problem at hand is that there's no way for the hwaccel API to signal to the application which surface format should be used. And he's right: if new surface types other than 420 were ever supported, it would probably break dxva/vdpau/vaapi. So the basic problem is that even if the decoder reports a higher level profile as supported, the application (written against the current API) would allocate the wrong surface type. > > libavcodec does not currently call get_format() for anything other than 420 > > content(*)- Therefore, it does not offer AV_PIX_FMT_(VDPAU|VAAPI) for 422. > > Instead, it just hard codes the software decoding pixel format in that case. > > That can be easily fixed, I guess. > > >> I'm sorry about this misconception, sadly hwaccel hadn't been documented > >> so everybody had an understanding on how it works and all the time a > >> detail or another might fit by pure chance. > > > > You are distorting reality here. This stuff (non-420 hwaccel) is not > > implemented yet. Of the two potential ways to implement it, you defend the > > backward-incompatible and ugliest one. > > I'm not distorting anything, please tone down. > > You assume one way is the correct one, the other people involved assume > the other. > > As I told you, the original hwaccel does not assume anything beside > black boxes and opaque pointers. > > What Hendrik, Anton, wm4 consider correct as approach had been > implemented on their side, you assumed otherwise and implemented that > way in VLC. > > It can be *calmly* discussed w/out considering a war. > > Worst case I'll fix that part in VLC if you do not want to. > > lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
