Hello Vishwanath, > On Oct 13, 2017, at 1:42 AM, Dixit, Vishwanath <vdi...@akamai.com> wrote: > > Hi, > > Please find the attached patch which adds support to decode SCTE-104 message > from VANC for decklink capture use case. >
I’ve got a couple of concerns about this approach. Because I am doing a bunch of VANC related work, I looked at various VANC types and assessed their suitability for the use of AV_FRAME_SIDE_DATA versus generating new streams. While side data is well suited for content that will ultimately be fed into the encoder (e.g. EIA-708 captions, AFD, etc), there are significant limitations for using side data for content types that may need to result in new stream creation. Examples of this include SCTE-104 (which in many use cases will result in creation of an SCTE-35 stream), SMPTE 2038 (which again creates a corresponding elementary stream), and Teletext (which you see in the implementation today), etc. Further, there are significant limitations in the ability to access side data from within a pipeline. If tied to the video frame as side data, the only way to access it if not the target encoder codec is to use a video filter. Video filters cannot create new streams, and hence creating pipelines which make use of SCTE-104 packets can be very difficult. What you’ve submitted seems like half an actual use case - you’re ingesting the SCTE-104 packet and inserting it into as frame side data, but what are you actually planning to do with the data? Do your use cases involve transformation to SCTE-35? Do you care about the decklink input exclusively, or do you need the decklink output working as well? I’ve got patches queueing which implement SCTE-104 and SCTE-35 for the following use cases: - Ingest SCTE-104 on the decklink input, and create an SCTE-35 stream in the TS (including proper timing) - Decode a TS containing SCTE-35 and output the resulting data on the decklink output as SCTE-104 - Be able to ingest SCTE-104 from network port (either TCP or UDP) and output the data into the decklink output (i.e. a SCTE-104 inserter) - Be able to ingest SCTE-104 from a network port and insert the data into a TS as SCTE-35 The above cases require the flexibility to access the data from within the general pipeline as a stream, as opposed to the data being tied to the video frame as side-data. It may be beneficial for the two of us to talk about use cases so we can avoid duplicated effort. I already have patches which incorporate our mature VANC processing library for both the decklink input and output interfaces, and I’ve got trees which already implement EIA-708, AFD, SCTE-104, SCTE-35, and SMPTE 2038. I’ve been trickling the patches on the ML and the speed at which I’ve been providing them has been driven by how quickly they are reviewed and merged, not whether the work is already completed. For your reference it may be worthwhile for you to look at our “libklvanc” library, which we are actively deploying in OBE and VLC and which already implements much of the stuff you’re in the process of writing from scratch. My plan is to work on adding the glue in ffmpeg to leverage this library as well, given it’s code which is already in active use elsewhere and that work can be shared across multiple open source projects. https://github.com/stoth68000/libklvanc <https://github.com/stoth68000/libklvanc> I’m tied up working on multi-channel audio right now but I think there is definitely value in us syncing up to avoid duplicated effort and conflicting patches. Let’s see where we can divide/conquer rather than re-implementing work the other may have already done. Cheers, Devin Heitmueller LTN Global Communications _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
