| Message ID | 640f127c-ff4b-c1f9-82b6-063c6e731ba2@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] libavformat/flvdec: add HEVC demuxing support | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | success | Make fate finished |
On 7/25/2021 10:04 AM, Xiaolei Yu wrote: > Explicitly supply an HEVC codec id to enable this feature. > --- > libavformat/flv.h | 1 + > libavformat/flvdec.c | 21 ++++++++++++++++++--- > 2 files changed, 19 insertions(+), 3 deletions(-) This has been rejected time and time again, last time not even a month ago.
On 2021-07-25 19:07, James Almer wrote: > On 7/25/2021 10:04 AM, Xiaolei Yu wrote: >> Explicitly supply an HEVC codec id to enable this feature. >> --- >> libavformat/flv.h | 1 + >> libavformat/flvdec.c | 21 ++++++++++++++++++--- >> 2 files changed, 19 insertions(+), 3 deletions(-) > > This has been rejected time and time again, last time not even a month > ago. We may not support muxing it, since that is apparently out of spec, but what's wrong with demuxing? We support demuxing PCM in MP4 but not muxing it. There are a couple of other examples which I can't recall off hand. Isn't Postel's law accepted here? Regards, Gyan
> 2021年7月26日 上午11:44，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > > > On 2021-07-25 19:07, James Almer wrote: >> On 7/25/2021 10:04 AM, Xiaolei Yu wrote: >>> Explicitly supply an HEVC codec id to enable this feature. >>> --- >>> libavformat/flv.h | 1 + >>> libavformat/flvdec.c | 21 ++++++++++++++++++--- >>> 2 files changed, 19 insertions(+), 3 deletions(-) >> >> This has been rejected time and time again, last time not even a month ago. > > We may not support muxing it, since that is apparently out of spec, but what's wrong with demuxing? > > We support demuxing PCM in MP4 but not muxing it. There are a couple of other examples which I can't recall off hand. Isn't Postel's law accepted here? There maybe have lots of codecs, not only hevc, for example opus av1 vvc av2 vp8 vp9 and so on, but there have no enough codec id in flv format. Yes this patch can fix his hevc in his flv, but cannot fix mine. Because it’s not the only one hevc in flv. And not only one patch for demuxing hevc in flv in history mails. > > Regards, > Gyan > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". Thanks Steven Liu
On 2021-07-26 13:45, Steven Liu wrote: > >> 2021年7月26日 上午11:44，Gyan Doshi <ffmpeg@gyani.pro> 写道： >> >> >> >> On 2021-07-25 19:07, James Almer wrote: >>> On 7/25/2021 10:04 AM, Xiaolei Yu wrote: >>>> Explicitly supply an HEVC codec id to enable this feature. >>>> --- >>>> libavformat/flv.h | 1 + >>>> libavformat/flvdec.c | 21 ++++++++++++++++++--- >>>> 2 files changed, 19 insertions(+), 3 deletions(-) >>> This has been rejected time and time again, last time not even a month ago. >> We may not support muxing it, since that is apparently out of spec, but what's wrong with demuxing? >> >> We support demuxing PCM in MP4 but not muxing it. There are a couple of other examples which I can't recall off hand. Isn't Postel's law accepted here? > There maybe have lots of codecs, not only hevc, for example opus av1 vvc av2 vp8 vp9 and so on, but there have no enough codec id in flv format. > Yes this patch can fix his hevc in his flv, but cannot fix mine. Because it’s not the only one hevc in flv. And not only one patch for demuxing hevc in flv in history mails. Are you referring to the choice of FLV_CODECID values? Regards, Gyan
> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > Are you referring to the choice of FLV_CODECID values? Not only, you can find whole history on: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ https://trac.ffmpeg.org/ticket/6389 https://trac.ffmpeg.org/ticket/3581 And there have lots of use case in China Mainland: https://github.com/CDN-Union/Code As many developers said in irc, maybe there need some add a new format looks like flv in RFC or IEEE, I think this is a better way, or choose mkv :D Thanks Steven Liu
On 2021-07-26 16:39, Steven Liu wrote: > >> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： >> >> Are you referring to the choice of FLV_CODECID values? > Not only, you can find whole history on: > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ > https://trac.ffmpeg.org/ticket/6389 > https://trac.ffmpeg.org/ticket/3581 The objections mainly center on compliance with Adobe's spec which is a concern when muxing. This patch is only concerned with demuxing, so we are only talking about files generated by others. The only technical issue is the assignment of FLV_CODECID which can be mitigated by letting the user specify it at runtime. So muxers which use different values can be accommodated. About other codecs, HW enc/dec for HEVC are widely available, not so for VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near or mid-term. Regards, Gyan
在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > > On 2021-07-26 16:39, Steven Liu wrote: > >> >> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>> >>> Are you referring to the choice of FLV_CODECID values? >>> >> Not only, you can find whole history on: >> >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >> https://trac.ffmpeg.org/ticket/6389 >> https://trac.ffmpeg.org/ticket/3581 >> > try play this sample in ticket > The objections mainly center on compliance with Adobe's spec which is a > concern when muxing. > > no not only muxing, it’s format spec, and no documentation said which codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc from users flv? This is very unreasonable. > This patch is only concerned with demuxing, so we are only talking about > files generated by others. > > The only technical issue is the assignment of FLV_CODECID which can be > mitigated by letting the user specify it at runtime. So muxers which use > different values can be accommodated. > > About other codecs, HW enc/dec for HEVC are widely available, not so for > VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near or > mid-term. opus? HEVC is just one codec today, what about tomorrow? This is why so many people objection about this kind of patchset. > > Regards, > Gyan > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On 2021-07-26 19:49, Steven Liu wrote: > 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： > >> >> On 2021-07-26 16:39, Steven Liu wrote: >> >>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>>> Are you referring to the choice of FLV_CODECID values? >>>> >>> Not only, you can find whole history on: >>> >>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >>> https://trac.ffmpeg.org/ticket/6389 >>> https://trac.ffmpeg.org/ticket/3581 >>> >> try play this sample in ticket >> The objections mainly center on compliance with Adobe's spec which is a >> concern when muxing. >> >> no not only muxing, it’s format spec, and no documentation said which > codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc > from users flv? This is very unreasonable. By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... >> This patch is only concerned with demuxing, so we are only talking about >> files generated by others. >> >> The only technical issue is the assignment of FLV_CODECID which can be >> mitigated by letting the user specify it at runtime. So muxers which use >> different values can be accommodated. >> >> About other codecs, HW enc/dec for HEVC are widely available, not so for >> VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near or >> mid-term. > opus? HEVC is just one codec today, what about tomorrow? This is why so > many people objection about this kind of patchset. The slippery slope is theoretical. It will only come up when *other* FLV producers start muxing new codecs and *other* consumers start accepting such files. Without that co-ordination and certain amount of market buy-in, this is not a concern. Regards, Gyan > >> Regards, >> Gyan >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".
On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi <ffmpeg@gyani.pro> wrote: > > > > On 2021-07-26 19:49, Steven Liu wrote: > > 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > > >> > >> On 2021-07-26 16:39, Steven Liu wrote: > >> > >>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： > >>>> Are you referring to the choice of FLV_CODECID values? > >>>> > >>> Not only, you can find whole history on: > >>> > >>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ > >>> https://trac.ffmpeg.org/ticket/6389 > >>> https://trac.ffmpeg.org/ticket/3581 > >>> > >> try play this sample in ticket > >> The objections mainly center on compliance with Adobe's spec which is a > >> concern when muxing. > >> > >> no not only muxing, it’s format spec, and no documentation said which > > codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc > > from users flv? This is very unreasonable. > > By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... > > Which just screams ugly hack even more then anything else. Maybe FLV should just export any unknown streams as data and the user can just deal with identifying and using them. - Hendrik
在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > > On 2021-07-26 19:49, Steven Liu wrote: > >> 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： >> >> >>> On 2021-07-26 16:39, Steven Liu wrote: >>> >>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>>> >>>>> Are you referring to the choice of FLV_CODECID values? >>>>> >>>>> Not only, you can find whole history on: >>>> >>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >>>> https://trac.ffmpeg.org/ticket/6389 >>>> https://trac.ffmpeg.org/ticket/3581 >>>> >>>> try play this sample in ticket >>> The objections mainly center on compliance with Adobe's spec which is a >>> concern when muxing. >>> >>> no not only muxing, it’s format spec, and no documentation said which >>> >> codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is >> hevc >> from users flv? This is very unreasonable. >> > > By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... i do not think this can play all flv from other muxing, just private demuxing, so why add it in ffmpeg? It is your private format, it can not play all flv with hevc. > > > This patch is only concerned with demuxing, so we are only talking about >>> files generated by others. >>> >>> The only technical issue is the assignment of FLV_CODECID which can be >>> mitigated by letting the user specify it at runtime. So muxers which use >>> different values can be accommodated. >>> >>> About other codecs, HW enc/dec for HEVC are widely available, not so for >>> VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near >>> or >>> mid-term. >>> >> opus? HEVC is just one codec today, what about tomorrow? This is why so >> many people objection about this kind of patchset. >> > > The slippery slope is theoretical. It will only come up when *other* FLV > producers start muxing new codecs and *other* consumers start accepting > such files. > Without that co-ordination and certain amount of market buy-in, this is > not a concern. Of course, We are using now, ok? > > Regards, > Gyan > > > >> Regards, >>> Gyan >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@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-request@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-request@ffmpeg.org with subject "unsubscribe". >
在 2021年7月27日星期二，Hendrik Leppkes <h.leppkes@gmail.com> 写道： > On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi <ffmpeg@gyani.pro> wrote: > > > > > > > > On 2021-07-26 19:49, Steven Liu wrote: > > > 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > > > > >> > > >> On 2021-07-26 16:39, Steven Liu wrote: > > >> > > >>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > >>>> Are you referring to the choice of FLV_CODECID values? > > >>>> > > >>> Not only, you can find whole history on: > > >>> > > >>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ > > >>> https://trac.ffmpeg.org/ticket/6389 > > >>> https://trac.ffmpeg.org/ticket/3581 > > >>> > > >> try play this sample in ticket > > >> The objections mainly center on compliance with Adobe's spec which is > a > > >> concern when muxing. > > >> > > >> no not only muxing, it’s format spec, and no documentation said which > > > codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is > hevc > > > from users flv? This is very unreasonable. > > > > By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... > > > > > > Which just screams ugly hack even more then anything else. > Maybe FLV should just export any unknown streams as data and the user > can just deal with identifying and using them. Third way about flv with hevc/av1/opus. :D > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On 2021-07-26 22:51, Hendrik Leppkes wrote: > On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi <ffmpeg@gyani.pro> wrote: >> >> >> On 2021-07-26 19:49, Steven Liu wrote: >>> 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>> >>>> On 2021-07-26 16:39, Steven Liu wrote: >>>> >>>>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>>>>> Are you referring to the choice of FLV_CODECID values? >>>>>> >>>>> Not only, you can find whole history on: >>>>> >>>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >>>>> https://trac.ffmpeg.org/ticket/6389 >>>>> https://trac.ffmpeg.org/ticket/3581 >>>>> >>>> try play this sample in ticket >>>> The objections mainly center on compliance with Adobe's spec which is a >>>> concern when muxing. >>>> >>>> no not only muxing, it’s format spec, and no documentation said which >>> codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc >>> from users flv? This is very unreasonable. >> By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... >> >> > Which just screams ugly hack even more then anything else. Of course. The format is alive but the publisher has abandoned it, so hacks are all that is left. Gyan
On 2021-07-27 04:28, Steven Liu wrote: > 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： > >> >> On 2021-07-26 19:49, Steven Liu wrote: >> >>> 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>> >>> >>>> On 2021-07-26 16:39, Steven Liu wrote: >>>> >>>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>>>>> Are you referring to the choice of FLV_CODECID values? >>>>>> >>>>>> Not only, you can find whole history on: >>>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >>>>> https://trac.ffmpeg.org/ticket/6389 >>>>> https://trac.ffmpeg.org/ticket/3581 >>>>> >>>>> try play this sample in ticket >>>> The objections mainly center on compliance with Adobe's spec which is a >>>> concern when muxing. >>>> >>>> no not only muxing, it’s format spec, and no documentation said which >>>> >>> codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is >>> hevc >>> from users flv? This is very unreasonable. >>> >> By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... > i do not think this can play all flv from other muxing, just private > demuxing, so why add it in ffmpeg? It is your private format, it can not > play all flv with hevc. Is there a sample HEVC-in-FLV file for which this method won't work? Regards, Gyan
在 2021年7月27日星期二，Gyan Doshi <ffmpeg@gyani.pro> 写道： > > > On 2021-07-27 04:28, Steven Liu wrote: > >> 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： >> >> >>> On 2021-07-26 19:49, Steven Liu wrote: >>> >>> 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>>> >>>> >>>> On 2021-07-26 16:39, Steven Liu wrote: >>>>> >>>>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： >>>>> >>>>>> Are you referring to the choice of FLV_CODECID values? >>>>>>> >>>>>>> Not only, you can find whole history on: >>>>>>> >>>>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >>>>>> https://trac.ffmpeg.org/ticket/6389 >>>>>> https://trac.ffmpeg.org/ticket/3581 >>>>>> >>>>>> try play this sample in ticket >>>>>> >>>>> The objections mainly center on compliance with Adobe's spec which is a >>>>> concern when muxing. >>>>> >>>>> no not only muxing, it’s format spec, and no documentation said which >>>>> >>>>> codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is >>>> hevc >>>> from users flv? This is very unreasonable. >>>> >>>> By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... >>> >> i do not think this can play all flv from other muxing, just private >> demuxing, so why add it in ffmpeg? It is your private format, it can not >> play all flv with hevc. >> > > Is there a sample HEVC-in-FLV file for which this method won't work? Maybe you can find it in the past mail context > > Regards, > Gyan > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Tue, Jul 27, 2021 at 5:50 AM Gyan Doshi <ffmpeg@gyani.pro> wrote: > > > > On 2021-07-26 22:51, Hendrik Leppkes wrote: > > On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi <ffmpeg@gyani.pro> wrote: > >> > >> > >> On 2021-07-26 19:49, Steven Liu wrote: > >>> 在 2021年7月26日星期一，Gyan Doshi <ffmpeg@gyani.pro> 写道： > >>> > >>>> On 2021-07-26 16:39, Steven Liu wrote: > >>>> > >>>>> 2021年7月26日 下午6:57，Gyan Doshi <ffmpeg@gyani.pro> 写道： > >>>>>> Are you referring to the choice of FLV_CODECID values? > >>>>>> > >>>>> Not only, you can find whole history on: > >>>>> > >>>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ > >>>>> https://trac.ffmpeg.org/ticket/6389 > >>>>> https://trac.ffmpeg.org/ticket/3581 > >>>>> > >>>> try play this sample in ticket > >>>> The objections mainly center on compliance with Adobe's spec which is a > >>>> concern when muxing. > >>>> > >>>> no not only muxing, it’s format spec, and no documentation said which > >>> codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc > >>> from users flv? This is very unreasonable. > >> By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... > >> > >> > > Which just screams ugly hack even more then anything else. > > Of course. The format is alive but the publisher has abandoned it, so > hacks are all that is left. > That doesn't mean we have to endorse those hacks. HEVC in FLV, and a few other codecs, have been brought up numerous times. You can find all the arguments in the ML archives. Just posting yet-another-patch is not going to change those arguments or the reasons to not apply such a patch. - Hendrik
On Tue, 27 Jul 2021, at 05:49, Gyan Doshi wrote: > Of course. The format is alive but the publisher has abandoned it, so > hacks are all that is left. Or you define a proper extension with proper documentation and reviewing.
diff --git a/libavformat/flv.h b/libavformat/flv.h index 3571b90279..7cb1b72b4c 100644 --- a/libavformat/flv.h +++ b/libavformat/flv.h @@ -42,6 +42,7 @@ #define FLV_AUDIO_CODECID_MASK 0xf0 #define FLV_VIDEO_CODECID_MASK 0x0f +#define FLV_VIDEO_CODECID_MAX 0x0f #define FLV_VIDEO_FRAMETYPE_MASK 0xf0 #define AMF_END_OF_OBJECT 0x09 diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c index b4a419177a..e44aa693b7 100644 --- a/libavformat/flvdec.c +++ b/libavformat/flvdec.c @@ -74,6 +74,7 @@ typedef struct FLVContext { int64_t *keyframe_times; int64_t *keyframe_filepositions; int missing_streams; + int hevc_codec_id; AVRational framerate; int64_t last_ts; int64_t time_offset; @@ -301,7 +302,7 @@ static void flv_set_audio_codec(AVFormatContext *s, AVStream *astream, } } -static int flv_same_video_codec(AVCodecParameters *vpar, int flags) +static int flv_same_video_codec(FLVContext *flv, AVCodecParameters *vpar, int flags) { int flv_codecid = flags & FLV_VIDEO_CODECID_MASK; @@ -322,6 +323,8 @@ static int flv_same_video_codec(AVCodecParameters *vpar, int flags) case FLV_CODECID_H264: return vpar->codec_id == AV_CODEC_ID_H264; default: + if (flv->hevc_codec_id && flv_codecid == flv->hevc_codec_id) + return vpar->codec_id == AV_CODEC_ID_HEVC; return vpar->codec_tag == flv_codecid; } } @@ -329,6 +332,7 @@ static int flv_same_video_codec(AVCodecParameters *vpar, int flags) static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream, int flv_codecid, int read) { + FLVContext *flv = s->priv_data; int ret = 0; AVCodecParameters *par = vstream->codecpar; enum AVCodecID old_codec_id = vstream->codecpar->codec_id; @@ -371,6 +375,12 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream, ret = 3; break; default: + if (flv->hevc_codec_id && flv_codecid == flv->hevc_codec_id) { + par->codec_id = AV_CODEC_ID_HEVC; + vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS; + ret = 3; // not 4, reading packet type will consume one byte + break; + } avpriv_request_sample(s, "Video codec (%x)", flv_codecid); par->codec_tag = flv_codecid; } @@ -1126,7 +1136,7 @@ skip: break; } else if (stream_type == FLV_STREAM_TYPE_VIDEO) { if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO && - (s->video_codec_id || flv_same_video_codec(st->codecpar, flags))) + (s->video_codec_id || flv_same_video_codec(flv, st->codecpar, flags))) break; } else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) { if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE) @@ -1241,6 +1251,7 @@ retry_duration: if (st->codecpar->codec_id == AV_CODEC_ID_AAC || st->codecpar->codec_id == AV_CODEC_ID_H264 || + st->codecpar->codec_id == AV_CODEC_ID_HEVC || st->codecpar->codec_id == AV_CODEC_ID_MPEG4) { int type = avio_r8(s->pb); size--; @@ -1250,7 +1261,9 @@ retry_duration: goto leave; } - if (st->codecpar->codec_id == AV_CODEC_ID_H264 || st->codecpar->codec_id == AV_CODEC_ID_MPEG4) { + if (st->codecpar->codec_id == AV_CODEC_ID_H264 || + st->codecpar->codec_id == AV_CODEC_ID_HEVC || + st->codecpar->codec_id == AV_CODEC_ID_MPEG4) { // sign extension int32_t cts = (avio_rb24(s->pb) + 0xff800000) ^ 0xff800000; pts = av_sat_add64(dts, cts); @@ -1266,6 +1279,7 @@ retry_duration: } } if (type == 0 && (!st->codecpar->extradata || st->codecpar->codec_id == AV_CODEC_ID_AAC || + st->codecpar->codec_id == AV_CODEC_ID_HEVC || st->codecpar->codec_id == AV_CODEC_ID_H264)) { AVDictionaryEntry *t; @@ -1361,6 +1375,7 @@ static const AVOption options[] = { { "flv_metadata", "Allocate streams according to the onMetaData array", OFFSET(trust_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD }, { "flv_full_metadata", "Dump full metadata of the onMetadata", OFFSET(dump_full_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD }, { "flv_ignore_prevtag", "Ignore the Size of previous tag", OFFSET(trust_datasize), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD }, + { "flv_hevc_codec_id", "Assign HEVC stream codec ID", OFFSET(hevc_codec_id), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, FLV_VIDEO_CODECID_MAX, VD }, { "missing_streams", "", OFFSET(missing_streams), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 0xFF, VD | AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY }, { NULL } };