On 25.05.2015 18:31, Michael Niedermayer wrote:
> On Mon, May 25, 2015 at 05:25:18PM +0200, Andreas Cadhalpun wrote:
>> On 24.05.2015 19:23, Michael Niedermayer wrote:
>>> ISO/IEC 14496-12:2012(E) says the field is unsigned so it cannot be
>>> negative
>>>
>>> 8.7.4.2 Syntax
>>> aligned(8) class SampleToChunkBox
>>> extends FullBox("stsc", version = 0, 0) {
>>> unsigned int(32) entry_count;
>>> for (i=1; i <= entry_count; i++) {
>>> unsigned int(32) first_chunk;
>>> unsigned int(32) samples_per_chunk;
>>> unsigned int(32) sample_description_index;
>>> }
>>> }
>>
>> OK, but then the types of the members of MOVStsc and likely also MOVStts
>> are incorrectly int. The first attached patch changes that.
>
> MOVStts needs to stay signed, its used for ctts and that is signed
> per spec
> aligned(8) class CompositionOffsetBox
> extends FullBox("ctts", version = 0, 0) {
> unsigned int(32) entry_count;
> int i;
> if (version==0) {
> for (i=0; i < entry_count; i++) {
> unsigned int(32) sample_count;
> unsigned int(32) sample_offset;
> }
> }
> else if (version == 1) {
> for (i=0; i < entry_count; i++) {
> unsigned int(32) sample_count;
> signed int(32) sample_offset;
> }
> }
> }
>
> also above is just the ISO side, theres also a quicktime spec
> that is seperate and while similar enough so our demuxer supports both
> they are seperate file formats
> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/qtff.pdf
That one says about ctts/stts:
ctts:
* sampleCount
A 32-bit unsigned integer that provides the number of consecutive
samples with the calculated composition offset in the field.
* compositionOffset
A 32-bit signed integer indicating the value of the calculated
compositionOffset.
stts:
* Sample count
A 32-bit integer that specifies the number of consecutive samples
that have the same duration.
* Sample duration
A 32-bit integer that specifies the duration of each sample.
So it can be signed or unsigned.
For stsc it doesn't even mention the sign:
* First chunk
The first chunk number using this table entry.
* Samples per chunk
The number of samples in each chunk.
* Sample description ID
The identification number associated with the sample description
for the sample. For details on sample description atoms, see Sample
Description Atoms (page 99).
So if you don't like the first patch changing the types, consider it dropped.
It shouldn't change the behavior anyway.
I'm more interested in the second patch validating the
bytes_per_frame/samples_per_frame combination.
The quicktime spec says about these:
* Samples per packet (sc->samples_per_frame)
The number of uncompressed frames generated by a compressed frame
(an uncompressed frame is one sample from each channel). This is
also the frame duration, expressed in the media's timescale, where
the timescale is equal to the sample rate. For uncompressed formats,
this field is always 1.
* Bytes per packet (ignored)
For uncompressed audio, the number of bytes in a sample for a single
channel. This replaces the older sampleSize field, which is set to 16.
This value is calculated by dividing the frame size by the number of
channels. The same calculation is performed to calculate the value of
this field for compressed audio, but the result of the calculation is
not generally meaningful for compressed audio.
* Bytes per frame (sc->bytes_per_frame)
The number of bytes in a frame: for uncompressed audio, an
uncompressed frame; for compressed audio, a compressed frame. This
can be calculated by multiplying the bytes per packet field by the
number of channels.
* Bytes per sample (ignored)
The size of an uncompressed sample in bytes. This is set to 1 for
8-bit audio, 2 for all other cases, even if the sample size is
greater than 2 bytes.
[...]
If these fields are not used, they are set to 0. File readers only need
to check to see if samplesPerPacket is 0.
This suggests that if the field is 0, it should not be used.
That's the check my last patch implemented, so I think it should be fine.
Best regards,
Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
