On Wed, 26 Feb 2014, Tim Walker wrote:
I believe/hope I managed to get hvcC creation right
(as per ISO/IEC 14496-15). -vcodec copy output seems
to work in VLC and avplay. Note: the libx265 wrapper
doesn't set the context extradata, so ff_isom_write_hvcc()
does nothing in that case (output seems to work in VLC and
avplay regardless).
I didn't bother adding 3gp/f4v tags for HEVC, as I don't
know whether this is even supported/possible yet.
For 3gp I guess it's best to wait until a spec says it's ok. For f4v, I'd
wait until flash player would support such f4v files.
Similarly, I don't know whether mov_write_isml_manifest()
can and/or should be updated yet.
Probably only once smooth streaming (either in spec or in one of MS's
reference players) supports it.
I didn't update mov_write_ftyp_tag() either (same reasons).
Does the spec (or drafts if that's all that there is?) say anything about
this?
I tried to update the AVC-specific code in matroskaenc
and movenc when it looked like it may have been applicable
to HEVC as well. In some cases, I have no clue what that
code actually does, so it may be quite wrong. Examples:
/* nal reformating needed */ in movenc.c
…no idea what this code does.
Your change looks good. It reformats the NALs from annex b to mp4 format -
normally just writing the reformatted data straight to an AVIOContext, but
if using RTP hinting, reformatting and storing the new data in a buffer
for other use later (the RTP hinting needs to know exactly what was
written to the file), so it's basically an optimization to avoid extra
copying/allocing/freeing for the normal case.
ff_avc_parse_nal_units_buf(pkt->data, &data, &size);
…in matroskaenc.c, only when a start code is found in
the extradata (Annex B formatted), but not if the
extradata is e.g. already hvcC-formatted?
Yes, generally you'd assume that the packets use MP4 style nal prefixes
instead of annex b, if the extradata is in avcC/hvcC format (since it's
much easier to determine what format is being used based on extradata,
instead of allowing extradata in one format and packets in another, or
even better, different format in each packet...)
ff_isom_write_avcc() and
ff_avc_write_annexb_extradata() are H.264-specific,
but the other ff_avc_*() functions in avc.c are also
applicable to HEVC, thus should probably be renamed
and moved to a separate file. Someone suggested
ff_avc -> ff_xvc, thoughts?
Either that, or just keep them as is - avc.c doesn't have much external
dependencies right? So I don't think it's a big issue to have all those
users just pull in the whole avc.c (which they probably do already
anyway), and having the hevc code call ff_avc_* functions probably isn't
too much of an issue either?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
