While a 25 fps stream can in general store frame durations in 1/25
units, this is not true for the timestamps. For example a 25fps
and a 25000/1001 fps stream when they are stored together might have
a matching 0 timestamp point but when for example a chapter from
this is cut the new start is no longer aligned. The issue gets
MUCH worse when the streams are lower fps, like 1 or 2 fps.
This commit thus makes the muxer choose a multiple of the
framerate as timebase that is at least about 20 micro seconds precise
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With this, when we use a finer timebase than neccessary to store
durations the demuxer still knows what the original timebase was.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is not correct in all cases and it is less predictable than a skip of 0
for user applications.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Use the MAX_URL_SIZE define where applicable. Increase buffer
sizes for all buffers that need to fit a long pathname - buffers
that need to fit only the hostname (and other short strings, but
not the pathname - such as "headers" in http_connect) are kept
at 1024 bytes for now.
Also increase the max line length in http_read_header, since it
might need to contain a full url for Location: redirects.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes some DNXHD files generated by AVID TM, where codec UL was set to A-law
meanwhile the real audio codec was PCM S16. According to SMPTE RP 224, A-law is
the default value for sound essence parameters therefore we should handle it
specially.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Anonymous typedef structs prevent forward declaration, this
change gives the AVIOContext and AVIOInterruptCB structures
a name. These structures are now in line with other common
structures such as AVFormatContext and AVCodecContext.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
At the moment, the moov header is written at the end of the file, so we
can use the current offset (which focus on the end of the mdat already
written) to guess if 64-bits offset will be required or not.
Though, the next commits will make possible the writing of this table at
the beginning, so this heuristic can't work. As a consequence, we check
all the values within the potential offset table for any value >
32-bits.
Previously we had ignored the past dts and just filled in from the
point where we have had sufficient information.
This should fix Ticket1734
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This packetization scheme simply places the full packets into the
RTP packet without any extra header bytes.
Signed-off-by: Martin Storsjö <martin@martin.st>