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 you think it is possible to do?
On 5/2/15 10:41 AM, Anatol wrote:
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 Source key frames") in its
Transcoder add-on.
But Wowza also has other problems ...
On Sat, May 2, 2015 at 11:06 AM, Henk D. Schoneveld <[email protected]>
wrote:
On 02 May 2015, at 06:27, Anatol <[email protected]> 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, except the livestream itself ?
Or is the livestream also available via HLS ?
If yes, then you’ll have to encode this one as well.
This can only be achieved if the source stream is encoded with the same
version of the encoder you’re using your self. I can imagine that different
encoders could behave slightly different.
BTW what is your source ? Is it predictable like DVB-S from the same
broadcaster ?
From the top of my head BBC broadcast has an I-frame every 12 or 13 frames.
Another potential issue could be the delay between the video and audio
stream, which would force you to also encode the source stream.
Hope it helps.
On Sat, May 2, 2015 at 2:48 AM, Henk D. Schoneveld <[email protected]>
wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <[email protected]
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 possibly also
all
other frametypes from the input stream there would not be any need for
scene detection if that was already done in the input stream. I am not
sure
how much heavy lookahead calculations and perhaps other heavy
calculations
could also be skipped?
What are you trying to achieve ? A performance boost ? I don’t think
that
you’ll achieve improvement worthwhile, if anything at all. The working
of
the encoder should need to be totally rewritten to make something like
this
happen at all. Encoding of a frame depends on former and following
frames,
the result I P or B frame is the result. Your source is h264 already,
so I
think you’ll rescale and re-encode to achieve that. The calculation has
to
be done. Knowing in advance that it will be en I P or B frame won’t make
any difference in the amount of calculations in my opinion.
On May 1, 2015 7:42 PM, "Henk D. Schoneveld" <[email protected]>
wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <
[email protected]
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 arbitrary amount of
frames
by specifying the gop-size. The function of an I-frame is to hold max
frame
info P and B frames build on that complete I-frame. It doesn’t make
sense
from an encoding viewpoint to skip an I-frame at a scene-change, it’s
just
impossible.
Adding more than ‘a minimum amount’ of I-frames only makes sense for
seeking purposes, at the cost of less compression/higher then
necessary
bitrate.
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 <
[email protected]> 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
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
second
pass keyframes are inserted exactly where they are recorded in the
first
pass... Is that something like that even theoretically doable for
live
streaming?
thanx
--
--
Haris Zukanovic
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
--
--
Haris Zukanovic
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
--
--
Haris Zukanovic
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
