| Message ID | 20220603124620.15099-1-jeebjp@gmail.com |
|---|---|
| Headers | show |
| Series | avformat/movenc: normalize on AC-3 parser usage | expand |
On Fri, Jun 3, 2022 at 3:46 PM Jan Ekström <jeebjp@gmail.com> wrote: > > The simplified parsing currently in `mov_write_ac3_tag` trusts the content > of the packets a bit too much (the AC-3 parser returns all data fed to it, > including any possible data before the start code), while the existing E-AC-3 > logic does proper header validation by utilizing the (E-)AC-3 parser. > > Thus, normalize on AC-3 parser usage for both AC-3 and E-AC-3. Ping on this patch set, as this seems to improve the state of affairs with the input being MPEG-TS muxes where PES packets do not start with a start code (the previous ad-hoc parsing was way too trusting and would write bogus values based on the last N bytes of a previous packet into the AC-3 sample description). When applying, `avcodec/ac3_parser{,_internal}: expose AC-3 bit_rate_code` will have a minor bump as technically a private-yet-utilized-from-lavf structure has something appended to it. Jan
On Tue, Jun 7, 2022 at 9:58 AM Jan Ekström <jeebjp@gmail.com> wrote: > > On Fri, Jun 3, 2022 at 3:46 PM Jan Ekström <jeebjp@gmail.com> wrote: > > > > The simplified parsing currently in `mov_write_ac3_tag` trusts the content > > of the packets a bit too much (the AC-3 parser returns all data fed to it, > > including any possible data before the start code), while the existing E-AC-3 > > logic does proper header validation by utilizing the (E-)AC-3 parser. > > > > Thus, normalize on AC-3 parser usage for both AC-3 and E-AC-3. > > Ping on this patch set, as this seems to improve the state of affairs > with the input being MPEG-TS muxes where PES packets do not start with > a start code (the previous ad-hoc parsing was way too trusting and > would write bogus values based on the last N bytes of a previous > packet into the AC-3 sample description). > > When applying, `avcodec/ac3_parser{,_internal}: expose AC-3 > bit_rate_code` will have a minor bump as technically a > private-yet-utilized-from-lavf structure has something appended to it. If there are no further comments, I will pull this in tomorrow, as this has been generating valid sample descriptions for a piece of software which is picky that the data is correct. Jan
The simplified parsing currently in `mov_write_ac3_tag` trusts the content of the packets a bit too much (the AC-3 parser returns all data fed to it, including any possible data before the start code), while the existing E-AC-3 logic does proper header validation by utilizing the (E-)AC-3 parser. Thus, normalize on AC-3 parser usage for both AC-3 and E-AC-3. Jan Ekström (6): avcodec/ac3_parser{,_internal}: expose AC-3 bit_rate_code {configure,avformat/movenc}: enable AC-3 parser for movenc avformat/movenc: enable handle_eac3 to handle AC-3 tracks avformat/movenc: move eac3_info definition so that it can be used for AC-3 avformat/movenc: utilize existing AC-3 parsing workflow for AC-3 avformat/movenc: handle OOM situations when parsing AC-3 headers configure | 2 +- libavcodec/ac3_parser.c | 3 + libavcodec/ac3_parser_internal.h | 1 + libavformat/movenc.c | 123 ++++++++++++++++--------------- 4 files changed, 69 insertions(+), 60 deletions(-)