diff mbox series

[FFmpeg-devel] libavformat/flvdec: add HEVC demuxing support

Message ID 640f127c-ff4b-c1f9-82b6-063c6e731ba2@gmail.com
State New
Headers show
Series [FFmpeg-devel] libavformat/flvdec: add HEVC demuxing support
Related show

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

Xiaolei Yu July 25, 2021, 1:04 p.m. UTC
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(-)

Comments

James Almer July 25, 2021, 1:37 p.m. UTC | #1
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.
Gyan Doshi July 26, 2021, 3:44 a.m. UTC | #2
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
Steven Liu July 26, 2021, 8:15 a.m. UTC | #3
> 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
Gyan Doshi July 26, 2021, 10:57 a.m. UTC | #4
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
Steven Liu July 26, 2021, 11:09 a.m. UTC | #5
> 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
Gyan Doshi July 26, 2021, 1:37 p.m. UTC | #6
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
Steven Liu July 26, 2021, 2:19 p.m. UTC | #7
在 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".
>
Gyan Doshi July 26, 2021, 3:16 p.m. UTC | #8
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".
Hendrik Leppkes July 26, 2021, 5:21 p.m. UTC | #9
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
Steven Liu July 26, 2021, 10:58 p.m. UTC | #10
在 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".
>
Steven Liu July 26, 2021, 11:04 p.m. UTC | #11
在 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".
>
Gyan Doshi July 27, 2021, 3:49 a.m. UTC | #12
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
Gyan Doshi July 27, 2021, 3:53 a.m. UTC | #13
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
Steven Liu July 27, 2021, 4:04 a.m. UTC | #14
在 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".
>
Hendrik Leppkes July 27, 2021, 5:44 a.m. UTC | #15
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
Jean-Baptiste Kempf July 27, 2021, 6:47 a.m. UTC | #16
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 mbox series

Patch

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 }
 };