Hi Dave, > > The President of AJA has publicly stated an intent to add an open license to > their SDK, https://twitter.com/ajaprez/status/910100436224499713 > <https://twitter.com/ajaprez/status/910100436224499713>.
This is certainly good news. Looking at AJA’s offering is on my TODO list but I just haven’t found the time to pick up a card and dig into their SDK. > I’m glad to hear that handling other VANC data is in the works, I’m > particularly interested in VITC and EIA-608 with inputs. I am certainly interested in supporting VITC, assuming you’re talking about SMPTE 12M/RP-188 time codes. EIA-608 wouldn’t be very hard to do, although there isn’t much equipment out there which does CEA-608 but not CEA-708. Maybe some old legacy pre-HD equipment. It would actually be pretty easy to do EIA-608 and just shoe-horn it in as AV_FRAME_DATA_A53_CC side data. You would just need to compute the correct value for cc_count based on the frame rate, create an array of bytes of size [cc_count][3], and then fill the first two entries with the EIA-608 byte pairs. Creating a new side-data type would seem like the reasonable approach at first glance, but then you have to duplicate all the logic on the insertion side for the various encoder codecs. That said, supporting both 608 and 708 creates an unfortunate side effect - you have to write logic to decide which takes precedence if both are in an SDI frame (or expose configuration options to let the user specify). Any SDI capture routine would have to choose one or the other, since downstream codecs general don’t have the capacity to insert both into a transport stream. My inclination would probably be to simply ignore EIA-608 if there are also 708 VANC packets present, but I can imagine you would also want a config option to allow the user to override that behavior. Devin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
