On Fri, Mar 10, 2023 at 2:44 AM Nicolas Gaullier
<nicolas.gaullier@cji.paris> wrote:
>
> >+static int create_s337_payload(AVPacket *pkt, enum AVCodecID codec_id,
> >+uint8_t **outbuf, int *outsize) {
>
> This is very interesting in many other contexts.
> My current patch serie is about demuxing s337 (targeting dolby_e) from wav
> files, and it would be great
> to be able to re-mux back to s337 in output formats, be it decklink, wav or
> any broadcast format.
> So, maybe this belongs to s337m.c ? It could be later updated to support
> dolby_e.
Hi Nicolas,
I've been following your work on s337 for a while now, as I have
corresponding patches to decklink capture and it might be better to
reuse your s337 avformat module from within the decklink libavdevice
(i.e. as a sub-demuxer).
At this point I'm inclined to keep the code separate/private to
decklink. It's limited to AC-3 and only produces packets which are
s16 little endian. At some point I think it would be worthwhile to
have some common code that supports 20/24 bit, both endians, and other
codecs like Dolby-E, but my concern was at this point that would
require a bunch of extra testing (much of which I don't have the
streams or hardware to do), and I didn't want to lock us permanently
into an ABI that I didn't know would meet our needs long term.
Moving it from a static function to something that can be shared is a
relatively simple operation, but I want to wait until we have a second
use case prior to refactoring the code.
Regards,
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com
_______________________________________________
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".
