On Wed, Jan 25, 2012 at 9:42 PM, Brian Matherly wrote:
>>> I can provide a patch to convert the entire module to use mlt_log() later.
>
>
> And here it is:
> https://github.com/pez4brian/mlt/commit/dc854a78f229b7218990cb742a8a507fba457842
applied
--
+-DRD-+
---
>> I can provide a patch to convert the entire module to use mlt_log() later.
And here it is:
https://github.com/pez4brian/mlt/commit/dc854a78f229b7218990cb742a8a507fba457842
~BM
--
Keep Your Developer Skills Current
On Wed, Jan 25, 2012 at 8:21 PM, Brian Matherly wrote:
> Dan,
>
>
>>> I made my comments on github.
>>
>> Thanks Dan. Let me rework the patch and get back to you. I think I will:
>> * Put the startElement callback back where it belongs.
>> * Add code to bail out after the first pass if there is a
Dan,
>> I made my comments on github.
>
> Thanks Dan. Let me rework the patch and get back to you. I think I will:
> * Put the startElement callback back where it belongs.
> * Add code to bail out after the first pass if there is an error.
> * Add a handler for the "warning" callback which uses
I did come up with some additional error reporting so that if the
> xml
fails to load, at least it doesn't fail silently:
>>> I definitely like the contribution, but it should use
>>> mlt_log_warning() instead of fprintf(stderr). The other
>>> fprintf(stderr) you see there
On Mon, Jan 23, 2012 at 7:58 PM, Brian Matherly wrote:
> 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
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
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:
>>
>
On Sun, Jan 22, 2012 at 10:15 PM, Dan Dennedy wrote:
> On Sun, Jan 22, 2012 at 9:56 PM, Dan Dennedy wrote:
>>> 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.
On Sun, Jan 22, 2012 at 9:56 PM, Dan Dennedy wrote:
> -- Forwarded message --
> From: Brian Matherly
> Date: Sun, Jan 22, 2012 at 9:04 PM
> Subject: Re: [Mlt-devel] Xml output is currenty broken
> To: Dan Dennedy
>
>
> Dan,
>
>
>>> OK, a
On Sun, Jan 22, 2012 at 1:48 PM, Dan Dennedy wrote:
> On Sun, Jan 22, 2012 at 1:36 PM, Brian Matherly wrote:
>> JB,
>>
>>
>>
>>> Creating xml files from the avformat producer is currently broken with
>>> FFmpeg's recent git. The problem comes from avformat's
>>> "handler_name"
>>> metadata, whose
On Sun, Jan 22, 2012 at 1:36 PM, Brian Matherly wrote:
> JB,
>
>
>
>> Creating xml files from the avformat producer is currently broken with
>> FFmpeg's recent git. The problem comes from avformat's
>> "handler_name"
>> metadata, whose value contains invalid characters.
>>
>> The problem only appe
JB,
> Creating xml files from the avformat producer is currently broken with
> FFmpeg's recent git. The problem comes from avformat's
> "handler_name"
> metadata, whose value contains invalid characters.
>
> The problem only appears when creating xml files, not when outputting to
> stdout.
Hello!
Creating xml files from the avformat producer is currently broken with
FFmpeg's recent git. The problem comes from avformat's "handler_name"
metadata, whose value contains invalid characters.
The problem only appears when creating xml files, not when outputting to
stdout.
For example:
15 matches
Mail list logo
