Hello,
Le 2014-10-13 14:16, Luca Barbato a écrit :
Based on the VDPAU series review, I have to believe that adding new
visible
but internal members to AVHWAccel is not allowed.
I consider AVHWAccel the same as AVCodec, from outside should be
always accessed by reference.
That's also true of AVVDPAUContext.
Are the codec profile and resolution known at that point? I would
not think so.
A bitstream hwaccel does that internally.
Unless the back-end supports everything and falls back to software
internally, that will be unusable in generic media players or
transcoding pipelines with untrusted/unknown inptus, where the user
cannot be expected to toggle hardware acceleration on a per-input basis.
If not, that will never going to work smoothly, unless the back-end
supported
all profiles and all resolutions. In particular, that will prevent
software
fallback.
I'd rather rework the software fallback on a second time and I'd
rather add an option to make it an explicit error instead of always
automagic.
Rewinding is not generally an option. It carries implications for the
upstream bytestream and demuxer that are not generally true. Even when
true, that hardly fits the typical architecture of a video decoding
pipeline where there are no provisions for the decoder to rewind of its
own.
If it is not generic *and* libavcodec is not doing anything with the
data (not even parsing slices), then what's the point in abstracting it
inside libavcodec and cluttering the hwaccel abstraction with it?
--
Rémi Denis-Courmont
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
