>De : Anton Khirnov <an...@khirnov.net> >Envoyé : jeudi 5 décembre 2024 15:06 >Hi, >I believe a similar approach was tried by Gyan earlier this year and >unanimously rejected by the TC [1-3]. > >[1] >https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/ >[2] Message-Id <9be400cf-949f-4eb1-93a1-b352a1b80...@gyani.pro> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321564.html >[3] Message-Id <20240412122920.gb3...@haasn.xyz> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325588.html
Anton, Yes, of course, I followed this work. I thought I had highlighted many new elements (including many s337m issues in current code), and my work is not focused on s302m, so I would have expected some discussions to start. You certainely noticed that I posted this as an "RFC", so it is more "open". To take an example, I will quote one point of the TC: "The opposition to the patch was based on the opinion that this implementation of S302M should be handled by libavformat, not libavcodec." In my patch serie, the s302m decoder IS moved to libavformat, which is what was asked. So: even if there are some strong/hard points against the s337m decoder I designed, maybe part of this work can be helpful. Maybe just the s302m decoder moved to libavformat, I don't know. Nicolas _______________________________________________ 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".
