[vlc-devel] [PATCH] Naming patterns for HLS segments

[Krenar Qehaja]

On Fri, Apr 13, 2012 at 10:35 AM, Jean-Baptiste Kempf <jb at videolan.org> wrote:
> timestamp since EPOCH seems overkill.

Hi Jean-Baptiste Kempf,

Me and Lukasz (the author of this patch) are working on a few features
for VLC. I'll try to make a comparison between incremental naming
pattern and Unix time-stamps.

*Incremental naming pattern:
**It uses the following format: 00000001.ts, 00000002.ts, 00000003.ts, etc.
**In essence, it has two "flaws":
***There is now way to navigate in time using this naming pattern. If
you collect the .ts segments from a live feed, and want to play them
from let's say 9 April 2012 12:34:56, is almost impossible, as
00017661.ts doesn't help you much on that.
***If VLC crashes (which is likely to happen at some point) while it's
writing the .ts segments, it will loose track. Starting VLC again (or
autostart), will start overwriting the existing .ts segments, starting
from 00000001.ts.

*Unix time-stamp naming pattern:
**It uses the following format: 1334332990.ts, 1334332991.ts,
1334332992.ts, etc.
**Pros over incremental naming pattern:
***Having Unix time-stamps as file-names, gives us the ability to
manage time/dates using POSIX standards. Using it, we have clear
navigation in time. If I want to play content from 9 April 2012
12:34:56, I know that starting point is 1333974896.ts.
***If VLC crashes (again, it's likely to happen at some point) while
it's in the process of writing .ts files, it will not loose track as
file-names are always unique. Starting VLC again, will simply continue
writing .ts segments to whatever current Unix time-stamp it is, and
doesn't overwrite anything.

By the way, we've been using/testing this feature for some time now,
and we want it to get merged in VLC as an option, while incremental
naming pattern would still be the primary option.

Cheers,
Krenar