> >A few years back, there were developers working on scte 35 support in ffmpeg, >and so far, the mpegts demuxer recognizes the SCTE 35 codec (due to the patch >work written by >a certain Carlos Fernandez Sans). However, these threads were >often mired by a lot of push-back by some developers here and these efforts >did not amount to much. It's as if >they never wanted to see support for >SCTE-35 event splicing enabled, for some reason(s) beyond the quality of code >committed then. > >Examples of such threads (one by Anshul Maheshwari): >https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167487.html >And works by Carlos: >https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2016-October/102553.html >Of which only the codec ID info was merged: >https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2016-October/102552.html > >As things are at the moment, the workflow you desire with SCTE-35 seems to be >unsupported. > >
That’s what we were seeing from our searching as well. I do know that there are vendors that output cable channels after decryption with a cable card, with SCTE-35 that are using FFMPEG in the backend code. Silicon Dust with the now discontinued PRIME units for an example. Does anyone know how this is being facilitated? _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
