On 26 Feb 2014, at 08:47, Martin Storsjö <mar...@martin.st> wrote: > On Wed, 26 Feb 2014, Tim Walker wrote: > >> 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?
Actually, no. Under section '5.4 Derivation from ISO Base Media File Format', there is a sub-section '5.4.1 AVC File type and identification' before '5.4.2 AVC Video Stream Definition', but section '8.4 Derivation from ISO base media file format' goes straight to '8.4.1 HEVC video stream definition'. So I *guess* there is no HEVC-specific brand like there is for AVC. > >> 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. I just realized ff_avc_parse_nal_units() writes the data to the AVIOContext, d'oh! That code makes more sense now. > >> >> 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...) Hmm. It looks like the libavcodec libx264 wrapper provides extradata in Annex B format - does it also provide packets in Annex B format, or with MP4-style NAL prefixes (looks like the former, but I'm not sure)? Perhaps a better question, what issue(s) (if any) would occur if a caller provided avcC- of hvcC-formatted extradata, but Annex B formatted packets? > >> 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? OK. Otherwise I was thinking of moving the non AVC-specific stuff to nal_unit.h/nal_unit.c, and then maybe rename as follows: ff_avc_foo() -> ff_nal_unit_foo() …and so on. Still, if calling AVC-named functions of HEVC is fine, it's less work :-) Tim _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
