On 11/14/2019 2:31 PM, Andrey Semashev wrote:
> On 2019-11-14 20:19, James Almer wrote:
>> On 11/14/2019 2:15 PM, Thierry Foucu wrote:
>>> Set the option to false by default, to match libaomdec wrapper.
>>> ---
>>> libavcodec/libdav1d.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
>>> index cf4b178f1d..5efa8eeb48 100644
>>> --- a/libavcodec/libdav1d.c
>>> +++ b/libavcodec/libdav1d.c
>>> @@ -40,6 +40,7 @@ typedef struct Libdav1dContext {
>>> int tile_threads;
>>> int frame_threads;
>>> int apply_grain;
>>> + int all_layers;
>>> } Libdav1dContext;
>>> static const enum AVPixelFormat pix_fmt[][3] = {
>>> @@ -134,6 +135,8 @@ static av_cold int libdav1d_init(AVCodecContext *c)
>>> if (dav1d->apply_grain >= 0)
>>> s.apply_grain = dav1d->apply_grain;
>>> + s.all_layers = dav1d->all_layers;
>>> +
>>> s.n_tile_threads = dav1d->tile_threads
>>> ? dav1d->tile_threads
>>> : FFMIN(floor(sqrt(threads)),
>>> DAV1D_MAX_TILE_THREADS);
>>> @@ -378,6 +381,7 @@ static const AVOption libdav1d_options[] = {
>>> { "tilethreads", "Tile threads", OFFSET(tile_threads),
>>> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
>>> { "framethreads", "Frame threads", OFFSET(frame_threads),
>>> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
>>> { "filmgrain", "Apply Film Grain", OFFSET(apply_grain),
>>> AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
>>> + { "alllayers", "Output all spatial layers", OFFSET(all_layers),
>>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
>>> { NULL }
>>> };
>>
>> IMO, we don't want to output all layers under any circumstance. It'll
>> result in a mix of frames with duplicate pts and different dimensions.
>
> IIRC, for VP9 with spatial SVC lavc decoder worked exactly like that -
> by returning a frame per spatial layer. Is this considered a bug?
I don't know if it's a bug, and never seen or tested vp9 svc samples
before. Ronald might know. But it sounds like having more than one video
"stream" per AVCodecContext, which i don't think was intended.
And if it was, then it would be up to the library user to figure what to
do with these frames.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
