| Message ID | 89a2a366-de1c-8dd6-116c-f16a990fd907@gyani.pro |
|---|---|
| State | New |
| Headers | show |
On 08-07-2019 05:35 PM, Gyan wrote: > > > On 25-04-2019 01:48 PM, Gyan wrote: >> >> >> On 25-04-2019 01:23 PM, Ali KIZIL wrote: >>> >>> There are also Dolby Codecs (ac3 & eac3). Will it also throw error for >>> these codecs ? >> >> AC3 is supported before and after this patch. >> EAC3 is unsupported before and after this patch. >> >> But it's sent to the same decoder, so support could be added. I'll >> check. > > Attached patch allows muxing EAC3 in MPEG-PS. Stock ffmpeg can demux > and decode such streams fine. Will push tonight. Gyan
> Am 08.07.2019 um 14:05 schrieb Gyan <ffmpeg@gyani.pro>: > > > >> On 25-04-2019 01:48 PM, Gyan wrote: >> >> >>> On 25-04-2019 01:23 PM, Ali KIZIL wrote: >>> >>> There are also Dolby Codecs (ac3 & eac3). Will it also throw error for >>> these codecs ? >> >> AC3 is supported before and after this patch. >> EAC3 is unsupported before and after this patch. >> >> But it's sent to the same decoder, so support could be added. I'll check. > > Attached patch allows muxing EAC3 in MPEG-PS. Stock ffmpeg can demux and decode such streams fine. Which descriptor is used for eac3? Please do not commit just because decoding works with FFmpeg, at least try to find some specification. Carl Eugen
On 17-07-2019 02:23 PM, Carl Eugen Hoyos wrote: > > >> Am 08.07.2019 um 14:05 schrieb Gyan <ffmpeg@gyani.pro>: >> >> >> >>> On 25-04-2019 01:48 PM, Gyan wrote: >>> >>> >>>> On 25-04-2019 01:23 PM, Ali KIZIL wrote: >>>> >>>> There are also Dolby Codecs (ac3 & eac3). Will it also throw error for >>>> these codecs ? >>> AC3 is supported before and after this patch. >>> EAC3 is unsupported before and after this patch. >>> >>> But it's sent to the same decoder, so support could be added. I'll check. >> Attached patch allows muxing EAC3 in MPEG-PS. Stock ffmpeg can demux and decode such streams fine. > Which descriptor is used for eac3? > Please do not commit just because decoding works with FFmpeg, at least try to find some specification. The PS muxer appears to use System A and this is what the ATSC A/52 (2012) standard says, "For System A, this section extends the use ofthe AC-3 Registration Descriptor defined in Section A3 in combination with the E-AC-3 stream_type value defined below." and "E-AC-3 bit streams shall be identified with a stream_typevalue of 0x87 when transmitted as PES streams conforming to ATSC-published standards." Note that the stream_type value of AC-3 is 0x81 yet our id sequence starts from 0x80. This patch uses the same descriptor series as AC-3, however if I switch to 0x87, only one such stream may be muxed as 0x88 was assigned (by you) to DTS. Also, our demuxer sets the codec_id to DTS for 0x88 to 0x8f. Both stock ffmpeg and VlC 4.0 nightly play files using the current patch. Mediainfo also identifies the codec correctly. Comments? Gyan
On 19-07-2019 04:14 PM, Gyan wrote: > > > On 17-07-2019 02:23 PM, Carl Eugen Hoyos wrote: >> >> >>> Am 08.07.2019 um 14:05 schrieb Gyan <ffmpeg@gyani.pro>: >>> >>> >>> >>>> On 25-04-2019 01:48 PM, Gyan wrote: >>>> >>>> >>>>> On 25-04-2019 01:23 PM, Ali KIZIL wrote: >>>>> >>>>> There are also Dolby Codecs (ac3 & eac3). Will it also throw error >>>>> for >>>>> these codecs ? >>>> AC3 is supported before and after this patch. >>>> EAC3 is unsupported before and after this patch. >>>> >>>> But it's sent to the same decoder, so support could be added. I'll >>>> check. >>> Attached patch allows muxing EAC3 in MPEG-PS. Stock ffmpeg can >>> demux and decode such streams fine. >> Which descriptor is used for eac3? >> Please do not commit just because decoding works with FFmpeg, at >> least try to find some specification. > > The PS muxer appears to use System A and this is what the ATSC A/52 > (2012) standard says, > > "For System A, this section extends the use ofthe AC-3 Registration > Descriptor defined in Section A3 in combination with the E-AC-3 > stream_type value defined below." > > and > > "E-AC-3 bit streams shall be identified with a stream_typevalue of > 0x87 when transmitted as PES streams conforming to ATSC-published > standards." > > Note that the stream_type value of AC-3 is 0x81 yet our id sequence > starts from 0x80. This patch uses the same descriptor series as AC-3, > however if I switch to 0x87, only one such stream may be muxed as 0x88 > was assigned (by you) to DTS. Also, our demuxer sets the codec_id to > DTS for 0x88 to 0x8f. > > Both stock ffmpeg and VlC 4.0 nightly play files using the current > patch. Mediainfo also identifies the codec correctly. > > Comments? Carl, ping. Gyan
> Am 19.07.2019 um 12:44 schrieb Gyan <ffmpeg@gyani.pro>: > > > >> On 17-07-2019 02:23 PM, Carl Eugen Hoyos wrote: >> >> >>> Am 08.07.2019 um 14:05 schrieb Gyan <ffmpeg@gyani.pro>: >>> >>> >>> >>>> On 25-04-2019 01:48 PM, Gyan wrote: >>>> >>>> >>>>> On 25-04-2019 01:23 PM, Ali KIZIL wrote: >>>>> >>>>> There are also Dolby Codecs (ac3 & eac3). Will it also throw error for >>>>> these codecs ? >>>> AC3 is supported before and after this patch. >>>> EAC3 is unsupported before and after this patch. >>>> >>>> But it's sent to the same decoder, so support could be added. I'll check. >>> Attached patch allows muxing EAC3 in MPEG-PS. Stock ffmpeg can demux and decode such streams fine. >> Which descriptor is used for eac3? >> Please do not commit just because decoding works with FFmpeg, at least try to find some specification. > > The PS muxer appears to use System A and this is what the ATSC A/52 (2012) standard says, > > "For System A, this section extends the use ofthe AC-3 Registration Descriptor defined in Section A3 in combination with the E-AC-3 stream_type value defined below." > > and > > "E-AC-3 bit streams shall be identified with a stream_typevalue of 0x87 when transmitted as PES streams conforming to ATSC-published standards." > > Note that the stream_type value of AC-3 is 0x81 yet our id sequence starts from 0x80. This patch uses the same descriptor series as AC-3, however if I switch to 0x87, only one such stream may be muxed as 0x88 was assigned (by you) to DTS. Also, our demuxer sets the codec_id to DTS for 0x88 to 0x8f. > > Both stock ffmpeg and VlC 4.0 nightly play files using the current patch. Mediainfo also identifies the codec correctly. > > Comments? Did you test with WMP or QT? Carl Eugen
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c index 43ebc46e0e..15b191bc9d 100644 --- a/libavformat/mpegenc.c +++ b/libavformat/mpegenc.c @@ -352,6 +352,7 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx) case AVMEDIA_TYPE_AUDIO: if (!s->is_mpeg2 && (st->codecpar->codec_id == AV_CODEC_ID_AC3 || + st->codecpar->codec_id == AV_CODEC_ID_EAC3 || st->codecpar->codec_id == AV_CODEC_ID_DTS || st->codecpar->codec_id == AV_CODEC_ID_PCM_S16BE || st->codecpar->codec_id == AV_CODEC_ID_PCM_DVD)) @@ -360,7 +361,8 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx) "consider using the vob or the dvd muxer " "to force a MPEG-2 program stream.\n", avcodec_get_name(st->codecpar->codec_id)); - if (st->codecpar->codec_id == AV_CODEC_ID_AC3) { + if (st->codecpar->codec_id == AV_CODEC_ID_AC3 || + st->codecpar->codec_id == AV_CODEC_ID_EAC3) { stream->id = ac3_id++; } else if (st->codecpar->codec_id == AV_CODEC_ID_DTS) { stream->id = dts_id++; @@ -415,7 +417,7 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx) } else if (st->codecpar->codec_id != AV_CODEC_ID_MP1 && st->codecpar->codec_id != AV_CODEC_ID_MP2 && st->codecpar->codec_id != AV_CODEC_ID_MP3) { - av_log(ctx, AV_LOG_ERROR, "Unsupported audio codec. Must be one of mp1, mp2, mp3, 16-bit pcm_dvd, pcm_s16be, ac3 or dts.\n"); + av_log(ctx, AV_LOG_ERROR, "Unsupported audio codec. Must be one of mp1, mp2, mp3, 16-bit pcm_dvd, pcm_s16be, ac3, eac3 or dts.\n"); goto fail; } else { stream->id = mpa_id++;