[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-devel
Subject:    Re: [xine-devel] How can I change stream->meta_info during the
From:       Miguel Freitas <miguel () cetuc ! puc-rio ! br>
Date:       2003-09-30 17:28:33
[Download RAW message or body]

Hi Thibaut,

yesterday i tested the new mp3 demuxer (with some vbr files) and it
worked great, the timing information is perfect! nice work!
(don't forget to mention it on changelog)

On Tue, 2003-09-30 at 12:11, tmattern@noos.fr wrote:
> The mpeg audio demuxer can now parse id3v2 tags, but it's seems that the xine-
> lib api is not really designed to handle meta info changes.
> Here is the code of the xine_get_meta_info function :
> 
>   const char *xine_get_meta_info (xine_stream_t *stream, int info) {
>     return stream->meta_info[info];
>   }
> 
> If the frontend calls this function, it gets a pointer on the meta info string, 
> so if i want to change the meta info from a demuxer, i can't free the old meta 
> info because i don't know if the frontend holds a pointer on it.


i guess the frontend should never hold a pointer to it, no?

these strings are freed every time we open a new stream, so the problem
you are saying already exists.

>  If i change 
> the meta info without freeing the old one, there will be a memleak.
> Am I missing something ?

no, you are right. at least check if the meta_info[i] != NULL and free
it.

> What can i do to solve this issue ?

without changing the way api works, you should free the old value and
strdup the new one. 

of course, this is not 100% safe in terms of multithread programming. i
guess the only way to fix it properly would be returning a copy of the
string that frontend could store or free. but that would change the api.
[1]


> Second problem, i need an event to signal to the frontend the meta info change.

ok

> Third problem, the meta info change will be in advance if i send an event from 
> a demuxer or an input plugin.

yes... this is a old problem we have. i don't have any simple solution
in mind.

regards,

Miguel

[1] another option (to keep the api compatibility) would be never
freeing any meta_info strings, but rather move their pointers to a list
of strings to be deleted when the stream is destroyed.

btw: i guess we could add an internal helper function so
input/demuxers/decoders don't have to care about strdup'ing and freeing
old values.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel
[prev in list] [next in list] [prev in thread] [next in thread]