to, 2017-05-11 kello 12:52 +0800, Holy Wu kirjoitti: > > 2017-05-11 5:00 GMT+08:00 John Stebbins <[email protected]>: > > On 05/09/2017 10:29 AM, Holy Wu wrote: > > > 2017-05-09 19:46 GMT+08:00 Petri Hintukainen <[email protected] > > > 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 > > [email protected] > > 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 > [email protected] > https://mailman.videolan.org/listinfo/libbluray-devel _______________________________________________ libbluray-devel mailing list [email protected] https://mailman.videolan.org/listinfo/libbluray-devel
