On Mon, Jan 14, 2019 at 11:11:59AM -0500, Devin Heitmueller wrote: > > > In short, a centralized function would be good, but we probably need > > > to think through what the API looks like so we don't have to introduce > > > a new API in libavutil and then deprecate it once we want to make the > > > splitting/combining logic work according to the spec. > > > > I fear that no matter how hard we try we will likely eventually run > > into cases that it cannot handle > > Oh, I completely agree. Some captions are just going to be too > screwed up to render. However I think there are cases we can recover > from, and in particular I would like to make sure that streams created > with versions of ffmpeg before this patch continue to play properly > (i.e. where the stream only has caption data on every other frame and > the cc_count is 2x what it is supposed to be). > > > also maybe 2 functions would keep this simpler > > one to deal with temporal transformations (frame drop, duplicate, > > interpolate, > > combine) > > one to deal with spatial transformations, crop, pad, scale, rotate > > There shouldn't be any need for a function for spatial > transformations. The expected cc_count is unrelated to the resolution > of the video. It's tied exclusively to the framerate and whether you > are doing frame or field-level encoding when the video is interlaced. > The underlying goal was to ensure that the bitrate of the caption data > is a constant 9600bps and thus they wanted it to be spread evenly > across the frames/fields. When people encounter problems going from > 1080i to 720p for example, it's because that also involves framerate > conversion, not because the resolution of the individual video frames > is being changed.
well, there are other types of side data too. for example motion vectors would need to be updated on crop depending on which rectangle is croped out [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel