Should vlc_preparser_t and vlc_thumbnailer_t share the same input_thread_t ?

Hello, while working on !3503, I just realized that parser and thumbnailer could share the same context, but it's not done in the core.

Do you think it's worth it to share the same input_thread_t for thumbnailing and preparsing ? Are there some known limitations by using one single instance for both ?

If so, we could easily merge both Core API into one.

As an alternative, we can use one single API for libVLC and take care of the Core later.

changed milestone to %4.0

added Component::Core: Input label

OK, generally, apps do parse everything then do the thumbnailing for each video in separate steps, so not sure if it's worth it.

They aren't sharing the same enum input_type and it's different during the input_Create then input_Start uses different thread mainloops Run vs Preparse in the thumbnailer you actually need to run a decoder so I'm not sure unifying them would be a good idea or at least worth the effort to enumerate and fix all the corner cases that it would require.

Yes, I'm aware of all these details.

You could use a thumbnailer to do the parsing, since it's doing all the necessary steps required by preparsing.

We likely don't want to do that for 4.0, but should the future libVLC 4.0 API use one object/API for preparsing and thumbnailing ?

How would the thumbnailer handle playlists? Seek at the same time for every item?

How would the thumbnailer handle playlists?

With input events, like preparser and thumbnailer are already doing.

Seek at the same time for every item?

It's already seeking as the same position for every item by default, but the user can control it and use time instead.

Then I don't understand what you mean by sharing APIs.

@typx run preparsing or thumbnailing requests (2 differents structs) by the same object: libvlc_parser_t

It would be faster for medias with video, but it might be impossible to know when to stop reading if there are no videos.

I guess it's a bad idea.

If some large code can be extracted elsewhere while still provide unification and new reasonable interception point, fine with me, or else if it provides a measurable gain, but I guess it probably needs some kind of middleware implementation so that we can start input_thread[preparse] or input_thread[preparse,thumbnail] or input_thread[thumbnail]?

However, is that for 4.0 or 5.0 ?

Not sure that it would provide measurable gains at least for people who only want preparsing. Preparsing is a toned down version of playback that skips initializing a lot of stuff in order to be faster and lighter. Unless of course you keep the simple preparsing when you just want preparsing but then I'm not sure what the core merge would entail.

However, is that for 4.0 or 5.0 ?

Merging parser and thumbnailer API in libVLC can be quite fast, then we open for improvement on future versions (or not).

TLDR;

struct libvlc_parser_cbs
{

    void (*on_parsed)( void *opaque, libvlc_parser_request_t *req,
                       libvlc_media_parsed_status_t status );

    void (*on_attachments_added)( void *opaque, libvlc_parser_request_t *req,
                                  libvlc_picture_list_t *list );
    void (*on_picture)( void *opaque, libvlc_thumbnailer_request_t *req,
                        libvlc_picture_t *picture );
};

libvlc_parser_create();
libvlc_parser_queue_thumbnail_req();
libvlc_parser_queue_parsing_req();

The user is free to implement any callbacks. Obviously, queuing a thumbnail request without listening to the specific event is useless (we could assert).

Why would you have to wait for thumbnailing to have metadata everywhere ?

Parsing and picture callbacks are asynchronous, so you would receive the parsing callback first. But yes, the next item in line will wait for the thumbnailing indeed.

closed

mentioned in merge request !6272 (merged)