[libbluray-devel] Headers needed by bd_read_mpls() are not installed

[Petri Hintukainen]

to, 2017-05-11 kello 12:52 +0800, Holy Wu kirjoitti:
> 
> 2017-05-11 5:00 GMT+08:00 John Stebbins <stebbins at jetheaddev.com>:
> > On 05/09/2017 10:29 AM, Holy Wu wrote:
> > > 2017-05-09 19:46 GMT+08:00 Petri Hintukainen <phintuka at users.sour
> > > ceforge.net>:
> > > > Hello,
> > > > 
> > > > la, 2017-05-06 kello 23:08 +0800, Holy Wu kirjoitti:
> > > > > In bluray.h, the mpls_pl struct only has declaration but no
> > > > > definition. Therefore the user can't do anything useful on
> > > > the
> > > > > returned pointer of
> > > > 
> > > > bd_read_mpls(), because it's an incomplete type.
> > > > 
> > > > Do you have a real use case for the data ?
> > > > 
> > > 
> > >  
> > > The users of AviSynth or VapourSynth want to directly open a
> > > mpls file by a source filter, like ffms2, rather than manually
> > > open each of the m2ts files in the script. I need to know what
> > > and how many m2ts files the playlist contains, so I can let the
> > > source filter open the corresponding files automatically. And I
> > > find bd_read_mpls is quite suitable here.

There may be "hidden" pitfalls. I'm not 100% sure if movie clips can
start from the middle of .m2ts file. In that case simply concatenating
the files won't work. And to find the cutting points you need to parse
also clpi files.

> > Hi,
> > 
> > The specific information you are asking for is already exported in
> > the public APIs.  bd_get_title_info will return BLURAY_TITLE_INFO
> > that contains an array of BLURAY_CLIP_INFO.  The clip_id in
> > BLURAY_CLIP_INFO identifies an m2ts file.
> > 
> > If you are trying to read mpls files without using the higher level
> > disc parsing provided by libbluray, that's a matter of project
> > scope.  libbluray isn't really intended for that type of usage
> > scenario.  But I'll leave it to Petri to decide if he wants to
> > expand the scope of libbluray to cover such scenarios.

I think we should keep those hidden for now. 3D playlists / extension
data may require changes there, and it is easier if the structs are
hidden. There were already some problems because of clpi data was
public.

We can always expose those later if there's use for the data. But the
preferred method should be using existing API.

> >  
> > John      GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1
> > D7B2 60D4 D0F7
> > 
> > _______________________________________________
> > libbluray-devel mailing list
> > libbluray-devel at videolan.org
> > https://mailman.videolan.org/listinfo/libbluray-devel
> > 
> 
> Hi,
> 
> Thanks for your explanation. And yes, libbluray is designed to be
> used by player application to load a BD disc. My use case is probably
> too specific. Anyway, I already copy the missing header with some
> modification to my program and it works as expected. So it's not a
> big problem here. :)

I've splitted the header, it should be easier to use now.

There shouldn't be any problems using it as long as you link
_statically_. As long as those are not part of public API nothing
guarantees there won't be incompatible changes between library
versions.

> _______________________________________________
> libbluray-devel mailing list
> libbluray-devel at videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel