[FFmpeg-devel] [PATCH] hlsenc: added floating point time support.
Reimar.Doeffinger at gmx.de
Thu Apr 3 21:29:12 CEST 2014
On Thu, Apr 03, 2014 at 12:28:49PM +0200, Michael Niedermayer wrote:
> On Thu, Apr 03, 2014 at 08:20:56AM +0200, Reimar Döffinger wrote:
> > On 03.04.2014, at 00:39, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Thu, Apr 03, 2014 at 12:57:44AM +0530, Senthil wrote:
> > >> On Wed, Apr 2, 2014 at 10:56 AM, Reimar Döffinger
> > >> <Reimar.Doeffinger at gmx.de>wrote:
> > >>
> > >>> On 02.04.2014, at 05:29, Senthil <senthil.codr at gmail.com> wrote:
> > >>>> Necessary for HLS version 3 and above. Fixes ticket #3505.
> > >>>
> > >> Either way, both float itself and %f have very limited precision.
> > >>> I'd suggest going with double and explicitly specifying a higher precision
> > >>> in the format string.
> > >>> Possibly even going with %e if the spec allows for it and there are no
> > >>> compatibility issues.
> > >>>
> > >> Here is the relevant portion in the spec:
> > >> http://tools.ietf.org/html/draft-pantos-http-live-streaming-12#section-3.3.2
> > >>
> > >> Though it does not mention about double precision, I have produced a double
> > >> version of the patch below.
> > >>
> > >> Necessary for HLS version 3 and above. Fixes ticket #3505.
> > >>
> > >> Signed-off-by: Senthilnathan M <senthil.codr at gmail.com>
> > >
> > > applied
> > Sorry, but I disagree.
> > The specification says _should_ use float, so it is absolutely _not_ in any way necessary for HLS3.
> > At the same time it is _not_ allowed for HLS2, so unless I missed a check this breaks anything that only supports HLS2.
> > Lastly, the latest change did nothing to address the very limited precision of the %f format specifier (even though it might not be that relevant).
> > Lastly, the ticket does not even mention what the point/advantage of sub-second precision would be.
> > In summary: It looks to me like the patch break things without actually fixing anything at all.
> our hls code unconditionally adds "#EXT-X-VERSION:3" thus these files
> are not version 2 compatible and i would expect version 2 players
> to not even try to play them but i might be wrong or miss something
I missed that we only do version 3. I guess it's fine then.
I still have some concerns about the %f specifier, though since
it's used elsewhere it might be a bit pointless to care about it.
The concerns I have are
1) It is highly locale-dependent, it would be nice to be able to use
this muxer even in an application that uses e.g. de_DE as locale...
2) Its implementations regularly give different output. For example
Microsoft's implementation will use round-to-nearest, current libc
uses round-to-nearest-even, and older libc if I remember right do
something that would best be described as "kind of wrong".
More information about the ffmpeg-devel