On 13/10/14 13:50, Rémi Denis-Courmont wrote:
That's also true of AVVDPAUContext.
Would be nice to make clear so there aren't users not assuming that,
updating the hwaccel page with a vdpau section probably might help.
With hwaccel 1.2 we already stated that the contexts must be allocated
using the provided function.
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.
There is no way to make sure about it beside trying to decode in general.
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.
In general bitstream/frame oriented hwaccel just take some bitstream in
(the extradata) and return on setup or on bitstream change if it is not
supported, leaving the data as is.
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?
Provide an uniform abstraction and save some time to the other people
that are already using libav AND have that hardware to leverage.
That said I see your point.
A seamless fallback is possible only at the start of the stream or if
the frame/packet causing the switch can be fed back to the software decoder.
In order to achieve that we'd need to preserve the packets containing
synchronization data (I frame or assimilated) or just return the error
and sync up to the next packet with data we can decode.
Right now basically we do the rewinding because with slice-based hwaccel
we do the parsing and we preserve some information for longer in
intermediate buffers and it should be enough as long we do not have
hwaccels queueing up more frames and return errors later.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
