sön 2020-07-05 klockan 10:43 +0200 skrev Jan Engelhardt: > On Sunday 2020-07-05 01:04, James Almer wrote: > > [[the header file says: > > * You can use AVOptions (av_opt* / av_set/get*()) to access these fields > > from user > > * applications.]] > > A "can" can be read as "need not". Perhaps that is what we are seeing with > blender which seems to access av fields directly, and has no noticable > av_set_ calls. > > writeffmpeg.c: if ((of->oformat->flags & AVFMT_GLOBALHEADER)) { > writeffmpeg.c: if (of->oformat->flags & AVFMT_GLOBALHEADER) { > writeffmpeg.c: of->oformat = fmt; > writeffmpeg.c: of->packet_size = rd->ffcodecdata.mux_packet_size; > writeffmpeg.c: of->max_delay = (int)(0.7 * AV_TIME_BASE); > writeffmpeg.c: BLI_strncpy(of->filename, name, sizeof(of->filename)); > writeffmpeg.c: if (avio_open(&of->pb, name, AVIO_FLAG_WRITE) < 0) { > writeffmpeg.c: &of->metadata, context->stamp_data, > ffmpeg_add_metadata_callback, false); > writeffmpeg.c: if (of->pb) { > writeffmpeg.c: avio_close(of->pb);
This looks like perfectly legitimate code to me. But, if Blender is using libav*'s APIs incorrectly somewhere then Blender should be fixed. > Or, summarized: A program may have been built with 4.3 but is combined > with 4.2.3 at runtime, then this can happen: > > a = avcodec_dct_alloc(); // allocates 896 > #ifdef HAVE_STRUCT_AVDCT_GET_PIXELS_UNALIGNED > a->get_pixels_unaligned = ffunc; // boom accessing byte ~952 > #endif "Doctor it hurts when I do this!" Downgrading to a .so file with a lower minor version number than the program is built against can never be expected to work. Else we couldn't add new functions without a major bump. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".