[FFmpeg-cvslog] r17011 - trunk/libavformat/mxfenc.c

[Reimar Döffinger]

On Fri, Feb 06, 2009 at 01:22:32AM -0800, Baptiste Coudurier wrote:
> However how can I explain that time displayed is not the correct one ? 
> While every other application creating mxf around are doing it 
> "somewhat" correctly.

I don't understand what your use case/problem is.
I gave you one solution if it is some custom application.
If you are using ffmpeg itself, you can lie to it by claiming you are
specifying UTC while actually passing the local time to parse_date (just
add a z at then end).

> This is not reasonable. If people have problem with local time, as 
> people using mxf are mainly industry people, they can complain to SMPTE 
> to provide a mechanism to supply time zone. Standardization screwed up, 
> people have to deal with it.

Does the standard _explictly_ specify to use local time (I do not have a
current version)? If not, there is only one "correct", global time and
that is UTC.

> Furthermore, many muxers are using the value returned from parse_time 
> which uses localtime already, so far _nobody_ complained.

parse_date (which I assume you meant) uses local time _optionally_,
which is something completely different (and I'll accept it being the
default, despite its obvious shortcomings).
Also, parse_date AFAICT is used to parse a string on the command line,
it is somewhat reasonable to assume that a string on the command line is
in local time, but you are assuming that whenever someone muxes a file
they want the time to be represented in the machine's local time, even
when simply transcoding a file.
There is one use of parse_date in rtsp.c, but it uses the "duration"
flag and thus does not use the whole localtime stuff.

Greetings,
Reimar D?ffinger