<br><br><div class="gmail_quote">On Tue, Jun 22, 2010 at 5:03 PM, Jakob Leben <span dir="ltr"><<a href="mailto:jakob.leben@gmail.com">jakob.leben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Mon, Jun 21, 2010 at 7:53 PM, Srikanth Raju <span dir="ltr"><<a href="mailto:srikiraju@gmail.com" target="_blank">srikiraju@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

Hello,<div>I have attached two patches. I will merge these into master by Wednesday if nobody has any problems with them. These are the include files and some minor changes to the core.<br></div></blockquote></div><div><br>
<br>
Hi, Srikanth,<br><br>Maybe I'm a bit late, but I have a couple 
of conceptual questions about this, so please enlighten me:<br><br>I was
 wondering what is the reasoning behind adding all the information 
fields like artist, album, track number, etc. to ml_media_t instead of 
re-using vlc_meta_t (or developing it, if it is not sufficient) ?<br>For
 that matter, couldn't an input_item_t be used on the place of 
ml_media_t?<br><br></div></div></blockquote><div><br></div><div>This was much argued over last year. We decided that input_item_t and vlc_meta_t will represent information that can be obtained from the file directly and ml_media_t will be what is stored in the sql database. There are numerous reasons for this</div>
<div>* input_item_t can represent streams, read only files, etc, and editing media information and storing it may not always be possible. In cases where the file is modifiable, formats may not support specific meta data. Handling this would be overly complicated, cumbersome, with all sorts of format specific hacks needed.</div>
<div>* the current vlc_meta_t scheme doesn't support all the metadata we want or would like in the future. Having a new structure that is free from the format will make the data structure much more flexible.</div><div>
* We don't want to mess with any current functionality, so it's best to keep those working functions there, for now.</div><div>* There is a lot of metadata, and this might increase. We don't want to load all that information if the user isn't using the media library.</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
Or is the idea for development just the opposite, to remove that information from input_item_t, once the new ML is done?</blockquote><div><br></div><div>I suspect this is what will eventually happen, only for the metadata in input_item_t ofcourse.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Cheers,<br><br>Jakob<br></div></div>
<br>_______________________________________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>Srikanth Raju<br>