Marton Balint (12020-08-28):
> Sure, if you promise you won't change system time, and you ensure a smooth
> time transition during leap seconds, then you may use it depending on
> application. But this certainly should not be the default
Nobody suggested that it be the default. But it should be an
On Thu, 27 Aug 2020, Jim DeLaHunt wrote:
On 2020-08-27 13:05, Marton Balint wrote:
On Thu, 27 Aug 2020, Nicolas George wrote:
Marton Balint (12020-08-27):
+1, this seems like the right thing. PTS is not really suitable, as
that is
based (or at least should be based) on monotonic clock, n
On 2020-08-28 00:19, Moritz Barsnick wrote:
On Wed, Aug 26, 2020 at 23:52:58 -0700, Jim DeLaHunt wrote:
Earlier this year, there were patches[3] which aimed to put linear
timecodes in a format related to SMPTE 12M into a structure marked by a
`AV_FRAME_DATA_S12M_TIMECODE` value. Maybe that refe
On Wed, Aug 26, 2020 at 23:52:58 -0700, Jim DeLaHunt wrote:
> Earlier this year, there were patches[3] which aimed to put linear
> timecodes in a format related to SMPTE 12M into a structure marked by a
> `AV_FRAME_DATA_S12M_TIMECODE` value. Maybe that refers to a location
> where you could store t
On 2020-08-27 13:05, Marton Balint wrote:
On Thu, 27 Aug 2020, Nicolas George wrote:
Marton Balint (12020-08-27):
+1, this seems like the right thing. PTS is not really suitable, as
that is
based (or at least should be based) on monotonic clock, not realtime
clock.
PTS are based on what w
On Thu, 27 Aug 2020, Nicolas George wrote:
Marton Balint (12020-08-27):
+1, this seems like the right thing. PTS is not really suitable, as that is
based (or at least should be based) on monotonic clock, not realtime clock.
PTS are based on what we decide they are based.
Realtime clock is
Marton Balint (12020-08-27):
> +1, this seems like the right thing. PTS is not really suitable, as that is
> based (or at least should be based) on monotonic clock, not realtime clock.
PTS are based on what we decide they are based. For ALSA, they default
to monotonic, but wall is an option. Frank
Den ons 26 aug. 2020 kl 12:56 skrev Andreas Rheinhardt <
andreas.rheinha...@gmail.com>:
> Jesper Ek:
> > Hi,
> >
> > I have implemented a libavdevice to capture audio and video from an AJA
> > Kona card (similar to decklink). I'm then using the HLS muxer to encode
> my
> > stream. Now I need the H
On Wed, 26 Aug 2020, Andreas Rheinhardt wrote:
Jesper Ek:
Hi,
I have implemented a libavdevice to capture audio and video from an AJA
Kona card (similar to decklink). I'm then using the HLS muxer to encode my
stream. Now I need the HLS EXT-X-PROGRAM-DATE-TIME tag to specify exactly
when the
On 2020-08-26 03:29, Jesper Ek wrote:
…I have implemented a libavdevice to capture audio and video from an AJA
Kona card (similar to decklink). I'm then using the HLS muxer to encode my
stream. Now I need the HLS EXT-X-PROGRAM-DATE-TIME tag to specify exactly
when the input source was recorded,
Jesper Ek:
> Hi,
>
> I have implemented a libavdevice to capture audio and video from an AJA
> Kona card (similar to decklink). I'm then using the HLS muxer to encode my
> stream. Now I need the HLS EXT-X-PROGRAM-DATE-TIME tag to specify exactly
> when the input source was recorded, so my plan is
Jesper Ek (12020-08-26):
> I cant use PTS, so what is the correct way to pass "wall clock time"
> metadata for every frame to the HLS encoder?
PTS would be the correct way. Why can you not use it?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
Hi,
I have implemented a libavdevice to capture audio and video from an AJA
Kona card (similar to decklink). I'm then using the HLS muxer to encode my
stream. Now I need the HLS EXT-X-PROGRAM-DATE-TIME tag to specify exactly
when the input source was recorded, so my plan is to forward the "wall
cl
13 matches
Mail list logo
