[FFmpeg-devel] lavf/isom: Recognize fourcc HEVC

Submitted by Carl Eugen Hoyos on May 2, 2018, 6:44 p.m.

Details

Message ID CAB0OVGqE6BuhLzGT9KrevsAr4EAMydQgi5UtGjA3G=Se43GkTg@mail.gmail.com
State New
Headers show

Commit Message

Carl Eugen Hoyos May 2, 2018, 6:44 p.m.
Hi!

Attached patch fixes ticket #7110 for me.

Please comment, Carl Eugen

Comments

James Almer May 2, 2018, 6:52 p.m.
On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #7110 for me.

hevc in AVI is not a thing, and adding a non official fourcc to
ff_codec_movvideo_tags to support weird files created by faulty software
that are not even mov/mp4 is not a good idea.

Why the hell is the avi demuxer even looking at mov tags to begin with?

> 
> Please comment, Carl Eugen
> 
> 
> 0001-lavf-isom-Recognize-fourcc-HEVC.patch
> 
> 
> From 281899c95c5b94242fa2bdbb4e830eecaef78f8d Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos <ceffmpeg@gmail.com>
> Date: Wed, 2 May 2018 20:43:09 +0200
> Subject: [PATCH] lavf/isom: Recognize fourcc HEVC.
> 
> Fixes ticket #7110.
> ---
>  libavformat/isom.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 2792371..261fc6f 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -163,6 +163,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>  
>      { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */
>      { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */
> +    { AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') }, /* VirtualDub */
>  
>      { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
>      { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
> -- 1.7.10.4
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Carl Eugen Hoyos May 2, 2018, 6:59 p.m.
2018-05-02 20:52 GMT+02:00, James Almer <jamrial@gmail.com>:
> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:

>> Attached patch fixes ticket #7110 for me.
>
> hevc in AVI is not a thing, and adding a non official fourcc to
> ff_codec_movvideo_tags to support weird files created by
> faulty software that are not even mov/mp4 is not a good idea.

So what do you suggest?
Not supporting files that are written by common software?

> Why the hell is the avi demuxer even looking at mov tags to begin with?

Because every other software except FFmpeg writes such files.

Carl Eugen
James Almer May 2, 2018, 7:26 p.m.
On 5/2/2018 3:59 PM, Carl Eugen Hoyos wrote:
> 2018-05-02 20:52 GMT+02:00, James Almer <jamrial@gmail.com>:
>> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
> 
>>> Attached patch fixes ticket #7110 for me.
>>
>> hevc in AVI is not a thing, and adding a non official fourcc to
>> ff_codec_movvideo_tags to support weird files created by
>> faulty software that are not even mov/mp4 is not a good idea.
> 
> So what do you suggest?
> Not supporting files that are written by common software?

Asking the source of these files (VirtualDub) to stop creating them is
one option. Otherwise we'll be adding a similar tag to support h266 in
avi five years from now because people refuse to do things right.

Alternatively, actually start using avfmtctx->strict_std_compliance on
demuxers and refuse to handle these files unless it's set as unofficial
or lower, but i predict a lot of people will come out of the woodworks
complaining about their broken samples suddenly not working anymore
because ffmpeg started to honor its own standard compliance settings.

> 
>> Why the hell is the avi demuxer even looking at mov tags to begin with?
> 
> Because every other software except FFmpeg writes such files.

I doubt we're the only ones that try to not write non standard files...

> 
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Carl Eugen Hoyos May 2, 2018, 7:47 p.m.
2018-05-02 21:26 GMT+02:00, James Almer <jamrial@gmail.com>:
> On 5/2/2018 3:59 PM, Carl Eugen Hoyos wrote:
>> 2018-05-02 20:52 GMT+02:00, James Almer <jamrial@gmail.com>:
>>> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
>>
>>>> Attached patch fixes ticket #7110 for me.
>>>
>>> hevc in AVI is not a thing, and adding a non official fourcc to
>>> ff_codec_movvideo_tags to support weird files created by
>>> faulty software that are not even mov/mp4 is not a good idea.
>>
>> So what do you suggest?
>> Not supporting files that are written by common software?
>
> Asking the source of these files (VirtualDub) to stop creating them is
> one option. Otherwise we'll be adding a similar tag to support h266 in
> avi five years from now because people refuse to do things right.

How does this help?
We know that several applications write such files and they didn't
stop it when we asked last time?

Much more important: We try not to write invalid files, what is
suddenly bad about trying to support everything out there?
We support quite a few formats that are most likely less
common than hevc-in-avi and this was a very successful
approach afaict.

Why suddenly tell users to fuck themselves? Why does
this make sense?

> Alternatively, actually start using avfmtctx->strict_std_compliance on
> demuxers and refuse to handle these files unless it's set as unofficial
> or lower, but i predict a lot of people will come out of the woodworks
> complaining about their broken samples suddenly not working anymore
> because ffmpeg started to honor its own standard compliance settings.

Sounds completely unacceptable to me.

>>> Why the hell is the avi demuxer even looking at mov tags to begin with?
>>
>> Because every other software except FFmpeg writes such files.
>
> I doubt we're the only ones that try to not write non standard files...

Do you know immediately of another (general-usage!) tool?

Carl Eugen
Paul B Mahol May 2, 2018, 8:01 p.m.
On 5/2/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> Hi!
>
> Attached patch fixes ticket #7110 for me.
>
> Please comment, Carl Eugen
>

NACK.
Carl Eugen Hoyos May 2, 2018, 8:05 p.m.
2018-05-02 22:01 GMT+02:00, Paul B Mahol <onemda@gmail.com>:
> On 5/2/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> Hi!
>>
>> Attached patch fixes ticket #7110 for me.
>>
>> Please comment, Carl Eugen
>>
>
> NACK.

Why did you ask for a sample if you were not interested
in fixing it?
Or do have a better idea?

Carl Eugen
James Almer May 2, 2018, 8:30 p.m.
On 5/2/2018 4:47 PM, Carl Eugen Hoyos wrote:
> 2018-05-02 21:26 GMT+02:00, James Almer <jamrial@gmail.com>:
>> On 5/2/2018 3:59 PM, Carl Eugen Hoyos wrote:
>>> 2018-05-02 20:52 GMT+02:00, James Almer <jamrial@gmail.com>:
>>>> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
>>>
>>>>> Attached patch fixes ticket #7110 for me.
>>>>
>>>> hevc in AVI is not a thing, and adding a non official fourcc to
>>>> ff_codec_movvideo_tags to support weird files created by
>>>> faulty software that are not even mov/mp4 is not a good idea.
>>>
>>> So what do you suggest?
>>> Not supporting files that are written by common software?
>>
>> Asking the source of these files (VirtualDub) to stop creating them is
>> one option. Otherwise we'll be adding a similar tag to support h266 in
>> avi five years from now because people refuse to do things right.
> 
> How does this help?

An attempt to prevent the creation of even more broken non standard crap
in the future.

> We know that several applications write such files and they didn't
> stop it when we asked last time?

So we ask them to stop creating broken files, they ignore us, and the
result is we bend over and litter our codebase with workarounds for the
crap they release into the wild?

> 
> Much more important: We try not to write invalid files, what is
> suddenly bad about trying to support everything out there?
> We support quite a few formats that are most likely less
> common than hevc-in-avi and this was a very successful
> approach afaict.
> 
> Why suddenly tell users to fuck themselves? Why does
> this make sense?

Not to the users. To the developers of these applications if anything.

> 
>> Alternatively, actually start using avfmtctx->strict_std_compliance on
>> demuxers and refuse to handle these files unless it's set as unofficial
>> or lower, but i predict a lot of people will come out of the woodworks
>> complaining about their broken samples suddenly not working anymore
>> because ffmpeg started to honor its own standard compliance settings.
> 
> Sounds completely unacceptable to me.

And that's a problem. We add options to let the user choose between
supporting non standard features or not, then make it do nothing and
instead hardcode things in the laxest mode possible, which includes crap
like this.

If we start actually having some standards about standard compliance and
users start being told that their files are broken, then these
applications might get some incentive to stop creating them to begin with.

> 
>>>> Why the hell is the avi demuxer even looking at mov tags to begin with?
>>>
>>> Because every other software except FFmpeg writes such files.
>>
>> I doubt we're the only ones that try to not write non standard files...
> 
> Do you know immediately of another (general-usage!) tool?

Why are you asking me to list other software when you are the one that
assured me everyone but us writes crap like hevc in avi? Is it really
every other program, or just VirutalDub, as the comment you added to
this new ff_codec_movvideo_tags entry implies? What other program does
if it's not just that one?

If it's really that common and every other avi muxing application out
there writes hevc using this specific fourcc tag, then you'll have a
better argument to add support for it.
Carl Eugen Hoyos May 2, 2018, 8:32 p.m.
2018-05-02 22:30 GMT+02:00, James Almer <jamrial@gmail.com>:
> On 5/2/2018 4:47 PM, Carl Eugen Hoyos wrote:

>>> I doubt we're the only ones that try to not write non standard files...
>>
>> Do you know immediately of another (general-usage!) tool?
>
> Why are you asking me to list other software when you are the one that
> assured me everyone but us writes crap like hevc in avi? Is it really
> every other program, or just VirutalDub, as the comment you added to
> this new ff_codec_movvideo_tags entry implies? What other program does
> if it's not just that one?

Normally, it is vlc that produces such files.

> If it's really that common and every other avi muxing application out
> there writes hevc using this specific fourcc tag, then you'll have a
> better argument to add support for it.

MEncoder comes to mind.

Are three enough?

Carl Eugen
Hendrik Leppkes May 2, 2018, 8:50 p.m.
On Wed, May 2, 2018 at 8:52 PM, James Almer <jamrial@gmail.com> wrote:
> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #7110 for me.
>
> hevc in AVI is not a thing, and adding a non official fourcc to
> ff_codec_movvideo_tags to support weird files created by faulty software
> that are not even mov/mp4 is not a good idea.
>
> Why the hell is the avi demuxer even looking at mov tags to begin with?
>
>>
>> Please comment, Carl Eugen
>>
>>
>> 0001-lavf-isom-Recognize-fourcc-HEVC.patch
>>
>>
>> From 281899c95c5b94242fa2bdbb4e830eecaef78f8d Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> Date: Wed, 2 May 2018 20:43:09 +0200
>> Subject: [PATCH] lavf/isom: Recognize fourcc HEVC.
>>
>> Fixes ticket #7110.
>> ---
>>  libavformat/isom.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 2792371..261fc6f 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>> @@ -163,6 +163,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>>
>>      { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */
>>      { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */
>> +    { AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') }, /* VirtualDub */
>>
>>      { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
>>      { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
>> -- 1.7.10.4
>>
>>
>>

If anything at all, this should most definitely not go into movvideo
tags. This is about AVI files, so if it should go anywhere, it should
be in ff_codec_bmp_tags. But of course this would have the side-effect
that it actually allows encoding such files then, which would
absolutely not be OK.

- Hendrik
James Almer May 2, 2018, 9:07 p.m.
On 5/2/2018 5:32 PM, Carl Eugen Hoyos wrote:
> 2018-05-02 22:30 GMT+02:00, James Almer <jamrial@gmail.com>:
>> On 5/2/2018 4:47 PM, Carl Eugen Hoyos wrote:
> 
>>>> I doubt we're the only ones that try to not write non standard files...
>>>
>>> Do you know immediately of another (general-usage!) tool?
>>
>> Why are you asking me to list other software when you are the one that
>> assured me everyone but us writes crap like hevc in avi? Is it really
>> every other program, or just VirutalDub, as the comment you added to
>> this new ff_codec_movvideo_tags entry implies? What other program does
>> if it's not just that one?
> 
> Normally, it is vlc that produces such files.

VLC has ignored our requests to stop creating non standard files?

> 
>> If it's really that common and every other avi muxing application out
>> there writes hevc using this specific fourcc tag, then you'll have a
>> better argument to add support for it.
> 
> MEncoder comes to mind.

And so did they?

> 
> Are three enough?

No.

> 
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
James Almer May 2, 2018, 9:09 p.m.
On 5/2/2018 5:50 PM, Hendrik Leppkes wrote:
> On Wed, May 2, 2018 at 8:52 PM, James Almer <jamrial@gmail.com> wrote:
>> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch fixes ticket #7110 for me.
>>
>> hevc in AVI is not a thing, and adding a non official fourcc to
>> ff_codec_movvideo_tags to support weird files created by faulty software
>> that are not even mov/mp4 is not a good idea.
>>
>> Why the hell is the avi demuxer even looking at mov tags to begin with?
>>
>>>
>>> Please comment, Carl Eugen
>>>
>>>
>>> 0001-lavf-isom-Recognize-fourcc-HEVC.patch
>>>
>>>
>>> From 281899c95c5b94242fa2bdbb4e830eecaef78f8d Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos <ceffmpeg@gmail.com>
>>> Date: Wed, 2 May 2018 20:43:09 +0200
>>> Subject: [PATCH] lavf/isom: Recognize fourcc HEVC.
>>>
>>> Fixes ticket #7110.
>>> ---
>>>  libavformat/isom.c |    1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>>> index 2792371..261fc6f 100644
>>> --- a/libavformat/isom.c
>>> +++ b/libavformat/isom.c
>>> @@ -163,6 +163,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>>>
>>>      { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */
>>>      { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */
>>> +    { AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') }, /* VirtualDub */
>>>
>>>      { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
>>>      { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
>>> -- 1.7.10.4
>>>
>>>
>>>
> 
> If anything at all, this should most definitely not go into movvideo
> tags. This is about AVI files, so if it should go anywhere, it should
> be in ff_codec_bmp_tags. But of course this would have the side-effect
> that it actually allows encoding such files then, which would
> absolutely not be OK.
> 
> - Hendrik

Which just made me realize we have been allowing the muxing of all kind
of bullshit in AVI all this time and nobody bothered to prevent it.

Seriously, this is really sloppy. We're allowing VP9 and AV1 in avi, for
fucks sake. Why is ff_codec_bmp_tags such a dumping ground of fourccs
meant for random muxers?
Carl Eugen Hoyos May 2, 2018, 9:09 p.m.
2018-05-02 23:07 GMT+02:00, James Almer <jamrial@gmail.com>:
> On 5/2/2018 5:32 PM, Carl Eugen Hoyos wrote:

>> Are three enough?
>
> No.

Which other application do you know?

Carl Eugen
Carl Eugen Hoyos May 2, 2018, 9:12 p.m.
2018-05-02 23:09 GMT+02:00, James Almer <jamrial@gmail.com>:

> Which just made me realize we have been allowing the muxing of all kind
> of bullshit in AVI all this time and nobody bothered to prevent it.

Yes, I did.
(And thank you for accusing everybody.)

> Seriously, this is really sloppy. We're allowing VP9 and AV1 in avi, for
> fucks sake. Why is ff_codec_bmp_tags such a dumping ground of fourccs
> meant for random muxers?

Because merge commits are not reviewed?

Carl Eugen
Carl Eugen Hoyos May 2, 2018, 9:12 p.m.
2018-05-02 22:50 GMT+02:00, Hendrik Leppkes <h.leppkes@gmail.com>:

> If anything at all, this should most definitely not go into movvideo
> tags. This is about AVI files, so if it should go anywhere, it should
> be in ff_codec_bmp_tags. But of course this would have the side-effect
> that it actually allows encoding such files then, which would
> absolutely not be OK.

What do you suggest?

Carl Eugen
James Almer May 2, 2018, 9:24 p.m.
On 5/2/2018 6:12 PM, Carl Eugen Hoyos wrote:
> 2018-05-02 23:09 GMT+02:00, James Almer <jamrial@gmail.com>:
> 
>> Which just made me realize we have been allowing the muxing of all kind
>> of bullshit in AVI all this time and nobody bothered to prevent it.
> 
> Yes, I did.

How did you try to prevent it? The fourccs are there and being used to
mux non standard codecs into avi right now.

> (And thank you for accusing everybody.)
> 
>> Seriously, this is really sloppy. We're allowing VP9 and AV1 in avi, for
>> fucks sake. Why is ff_codec_bmp_tags such a dumping ground of fourccs
>> meant for random muxers?
> 
> Because merge commits are not reviewed?

eb7f7b797f is not a merge.
Carl Eugen Hoyos May 2, 2018, 9:35 p.m.
2018-05-02 23:24 GMT+02:00, James Almer <jamrial@gmail.com>:
> On 5/2/2018 6:12 PM, Carl Eugen Hoyos wrote:
>> 2018-05-02 23:09 GMT+02:00, James Almer <jamrial@gmail.com>:
>>
>>> Which just made me realize we have been allowing the muxing of all kind
>>> of bullshit in AVI all this time and nobody bothered to prevent it.
>>
>> Yes, I did.
>
> How did you try to prevent it?

I committed a patch to prevent it:
2e0b5f5c

> The fourccs are there and being used to
> mux non standard codecs into avi right now.
>
>> (And thank you for accusing everybody.)
>>
>>> Seriously, this is really sloppy. We're allowing VP9 and AV1 in avi, for
>>> fucks sake. Why is ff_codec_bmp_tags such a dumping ground of fourccs
>>> meant for random muxers?
>>
>> Because merge commits are not reviewed?
>
> eb7f7b797f is not a merge.

ed223eea was and we really had other problems 2013.

Carl Eugen
Michael Niedermayer May 3, 2018, 7:31 p.m.
Hi

On Wed, May 02, 2018 at 04:26:07PM -0300, James Almer wrote:
> On 5/2/2018 3:59 PM, Carl Eugen Hoyos wrote:
> > 2018-05-02 20:52 GMT+02:00, James Almer <jamrial@gmail.com>:
> >> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
> > 
> >>> Attached patch fixes ticket #7110 for me.
> >>
> >> hevc in AVI is not a thing, and adding a non official fourcc to
> >> ff_codec_movvideo_tags to support weird files created by
> >> faulty software that are not even mov/mp4 is not a good idea.
> > 
> > So what do you suggest?
> > Not supporting files that are written by common software?
> 
> Asking the source of these files (VirtualDub) to stop creating them is
> one option. Otherwise we'll be adding a similar tag to support h266 in
> avi five years from now because people refuse to do things right.

And what would be the argument why a codec be that h265 or h266 should
not be stored in a generic container (avi in this case) ?

Heres the official register:
https://www.iana.org/assignments/wave-avi-codec-registry/wave-avi-codec-registry.xml

there are matches for both h265 and h266
This should not be surprising as avi is intended to be and is a
generic container format. 

Thanks

[...]
James Almer May 3, 2018, 8:21 p.m.
On 5/3/2018 4:31 PM, Michael Niedermayer wrote:
> Hi
> 
> On Wed, May 02, 2018 at 04:26:07PM -0300, James Almer wrote:
>> On 5/2/2018 3:59 PM, Carl Eugen Hoyos wrote:
>>> 2018-05-02 20:52 GMT+02:00, James Almer <jamrial@gmail.com>:
>>>> On 5/2/2018 3:44 PM, Carl Eugen Hoyos wrote:
>>>
>>>>> Attached patch fixes ticket #7110 for me.
>>>>
>>>> hevc in AVI is not a thing, and adding a non official fourcc to
>>>> ff_codec_movvideo_tags to support weird files created by
>>>> faulty software that are not even mov/mp4 is not a good idea.
>>>
>>> So what do you suggest?
>>> Not supporting files that are written by common software?
>>
>> Asking the source of these files (VirtualDub) to stop creating them is
>> one option. Otherwise we'll be adding a similar tag to support h266 in
>> avi five years from now because people refuse to do things right.
> 
> And what would be the argument why a codec be that h265 or h266 should
> not be stored in a generic container (avi in this case) ?
> 
> Heres the official register:
> https://www.iana.org/assignments/wave-avi-codec-registry/wave-avi-codec-registry.xml
> 
> there are matches for both h265 and h266

There are none for HEVC, which is what this patch is adding (and in the
wrong place).

> This should not be surprising as avi is intended to be and is a
> generic container format. 
> 
> Thanks
> 
> [...]
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
James Almer May 3, 2018, 8:26 p.m.
On 5/2/2018 6:12 PM, Carl Eugen Hoyos wrote:
> 2018-05-02 22:50 GMT+02:00, Hendrik Leppkes <h.leppkes@gmail.com>:
> 
>> If anything at all, this should most definitely not go into movvideo
>> tags. This is about AVI files, so if it should go anywhere, it should
>> be in ff_codec_bmp_tags. But of course this would have the side-effect
>> that it actually allows encoding such files then, which would
>> absolutely not be OK.
> 
> What do you suggest?

Create a new table with all non standard codecids from ff_codec_bmp_tags
and use it exclusively in avidec, then remove them from
ff_codec_bmp_tags, adapting other de/muxers if needed (like ivf).

And then add this HEVC codecid to it.
Carl Eugen Hoyos May 3, 2018, 10:23 p.m.
2018-05-03 22:26 GMT+02:00, James Almer <jamrial@gmail.com>:
> On 5/2/2018 6:12 PM, Carl Eugen Hoyos wrote:
>> 2018-05-02 22:50 GMT+02:00, Hendrik Leppkes <h.leppkes@gmail.com>:
>>
>>> If anything at all, this should most definitely not go into
>>> movvideo tags. This is about AVI files, so if it should go
>>> anywhere, it should be in ff_codec_bmp_tags. But of
>>> course this would have the side-effect that it actually
>>> allows encoding such files then, which would absolutely
>>> not be OK.
>>
>> What do you suggest?
>
> Create a new table with all non standard codecids from
> ff_codec_bmp_tags and use it exclusively in avidec

Who is going to decide which are standard codecids?

Your suggestion is not really helpful and would impose
quite a burden for users using avi as a standard
container: What gain would there be?

Carl Eugen
compn May 4, 2018, 12:19 p.m.
On Thu, 3 May 2018 17:26:38 -0300, James Almer <jamrial@gmail.com>
wrote:
> Create a new table with all non standard codecids from ff_codec_bmp_tags
> and use it exclusively in avidec, then remove them from
> ff_codec_bmp_tags, adapting other de/muxers if needed (like ivf).
> 
> And then add this HEVC codecid to it.

as fourcc maintainer i approve carls patch to add h265.

while i like james's idea, it would create a duplicated mess
of fourcc lists in each container. the fourcc problem got worse as
more people were using mov tags in avi, which is why the hack was
requested to have the avi container look at the isom list. saving us
from duplicating the isom list in the avi list. mostly due to apple
users needing an intermediate format for their apple codecs.

i would be extremely against splitting and duplicating the
decoding fourccs again. internal and external fourccs like VLC and
mplayer would be the end game to that. ugh.

my idea would be to create a whitelist of codec ids we can encode to,
instead of splitting up the decode fourcc list amongst formats.

that way we fully control which fourcc we support in which codecs on
the encoder side (avienc, movenc). and we dont mess with the decoder
fourccs at all.

please let me know if my idea would work, i am probably missing some
huge flaw somewhere...

-compn
Paul B Mahol May 4, 2018, 12:24 p.m.
On 5/4/18, Compn <tempn@mi.rr.com> wrote:
> On Thu, 3 May 2018 17:26:38 -0300, James Almer <jamrial@gmail.com>
> wrote:
>> Create a new table with all non standard codecids from ff_codec_bmp_tags
>> and use it exclusively in avidec, then remove them from
>> ff_codec_bmp_tags, adapting other de/muxers if needed (like ivf).
>>
>> And then add this HEVC codecid to it.
>
> as fourcc maintainer i approve carls patch to add h265.

I blocked it, your approval means now nothing.
wm4 May 4, 2018, 12:36 p.m.
On Fri, 4 May 2018 08:19:27 -0400
Compn <tempn@mi.rr.com> wrote:

> On Thu, 3 May 2018 17:26:38 -0300, James Almer <jamrial@gmail.com>
> wrote:
> > Create a new table with all non standard codecids from ff_codec_bmp_tags
> > and use it exclusively in avidec, then remove them from
> > ff_codec_bmp_tags, adapting other de/muxers if needed (like ivf).
> > 
> > And then add this HEVC codecid to it.  
> 
> as fourcc maintainer i approve carls patch to add h265.

I'm against it.

> while i like james's idea, it would create a duplicated mess
> of fourcc lists in each container. the fourcc problem got worse as
> more people were using mov tags in avi, which is why the hack was
> requested to have the avi container look at the isom list. saving us
> from duplicating the isom list in the avi list. mostly due to apple
> users needing an intermediate format for their apple codecs.
> 
> i would be extremely against splitting and duplicating the
> decoding fourccs again. internal and external fourccs like VLC and
> mplayer would be the end game to that. ugh.

VLC and mplayer need internal FourCCs because of their architecture.
It's not relevant to FFmpeg.

> 
> my idea would be to create a whitelist of codec ids we can encode to,
> instead of splitting up the decode fourcc list amongst formats.

FourCC are already split up for avi and mov. Apparently it got
sabotaged at some point.

A mux whitelist would be just as much as splitting the list. (Although
having separate mux lists would be a good idea too.)

Also here's an advice to FFmpeg: STOP ALLOWING USERS TO CREATE INVALID
FILES. I'm sick of working them around. Stop creating a fucked up mess.
It starts with rejecting this patch.

> that way we fully control which fourcc we support in which codecs on
> the encoder side (avienc, movenc). and we dont mess with the decoder
> fourccs at all.
> 
> please let me know if my idea would work, i am probably missing some
> huge flaw somewhere...
> 
> -compn
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
compn May 4, 2018, 12:44 p.m.
On Fri, 4 May 2018 08:19:27 -0400, Compn <tempn@mi.rr.com> wrote:

> my idea would be to create a whitelist of codec ids we can encode to,
> instead of splitting up the decode fourcc list amongst formats.

that would also be a nightmare to maintain and users would ask for
support for "xxx codec" in "xyz format".

-compn
compn May 4, 2018, 12:56 p.m.
On Fri, 4 May 2018 14:36:03 +0200, wm4 <nfxjfg@googlemail.com> wrote:

> FourCC are already split up for avi and mov. Apparently it got
> sabotaged at some point.

i think mkv re-uses riff list from avi on purpose, as it was meant as a
replacement to avi (and has all the vfw codec tags in the spec).
duplicating mkv and avi seems like a bad idea as they use the same tags.

https://www.matroska.org/technical/guides/faq/index.html

> A mux whitelist would be just as much as splitting the list. (Although
> having separate mux lists would be a good idea too.)

-compn
wm4 May 4, 2018, 1:05 p.m.
On Fri, 4 May 2018 08:56:18 -0400
Compn <tempn@mi.rr.com> wrote:

> On Fri, 4 May 2018 14:36:03 +0200, wm4 <nfxjfg@googlemail.com> wrote:
> 
> > FourCC are already split up for avi and mov. Apparently it got
> > sabotaged at some point.  
> 
> i think mkv re-uses riff list from avi on purpose, as it was meant as a
> replacement to avi (and has all the vfw codec tags in the spec).
> duplicating mkv and avi seems like a bad idea as they use the same tags.
> 
> https://www.matroska.org/technical/guides/faq/index.html

mkv has a VfW muxing mode, in which it uses AVI headers and FourCCs in
the codec data. They're completely separate from normal Matroska codec
IDs, which are strings.

Patch hide | download patch | download mbox

From 281899c95c5b94242fa2bdbb4e830eecaef78f8d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Date: Wed, 2 May 2018 20:43:09 +0200
Subject: [PATCH] lavf/isom: Recognize fourcc HEVC.

Fixes ticket #7110.
---
 libavformat/isom.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 2792371..261fc6f 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -163,6 +163,7 @@  const AVCodecTag ff_codec_movvideo_tags[] = {
 
     { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */
     { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */
+    { AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') }, /* VirtualDub */
 
     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
-- 
1.7.10.4