Added a small patch to support 'source' option for 'force_key_frames' -
https://github.com/anatolschwarz/FFmpeg/commit/1968f5fd83fcece5422b7bca4a37e48087774915
On Sun, May 3, 2015 at 2:12 AM, Henk D. Schoneveld belca...@zonnet.nl
wrote:
On 02 May 2015, at 22:32, Anatol anatol2...@gmail.com
I don't think that 'keep source keyframes' might impose any a/v sync issues
that differ from any other encoding flows.
AFIAK, 'force_key_frames' acts on the output/encoding, it does not aware of
the decoding processing. For that matter - scene cuts are evaluated from
post-decoding/raw frames.
On
On 5/2/15 10:06 AM, Henk D. Schoneveld wrote:
Another potential issue could be the delay between the video and audio stream,
which would force you to also encode the source stream.
I had not thought about the audio at all... but audio is normally not a
problem even if re-encoded to get it
It does not matter the type of the incoming protocol.
And slight un-alignment tolerated by the CDN providers and Apple HLS
validation tools.
Therefore the source live stream can be used in an adaptive-bitrate sets,
IF the other streams match their key frames.
By the way Wowza has this option (keep
My simple idea was that instead of deducing from a formula like
-force_key_frames 'expr:gte(t,n_forced*5)'
force_key_frames somehow took this kind of info directly from the input
stream and passed onto all output streams
This could be called something like
-force_key_frames 'from_source'
Do
I was just trying to imagine optimisations when encoding multiple quality
outputs... For example doing sceene detection only once.
In reality, I am trying to get the input and outputs keyframes aligned so
that I can use the input with -c:v copy as one of the variants in the
resulting multiple
On 02 May 2015, at 06:27, Anatol anatol2...@gmail.com wrote:
The idea is to gain the option to use the H264 source stream along with
live transcoded streams in an adaptive bitrate delivery modes (HLS, HDS,
etc), that require aligned keyframes on ALL participating streams.
Could it be ALL,
My case is live streaming.
I have tried it and definitely keyframes are not aligned between input
and output streams.
For all encoded output streams it is very simple to obtain alignement
with setting the fixed GOP size. But the PTS and keyframes of input are
never aligned with that.
On 02 May 2015, at 11:38, Anatol anatol2...@gmail.com wrote:
I don't think that 'keep source keyframes' might impose any a/v sync issues
that differ from any other encoding flows.
AFIAK, 'force_key_frames' acts on the output/encoding, it does not aware of
the decoding processing. For that
On 02 May 2015, at 18:00, Haris Zukanovic haris.zukanovi...@gmail.com wrote:
My case is live streaming.
I have tried it and definitely keyframes are not aligned between input and
output streams.
For all encoded output streams it is very simple to obtain alignement with
setting the fixed
On Saturday, May 02, 2015 06:00:32 PM Haris Zukanovic wrote:
My case is live streaming.
I have tried it and definitely keyframes are not aligned between input
and output streams.
For all encoded output streams it is very simple to obtain alignement
with setting the fixed GOP size. But the PTS
Henk,
Its a real problem, if the streams are un-aligned, the playback gets into
jump-forward-backward mood.
It's not a problem to get source file key frames and to have them encoded
into the rest of the files.
The problem is with a live streaming, because it is not possible to query
it for the
On 02 May 2015, at 21:11, Anatol anatol2...@gmail.com wrote:
Henk,
Its a real problem, if the streams are un-aligned, the playback gets into
jump-forward-backward mood.
If you create a 5min source file and split in 5 1 minute chunks with the help
of the hls function of ffmpeg.
Then create
Henk,
Live streaming, not files.
On Sat, May 2, 2015 at 10:32 PM, Henk D. Schoneveld belca...@zonnet.nl
wrote:
On 02 May 2015, at 21:11, Anatol anatol2...@gmail.com wrote:
Henk,
Its a real problem, if the streams are un-aligned, the playback gets into
jump-forward-backward mood.
If
On 01 May 2015, at 20:43, Haris Zukanovic haris.zukanovi...@gmail.com wrote:
Indeed force-ing keyframes at certain positions is meant to keep multiple
output encodings keyframe aligned. The input stream is already h264 in our
case.
Moreover, if one could copy all iframe positions, and
The idea is to gain the option to use the H264 source stream along with
live transcoded streams in an adaptive bitrate delivery modes (HLS, HDS,
etc), that require aligned keyframes on ALL participating streams.
On Sat, May 2, 2015 at 2:48 AM, Henk D. Schoneveld belca...@zonnet.nl
wrote:
On
On 01 May 2015, at 13:06, Haris Zukanovic haris.zukanovi...@gmail.com wrote:
Is the decision about exactly which frame to make an IDR frame made in x264
or ffmpeg?
In general I-frames are placed at scene-changes, this can happen random.
Additionally you can can force an I-frame every
Indeed force-ing keyframes at certain positions is meant to keep multiple
output encodings keyframe aligned. The input stream is already h264 in our
case.
Moreover, if one could copy all iframe positions, and possibly also all
other frametypes from the input stream there would not be any need for
Is the decision about exactly which frame to make an IDR frame made in
x264 or ffmpeg?
Any pointer or advice on where to look for this in the code?
On 4/29/15 8:54 PM, Anatol wrote:
No responses on that one?
It is very important issue.
On Mon, Apr 27, 2015 at 11:47 PM, Haris Zukanovic
No responses on that one?
It is very important issue.
On Mon, Apr 27, 2015 at 11:47 PM, Haris Zukanovic
haris.zukanovi...@gmail.com wrote:
Hello,
Can I use force_key_frames in some way to produce keyframes (IDR, not
I-frames) at exactly the same PTS in output streams as they are found in
Hello,
Can I use force_key_frames in some way to produce keyframes (IDR, not
I-frames) at exactly the same PTS in output streams as they are found in
the live input stream? Both input and output are h264 and live streaming.
Something analogous to using 2 pass encoding for VOD and in the
21 matches
Mail list logo
