Dan,
>> I did come up with some additional error reporting so that if the xml
>> fails to load, at least it doesn't fail silently:
>>
> https://github.com/pez4brian/mlt/commit/5fc4d19e81e658e1236da5b82457cfa8b428a705
>> Feel free to pull it if you like.
>>
>> For JB's example file, it print
src/modules/xml/consumer_xml.c | 71 +--
1 files changed, 24 insertions(+), 47 deletions(-)
New commits:
commit f9b63f1bfa586c2245bbe43e334290093ae03f3b
Author: Dan Dennedy
Date: Mon Jan 23 17:00:55 2012 -0800
remove old 8-bit only version of xml char
On Mon, Jan 23, 2012 at 10:49 AM, Christophe Thommeret wrote:
> Le lundi 23 janvier 2012 19:38:14, Christophe Thommeret a écrit :
>> Hi, this is the error:
>>
>> producer_avformat.c: In function ‘producer_avformat_init’:
>> producer_avformat.c:202: warning: implicit declaration of function
>> ‘avf
Le lundi 23 janvier 2012 19:38:14, Christophe Thommeret a écrit :
> Hi, this is the error:
>
> producer_avformat.c: In function ‘producer_avformat_init’:
> producer_avformat.c:202: warning: implicit declaration of function
> ‘avformat_close_input’
This was with libavformat 53.24
Compiles fine aft
Hi, this is the error:
producer_avformat.c: In function ‘producer_avformat_init’:
producer_avformat.c:202: warning: implicit declaration of function
‘avformat_close_input’
producer_avformat.c: In function ‘decode_audio’:
producer_avformat.c:2152: warning: ‘avcodec_decode_audio3’ is deprecated
(d
I thought of a new policy to add to docs/policies.txt and somewhere
> in
doxygen comments:
The standard for strings in MLT is UTF-8. Applications must provide
valid UTF-8. That means, melt would be responsible for converting
> from
environment locale's encodin
>> I thought that I could add some sanity checking to producer_xml.c and
>> maybe even fix broken input XML encoding. But libxml doesn't make that
>> simple.
>>
>> I did come up with some additional error reporting so that if the xml
>> fails to load, at least it doesn't fail silently:
>>
>
