From: Michael Fabian 'Xaymar' Dirks
Adds "timestamp_precision" to the available options for Matroska muxing.
The option enables users and developers to change the precision of the
time stamps in the Matroska container up to 1 nanosecond, which can aid
with the proper detection of constant and
From: Michael Fabian 'Xaymar' Dirks
Adds "timestamp_precision" to the available option for Matroska muxing.
The option enables users and developers to change the precision of the
time stamps in the Matroska container up to 1 nanosecond, which can aid
with the proper detection of constant and
From: Michael Fabian 'Xaymar' Dirks
Adds "timestamp_precision" to the available option for Matroska/WebM
muxing. The option enables users and developers to change the precision
of the time stamps in the Matroska/WebM container up to 1 nanosecond,
which can aid with the proper detection of
From: Michael Fabian 'Xaymar' Dirks
Adds "timestamp_precision" to the available option for Matroska/WebM
muxing. The option enables users and developers to change the precision
of the time stamps in the Matroska/WebM container up to 1 nanosecond,
which can aid with the proper detection of
From: Michael Fabian 'Xaymar' Dirks
Adds "timestamp_precision" to the available option for Matroska/WebM
muxing. The option enables users and developers to change the precision
of the time stamps in the Matroska/WebM container up to 1 nanosecond,
which can aid with the proper detection of
From: Michael Fabian 'Xaymar' Dirks
Adds the "timestamp_precision" option to matroskaenc, which allows users
to increase the time stamp precision up to 1 nanosecond. This aids with
certain demuxers being unable to detect constant rate. It is a work
around fix for the problems reported in 259,
From: Michael Fabian 'Xaymar' Dirks
Increases the time stamp precision to 1 microsecond, the same as
AV_TIME_BASE. This hopefully prevents demuxers from being confused on
the number of frames/samples we actually have per second, and should
mark all future Matroska/WebM content as being constant
On 04.02.2019 11:05, Mark Thompson wrote:
Can you explain what this "skip frame" actually does in the encoder? The
concept does not exist in H.264 or H.265, as far as I know.
I believe this has to do with the pic_struct flag which has a value of 7
for frame doubling and 8 for frame
On 01.02.2019 19:31, Carl Eugen Hoyos wrote:
Could you take over mantainership?
Unfortunately I lack the necessary FFmpeg experience for this task. Even
though I am the maintainer of the OBS Studio AMD Encoder integration,
I'd be horribly lost in FFmpegs code when it comes to AMD/AMF.
On 15.01.2019 23:41, Michael Dirks wrote:
On 15.01.2019 23:05, michael.di...@xaymar.com wrote:
From: Michael Fabian 'Xaymar' Dirks
Adds support for the pict_type field in AVFrame to amf_h264 and
amf_h265 simultaneously. This field is needed in cases where the
application wishes to override
On 15.01.2019 23:05, michael.di...@xaymar.com wrote:
From: Michael Fabian 'Xaymar' Dirks
Adds support for the pict_type field in AVFrame to amf_h264 and amf_h265
simultaneously. This field is needed in cases where the application wishes to
override the frame type with another one, such as
From: Michael Fabian 'Xaymar' Dirks
Adds support for the pict_type field in AVFrame to amf_h264 and amf_h265
simultaneously. This field is needed in cases where the application wishes to
override the frame type with another one, such as forcefully inserting a key
frame for chapter markers or
On 14.01.2019 20:32, Carl Eugen Hoyos wrote:
2019-01-14 20:02 GMT+01:00, Michael Fabian 'Xaymar' Dirks :
Adds support for the pict_type field in AVFrame to amf_h264 and amf_h265
simultaneously. This field is needed in cases where the application wishes
to override the frame type with another
13 matches
Mail list logo
