Le samedi 09 juin 2012 à 15:49 +0200, Anton Khirnov a écrit : > On Thu, 7 Jun 2012 11:38:43 +0200, David Girault <[email protected]> wrote: > > This new decoder will allow to decode menu stream found > > in m2ts files in Bluray or AVCHD HDMV disks. > > > > The new decoder was developped using AVMEDIA_TYPE_OVERLAY, > > inspired from AVMEDIA_TYPE_SUBTITLE, since both may send > > multiple decoded pictures to add to video currently > > displayed. > > > > version 4: > > - Added some fixes for x264 demo disk that have button without > > picture. > > - Change palette conversion to avoid convertion in avplay. > > > > Signed-off-by: David Girault <[email protected]> > > --- > > I'm a bit concerned about adding a new media type for this highly > specific feature. I'm not rejecting it, but it needs more > thought/discussion.
Hi, Indeed, rejecting a patch without any discussion is not the best method to welcome new contributor. ;) So I'm pleased to see the discussion was engaged. This patchset was the first of huge project related to blu-ray authoring/playing. As you may know, there is now open-source tool capable of playing nor authoring blu-ray disk on linux. When I say playing, I think FULL PLAY, with interactive menu of HDMV authored disk. BD-J disks is another problem, mainly du to security concern. When I say authoring, I think converting video stream to format suitable to add them in HDMV Blu-ray. Creating clip info file, playlist file, etc. Today, the best free h264 encoder is x264 and it work very well in Linux, but there isn't any tool to mux all supported stream to BDAV MPEGTS files (192bytes frames). Currently available tsMuxer don't support IGS stream. BDedit have some bug in extracting IGS stream from m2ts file. So I think Libav is a good choice to start. > > Especially since the API is very similar to subtitles. Perhaps we could > just extend the subtitle API. Yes, it was very similar (igsmenudec.c was started as a fork of pgssubdec.c), and thus my first implementation use the subtitle API. But I switch to another media type for two main reason: - I don't want to change subtitle API, - avplay can only display one subtitle at a time, and this is very limiting for displaying blu-ray. I think subtitle and menu are different type of a generic overlay object. The two are displayed over the video but they differ in the way they are used. Regarding Bluray playing (my first priority), player must deal with at least 4 planes (that may displayed at the same time): - video plane, - PIP video plane, - Subtitle (or more generic 'presentation') plane, - Interactive graphics plane. Having this in mind, we may extend subtitle API or create a new 'father' API for both subtitle and menu. I have no preference. I don't know Libav internals that much. I start this project as a quick hack to suit my needs. > > From my quick glance through the patchset, it seems that the main > (only?) difference from subs is that those menus are interactive. Yes, mainly. Subtitle may be displayed a short time, menu can be here an infinite time. Subtitle don't have any interactivity, menu have. Interactivity mean: - redisplay menu with other pictures in response to key events, - return HDMV commands for current selected button when it was 'activated'. > > If I'm reading it correctly, you're implementing interactivity by the > player constructing its own packets. The first point here is that this > is also public API and thus needs to be documented. The second is that > this approach looks quite hacky to me. Using packet side data might be > better. > It's a hack, yes. But it work well without touching too much current avplay architecture. I saw the 'display segment' frame in the stream like the first interactive command executed. It result the first AVOverlay to be displayed. Injecting another 'display segment' with embedded (or extra 'key' data attached) is the simpliest way to do the job for now. But we can call decode api with no frame (player may not know how to create such frame) at all but with 'interactive key' data set. Regards, David _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
