Use force_key_frames to obtain keyframes at exactly the same positions as in the input stream?
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
No responses on that one? It is very important issue. On Mon, Apr 27, 2015 at 11:47 PM, Haris Zukanovic < haris.zukanovic74@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 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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 < haris.zukanovic74@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 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
On 01 May 2015, at 13:06, Haris Zukanovic <haris.zukanovic74@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 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 < haris.zukanovic74@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 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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? On May 1, 2015 7:42 PM, "Henk D. Schoneveld" <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <haris.zukanovic74@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 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 < haris.zukanovic74@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 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <haris.zukanovic74@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 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 < haris.zukanovic74@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 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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 <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <haris.zukanovic74@gmail.com
wrote:
Is the decision about exactly which frame to make an IDR frame made in
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 < haris.zukanovic74@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 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
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. live
streaming?
thanx
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On 02 May 2015, at 06:27, Anatol <anatol2002@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, 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 <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <haris.zukanovic74@gmail.com
wrote:
Is the decision about exactly which frame to make an IDR frame made in
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 < haris.zukanovic74@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 > 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
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. live
> streaming? > > > > thanx > > -- > -- > Haris Zukanovic > > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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 quality HLS delivery. This way I would not have to reencode the input. The only crucial requirement is to get the keyframes (IDR) aligned. Other I-frames like those created from scene changes are not necessary to get aligned. "Key frame aligned" means that all key frames carry the same PTS in all output streams. On May 2, 2015 1:57 AM, "Henk D. Schoneveld" <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <haris.zukanovic74@gmail.com
wrote:
Is the decision about exactly which frame to make an IDR frame made in
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 < haris.zukanovic74@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 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
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. live
streaming?
thanx
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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 <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 06:27, Anatol <anatol2002@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, 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 <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@gmail.com
wrote:
Indeed force-ing keyframes at certain positions is meant to keep
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
On May 1, 2015 7:42 PM, "Henk D. Schoneveld" <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <
haris.zukanovic74@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 arbitrary amount of
by specifying the gop-size. The function of an I-frame is to hold max
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 < > haris.zukanovic74@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 >> 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
multiple 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. frames frame live
>> streaming? >> >> >> >> thanx >> >> -- >> -- >> Haris Zukanovic >> >> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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
On 5/2/15 10:06 AM, Henk D. Schoneveld wrote: problem even if re-encoded to get it synced -- -- Haris Zukanovic
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 <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 06:27, Anatol <anatol2002@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, 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 <belcampo@zonnet.nl> wrote:
> On 01 May 2015, at 13:06, Haris Zukanovic < haris.zukanovic74@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 arbitrary amount of
by specifying the gop-size. The function of an I-frame is to hold max
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 < >> haris.zukanovic74@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 >>> 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
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> wrote: frames frame live
>>> streaming? >>> >>> >>> >>> thanx >>> >>> -- >>> -- >>> Haris Zukanovic >>> >>> _______________________________________________ >>> ffmpeg-user mailing list >>> ffmpeg-user@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>> >> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > -- > -- > Haris Zukanovic > > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
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 Sat, May 2, 2015 at 12:31 PM, Haris Zukanovic < haris.zukanovic74@gmail.com> wrote:
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 <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 06:27, Anatol <anatol2002@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, 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 <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl>
wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <
>> > haris.zukanovic74@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 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 < >>> haris.zukanovic74@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
> >> 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 >>>> ffmpeg-user@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>> >>>> _______________________________________________ >>> ffmpeg-user mailing list >>> ffmpeg-user@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>> >> -- >> -- >> Haris Zukanovic >> >> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On 02 May 2015, at 11:38, Anatol <anatol2002@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 matter - scene cuts are evaluated from post-decoding/raw frames. Did you try without thinking of alignment what happens ? Take a source file of several minutes and do your encoding for several bitrates with HLS and then test see if problems do really show up. Meaning maybe you try to solve a potential problem, looking at recuirements, that in reality don’t exist ?
On Sat, May 2, 2015 at 12:31 PM, Haris Zukanovic < haris.zukanovic74@gmail.com> wrote:
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 <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 06:27, Anatol <anatol2002@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, 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 <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> > wrote:
On 01 May 2015, at 13:06, Haris Zukanovic <
>>> >> haris.zukanovic74@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 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 < >>>> haris.zukanovic74@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
>> >>> 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 >>>>> ffmpeg-user@ffmpeg.org >>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>> >>>>> _______________________________________________ >>>> ffmpeg-user mailing list >>>> ffmpeg-user@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>> >>> -- >>> -- >>> Haris Zukanovic >>> >>> _______________________________________________ >>> ffmpeg-user mailing list >>> ffmpeg-user@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>> >> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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. Sometimes, PTS of the output streams are not aligned, and it seems that encoding does not start "at the same time", like there is a delay to startup different for different output streams. I have seen this very often using the "tee" output On 5/2/15 1:43 PM, Henk D. Schoneveld wrote:
On 02 May 2015, at 11:38, Anatol <anatol2002@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 matter - scene cuts are evaluated from post-decoding/raw frames. Did you try without thinking of alignment what happens ? Take a source file of several minutes and do your encoding for several bitrates with HLS and then test see if problems do really show up. Meaning maybe you try to solve a potential problem, looking at recuirements, that in reality don’t exist ? On Sat, May 2, 2015 at 12:31 PM, Haris Zukanovic < haris.zukanovic74@gmail.com> wrote:
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 <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 06:27, Anatol <anatol2002@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, 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 <belcampo@zonnet.nl> wrote:
On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> >> > wrote: On 01 May 2015, at 13:06, Haris Zukanovic < >>> haris.zukanovic74@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 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 < >>>>> haris.zukanovic74@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 >>>> 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 >>>>>> ffmpeg-user@ffmpeg.org >>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>> >>>>>> _______________________________________________ >>>>> ffmpeg-user mailing list >>>>> ffmpeg-user@ffmpeg.org >>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>> >>>> -- >>>> -- >>>> Haris Zukanovic >>>> >>>> _______________________________________________ >>>> ffmpeg-user mailing list >>>> ffmpeg-user@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>> >>> _______________________________________________ >>> ffmpeg-user mailing list >>> ffmpeg-user@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>> >>> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
On 02 May 2015, at 18:00, Haris Zukanovic <haris.zukanovic74@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 GOP size. But the PTS and keyframes of input are never aligned with that. Different approach, adaptive means being able to switch to other ‘quality’ if circumstances change. So if the parts of individual fragments contain the same content everything is OK I think ? Don’t start the encode of the ‘whole’ incoming stream, but the parts created by HLS of that same stream. Maybe a workable solution ?
Sometimes, PTS of the output streams are not aligned, and it seems that encoding does not start "at the same time", like there is a delay to startup different for different output streams. I have seen this very often using the "tee" output
On 5/2/15 1:43 PM, Henk D. Schoneveld wrote:
On 02 May 2015, at 11:38, Anatol <anatol2002@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 matter - scene cuts are evaluated from post-decoding/raw frames. Did you try without thinking of alignment what happens ? Take a source file of several minutes and do your encoding for several bitrates with HLS and then test see if problems do really show up. Meaning maybe you try to solve a potential problem, looking at recuirements, that in reality don’t exist ? On Sat, May 2, 2015 at 12:31 PM, Haris Zukanovic < haris.zukanovic74@gmail.com> wrote:
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 <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 06:27, Anatol <anatol2002@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, 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 <belcampo@zonnet.nl> > wrote: > > On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74@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 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" <belcampo@zonnet.nl> >>> >> wrote: > On 01 May 2015, at 13:06, Haris Zukanovic < >>>> haris.zukanovic74@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 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 < >>>>>> haris.zukanovic74@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 >>>>> 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 >>>>>>> ffmpeg-user@ffmpeg.org >>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>>> >>>>>>> _______________________________________________ >>>>>> ffmpeg-user mailing list >>>>>> ffmpeg-user@ffmpeg.org >>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>> >>>>> -- >>>>> -- >>>>> Haris Zukanovic >>>>> >>>>> _______________________________________________ >>>>> ffmpeg-user mailing list >>>>> ffmpeg-user@ffmpeg.org >>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>> >>>> _______________________________________________ >>>> ffmpeg-user mailing list >>>> ffmpeg-user@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>> >>>> _______________________________________________ >>> ffmpeg-user mailing list >>> ffmpeg-user@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>> >> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
-- -- Haris Zukanovic
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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 and keyframes of input are never aligned with that.
I’ve had success with it as long as I encode all the derivative streams at once from the same encoder process. This of course can consume significant CPU resources.
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 keyframe lications Reuben, The whole idea is to avoid intense CPU consumption for LIVE streaming. On Sat, May 2, 2015 at 8:31 PM, Reuben Martin <reuben.m@gmail.com> wrote:
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 and keyframes of input are never aligned with that.
I’ve had success with it as long as I encode all the derivative streams at once from the same encoder process. This of course can consume significant CPU resources. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On 02 May 2015, at 21:11, Anatol <anatol2002@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 3 other quality streams form these chunks. This results in a total of 4 hls compatible streams where switching between each of them should be without any problem I think. 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 keyframe lications
Reuben, The whole idea is to avoid intense CPU consumption for LIVE streaming.
On Sat, May 2, 2015 at 8:31 PM, Reuben Martin <reuben.m@gmail.com> wrote:
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 and keyframes of input are never aligned with that.
I’ve had success with it as long as I encode all the derivative streams at once from the same encoder process. This of course can consume significant CPU resources. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Henk, Live streaming, not files. On Sat, May 2, 2015 at 10:32 PM, Henk D. Schoneveld <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 21:11, Anatol <anatol2002@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 3 other quality streams form these chunks. This results in a total of 4 hls compatible streams where switching between each of them should be without any problem I think. 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 keyframe lications
Reuben, The whole idea is to avoid intense CPU consumption for LIVE streaming.
On Sat, May 2, 2015 at 8:31 PM, Reuben Martin <reuben.m@gmail.com> wrote:
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 and keyframes of input are never aligned with that.
I’ve had success with it as long as I encode all the derivative streams at once from the same encoder process. This of course can consume significant CPU resources. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On 02 May 2015, at 22:32, Anatol <anatol2002@gmail.com> wrote:
Henk, Live streaming, not files. OK, I was thinking with options as pause and go back in time, but you only intend linear streaming. Sorry for the misunderstanding.
On Sat, May 2, 2015 at 10:32 PM, Henk D. Schoneveld <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 21:11, Anatol <anatol2002@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 3 other quality streams form these chunks. This results in a total of 4 hls compatible streams where switching between each of them should be without any problem I think. 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 keyframe lications
Reuben, The whole idea is to avoid intense CPU consumption for LIVE streaming.
On Sat, May 2, 2015 at 8:31 PM, Reuben Martin <reuben.m@gmail.com> wrote:
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 and keyframes of input are never aligned with that.
I’ve had success with it as long as I encode all the derivative streams at once from the same encoder process. This of course can consume significant CPU resources. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Added a small patch to support 'source' option for 'force_key_frames' - https://github.com/anatolschwarz/FFmpeg/commit/1968f5fd83fcece5422b7bca4a37e... On Sun, May 3, 2015 at 2:12 AM, Henk D. Schoneveld <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 22:32, Anatol <anatol2002@gmail.com> wrote:
Henk, Live streaming, not files. OK, I was thinking with options as pause and go back in time, but you only intend linear streaming. Sorry for the misunderstanding.
On Sat, May 2, 2015 at 10:32 PM, Henk D. Schoneveld <belcampo@zonnet.nl> wrote:
On 02 May 2015, at 21:11, Anatol <anatol2002@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 3 other quality streams form these chunks. This results in a total of 4 hls compatible streams where switching between each of them should be without any problem I think. 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 keyframe lications
Reuben, The whole idea is to avoid intense CPU consumption for LIVE streaming.
On Sat, May 2, 2015 at 8:31 PM, Reuben Martin <reuben.m@gmail.com> wrote:
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 and keyframes of input are never aligned with that.
I’ve had success with it as long as I encode all the derivative streams at once from the same encoder process. This of course can consume significant CPU resources. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
participants (4)
-
Anatol -
Haris Zukanovic -
Henk D. Schoneveld -
Reuben Martin