| Message ID | 1595948614-10861-2-git-send-email-lance.lmwang@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/5] API: add AV_PKT_DATA_MPEGTS_DESC_6A to AVPacketSideDataType | expand |
| Context | Check | Description |
|---|---|---|
| andriy/default | pending | |
| andriy/make | success | Make finished |
| andriy/make_fate | success | Make fate finished |
On Tue, 28 Jul 2020 at 16:31, <lance.lmwang@gmail.com> wrote: > From: Limin Wang <lance.lmwang@gmail.com> > > Signed-off-by: Limin Wang <lance.lmwang@gmail.com> > --- > Hi, There is already libdvbpsi or bitstream for these kind of applications, it should not go in FFmpeg, nor in public API. Kieran
On Wed, Aug 05, 2020 at 11:14:39AM +0100, Kieran Kunhya wrote: > On Tue, 28 Jul 2020 at 16:31, <lance.lmwang@gmail.com> wrote: > > > From: Limin Wang <lance.lmwang@gmail.com> > > > > Signed-off-by: Limin Wang <lance.lmwang@gmail.com> > > --- > > > > Hi, > > There is already libdvbpsi or bitstream for these kind of applications, it > should not go in FFmpeg, nor in public API. The major goal of the patchset is to support the audio descriptor(AC3) pass through as some fields are needed by some IRDs. I have no clues how to use libdvbpsi or bitstream library to achieve that, please give comments. > > Kieran
On Wed, 5 Aug 2020 at 12:54, <lance.lmwang@gmail.com> wrote: > On Wed, Aug 05, 2020 at 11:14:39AM +0100, Kieran Kunhya wrote: > > On Tue, 28 Jul 2020 at 16:31, <lance.lmwang@gmail.com> wrote: > > > > > From: Limin Wang <lance.lmwang@gmail.com> > > > > > > Signed-off-by: Limin Wang <lance.lmwang@gmail.com> > > > --- > > > > > > > Hi, > > > > There is already libdvbpsi or bitstream for these kind of applications, > it > > should not go in FFmpeg, nor in public API. > > The major goal of the patchset is to support the audio descriptor(AC3) > pass through > as some fields are needed by some IRDs. > > I have no clues how to use libdvbpsi or bitstream library to achieve that, > please > give comments. > Why does it need to be public api? The flaw with this method is that PSI is a separate data stream that doesn't fit within AVPacket or AVFrame etc, so it's a hack to just add it to AVPacket. Kieran
On Wed, Aug 05, 2020 at 05:50:56PM +0100, Kieran Kunhya wrote: > On Wed, 5 Aug 2020 at 12:54, <lance.lmwang@gmail.com> wrote: > > > On Wed, Aug 05, 2020 at 11:14:39AM +0100, Kieran Kunhya wrote: > > > On Tue, 28 Jul 2020 at 16:31, <lance.lmwang@gmail.com> wrote: > > > > > > > From: Limin Wang <lance.lmwang@gmail.com> > > > > > > > > Signed-off-by: Limin Wang <lance.lmwang@gmail.com> > > > > --- > > > > > > > > > > Hi, > > > > > > There is already libdvbpsi or bitstream for these kind of applications, > > it > > > should not go in FFmpeg, nor in public API. > > > > The major goal of the patchset is to support the audio descriptor(AC3) > > pass through > > as some fields are needed by some IRDs. > > > > I have no clues how to use libdvbpsi or bitstream library to achieve that, > > please > > give comments. > > > > Why does it need to be public api? Marton Balint give review comment to use the packet side data type like DOVI video descriptor when I try to use meta data of stream for the first patchset. In fact, if it's not input copy instead of encode, we should create audio descriptor for our AC-3 audio encoder also. If it's not public api, how to let encoder add it? > The flaw with this method is that PSI is a separate data stream that > doesn't fit within AVPacket or AVFrame etc, so it's a hack to just add it > to AVPacket. It's audio descriptor information although it's stored in PSI table, but it'll map to specific audio packet in the end, so I don't think it's hacky. I have tested with mpts with multiple audio stream, it's pass-by if copy specifc audio stream. > > Kieran > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> > It's audio descriptor information although it's stored in PSI table, but > it'll map to > specific audio packet in the end, so I don't think it's hacky. I have > tested > with mpts with multiple audio stream, it's pass-by if copy specifc audio > stream. > Why not just parse the AC-3 packet header in the mux and change the PSI there? Kieran
On Thu, Aug 06, 2020 at 07:51:55AM +0100, Kieran Kunhya wrote: > > > > It's audio descriptor information although it's stored in PSI table, but > > it'll map to > > specific audio packet in the end, so I don't think it's hacky. I have > > tested > > with mpts with multiple audio stream, it's pass-by if copy specifc audio > > stream. > > > > Why not just parse the AC-3 packet header in the mux and change the PSI > there? At first, I consider to pass-by the input descriptor so I haven't dig into the AC-3 parser/decode yet, I'm not sure whether it's possible to get all fields of the descriptor from AC-3 header. If it's OK, I think the parser should export such API to get the different audio descriptor after parse frame. > > Kieran > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Thu, 6 Aug 2020 at 15:48, <lance.lmwang@gmail.com> wrote: > On Thu, Aug 06, 2020 at 07:51:55AM +0100, Kieran Kunhya wrote: > > > > > > It's audio descriptor information although it's stored in PSI table, > but > > > it'll map to > > > specific audio packet in the end, so I don't think it's hacky. I have > > > tested > > > with mpts with multiple audio stream, it's pass-by if copy specifc > audio > > > stream. > > > > > > > Why not just parse the AC-3 packet header in the mux and change the PSI > > there? > No, I don't mean use a parser, the ac3 packet header is a simple bitstream, it's only a few bytes that need reading. Kieran
On Thu, Aug 06, 2020 at 03:52:33PM +0100, Kieran Kunhya wrote: > On Thu, 6 Aug 2020 at 15:48, <lance.lmwang@gmail.com> wrote: > > > On Thu, Aug 06, 2020 at 07:51:55AM +0100, Kieran Kunhya wrote: > > > > > > > > It's audio descriptor information although it's stored in PSI table, > > but > > > > it'll map to > > > > specific audio packet in the end, so I don't think it's hacky. I have > > > > tested > > > > with mpts with multiple audio stream, it's pass-by if copy specifc > > audio > > > > stream. > > > > > > > > > > Why not just parse the AC-3 packet header in the mux and change the PSI > > > there? > > > > No, I don't mean use a parser, the ac3 packet header is a simple bitstream, > it's only a few bytes that need reading. thanks, I'll look into the ac3 bitstream for the parse later. > > Kieran > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Thu, Aug 06, 2020 at 03:52:33PM +0100, Kieran Kunhya wrote: > On Thu, 6 Aug 2020 at 15:48, <lance.lmwang@gmail.com> wrote: > > > On Thu, Aug 06, 2020 at 07:51:55AM +0100, Kieran Kunhya wrote: > > > > > > > > It's audio descriptor information although it's stored in PSI table, > > but > > > > it'll map to > > > > specific audio packet in the end, so I don't think it's hacky. I have > > > > tested > > > > with mpts with multiple audio stream, it's pass-by if copy specifc > > audio > > > > stream. > > > > > > > > > > Why not just parse the AC-3 packet header in the mux and change the PSI > > > there? > > > > No, I don't mean use a parser, the ac3 packet header is a simple bitstream, > it's only a few bytes that need reading. I haven't found out how to recreated all the same field of original descriptor by the information of the header. For the header, I can get fscod, frmsizcod, bsid and I'm not sure how to map to dvb ac3 descriptor exactly, do you know which project is using this way? Thanks. > > Kieran > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
diff --git a/libavutil/Makefile b/libavutil/Makefile index 9b08372..4b4aa68 100644 --- a/libavutil/Makefile +++ b/libavutil/Makefile @@ -57,6 +57,7 @@ HEADERS = adler32.h \ md5.h \ mem.h \ motion_vector.h \ + mpegts_audio_desc_metadata.h \ murmur3.h \ opt.h \ parseutils.h \ @@ -140,6 +141,7 @@ OBJS = adler32.o \ mastering_display_metadata.o \ md5.o \ mem.o \ + mpegts_audio_desc_metadata.o \ murmur3.o \ opt.o \ parseutils.o \ diff --git a/libavutil/mpegts_audio_desc_metadata.c b/libavutil/mpegts_audio_desc_metadata.c new file mode 100644 index 0000000..14d9100 --- /dev/null +++ b/libavutil/mpegts_audio_desc_metadata.c @@ -0,0 +1,33 @@ +/* + * Copyright (c) 2020 Limin Wang <lance.lmwang@gmail.com> + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include "mpegts_audio_desc_metadata.h" +#include "mem.h" + +AVDescriptor6A *av_desc6a_alloc(size_t *size) +{ + AVDescriptor6A *desc6a = (AVDescriptor6A*)av_mallocz(sizeof(*desc6a)); + + if (!desc6a) + return NULL; + if (size) + *size = sizeof(*desc6a); + return desc6a; + +} diff --git a/libavutil/mpegts_audio_desc_metadata.h b/libavutil/mpegts_audio_desc_metadata.h new file mode 100644 index 0000000..58beee4 --- /dev/null +++ b/libavutil/mpegts_audio_desc_metadata.h @@ -0,0 +1,57 @@ +/* + * Copyright (c) 2020 Limin Wang <lance.lmwang@gmail.com> + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/** + * @file + * MPEGTS audio stream descriptor + */ + +#ifndef AVUTIL_MPEGTS_AUDIO_DESC_METADATA_H +#define AVUTIL_MPEGTS_AUDIO_DESC_METADATA_H +#include <stdint.h> +#include <stddef.h> + +/* ETSI 300 468 descriptor 0x6A(AC-3) + * Refer to: ETSI EN 300 468 V1.11.1 (2010-04) (SI in DVB systems) + * + * @note The struct must be allocated with av_desc6a_alloc() and + * its size is not a part of the public ABI. + */ +typedef struct AVDescriptor6A { + uint8_t component_type_flag; + uint8_t bsid_flag; + uint8_t mainid_flag; + uint8_t asvc_flag; + uint8_t reserved_flags; + uint8_t component_type; + uint8_t bsid; + uint8_t mainid; + uint8_t asvc; +} AVDescriptor6A; + +/** + * Allocate a AVDescriptor6A structure and initialize its + * fields to default values. + * + * @return the newly allocated struct or NULL on failure + */ +AVDescriptor6A *av_desc6a_alloc(size_t *size); + +#endif /* AVUTIL_MPEGTS_AUDIO_DESC_METADATA_H */