diff mbox series

[FFmpeg-devel,1/3] avformat/flv: add support for h265 streams

Message ID 20210701141528.776-1-jamrial@gmail.com
State New
Headers show
Series [FFmpeg-devel,1/3] avformat/flv: add support for h265 streams | expand

Checks

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

Commit Message

James Almer July 1, 2021, 2:15 p.m. UTC 
From: Matthieu Patou <mpatou@fb.com>

Suggested-by: ffmpeg@fb.com
Signed-off-by: James Almer <jamrial@gmail.com>
---
 libavformat/flv.h    |  1 +
 libavformat/flvdec.c | 14 ++++++++++++--
 2 files changed, 13 insertions(+), 2 deletions(-)

Comments

Andreas Rheinhardt July 1, 2021, 2:27 p.m. UTC | #1 
James Almer:
> From: Matthieu Patou <mpatou@fb.com>
> 
> Suggested-by: ffmpeg@fb.com
> Signed-off-by: James Almer <jamrial@gmail.com>
> ---
>  libavformat/flv.h    |  1 +
>  libavformat/flvdec.c | 14 ++++++++++++--
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/flv.h b/libavformat/flv.h
> index 3571b90279..7a026d3217 100644
> --- a/libavformat/flv.h
> +++ b/libavformat/flv.h
> @@ -110,6 +110,7 @@ enum {
>      FLV_CODECID_H264    = 7,
>      FLV_CODECID_REALH263= 8,
>      FLV_CODECID_MPEG4   = 9,
> +    FLV_CODECID_H265    = 10,
>  };

Is there an official source for these numbers?

>  
>  enum {
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 60d1a5c654..ba60d71196 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -321,6 +321,8 @@ static int flv_same_video_codec(AVCodecParameters *vpar, int flags)
>          return vpar->codec_id == AV_CODEC_ID_VP6A;
>      case FLV_CODECID_H264:
>          return vpar->codec_id == AV_CODEC_ID_H264;
> +    case FLV_CODECID_H265:
> +        return vpar->codec_id == AV_CODEC_ID_H265;
>      default:
>          return vpar->codec_tag == flv_codecid;
>      }
> @@ -366,6 +368,11 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream,
>          vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
>          ret = 3;     // not 4, reading packet type will consume one byte
>          break;
> +    case FLV_CODECID_H265:
> +        par->codec_id = AV_CODEC_ID_H265;
> +        vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
> +        ret = 3;     // not 4, reading packet type will consume one byte
> +        break;
>      case FLV_CODECID_MPEG4:
>          par->codec_id = AV_CODEC_ID_MPEG4;
>          ret = 3;
> @@ -1241,6 +1248,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_H265 ||
>          st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
>          int type = avio_r8(s->pb);
>          size--;
> @@ -1250,7 +1258,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_H265 ||
> +            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,7 +1276,7 @@ retry_duration:
>              }
>          }
>          if (type == 0 && (!st->codecpar->extradata || st->codecpar->codec_id == AV_CODEC_ID_AAC ||
> -            st->codecpar->codec_id == AV_CODEC_ID_H264)) {
> +            st->codecpar->codec_id == AV_CODEC_ID_H264 || st->codecpar->codec_id == AV_CODEC_ID_H265)) {
>              AVDictionaryEntry *t;
>  
>              if (st->codecpar->extradata) {
>
James Almer July 1, 2021, 2:41 p.m. UTC | #2 
On 7/1/2021 11:27 AM, Andreas Rheinhardt wrote:
> James Almer:
>> From: Matthieu Patou <mpatou@fb.com>
>>
>> Suggested-by: ffmpeg@fb.com
>> Signed-off-by: James Almer <jamrial@gmail.com>
>> ---
>>   libavformat/flv.h    |  1 +
>>   libavformat/flvdec.c | 14 ++++++++++++--
>>   2 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/flv.h b/libavformat/flv.h
>> index 3571b90279..7a026d3217 100644
>> --- a/libavformat/flv.h
>> +++ b/libavformat/flv.h
>> @@ -110,6 +110,7 @@ enum {
>>       FLV_CODECID_H264    = 7,
>>       FLV_CODECID_REALH263= 8,
>>       FLV_CODECID_MPEG4   = 9,
>> +    FLV_CODECID_H265    = 10,
>>   };
> 
> Is there an official source for these numbers?

Apparently no. Neither does REALH263 or MPEG4 as far as i can see. But 
if there are files out there that can be demuxed with this change, as 
long as we don't support creating them, it should be fine.

> 
>>   
>>   enum {
>> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>> index 60d1a5c654..ba60d71196 100644
>> --- a/libavformat/flvdec.c
>> +++ b/libavformat/flvdec.c
>> @@ -321,6 +321,8 @@ static int flv_same_video_codec(AVCodecParameters *vpar, int flags)
>>           return vpar->codec_id == AV_CODEC_ID_VP6A;
>>       case FLV_CODECID_H264:
>>           return vpar->codec_id == AV_CODEC_ID_H264;
>> +    case FLV_CODECID_H265:
>> +        return vpar->codec_id == AV_CODEC_ID_H265;
>>       default:
>>           return vpar->codec_tag == flv_codecid;
>>       }
>> @@ -366,6 +368,11 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream,
>>           vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
>>           ret = 3;     // not 4, reading packet type will consume one byte
>>           break;
>> +    case FLV_CODECID_H265:
>> +        par->codec_id = AV_CODEC_ID_H265;
>> +        vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
>> +        ret = 3;     // not 4, reading packet type will consume one byte
>> +        break;
>>       case FLV_CODECID_MPEG4:
>>           par->codec_id = AV_CODEC_ID_MPEG4;
>>           ret = 3;
>> @@ -1241,6 +1248,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_H265 ||
>>           st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
>>           int type = avio_r8(s->pb);
>>           size--;
>> @@ -1250,7 +1258,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_H265 ||
>> +            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,7 +1276,7 @@ retry_duration:
>>               }
>>           }
>>           if (type == 0 && (!st->codecpar->extradata || st->codecpar->codec_id == AV_CODEC_ID_AAC ||
>> -            st->codecpar->codec_id == AV_CODEC_ID_H264)) {
>> +            st->codecpar->codec_id == AV_CODEC_ID_H264 || st->codecpar->codec_id == AV_CODEC_ID_H265)) {
>>               AVDictionaryEntry *t;
>>   
>>               if (st->codecpar->extradata) {
>>
> 
> _______________________________________________
> 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".
>
James Almer July 1, 2021, 4:15 p.m. UTC | #3 
On 7/1/2021 11:41 AM, James Almer wrote:
> On 7/1/2021 11:27 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> From: Matthieu Patou <mpatou@fb.com>
>>>
>>> Suggested-by: ffmpeg@fb.com
>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>> ---
>>>   libavformat/flv.h    |  1 +
>>>   libavformat/flvdec.c | 14 ++++++++++++--
>>>   2 files changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/flv.h b/libavformat/flv.h
>>> index 3571b90279..7a026d3217 100644
>>> --- a/libavformat/flv.h
>>> +++ b/libavformat/flv.h
>>> @@ -110,6 +110,7 @@ enum {
>>>       FLV_CODECID_H264    = 7,
>>>       FLV_CODECID_REALH263= 8,
>>>       FLV_CODECID_MPEG4   = 9,
>>> +    FLV_CODECID_H265    = 10,
>>>   };
>>
>> Is there an official source for these numbers?
> 
> Apparently no. Neither does REALH263 or MPEG4 as far as i can see. But 
> if there are files out there that can be demuxed with this change, as 
> long as we don't support creating them, it should be fine.

There was some discussion on IRC and an old trac ticket where we had 
decided to strictly support only what Apple defined in the spec was 
linked as reference, so I'm withdrawing this set.
RADSL July 1, 2021, 4:21 p.m. UTC | #4 
On 7/1/2021 9:15 AM, James Almer wrote:
> On 7/1/2021 11:41 AM, James Almer wrote:
>> On 7/1/2021 11:27 AM, Andreas Rheinhardt wrote:
>>> James Almer:
>>>> From: Matthieu Patou <mpatou@fb.com>
>>>>
>>>> Suggested-by: ffmpeg@fb.com
>>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>>> ---
>>>>   libavformat/flv.h    |  1 +
>>>>   libavformat/flvdec.c | 14 ++++++++++++--
>>>>   2 files changed, 13 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/libavformat/flv.h b/libavformat/flv.h
>>>> index 3571b90279..7a026d3217 100644
>>>> --- a/libavformat/flv.h
>>>> +++ b/libavformat/flv.h
>>>> @@ -110,6 +110,7 @@ enum {
>>>>       FLV_CODECID_H264    = 7,
>>>>       FLV_CODECID_REALH263= 8,
>>>>       FLV_CODECID_MPEG4   = 9,
>>>> +    FLV_CODECID_H265    = 10,
>>>>   };
>>>
>>> Is there an official source for these numbers?
>>
>> Apparently no. Neither does REALH263 or MPEG4 as far as i can see. 
>> But if there are files out there that can be demuxed with this 
>> change, as long as we don't support creating them, it should be fine.
>
> There was some discussion on IRC and an old trac ticket where we had 
> decided to strictly support only what Apple defined in the spec was 
> linked as reference, so I'm withdrawing this set.
> _______________________________________________
You mean "Adobe" rather than "Apple"....
James Almer July 1, 2021, 4:22 p.m. UTC | #5 
On 7/1/2021 1:21 PM, RADSL wrote:
> 
> On 7/1/2021 9:15 AM, James Almer wrote:
>> On 7/1/2021 11:41 AM, James Almer wrote:
>>> On 7/1/2021 11:27 AM, Andreas Rheinhardt wrote:
>>>> James Almer:
>>>>> From: Matthieu Patou <mpatou@fb.com>
>>>>>
>>>>> Suggested-by: ffmpeg@fb.com
>>>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>>>> ---
>>>>>   libavformat/flv.h    |  1 +
>>>>>   libavformat/flvdec.c | 14 ++++++++++++--
>>>>>   2 files changed, 13 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/libavformat/flv.h b/libavformat/flv.h
>>>>> index 3571b90279..7a026d3217 100644
>>>>> --- a/libavformat/flv.h
>>>>> +++ b/libavformat/flv.h
>>>>> @@ -110,6 +110,7 @@ enum {
>>>>>       FLV_CODECID_H264    = 7,
>>>>>       FLV_CODECID_REALH263= 8,
>>>>>       FLV_CODECID_MPEG4   = 9,
>>>>> +    FLV_CODECID_H265    = 10,
>>>>>   };
>>>>
>>>> Is there an official source for these numbers?
>>>
>>> Apparently no. Neither does REALH263 or MPEG4 as far as i can see. 
>>> But if there are files out there that can be demuxed with this 
>>> change, as long as we don't support creating them, it should be fine.
>>
>> There was some discussion on IRC and an old trac ticket where we had 
>> decided to strictly support only what Apple defined in the spec was 
>> linked as reference, so I'm withdrawing this set.
>> _______________________________________________
> You mean "Adobe" rather than "Apple"....

Yes, brain fart, my bad.
Jean-Baptiste Kempf July 1, 2021, 4:23 p.m. UTC | #6 
On Thu, 1 Jul 2021, at 18:15, James Almer wrote:
> >> Is there an official source for these numbers?
> > 
> > Apparently no. Neither does REALH263 or MPEG4 as far as i can see. But 
> > if there are files out there that can be demuxed with this change, as 
> > long as we don't support creating them, it should be fine.
> 
> There was some discussion on IRC and an old trac ticket where we had 
> decided to strictly support only what Apple defined in the spec was 
> linked as reference, so I'm withdrawing this set.

What I suggested, in the past, is to use the last ID (16?) to define an extra header, that would allow other FourCC, like H265, VP8/VP9, since that ID is not used anywhere I've seen yet.
It needs a documentation, though, since Adobe stopped working on the format.

Best,
Thomas Volkert July 1, 2021, 4:25 p.m. UTC | #7 
On 01.07.2021 18:15, James Almer wrote:
> On 7/1/2021 11:41 AM, James Almer wrote:
>> On 7/1/2021 11:27 AM, Andreas Rheinhardt wrote:
>>> James Almer:
>>>> From: Matthieu Patou <mpatou@fb.com>
>>>>
>>>> Suggested-by: ffmpeg@fb.com
>>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>>> ---
>>>>   libavformat/flv.h    |  1 +
>>>>   libavformat/flvdec.c | 14 ++++++++++++--
>>>>   2 files changed, 13 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/libavformat/flv.h b/libavformat/flv.h
>>>> index 3571b90279..7a026d3217 100644
>>>> --- a/libavformat/flv.h
>>>> +++ b/libavformat/flv.h
>>>> @@ -110,6 +110,7 @@ enum {
>>>>       FLV_CODECID_H264    = 7,
>>>>       FLV_CODECID_REALH263= 8,
>>>>       FLV_CODECID_MPEG4   = 9,
>>>> +    FLV_CODECID_H265    = 10,
>>>>   };
>>>
>>> Is there an official source for these numbers?
>>
>> Apparently no. Neither does REALH263 or MPEG4 as far as i can see.
>> But if there are files out there that can be demuxed with this
>> change, as long as we don't support creating them, it should be fine.
>
> There was some discussion on IRC and an old trac ticket where we had
> decided to strictly support only what Apple defined in the spec was
> linked as reference, so I'm withdrawing this set.

I was also about to prepare a discussion mail against this patch set. We
shouldn't fuzzy the spec.

So.. +1 for skipping this patch set.

Best regards.
James Almer July 1, 2021, 4:27 p.m. UTC | #8 
On 7/1/2021 1:25 PM, Thomas Volkert wrote:
> 
> On 01.07.2021 18:15, James Almer wrote:
>> On 7/1/2021 11:41 AM, James Almer wrote:
>>> On 7/1/2021 11:27 AM, Andreas Rheinhardt wrote:
>>>> James Almer:
>>>>> From: Matthieu Patou <mpatou@fb.com>
>>>>>
>>>>> Suggested-by: ffmpeg@fb.com
>>>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>>>> ---
>>>>>    libavformat/flv.h    |  1 +
>>>>>    libavformat/flvdec.c | 14 ++++++++++++--
>>>>>    2 files changed, 13 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/libavformat/flv.h b/libavformat/flv.h
>>>>> index 3571b90279..7a026d3217 100644
>>>>> --- a/libavformat/flv.h
>>>>> +++ b/libavformat/flv.h
>>>>> @@ -110,6 +110,7 @@ enum {
>>>>>        FLV_CODECID_H264    = 7,
>>>>>        FLV_CODECID_REALH263= 8,
>>>>>        FLV_CODECID_MPEG4   = 9,
>>>>> +    FLV_CODECID_H265    = 10,
>>>>>    };
>>>>
>>>> Is there an official source for these numbers?
>>>
>>> Apparently no. Neither does REALH263 or MPEG4 as far as i can see.
>>> But if there are files out there that can be demuxed with this
>>> change, as long as we don't support creating them, it should be fine.
>>
>> There was some discussion on IRC and an old trac ticket where we had
>> decided to strictly support only what Apple defined in the spec was
>> linked as reference, so I'm withdrawing this set.
> 
> I was also about to prepare a discussion mail against this patch set. We
> shouldn't fuzzy the spec.

Please do it, since Jean-Baptiste Kempf started a discussion on this set 
anyway.

> 
> So.. +1 for skipping this patch set.
> 
> Best regards.
> _______________________________________________
> 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".
>
RADSL July 1, 2021, 4:30 p.m. UTC | #9 
On 7/1/2021 9:23 AM, Jean-Baptiste Kempf wrote:
> On Thu, 1 Jul 2021, at 18:15, James Almer wrote:
>>>> Is there an official source for these numbers?
>>> Apparently no. Neither does REALH263 or MPEG4 as far as i can see. But
>>> if there are files out there that can be demuxed with this change, as
>>> long as we don't support creating them, it should be fine.
>> There was some discussion on IRC and an old trac ticket where we had
>> decided to strictly support only what Apple defined in the spec was
>> linked as reference, so I'm withdrawing this set.
> What I suggested, in the past, is to use the last ID (16?) to define an extra header, that would allow other FourCC, like H265, VP8/VP9, since that ID is not used anywhere I've seen yet.
> It needs a documentation, though, since Adobe stopped working on the format.
>
> Best,
But FLV format is since 10 years in open source no?
Derek Buitenhuis July 1, 2021, 4:58 p.m. UTC | #10 
On 7/1/2021 5:25 PM, Thomas Volkert wrote:
> I was also about to prepare a discussion mail against this patch set. We
> shouldn't fuzzy the spec.
> 
> So.. +1 for skipping this patch set.

Hard NAK from me as well. We've rejected essentially this same thing several times,
and the reasonign has not changed.

We should not be extending FLV in incompatible ways (which adding an ID would be).

Frankly, people should not be using HEVC, VPx, or Opus in RTMP (I assum this is the intent of this)
either.

- Derek
Jan Ekström July 1, 2021, 5:48 p.m. UTC | #11 
On Thu, Jul 1, 2021 at 5:16 PM James Almer <jamrial@gmail.com> wrote:
>
> From: Matthieu Patou <mpatou@fb.com>
>
> Suggested-by: ffmpeg@fb.com
> Signed-off-by: James Almer <jamrial@gmail.com>
> ---

For the record, if Big Companies such as FB or Bilibili want to keep
on dragging FLV/RTMP around I recommend:

1. Create something like
https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ for FLV.
2. Have Adobe refer to that registry as the Point of Truth in their
spec/document.

That way we have a spec and Adobe does not have to update anything
beyond pointing towards the open codec register.

But really, I would just prefer the "no manifest live stream via TCP"
crowd that utilizes RTMP to just pivot towards either streamable
matroska or fragmented mp4 over plain TCP or HTTP. If I recall
correctly Icecast already has basic live Matroska over HTTP support
implemented so it's not like PoCs cannot be created with relatively
existing software?

Best regards,
Jan
Martin Storsjö July 1, 2021, 7:21 p.m. UTC | #12 
On Thu, 1 Jul 2021, Jan Ekström wrote:

> On Thu, Jul 1, 2021 at 5:16 PM James Almer <jamrial@gmail.com> wrote:
>>
>> From: Matthieu Patou <mpatou@fb.com>
>>
>> Suggested-by: ffmpeg@fb.com
>> Signed-off-by: James Almer <jamrial@gmail.com>
>> ---
>
> For the record, if Big Companies such as FB or Bilibili want to keep
> on dragging FLV/RTMP around I recommend:
>
> 1. Create something like
> https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ for FLV.
> 2. Have Adobe refer to that registry as the Point of Truth in their
> spec/document.
>
> That way we have a spec and Adobe does not have to update anything
> beyond pointing towards the open codec register.

+1 on something like this. There has to be some sort of official spec for 
it, with at least a handwavy acknowledgement from Adobe.

And some more extensible way of signaling codecs might be good like JB 
suggests (although it makes the FLV stream much more cumbersome compared 
to other codecs), because the field only allows IDs 0-15, out of which 
already over half of them are defined, and if defining more of them, we're 
very soon out of numbers.

// Martin
libav@airmail.cc July 1, 2021, 8:03 p.m. UTC | #13 
On 2021-07-01 12:58, Derek Buitenhuis wrote:
> On 7/1/2021 5:25 PM, Thomas Volkert wrote:
>> I was also about to prepare a discussion mail against this patch set. 
>> We
>> shouldn't fuzzy the spec.
>> 
>> So.. +1 for skipping this patch set.
> 
> Hard NAK from me as well. We've rejected essentially this same thing
> several times,
> and the reasonign has not changed.
> 

Yeah i'm going to have to agree with Derek on this one, and you know 
when me and Derek agree on the same thing, it's probably the right 
thing.
> We should not be extending FLV in incompatible ways (which adding an
> ID would be).
> 
> Frankly, people should not be using HEVC, VPx, or Opus in RTMP (I
> assum this is the intent of this)
Agree.
> either.
> 
> - Derek
> _______________________________________________
> 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".
Zhao Zhili July 2, 2021, 4:54 p.m. UTC | #14 
> On Jul 2, 2021, at 3:21 AM, Martin Storsjö <martin@martin.st> wrote:
> 
> On Thu, 1 Jul 2021, Jan Ekström wrote:
> 
>> On Thu, Jul 1, 2021 at 5:16 PM James Almer <jamrial@gmail.com> wrote:
>>> 
>>> From: Matthieu Patou <mpatou@fb.com>
>>> 
>>> Suggested-by: ffmpeg@fb.com
>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>> ---
>> 
>> For the record, if Big Companies such as FB or Bilibili want to keep
>> on dragging FLV/RTMP around I recommend:
>> 
>> 1. Create something like
>> https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ for FLV.
>> 2. Have Adobe refer to that registry as the Point of Truth in their
>> spec/document.
>> 
>> That way we have a spec and Adobe does not have to update anything
>> beyond pointing towards the open codec register.
> 
> +1 on something like this. There has to be some sort of official spec for it, with at least a handwavy acknowledgement from Adobe.
> 
> And some more extensible way of signaling codecs might be good like JB suggests (although it makes the FLV stream much more cumbersome compared to other codecs), because the field only allows IDs 0-15, out of which already over half of them are defined, and if defining more of them, we're very soon out of numbers.

Here is my two cents.

Firstly, FLV should be deprecated, without adding new codec support.

Secondly, there are a lot of HEVC-in-FLV files exist. From the current patch, I can see a conflict definition of codecid. So now it's too late to file a specification. HEVC-in-FLV is the Titanic after crash into iceberg. So remux those non-standard files to something like mp4 is the only way to save life.

> 
> // Martin
> _______________________________________________
> 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".
>
diff mbox series

Patch

diff --git a/libavformat/flv.h b/libavformat/flv.h
index 3571b90279..7a026d3217 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -110,6 +110,7 @@  enum {
     FLV_CODECID_H264    = 7,
     FLV_CODECID_REALH263= 8,
     FLV_CODECID_MPEG4   = 9,
+    FLV_CODECID_H265    = 10,
 };
 
 enum {
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 60d1a5c654..ba60d71196 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -321,6 +321,8 @@  static int flv_same_video_codec(AVCodecParameters *vpar, int flags)
         return vpar->codec_id == AV_CODEC_ID_VP6A;
     case FLV_CODECID_H264:
         return vpar->codec_id == AV_CODEC_ID_H264;
+    case FLV_CODECID_H265:
+        return vpar->codec_id == AV_CODEC_ID_H265;
     default:
         return vpar->codec_tag == flv_codecid;
     }
@@ -366,6 +368,11 @@  static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream,
         vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
         ret = 3;     // not 4, reading packet type will consume one byte
         break;
+    case FLV_CODECID_H265:
+        par->codec_id = AV_CODEC_ID_H265;
+        vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
+        ret = 3;     // not 4, reading packet type will consume one byte
+        break;
     case FLV_CODECID_MPEG4:
         par->codec_id = AV_CODEC_ID_MPEG4;
         ret = 3;
@@ -1241,6 +1248,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_H265 ||
         st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
         int type = avio_r8(s->pb);
         size--;
@@ -1250,7 +1258,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_H265 ||
+            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,7 +1276,7 @@  retry_duration:
             }
         }
         if (type == 0 && (!st->codecpar->extradata || st->codecpar->codec_id == AV_CODEC_ID_AAC ||
-            st->codecpar->codec_id == AV_CODEC_ID_H264)) {
+            st->codecpar->codec_id == AV_CODEC_ID_H264 || st->codecpar->codec_id == AV_CODEC_ID_H265)) {
             AVDictionaryEntry *t;
 
             if (st->codecpar->extradata) {