On Thu, Sep 27, 2018 at 10:18 PM, <alx.sukha...@gmail.com> wrote:
> From: Alex Sukhanov <asukha...@google.com>
>
> ---
> 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) != 0x0000001 &&
> + (AV_RB24(pkt->data) != 0x000001 ||
> + (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) != 0x0000001 &&
> + (AV_RB24(pkt->data) != 0x000001 ||
> + (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
