FFmpeg

110105 Commits

37 Branches

400 Tags

492 MiB

Tag: Branch: Tree: 3f4c41839d

Commit Graph

Author	SHA1	Message	Date
rcombs	d3538dd293	lavf/spdifdec: support EAC3 Parsing should probably be enabled for all codecs, at least for headers, but e.g. the AAC parser produces 1-byte packets of zero padding with it, so I'm just enabling it for EAC3 for the moment.	2 years ago
Andreas Rheinhardt	9ad3db3ad9	fate/spdif: Add spdif tests These tests test both the demuxer as well as the muxer wherever possible. It is not always possible due to the fact that the muxer supports more codecs than the demuxer. The spdif demuxer does currently not set the need_parsing flag. If one were to set this to AVSTREAM_PARSE_FULL, the test results would change as follows: - For spdif-aac-remux, the packets are currently padded to 16bits, i.e. if the actual packet size is odd, there is a padding byte. The parser splits this byte away into a one byte packet of its own. Insanely, these one byte packets get the same duration as normal packets, i.e. timing is ruined. - The DCA-remux tests get proper duration/timestamps. - In the spdif-mp2-remux test the demuxer marks the stream as being MP2; the parser sets it to MP3 and this triggers the "Codec change in IEC 61937" codepath; this test therefore returns only two packets with the parser. - For spdif-mp3-remux some bytes end up in different packets: Some input packets of this file have an odd length (417B instead of 418B like all the other packets) and are padded to 418B. Without a parser, all returned packets from the spdif-demuxer are 418B. With a parser, the packets that were originally 417B are 417B again, but the padding byte has not been discarded, but added to the next packet which is now 419B. This fixes "Multiple frames in a packet" warning and avoids an "Invalid data found when processing input" error when decoding. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago

Author

SHA1

Message

Date

rcombs

d3538dd293

lavf/spdifdec: support EAC3

Parsing should probably be enabled for all codecs, at least for headers,
but e.g. the AAC parser produces 1-byte packets of zero padding with it,
so I'm just enabling it for EAC3 for the moment.

2 years ago

Andreas Rheinhardt

9ad3db3ad9

fate/spdif: Add spdif tests

These tests test both the demuxer as well as the muxer
wherever possible. It is not always possible due to the fact
that the muxer supports more codecs than the demuxer.

The spdif demuxer does currently not set the need_parsing flag.
If one were to set this to AVSTREAM_PARSE_FULL, the test results
would change as follows:
- For spdif-aac-remux, the packets are currently padded to 16bits,
i.e. if the actual packet size is odd, there is a padding byte.
The parser splits this byte away into a one byte packet of its own.
Insanely, these one byte packets get the same duration as normal
packets, i.e. timing is ruined.
- The DCA-remux tests get proper duration/timestamps.
- In the spdif-mp2-remux test the demuxer marks the stream as
being MP2; the parser sets it to MP3 and this triggers
the "Codec change in IEC 61937" codepath; this test therefore
returns only two packets with the parser.
- For spdif-mp3-remux some bytes end up in different packets:
Some input packets of this file have an odd length (417B instead
of 418B like all the other packets) and are padded to 418B.
Without a parser, all returned packets from the spdif-demuxer
are 418B. With a parser, the packets that were originally 417B
are 417B again, but the padding byte has not been discarded,
but added to the next packet which is now 419B.
This fixes "Multiple frames in a packet" warning and avoids
an "Invalid data found when processing input" error when decoding.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

3 years ago

2 Commits (3f4c41839d5d3d02a12cc6a7407e6586996040e7)