| Message ID | CAB0OVGqE6BuhLzGT9KrevsAr4EAMydQgi5UtGjA3G=Se43GkTg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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 >
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
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 >
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
On 5/2/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > Hi! > > Attached patch fixes ticket #7110 for me. > > Please comment, Carl Eugen > NACK.
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
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.
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
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
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 >
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?
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
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
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
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.
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
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 [...]
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 >
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.
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
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
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.
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
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
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
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.
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