On 7/12/2021 11:44 PM, Kieran Kunhya wrote:
On Tue, 13 Jul 2021, 02:45 James Almer, <jamr...@gmail.com> wrote:
On 7/12/2021 10:01 PM, Kieran Kunhya wrote:
Because it isn't something that should be marked as a keyframe as coded
bitstream in any kind of container, like it's the case of mp4 sync
samples.
MPEG-TS Random Access Indicator expects keyframes to be signalled like
this.
With intra-refresh and this code removed, there will be no random access
points at all.
If MPEG-TS wants to tag packets containing things other than IDR access
units as RAPs, then it should analyze the bitstream itself in order to
tag them itself as such in the output.
This parser as is is generating invalid output for other containers that
are strict about key frames, and signal recovery points (like those
indicated by the use of this SEI) by other means.
Why not just detect IDR in containers that only care about that (which is a
mistake because if things like open gop)? Doing that's is relatively simple
compared to adding bitstream parsing into MPEGTS.
Both would require bitstream parsing in a muxer to look at what pictures
are present within the AU in the packet, so I'm inclined to do it for
the muxer that wants to tag more things than normal as keyframes instead
of in every other muxer.
I will keep tagging these packets as keyframes in the parser but behind
a new flag that's disabled by default, then insert an internal instance
of the parser to mpegtsenc with said flag enabled, and use that to mark
mpegts RAPs.
This has the added benefit of marking these packets as RAPs in mpegts on
codec copy scenarios when the source is an mp4 or mkv and the generic
code never uses an AVParser.
Kieran
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
