The supplementary audio descriptor is defined in ETSI EN 300 468 and
provides more details regarding accessibility audio tracks, especially
the normative annex J contains a detailed description of its use.
Its language code (if present) overrides the language code of an also
present ISO 639
Am 20.02.2018 um 00:13 schrieb Marton Balint:
>>> + if (ext_desc_tag == 0x06) { /* supplementary audio descriptor */
>>> + char flags;
>
> Change this to int, I see no reason why this is a char.
OK, I will fix that with v3.
>> LGTM. Will commit in a couple days along with my
The supplementary audio descriptor is defined in ETSI EN 300 468 and
provides more details regarding accessibility audio tracks, especially
the normative annex J contains a detailed description of its use.
Its language code (if present) overrides the language code of an also
present ISO 639
Am 16.02.2018 um 20:01 schrieb Aman Gupta:
>> +if(flags & 0x01) {
>
> Please add a space after "if" here.
>
>> +if(language[0])
>
> Same, missing space.
OK, I will add the spaces. And also add the respective field names as
comments, as you did for the mix_type.
Am 16.02.2018 um 05:10 schrieb Aman Gupta:
> One option would be to re-use an existing flag.
>
> AV_DISPOSITION_CLEAN_EFFECTS seems to have a similar meaning, but is
> already used for a different purpose in mpegts.c
Right, so this would not be a distinct indicator.
> Another option is
Am 15.02.2018 um 20:52 schrieb Aman Gupta:
> Patch looks reasonable to me.
Great!
> It might also be worth surfacing when the audio descriptor flags contain
> mix_type=0, as this indicates a dependent stream which cannot be played
> standalone.
Yes, this seems to be useful, as both mixing types
The supplementary audio descriptor is defined in ETSI EN 300 468 and
provides more details regarding accessibility audio tracks, especially
the normative annex J contains a detailed description of its use.
Its language code (if present) overrides the language code of an also
present ISO 639
Fixes #6918.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index d5bbb5b..20ca792 100755
--- a/configure
+++ b/configure
@@ -5853,7 +5853,7 @@ enabled libkvazaar&& require_pkg_config
libkvazaar "kvazaar >= 0.8.1" kv
enabled
ag to embed an
> AC-3/E-AC-3 ES the DVB way
>
> On Sun, Dec 13, 2015 at 11:54:32AM +0100, Stefan Pöschel wrote:
> > So far an AC-3 elementary stream is refered to in the PMT according to
> > System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB)
> > way
Just wanted to ask if there is any further information needed regarding my
patch.
> Gesendet: Sonntag, 13. Dezember 2015 um 11:54 Uhr
> Von: "Stefan Pöschel" <basic.mas...@gmx.de>
> An: ffmpeg-devel@ffmpeg.org
> Betreff: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: ad
*bump*
Am 13.12.2015 um 15:23 schrieb Stefan Pöschel:
> Am 13.12.2015 um 14:18 schrieb Moritz Barsnick:
>> On Sun, Dec 13, 2015 at 11:54:32 +0100, Stefan Pöschel wrote:
>>> So far an AC-3 elementary stream is refered to in the PMT according to
>>> System A (ATSC
So far an AC-3 elementary stream is refered to in the PMT according to
System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
To fix this inconsistency, this commit changes the default E-AC-3 behaviour to
use the ATSC way, too. Furthermore a new flag is added to optionally
Am 13.12.2015 um 14:18 schrieb Moritz Barsnick:
> On Sun, Dec 13, 2015 at 11:54:32 +0100, Stefan Pöschel wrote:
>> So far an AC-3 elementary stream is refered to in the PMT according to
>> System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
>
>
[sorry, used wrong sender previously]
Hi,
within the MPEG-TS muxer, the signalling of AC-3 is done according to
System A (ATSC) while in contrast E-AC-3 is signalled according to
System B (DVB).
To fix this inconsistency, E-AC-3 should IMO be signalled according to
System A, too. Furthermore a
14 matches
Mail list logo
