[FFmpeg-devel] [PATCH] hlsenc: added floating point time support.

Michael Niedermayer michaelni at gmx.at
Fri Apr 4 01:59:51 CEST 2014


On Thu, Apr 03, 2014 at 09:29:12PM +0200, Reimar Döffinger wrote:
> 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.

i dont think its pointless
if theres an issue, that would just means theres one elsewhere too

maybe we could just provide our own double to ascii implementation


> 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".



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140404/77b0a655/attachment.asc>


More information about the ffmpeg-devel mailing list