Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Wed, Oct 24, 2018 at 04:50:07PM -0700, Alex Sukhanov wrote: > On Sat, Oct 13, 2018 at 5:17 PM Michael Niedermayer > wrote: > > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > > > Yeah, not really a spec. > > > > > > I have no strong objections, I guess. > > > > so IIUC noone is against this ? > > if so i will apply the last patch in a few days unless i forget or > > someone else does before > > > > thx > > > > [...] > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > Everything should be made as simple as possible, but not simpler. > > -- Albert Einstein > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > Michael, can you please apply this patch? It seemed to me that jan, james and vittorio where not happy about it It would be better if everyone agreed with what is applied, maybe you can talk with them to see if you can find something that everyone is happy with. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sat, Oct 13, 2018 at 5:17 PM Michael Niedermayer wrote: > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > Yeah, not really a spec. > > > > I have no strong objections, I guess. > > so IIUC noone is against this ? > if so i will apply the last patch in a few days unless i forget or > someone else does before > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Michael, can you please apply this patch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Mon, Oct 15, 2018 at 9:35 AM Vittorio Giovara wrote: > On Thu, Oct 11, 2018 at 5:28 PM Jan Ekström wrote: > > > On Thu, Oct 11, 2018 at 10:58 PM Alex Sukhanov > > wrote: > > > > > > Hi Mark, > > > > > > at Google we have some old service which is still running and it works > > only > > > with the IVF container. It would be great if ffmpeg could generate such > > > videos so we could give them to the service then. Given that ffmpeg IVF > > > demuxer already supports reading such files, I think it's reasonable to > > > make IVF muxer be able to generate them. > > > Hope it answers the question. > > > > > > Thank you > > > > Given the amount of code is not large I'm not against having it in, > > but if it's not something that ever was meant to go into the public > > I'd probably disable creation of such files unless you enable a less > > standards-compliant strictness mode. > > > > maybe creation of such files could be allowed only with a strict compliance > flag? > -- > Vittorio > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Vittorio, can you please elaborate your proposal? Is there already a flag in ffmpeg that we can consider use for that? What would be a benefit of guarding h264/hevc muxing into the IVF container by the flag? Thank you ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Oct 11, 2018 at 5:28 PM Jan Ekström wrote: > On Thu, Oct 11, 2018 at 10:58 PM Alex Sukhanov > wrote: > > > > Hi Mark, > > > > at Google we have some old service which is still running and it works > only > > with the IVF container. It would be great if ffmpeg could generate such > > videos so we could give them to the service then. Given that ffmpeg IVF > > demuxer already supports reading such files, I think it's reasonable to > > make IVF muxer be able to generate them. > > Hope it answers the question. > > > > Thank you > > Given the amount of code is not large I'm not against having it in, > but if it's not something that ever was meant to go into the public > I'd probably disable creation of such files unless you enable a less > standards-compliant strictness mode. > maybe creation of such files could be allowed only with a strict compliance flag? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Oct 14, 2018 at 10:24:22AM -0300, James Almer wrote: > On 10/14/2018 9:59 AM, Michael Niedermayer wrote: > > On Sun, Oct 14, 2018 at 01:29:53PM +0300, Jan Ekström wrote: > >> On Sun, Oct 14, 2018 at 1:27 PM Jan Ekström wrote: > >>> > >>> On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer > >>> wrote: > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > On 11/10/2018 23:39, Alex Sukhanov wrote: > >> The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > Yeah, not really a spec. > > > > I have no strong objections, I guess. > > so IIUC noone is against this ? > if so i will apply the last patch in a few days unless i forget or > someone else does before > > thx > > >>> > >>> As mentioned, since this is nothing should have ever been used outside > >>> of one of GOOG's legacy systems, I would only apply this with a > >>> warning and strictness requirement of experimental or whatever level > >>> matches these sorts of cases. > >>> > >> > >> For the record, this was regarding the muxer so that unknowing people > >> will not generate such files that nothing else can read. > > > > If you choose a random container and store a random codec in it (which you > > can do) > > chances are theres not much that will play it. > > > > for example i just tried muxing a stream of png images into mpeg and FFmpeg > > does that without complaining. > > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec png test.mpeg > > > > So if we do not check this for a major format that has a proper > > specification > > which i belive nowhere allows png > > > > Why should we add a limitation on a format that has nothing saying that you > > cannot put some other codec into it ? > > The proper thing to do would be to effectively disallow such invalid > muxing scenarios, fixing this instead of adding even more wrong cases to > the pile. > I'm fairly sure we blocked a patch to allow muxing hevc into flv years > ago. That's what needs to be done in general. I think where we disagree is not that "we should disallow invalid muxing" but if this is invalid/wrong. And also it seems to me that people appear to be very quick in jumping onto such "lets block it" movments without doing much research about new codecs in IVF, which this thread is about, why is that invalid ? our ivf demuxer refers to itself as "On2 IVF" so i presume the format was created by On2 (googling for On2 IVF results in only strange results interrestingly) but presumably IVF was created by On2 In February 2010, On2 Technologies was acquired by Google (https://en.wikipedia.org/wiki/On2_Technologies) And google is using IVF apparently from what was said in this thread with more codecs. Well from how i understand it (please correct me if iam wrong) IVF is now a format "owned" by google. They certainly can add things to it. Theres nothing wrong or invalid on this. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 10/14/2018 9:59 AM, Michael Niedermayer wrote: > On Sun, Oct 14, 2018 at 01:29:53PM +0300, Jan Ekström wrote: >> On Sun, Oct 14, 2018 at 1:27 PM Jan Ekström wrote: >>> >>> On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer >>> wrote: On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > On 11/10/2018 23:39, Alex Sukhanov wrote: >> The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > Yeah, not really a spec. > > I have no strong objections, I guess. so IIUC noone is against this ? if so i will apply the last patch in a few days unless i forget or someone else does before thx >>> >>> As mentioned, since this is nothing should have ever been used outside >>> of one of GOOG's legacy systems, I would only apply this with a >>> warning and strictness requirement of experimental or whatever level >>> matches these sorts of cases. >>> >> >> For the record, this was regarding the muxer so that unknowing people >> will not generate such files that nothing else can read. > > If you choose a random container and store a random codec in it (which you > can do) > chances are theres not much that will play it. > > for example i just tried muxing a stream of png images into mpeg and FFmpeg > does that without complaining. > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec png test.mpeg > > So if we do not check this for a major format that has a proper specification > which i belive nowhere allows png > > Why should we add a limitation on a format that has nothing saying that you > cannot put some other codec into it ? The proper thing to do would be to effectively disallow such invalid muxing scenarios, fixing this instead of adding even more wrong cases to the pile. I'm fairly sure we blocked a patch to allow muxing hevc into flv years ago. That's what needs to be done in general. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Oct 14, 2018 at 01:29:53PM +0300, Jan Ekström wrote: > On Sun, Oct 14, 2018 at 1:27 PM Jan Ekström wrote: > > > > On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer > > wrote: > > > > > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > > > > > Yeah, not really a spec. > > > > > > > > I have no strong objections, I guess. > > > > > > so IIUC noone is against this ? > > > if so i will apply the last patch in a few days unless i forget or > > > someone else does before > > > > > > thx > > > > > > > As mentioned, since this is nothing should have ever been used outside > > of one of GOOG's legacy systems, I would only apply this with a > > warning and strictness requirement of experimental or whatever level > > matches these sorts of cases. > > > > For the record, this was regarding the muxer so that unknowing people > will not generate such files that nothing else can read. If you choose a random container and store a random codec in it (which you can do) chances are theres not much that will play it. for example i just tried muxing a stream of png images into mpeg and FFmpeg does that without complaining. ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec png test.mpeg So if we do not check this for a major format that has a proper specification which i belive nowhere allows png Why should we add a limitation on a format that has nothing saying that you cannot put some other codec into it ? And i mean there IS software that uses that what is asked for here. If you object because the text at https://wiki.multimedia.cx/index.php/IVF does not list all codecs. Well its a wiki, the author of the patch could get an account and update this. In fact independant of this discussion here it surely wont hurt if the people using the format review and update that page. The other concern IIUC (please correct me if i misunderstood) is that its a legacy format. FFmpeg is full of legacy format support, we suport some really bizare formats ... And another concern IIUC ( again please correct me if i misunderstood) is that someone might unintentionally generate a unsupported file this is tricky, the default video codec for ivf is AV_CODEC_ID_VP8 to get something else, one would need to manually override this and as we already saw thats not something we current protect against very well. Iam not against disallowing the new codecs by default but it feels inconsistent compared to other containers. what do you say ? did i convince you or should we disallow it and add a check. Iam happy with whatever people agree on thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer wrote: > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > Yeah, not really a spec. > > > > I have no strong objections, I guess. > > so IIUC noone is against this ? > if so i will apply the last patch in a few days unless i forget or > someone else does before > > thx > As mentioned, since this is nothing should have ever been used outside of one of GOOG's legacy systems, I would only apply this with a warning and strictness requirement of experimental or whatever level matches these sorts of cases. Nothing in public that utilizes IVF files will output or read AVC/HEVC from IVF files. It was explicitly only utilized by the webm/libvpx project publicly, and that for obvious reasons will not support AVC/HEVC. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > On 11/10/2018 23:39, Alex Sukhanov wrote: > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > Yeah, not really a spec. > > I have no strong objections, I guess. so IIUC noone is against this ? if so i will apply the last patch in a few days unless i forget or someone else does before thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 11/10/2018 23:39, Alex Sukhanov wrote: > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF Yeah, not really a spec. I have no strong objections, I guess. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Oct 11, 2018 at 2:47 PM Derek Buitenhuis wrote: > On 11/10/2018 22:21, Jan Ekström wrote: > > I'd probably disable creation of such files unless you enable a less > > standards-compliant strictness mode. > > Is there even an IVF spec, though? If not, there's not really such a > thing as "standards-compliant". > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel The only "spec" I'm aware of: https://wiki.multimedia.cx/index.php/IVF ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 11/10/2018 22:21, Jan Ekström wrote: > I'd probably disable creation of such files unless you enable a less > standards-compliant strictness mode. Is there even an IVF spec, though? If not, there's not really such a thing as "standards-compliant". - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Oct 11, 2018 at 10:58 PM Alex Sukhanov wrote: > > Hi Mark, > > at Google we have some old service which is still running and it works only > with the IVF container. It would be great if ffmpeg could generate such > videos so we could give them to the service then. Given that ffmpeg IVF > demuxer already supports reading such files, I think it's reasonable to > make IVF muxer be able to generate them. > Hope it answers the question. > > Thank you Given the amount of code is not large I'm not against having it in, but if it's not something that ever was meant to go into the public I'd probably disable creation of such files unless you enable a less standards-compliant strictness mode. Or if others are against it, I'm OK with this thing not being included as it clearly is to enable some GOOG internal workflows only. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sat, Oct 6, 2018 at 10:37 AM Mark Thompson wrote:
> On 05/10/18 21:45, Alex Sukhanov wrote:
> > On Mon, Oct 1, 2018 at 11:01 AM wrote:
> >
> >> From: Alex Sukhanov
> >>
> >> ---
> >> libavformat/ivfenc.c | 50 +---
> >> 1 file changed, 38 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> >> index 66441a2a43..6410828533 100644
> >> --- a/libavformat/ivfenc.c
> >> +++ b/libavformat/ivfenc.c
> >> @@ -36,19 +36,29 @@ static int ivf_write_header(AVFormatContext *s)
> >> return AVERROR(EINVAL);
> >> }
> >> par = s->streams[0]->codecpar;
> >> -if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> >> -!(par->codec_id == AV_CODEC_ID_AV1 ||
> >> - par->codec_id == AV_CODEC_ID_VP8 ||
> >> - par->codec_id == AV_CODEC_ID_VP9)) {
> >> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> >> supported!\n");
> >> -return AVERROR(EINVAL);
> >> -}
> >> avio_write(pb, "DKIF", 4);
> >> avio_wl16(pb, 0); // version
> >> avio_wl16(pb, 32); // header length
> >> -avio_wl32(pb,
> >> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> >> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> >> AV_RL32("AV01"));
> >> +switch (par->codec_id) {
> >> + case AV_CODEC_ID_AV1:
> >> +avio_wl32(pb, AV_RL32("AV01"));
> >> +break;
> >> + case AV_CODEC_ID_H264:
> >> +avio_wl32(pb, AV_RL32("H264"));
> >> +break;
> >> + case AV_CODEC_ID_HEVC:
> >> +avio_wl32(pb, AV_RL32("HEVC"));
> >> +break;
> >> + case AV_CODEC_ID_VP8:
> >> +avio_wl32(pb, AV_RL32("VP80"));
> >> +break;
> >> + case AV_CODEC_ID_VP9:
> >> +avio_wl32(pb, AV_RL32("VP90"));
> >> +break;
> >> + default:
> >> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8
> and
> >> VP9 and AV1 are supported!\n");
> >> +return AVERROR(EINVAL);
> >> +}
> >> avio_wl16(pb, par->width);
> >> avio_wl16(pb, par->height);
> >> avio_wl32(pb, s->streams[0]->time_base.den);
> >> @@ -95,16 +105,32 @@ static int ivf_check_bitstream(struct
> AVFormatContext
> >> *s, const AVPacket *pkt)
> >> int ret = 1;
> >> AVStream *st = s->streams[pkt->stream_index];
> >>
> >> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
> >> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> >> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> >> + (AV_RB24(pkt->data) != 0x01 ||
> >> + (st->codecpar->extradata_size > 0 &&
> >> + st->codecpar->extradata[0] == 1)))
> >> +ret = ff_stream_add_bitstream_filter(st,
> "h264_mp4toannexb",
> >> NULL);
> >> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> >> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> >> + (AV_RB24(pkt->data) != 0x01 ||
> >> + (st->codecpar->extradata_size > 0 &&
> >> + st->codecpar->extradata[0] == 1)))
> >> +ret = ff_stream_add_bitstream_filter(st,
> "hevc_mp4toannexb",
> >> NULL);
> >> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
> >> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe",
> NULL);
> >> +}
> >>
> >> return ret;
> >> }
> >>
> >> static const AVCodecTag codec_ivf_tags[] = {
> >> +{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> >> +{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
> >> +{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
> >> { AV_CODEC_ID_VP8, MKTAG('V', 'P', '8', '0') },
> >> { AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
> >> -{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> >> +
> >> { AV_CODEC_ID_NONE, 0 }
> >> };
> >>
> >> --
> >> 2.19.0.605.g01d371f741-goog
> >>
> >>
> > Can you please take a look on this patch?
>
> Can you answer the question posed in <
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2018-September/234655.html>
> about the reasoning for this patch?
>
> In particular, it might be helpful if you could point out any
> tools/standards which support (or are in future intending to support) this
> format - in my experience pretty much everything dealing with H.26[45] raw
> streams uses the Annex B format.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi Mark,
at Google we have some old service which is still running and it works only
with the IVF container. It would be great if ffmpeg could generate such
videos so we could give them to the service then. Given that ffmpeg IVF
demuxer already supports reading such files, I think it's reasonable to
make IVF muxer be
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 05/10/18 21:45, Alex Sukhanov wrote:
> On Mon, Oct 1, 2018 at 11:01 AM wrote:
>
>> From: Alex Sukhanov
>>
>> ---
>> libavformat/ivfenc.c | 50 +---
>> 1 file changed, 38 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
>> index 66441a2a43..6410828533 100644
>> --- a/libavformat/ivfenc.c
>> +++ b/libavformat/ivfenc.c
>> @@ -36,19 +36,29 @@ static int ivf_write_header(AVFormatContext *s)
>> return AVERROR(EINVAL);
>> }
>> par = s->streams[0]->codecpar;
>> -if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
>> -!(par->codec_id == AV_CODEC_ID_AV1 ||
>> - par->codec_id == AV_CODEC_ID_VP8 ||
>> - par->codec_id == AV_CODEC_ID_VP9)) {
>> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
>> supported!\n");
>> -return AVERROR(EINVAL);
>> -}
>> avio_write(pb, "DKIF", 4);
>> avio_wl16(pb, 0); // version
>> avio_wl16(pb, 32); // header length
>> -avio_wl32(pb,
>> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
>> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
>> AV_RL32("AV01"));
>> +switch (par->codec_id) {
>> + case AV_CODEC_ID_AV1:
>> +avio_wl32(pb, AV_RL32("AV01"));
>> +break;
>> + case AV_CODEC_ID_H264:
>> +avio_wl32(pb, AV_RL32("H264"));
>> +break;
>> + case AV_CODEC_ID_HEVC:
>> +avio_wl32(pb, AV_RL32("HEVC"));
>> +break;
>> + case AV_CODEC_ID_VP8:
>> +avio_wl32(pb, AV_RL32("VP80"));
>> +break;
>> + case AV_CODEC_ID_VP9:
>> +avio_wl32(pb, AV_RL32("VP90"));
>> +break;
>> + default:
>> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and
>> VP9 and AV1 are supported!\n");
>> +return AVERROR(EINVAL);
>> +}
>> avio_wl16(pb, par->width);
>> avio_wl16(pb, par->height);
>> avio_wl32(pb, s->streams[0]->time_base.den);
>> @@ -95,16 +105,32 @@ static int ivf_check_bitstream(struct AVFormatContext
>> *s, const AVPacket *pkt)
>> int ret = 1;
>> AVStream *st = s->streams[pkt->stream_index];
>>
>> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
>> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
>> + (AV_RB24(pkt->data) != 0x01 ||
>> + (st->codecpar->extradata_size > 0 &&
>> + st->codecpar->extradata[0] == 1)))
>> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
>> NULL);
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
>> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
>> + (AV_RB24(pkt->data) != 0x01 ||
>> + (st->codecpar->extradata_size > 0 &&
>> + st->codecpar->extradata[0] == 1)))
>> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
>> NULL);
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
>> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
>> +}
>>
>> return ret;
>> }
>>
>> static const AVCodecTag codec_ivf_tags[] = {
>> +{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
>> +{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
>> +{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
>> { AV_CODEC_ID_VP8, MKTAG('V', 'P', '8', '0') },
>> { AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
>> -{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
>> +
>> { AV_CODEC_ID_NONE, 0 }
>> };
>>
>> --
>> 2.19.0.605.g01d371f741-goog
>>
>>
> Can you please take a look on this patch?
Can you answer the question posed in
about the reasoning for this patch?
In particular, it might be helpful if you could point out any tools/standards
which support (or are in future intending to support) this format - in my
experience pretty much everything dealing with H.26[45] raw streams uses the
Annex B format.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Mon, Oct 1, 2018 at 11:01 AM wrote:
> From: Alex Sukhanov
>
> ---
> libavformat/ivfenc.c | 50 +---
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index 66441a2a43..6410828533 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -36,19 +36,29 @@ static int ivf_write_header(AVFormatContext *s)
> return AVERROR(EINVAL);
> }
> par = s->streams[0]->codecpar;
> -if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> -!(par->codec_id == AV_CODEC_ID_AV1 ||
> - par->codec_id == AV_CODEC_ID_VP8 ||
> - par->codec_id == AV_CODEC_ID_VP9)) {
> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> supported!\n");
> -return AVERROR(EINVAL);
> -}
> avio_write(pb, "DKIF", 4);
> avio_wl16(pb, 0); // version
> avio_wl16(pb, 32); // header length
> -avio_wl32(pb,
> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> AV_RL32("AV01"));
> +switch (par->codec_id) {
> + case AV_CODEC_ID_AV1:
> +avio_wl32(pb, AV_RL32("AV01"));
> +break;
> + case AV_CODEC_ID_H264:
> +avio_wl32(pb, AV_RL32("H264"));
> +break;
> + case AV_CODEC_ID_HEVC:
> +avio_wl32(pb, AV_RL32("HEVC"));
> +break;
> + case AV_CODEC_ID_VP8:
> +avio_wl32(pb, AV_RL32("VP80"));
> +break;
> + case AV_CODEC_ID_VP9:
> +avio_wl32(pb, AV_RL32("VP90"));
> +break;
> + default:
> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and
> VP9 and AV1 are supported!\n");
> +return AVERROR(EINVAL);
> +}
> avio_wl16(pb, par->width);
> avio_wl16(pb, par->height);
> avio_wl32(pb, s->streams[0]->time_base.den);
> @@ -95,16 +105,32 @@ static int ivf_check_bitstream(struct AVFormatContext
> *s, const AVPacket *pkt)
> int ret = 1;
> AVStream *st = s->streams[pkt->stream_index];
>
> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
> +}
>
> return ret;
> }
>
> static const AVCodecTag codec_ivf_tags[] = {
> +{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> +{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
> +{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
> { AV_CODEC_ID_VP8, MKTAG('V', 'P', '8', '0') },
> { AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
> -{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> +
> { AV_CODEC_ID_NONE, 0 }
> };
>
> --
> 2.19.0.605.g01d371f741-goog
>
>
Can you please take a look on this patch?
Thank you
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Sep 30, 2018 at 2:09 PM Jan Ekström wrote:
> Sn Sun, Sep 30, 2018 at 8:56 PM wrote:
> >
> > ...
> > +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> > +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> > + (AV_RB24(pkt->data) != 0x01 ||
> > + (st->codecpar->extradata_size > 0 &&
> > + st->codecpar->extradata[0] == 1)))
> > +ret = ff_stream_add_bitstream_filter(st,
> "h264_mp4toannexb", NULL);
> > +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> > +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> > + (AV_RB24(pkt->data) != 0x01 ||
> > + (st->codecpar->extradata_size > 0 &&
> > + st->codecpar->extradata[0] == 1)))
> > +ret = ff_stream_add_bitstream_filter(st,
> "hevc_mp4toannexb", NULL);
>
> Please verify that there is no AVCc/Annex B deciding helper function
> within lavf/lavc that could be used here. I tried to ask about this on
> IRC but didn't get responses so I can't straight up note you a
> function name. If there's none, then it might be worth making a lavf
> helper for that since I think at least movenc/matroskaenc try to
> figure out if the input bit stream is Annex B and convert it the other
> way.
>
> Additionally, please make sure that the files created with these
> changes can be demuxed with the FFmpeg IVF demuxer (ivfdec.c). I would
> guess the H.264 stuff would work, but since the IVF demuxer utilizes
> the ff_codec_bmp_tags list, which doesn't seem to contain HEVC entries
> I would guess additional stuff would be required there.
>
>
Verified that demuxer can handle the files by running ffplay.
Thank you.
> That of course doesn't have to be within this patch, but just within
> this patch set (one patch for demuxer, one for muxer).
>
> Best regards,
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
From: Alex Sukhanov
---
libavformat/ivfenc.c | 50 +---
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 66441a2a43..6410828533 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -36,19 +36,29 @@ static int ivf_write_header(AVFormatContext *s)
return AVERROR(EINVAL);
}
par = s->streams[0]->codecpar;
-if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
-!(par->codec_id == AV_CODEC_ID_AV1 ||
- par->codec_id == AV_CODEC_ID_VP8 ||
- par->codec_id == AV_CODEC_ID_VP9)) {
-av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
supported!\n");
-return AVERROR(EINVAL);
-}
avio_write(pb, "DKIF", 4);
avio_wl16(pb, 0); // version
avio_wl16(pb, 32); // header length
-avio_wl32(pb,
- par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
- par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
AV_RL32("AV01"));
+switch (par->codec_id) {
+ case AV_CODEC_ID_AV1:
+avio_wl32(pb, AV_RL32("AV01"));
+break;
+ case AV_CODEC_ID_H264:
+avio_wl32(pb, AV_RL32("H264"));
+break;
+ case AV_CODEC_ID_HEVC:
+avio_wl32(pb, AV_RL32("HEVC"));
+break;
+ case AV_CODEC_ID_VP8:
+avio_wl32(pb, AV_RL32("VP80"));
+break;
+ case AV_CODEC_ID_VP9:
+avio_wl32(pb, AV_RL32("VP90"));
+break;
+ default:
+av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and VP9
and AV1 are supported!\n");
+return AVERROR(EINVAL);
+}
avio_wl16(pb, par->width);
avio_wl16(pb, par->height);
avio_wl32(pb, s->streams[0]->time_base.den);
@@ -95,16 +105,32 @@ static int ivf_check_bitstream(struct AVFormatContext *s,
const AVPacket *pkt)
int ret = 1;
AVStream *st = s->streams[pkt->stream_index];
-if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
+if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ (AV_RB24(pkt->data) != 0x01 ||
+ (st->codecpar->extradata_size > 0 &&
+ st->codecpar->extradata[0] == 1)))
+ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb", NULL);
+} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ (AV_RB24(pkt->data) != 0x01 ||
+ (st->codecpar->extradata_size > 0 &&
+ st->codecpar->extradata[0] == 1)))
+ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb", NULL);
+} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
+}
return ret;
}
static const AVCodecTag codec_ivf_tags[] = {
+{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
+{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
+{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
{ AV_CODEC_ID_VP8, MKTAG('V', 'P', '8', '0') },
{ AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
-{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
+
{ AV_CODEC_ID_NONE, 0 }
};
--
2.19.0.605.g01d371f741-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 10/1/18, Nicolas George wrote: > Paul B Mahol (2018-10-01): >> Same is given with AVERROR_BUG, instead of hard crashing with assert, >> which is >> very unprofessional. > > A program crashing seems very professional to me. The most professional > program ever, windows, has a long history of crashing. Fortunately, > FFmpeg is not a professional project, we can afford to do things > properly. > > A program that crashes is sloppy, indeed. Assert failures are bad. But > AVERROR_BUG is just as bad. It should not happen after commit either. > Therefore, this is not an argument to choose one over the other. I lost motivation to feed more. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
Paul B Mahol (2018-10-01): > Same is given with AVERROR_BUG, instead of hard crashing with assert, which is > very unprofessional. A program crashing seems very professional to me. The most professional program ever, windows, has a long history of crashing. Fortunately, FFmpeg is not a professional project, we can afford to do things properly. A program that crashes is sloppy, indeed. Assert failures are bad. But AVERROR_BUG is just as bad. It should not happen after commit either. Therefore, this is not an argument to choose one over the other. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 9/30/18, Nicolas George wrote: > Paul B Mahol (2018-09-30): >> > For consistency within a single function, an assert is the correct >> > choice. >> No, it is not. Asserts do not add any consistency. > > Asserts do not add consistency indeed. Their purpose is to check > consistency, which is exactly what needs testing here: the consistency > between the preliminary test and the later switch statement. > > If you want to argue for AVERROR_BUG, please give arguments. Same is given with AVERROR_BUG, instead of hard crashing with assert, which is very unprofessional. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Mon, Oct 1, 2018 at 12:01 AM Jan Ekström wrote: > > Additionally, please make sure that the files created with these > changes can be demuxed with the FFmpeg IVF demuxer (ivfdec.c). I would > guess the H.264 stuff would work, but since the IVF demuxer utilizes > the ff_codec_bmp_tags list, which doesn't seem to contain HEVC entries > I would guess additional stuff would be required there. > For the record, I was noted that people were previously against adding HEVC to riff.c's lists as that would end up supporting HEVC in AVI, which we would prefer not to see in the wild. Thus I think the proper way of doing this would be to have the IVF demuxer to have its own AVCodecTag list instead of using the global RIFF list. This could be shared between the demuxer and muxer so it doesn't get duplicated. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 9/30/2018 6:01 PM, Jan Ekström wrote:
> Sn Sun, Sep 30, 2018 at 8:56 PM wrote:
>>
>> ...
>> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
>> + (AV_RB24(pkt->data) != 0x01 ||
>> + (st->codecpar->extradata_size > 0 &&
>> + st->codecpar->extradata[0] == 1)))
>> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
>> NULL);
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
>> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
>> + (AV_RB24(pkt->data) != 0x01 ||
>> + (st->codecpar->extradata_size > 0 &&
>> + st->codecpar->extradata[0] == 1)))
>> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
>> NULL);
>
> Please verify that there is no AVCc/Annex B deciding helper function
> within lavf/lavc that could be used here. I tried to ask about this on
> IRC but didn't get responses so I can't straight up note you a
> function name. If there's none, then it might be worth making a lavf
> helper for that since I think at least movenc/matroskaenc try to
> figure out if the input bit stream is Annex B and convert it the other
> way.
The *_mp4toannexb bitstream filters convert mp4 encapsulated packets
into annex-b, or pass already annex-b formatted packets through.
Assuming ivf is meant to use annex-b, then what this patch is doing is
correct.
>
> Additionally, please make sure that the files created with these
> changes can be demuxed with the FFmpeg IVF demuxer (ivfdec.c). I would
> guess the H.264 stuff would work, but since the IVF demuxer utilizes
> the ff_codec_bmp_tags list, which doesn't seem to contain HEVC entries
> I would guess additional stuff would be required there.
>
> That of course doesn't have to be within this patch, but just within
> this patch set (one patch for demuxer, one for muxer).
Yes, a demuxer patch removing the usage of ff_codec_bmp_tags and
replacing it with a custom ivf specific one is needed after, or probably
before this patch.
>
> Best regards,
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
Sn Sun, Sep 30, 2018 at 8:56 PM wrote:
>
> ...
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
> NULL);
Please verify that there is no AVCc/Annex B deciding helper function
within lavf/lavc that could be used here. I tried to ask about this on
IRC but didn't get responses so I can't straight up note you a
function name. If there's none, then it might be worth making a lavf
helper for that since I think at least movenc/matroskaenc try to
figure out if the input bit stream is Annex B and convert it the other
way.
Additionally, please make sure that the files created with these
changes can be demuxed with the FFmpeg IVF demuxer (ivfdec.c). I would
guess the H.264 stuff would work, but since the IVF demuxer utilizes
the ff_codec_bmp_tags list, which doesn't seem to contain HEVC entries
I would guess additional stuff would be required there.
That of course doesn't have to be within this patch, but just within
this patch set (one patch for demuxer, one for muxer).
Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
Paul B Mahol (2018-09-30): > > For consistency within a single function, an assert is the correct > > choice. > No, it is not. Asserts do not add any consistency. Asserts do not add consistency indeed. Their purpose is to check consistency, which is exactly what needs testing here: the consistency between the preliminary test and the later switch statement. If you want to argue for AVERROR_BUG, please give arguments. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 9/30/18, Nicolas George wrote: > Paul B Mahol (2018-09-30): >> No, AVERROR_BUG is better. > > For consistency within a single function, an assert is the correct > choice. No, it is not. Asserts do not add any consistency. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
Paul B Mahol (2018-09-30): > No, AVERROR_BUG is better. For consistency within a single function, an assert is the correct choice. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 9/28/2018 3:51 PM, alx.sukha...@gmail.com wrote:
> From: Alex Sukhanov
>
> ---
> libavformat/ivfenc.c | 41 -
> 1 file changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index 66441a2a43..68c36daf09 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -38,17 +38,35 @@ static int ivf_write_header(AVFormatContext *s)
> par = s->streams[0]->codecpar;
> if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> !(par->codec_id == AV_CODEC_ID_AV1 ||
> + par->codec_id == AV_CODEC_ID_H264 ||
> + par->codec_id == AV_CODEC_ID_HEVC ||
>par->codec_id == AV_CODEC_ID_VP8 ||
>par->codec_id == AV_CODEC_ID_VP9)) {
> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> supported!\n");
> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and VP9
> and AV1 are supported!\n");
> return AVERROR(EINVAL);
> }
> avio_write(pb, "DKIF", 4);
> avio_wl16(pb, 0); // version
> avio_wl16(pb, 32); // header length
> -avio_wl32(pb,
> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> AV_RL32("AV01"));
> +switch (par->codec_id) {
> + case AV_CODEC_ID_AV1:
> +avio_wl32(pb, AV_RL32("AV01"));
> +break;
> + case AV_CODEC_ID_H264:
> +avio_wl32(pb, AV_RL32("H264"));
> +break;
> + case AV_CODEC_ID_HEVC:
> +avio_wl32(pb, AV_RL32("HEVC"));
> +break;
> + case AV_CODEC_ID_VP8:
> +avio_wl32(pb, AV_RL32("VP80"));
> +break;
> + case AV_CODEC_ID_VP9:
> +avio_wl32(pb, AV_RL32("VP90"));
> +break;
> + default:
> +break;
> +}
> avio_wl16(pb, par->width);
> avio_wl16(pb, par->height);
> avio_wl32(pb, s->streams[0]->time_base.den);
> @@ -95,8 +113,21 @@ static int ivf_check_bitstream(struct AVFormatContext *s,
> const AVPacket *pkt)
> int ret = 1;
> AVStream *st = s->streams[pkt->stream_index];
>
> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
> +}
>
> return ret;
> }
>
This is missing adding the new codec tags to codec_ivf_tags[] at the end
of the file.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 9/30/18, Carl Eugen Hoyos wrote:
> 2018-09-28 20:51 GMT+02:00, alx.sukha...@gmail.com :
>> From: Alex Sukhanov
>
>> if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
>> !(par->codec_id == AV_CODEC_ID_AV1 ||
>> + par->codec_id == AV_CODEC_ID_H264 ||
>> + par->codec_id == AV_CODEC_ID_HEVC ||
>>par->codec_id == AV_CODEC_ID_VP8 ||
>>par->codec_id == AV_CODEC_ID_VP9)) {
>> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
>> supported!\n");
>> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and
>> VP9 and AV1 are supported!\n");
>> return AVERROR(EINVAL);
>
>> }
>> avio_write(pb, "DKIF", 4);
>> avio_wl16(pb, 0); // version
>> avio_wl16(pb, 32); // header length
>> -avio_wl32(pb,
>> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
>> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
>> AV_RL32("AV01"));
>> +switch (par->codec_id) {
>> + case AV_CODEC_ID_AV1:
>> +avio_wl32(pb, AV_RL32("AV01"));
>> +break;
>> + case AV_CODEC_ID_H264:
>> +avio_wl32(pb, AV_RL32("H264"));
>> +break;
>> + case AV_CODEC_ID_HEVC:
>> +avio_wl32(pb, AV_RL32("HEVC"));
>> +break;
>> + case AV_CODEC_ID_VP8:
>> +avio_wl32(pb, AV_RL32("VP80"));
>> +break;
>> + case AV_CODEC_ID_VP9:
>> +avio_wl32(pb, AV_RL32("VP90"));
>> +break;
>
>> + default:
>> +break;
>
> Please either remove this or make it an assert().
No, AVERROR_BUG is better.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
2018-09-28 20:51 GMT+02:00, alx.sukha...@gmail.com :
> From: Alex Sukhanov
> if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> !(par->codec_id == AV_CODEC_ID_AV1 ||
> + par->codec_id == AV_CODEC_ID_H264 ||
> + par->codec_id == AV_CODEC_ID_HEVC ||
>par->codec_id == AV_CODEC_ID_VP8 ||
>par->codec_id == AV_CODEC_ID_VP9)) {
> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> supported!\n");
> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and
> VP9 and AV1 are supported!\n");
> return AVERROR(EINVAL);
> }
> avio_write(pb, "DKIF", 4);
> avio_wl16(pb, 0); // version
> avio_wl16(pb, 32); // header length
> -avio_wl32(pb,
> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> AV_RL32("AV01"));
> +switch (par->codec_id) {
> + case AV_CODEC_ID_AV1:
> +avio_wl32(pb, AV_RL32("AV01"));
> +break;
> + case AV_CODEC_ID_H264:
> +avio_wl32(pb, AV_RL32("H264"));
> +break;
> + case AV_CODEC_ID_HEVC:
> +avio_wl32(pb, AV_RL32("HEVC"));
> +break;
> + case AV_CODEC_ID_VP8:
> +avio_wl32(pb, AV_RL32("VP80"));
> +break;
> + case AV_CODEC_ID_VP9:
> +avio_wl32(pb, AV_RL32("VP90"));
> +break;
> + default:
> +break;
Please either remove this or make it an assert().
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
From: Alex Sukhanov
---
libavformat/ivfenc.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 66441a2a43..68c36daf09 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -38,17 +38,35 @@ static int ivf_write_header(AVFormatContext *s)
par = s->streams[0]->codecpar;
if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
!(par->codec_id == AV_CODEC_ID_AV1 ||
+ par->codec_id == AV_CODEC_ID_H264 ||
+ par->codec_id == AV_CODEC_ID_HEVC ||
par->codec_id == AV_CODEC_ID_VP8 ||
par->codec_id == AV_CODEC_ID_VP9)) {
-av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
supported!\n");
+av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and VP9
and AV1 are supported!\n");
return AVERROR(EINVAL);
}
avio_write(pb, "DKIF", 4);
avio_wl16(pb, 0); // version
avio_wl16(pb, 32); // header length
-avio_wl32(pb,
- par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
- par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
AV_RL32("AV01"));
+switch (par->codec_id) {
+ case AV_CODEC_ID_AV1:
+avio_wl32(pb, AV_RL32("AV01"));
+break;
+ case AV_CODEC_ID_H264:
+avio_wl32(pb, AV_RL32("H264"));
+break;
+ case AV_CODEC_ID_HEVC:
+avio_wl32(pb, AV_RL32("HEVC"));
+break;
+ case AV_CODEC_ID_VP8:
+avio_wl32(pb, AV_RL32("VP80"));
+break;
+ case AV_CODEC_ID_VP9:
+avio_wl32(pb, AV_RL32("VP90"));
+break;
+ default:
+break;
+}
avio_wl16(pb, par->width);
avio_wl16(pb, par->height);
avio_wl32(pb, s->streams[0]->time_base.den);
@@ -95,8 +113,21 @@ static int ivf_check_bitstream(struct AVFormatContext *s,
const AVPacket *pkt)
int ret = 1;
AVStream *st = s->streams[pkt->stream_index];
-if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
+if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ (AV_RB24(pkt->data) != 0x01 ||
+ (st->codecpar->extradata_size > 0 &&
+ st->codecpar->extradata[0] == 1)))
+ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb", NULL);
+} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ (AV_RB24(pkt->data) != 0x01 ||
+ (st->codecpar->extradata_size > 0 &&
+ st->codecpar->extradata[0] == 1)))
+ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb", NULL);
+} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
+}
return ret;
}
--
2.19.0.605.g01d371f741-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
2018-09-27 22:16 GMT+02:00, Jan Ekström :
> On Thu, Sep 27, 2018 at 10:18 PM, wrote:
>> From: Alex Sukhanov
>>
>> ---
>> libavformat/ivfenc.c | 37 -
>> 1 file changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
>> index 66441a2a43..9ff7894b88 100644
>> --- a/libavformat/ivfenc.c
>> +++ b/libavformat/ivfenc.c
>> @@ -38,17 +38,31 @@ static int ivf_write_header(AVFormatContext *s)
>> par = s->streams[0]->codecpar;
>> if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
>> !(par->codec_id == AV_CODEC_ID_AV1 ||
>> + par->codec_id == AV_CODEC_ID_H264 ||
>
> Misses HEVC if you're adding support for it as well (as noted in the
> title of the patch).
>
>>par->codec_id == AV_CODEC_ID_VP8 ||
>>par->codec_id == AV_CODEC_ID_VP9)) {
>> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
>> supported!\n");
>> +av_log(s, AV_LOG_ERROR, "Currently only H264, VP8, VP9 and AV1
>> are supported!\n");
>
> Ditto regarding HEVC.
>
>> return AVERROR(EINVAL);
>> }
>> avio_write(pb, "DKIF", 4);
>> avio_wl16(pb, 0); // version
>> avio_wl16(pb, 32); // header length
>> -avio_wl32(pb,
>> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
>> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
>> AV_RL32("AV01"));
>> +switch (par->codec_id) {
>> + case AV_CODEC_ID_AV1:
>> +avio_wl32(pb, AV_RL32("AV01"));
>> +break;
>> + case AV_CODEC_ID_H264:
>> +avio_wl32(pb, AV_RL32("H264"));
>> +break;
>> + case AV_CODEC_ID_VP8:
>> +avio_wl32(pb, AV_RL32("VP80"));
>> +break;
>> + case AV_CODEC_ID_VP9:
>> +avio_wl32(pb, AV_RL32("VP90"));
>> +break;
>> + default:
>> +break;
>> +}
>
> Ditto regarding HEVC.
>
>> avio_wl16(pb, par->width);
>> avio_wl16(pb, par->height);
>> avio_wl32(pb, s->streams[0]->time_base.den);
>> @@ -95,8 +109,21 @@ static int ivf_check_bitstream(struct AVFormatContext
>> *s, const AVPacket *pkt)
>> int ret = 1;
>> AVStream *st = s->streams[pkt->stream_index];
>>
>> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
>> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
>> + (AV_RB24(pkt->data) != 0x01 ||
>> + (st->codecpar->extradata_size > 0 &&
>> + st->codecpar->extradata[0] == 1)))
>> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
>> NULL);
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
>> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
>> + (AV_RB24(pkt->data) != 0x01 ||
>> + (st->codecpar->extradata_size > 0 &&
>> + st->codecpar->extradata[0] == 1)))
>> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
>> NULL);
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
>> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
>> +}
>>
>
> There is an honest question mark above my head right now. So you use
> AVC/HEVC in IVF? Which is Annex B inside of another very simplistic
> "container" that doesn't even have random access point flags? Could
> you explain what is the benefit this would produce for people as
> opposed to just writing raw AVC/HEVC Annex B streams?
If Google decided to specify it, I believe we should support it.
If we agree that it is a bad idea to write such files, we can
request an increased strictness level.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Sep 27, 2018 at 10:18 PM, wrote:
> From: Alex Sukhanov
>
> ---
> libavformat/ivfenc.c | 37 -
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index 66441a2a43..9ff7894b88 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -38,17 +38,31 @@ static int ivf_write_header(AVFormatContext *s)
> par = s->streams[0]->codecpar;
> if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> !(par->codec_id == AV_CODEC_ID_AV1 ||
> + par->codec_id == AV_CODEC_ID_H264 ||
Misses HEVC if you're adding support for it as well (as noted in the
title of the patch).
>par->codec_id == AV_CODEC_ID_VP8 ||
>par->codec_id == AV_CODEC_ID_VP9)) {
> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> supported!\n");
> +av_log(s, AV_LOG_ERROR, "Currently only H264, VP8, VP9 and AV1 are
> supported!\n");
Ditto regarding HEVC.
> return AVERROR(EINVAL);
> }
> avio_write(pb, "DKIF", 4);
> avio_wl16(pb, 0); // version
> avio_wl16(pb, 32); // header length
> -avio_wl32(pb,
> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> AV_RL32("AV01"));
> +switch (par->codec_id) {
> + case AV_CODEC_ID_AV1:
> +avio_wl32(pb, AV_RL32("AV01"));
> +break;
> + case AV_CODEC_ID_H264:
> +avio_wl32(pb, AV_RL32("H264"));
> +break;
> + case AV_CODEC_ID_VP8:
> +avio_wl32(pb, AV_RL32("VP80"));
> +break;
> + case AV_CODEC_ID_VP9:
> +avio_wl32(pb, AV_RL32("VP90"));
> +break;
> + default:
> +break;
> +}
Ditto regarding HEVC.
> avio_wl16(pb, par->width);
> avio_wl16(pb, par->height);
> avio_wl32(pb, s->streams[0]->time_base.den);
> @@ -95,8 +109,21 @@ static int ivf_check_bitstream(struct AVFormatContext *s,
> const AVPacket *pkt)
> int ret = 1;
> AVStream *st = s->streams[pkt->stream_index];
>
> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
> +}
>
There is an honest question mark above my head right now. So you use
AVC/HEVC in IVF? Which is Annex B inside of another very simplistic
"container" that doesn't even have random access point flags? Could
you explain what is the benefit this would produce for people as
opposed to just writing raw AVC/HEVC Annex B streams? Thanks.
Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
From: Alex Sukhanov
---
libavformat/ivfenc.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 66441a2a43..9ff7894b88 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -38,17 +38,31 @@ static int ivf_write_header(AVFormatContext *s)
par = s->streams[0]->codecpar;
if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
!(par->codec_id == AV_CODEC_ID_AV1 ||
+ par->codec_id == AV_CODEC_ID_H264 ||
par->codec_id == AV_CODEC_ID_VP8 ||
par->codec_id == AV_CODEC_ID_VP9)) {
-av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
supported!\n");
+av_log(s, AV_LOG_ERROR, "Currently only H264, VP8, VP9 and AV1 are
supported!\n");
return AVERROR(EINVAL);
}
avio_write(pb, "DKIF", 4);
avio_wl16(pb, 0); // version
avio_wl16(pb, 32); // header length
-avio_wl32(pb,
- par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
- par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
AV_RL32("AV01"));
+switch (par->codec_id) {
+ case AV_CODEC_ID_AV1:
+avio_wl32(pb, AV_RL32("AV01"));
+break;
+ case AV_CODEC_ID_H264:
+avio_wl32(pb, AV_RL32("H264"));
+break;
+ case AV_CODEC_ID_VP8:
+avio_wl32(pb, AV_RL32("VP80"));
+break;
+ case AV_CODEC_ID_VP9:
+avio_wl32(pb, AV_RL32("VP90"));
+break;
+ default:
+break;
+}
avio_wl16(pb, par->width);
avio_wl16(pb, par->height);
avio_wl32(pb, s->streams[0]->time_base.den);
@@ -95,8 +109,21 @@ static int ivf_check_bitstream(struct AVFormatContext *s,
const AVPacket *pkt)
int ret = 1;
AVStream *st = s->streams[pkt->stream_index];
-if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
+if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ (AV_RB24(pkt->data) != 0x01 ||
+ (st->codecpar->extradata_size > 0 &&
+ st->codecpar->extradata[0] == 1)))
+ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb", NULL);
+} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ (AV_RB24(pkt->data) != 0x01 ||
+ (st->codecpar->extradata_size > 0 &&
+ st->codecpar->extradata[0] == 1)))
+ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb", NULL);
+} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
+}
return ret;
}
--
2.19.0.605.g01d371f741-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
