2008-07-29, 23:08
CapnBry,
of course its the same. the debug output you posted earlier comes from the dvdplayer when it interrogates the file. technically a container could have many audio and video streams with differing parameters which could add a lot of complexity to this.
i would just put this information into CVideoInfoTag. but, first, we need to think about what bits of info do we really care about. do we care about the actual resolution or do just want to do things "if (Is720p)"? if we keep the full resolution info, then we need to test these things based on the resolution. standard 720p is 1280x720, but should Xbmc include everything from here up to 1919x1079 (one pixel less than true 1080p)?
then we need to think about the possibility of multiple streams which conflict. do we keep information about them all, or just one of them? if the primary use is an overlay, then we should just keep information about the "best" stream.
the database could be extended with a new table, streaminfo, with columns of "id", "type", "index", and whatever else we want to store such as "videocodec", "colorspace", "height", "width", "framerate", "audiocodec", "samplerate", "audioformat".
type and index combined would reference the items in the video database, ie type=MOVIE, index=1 would be the movie with id=1 in the movie table.
maintaining info for every stream id in the database for every item will greatly complicate things. assuming we dont, and only keep the info from one video and one audio stream, this new table could easily be "joined" during the nav sql query, like this:
join streaminfo where (type=MOVIE and id=idmovie)
then all the info offsets and all the get(SOMETHING)fromdataset functions will need to updated so that this information gets filled into the proper variable in CVideoInfoTag.
of course its the same. the debug output you posted earlier comes from the dvdplayer when it interrogates the file. technically a container could have many audio and video streams with differing parameters which could add a lot of complexity to this.
i would just put this information into CVideoInfoTag. but, first, we need to think about what bits of info do we really care about. do we care about the actual resolution or do just want to do things "if (Is720p)"? if we keep the full resolution info, then we need to test these things based on the resolution. standard 720p is 1280x720, but should Xbmc include everything from here up to 1919x1079 (one pixel less than true 1080p)?
then we need to think about the possibility of multiple streams which conflict. do we keep information about them all, or just one of them? if the primary use is an overlay, then we should just keep information about the "best" stream.
the database could be extended with a new table, streaminfo, with columns of "id", "type", "index", and whatever else we want to store such as "videocodec", "colorspace", "height", "width", "framerate", "audiocodec", "samplerate", "audioformat".
type and index combined would reference the items in the video database, ie type=MOVIE, index=1 would be the movie with id=1 in the movie table.
maintaining info for every stream id in the database for every item will greatly complicate things. assuming we dont, and only keep the info from one video and one audio stream, this new table could easily be "joined" during the nav sql query, like this:
join streaminfo where (type=MOVIE and id=idmovie)
then all the info offsets and all the get(SOMETHING)fromdataset functions will need to updated so that this information gets filled into the proper variable in CVideoInfoTag.