Skip to content

F
Ffmpeg

小白菜888 / Ffmpeg

通知 3
Star 0
Fork 0
F
Ffmpeg

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 05 7月, 2020 12 次提交
    • M
      project: Update for recent upstream merge. · d4f0aa18
      由 Matt Oliver 提交于
      d4f0aa18
    • M
      Merge remote-tracking branch 'upstream/master' · ba89adc9
      由 Matt Oliver 提交于
      ba89adc9
    • A
      avcodec/h264_metadata_bsf: Fix invalid av_freep · 04e06beb
      由 Andreas Rheinhardt 提交于 
      This bug was introduced in 3c8a2a11.
Reviewed-by: NJames Almer <jamrial@gmail.com>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      04e06beb
    • A
      avformat/smacker: Cosmetics · d534009f
      由 Andreas Rheinhardt 提交于 
      Mainly reindentation.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      d534009f
    • A
      avformat/smacker: Use st->priv_data to store array · e40ad1c0
      由 Andreas Rheinhardt 提交于 
      It simplifies freeing and allows to completely remove smacker_read_close.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      e40ad1c0
    • A
      avformat/smacker: Don't read only one byte at a time · 638ef5f7
      由 Andreas Rheinhardt 提交于 
      Instead use ffio_read_size to read data into a buffer. Also check that
the desired size was actually successfully read and combine the check
with the check for reading the extradata.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      638ef5f7
    • A
      avformat/smacker: Don't allocate arrays separately · 09a39042
      由 Andreas Rheinhardt 提交于 
      Allocating two arrays with the same number of elements together
simplifies freeing them.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      09a39042
    • A
      avformat/smacker: Improve timestamps · 6e5dbd62
      由 Andreas Rheinhardt 提交于 
      A Smacker file can contain up to seven audio tracks. Up until now,
the pts for the i. audio packet contained in a Smacker frame was
simply the end timestamp of the last i. audio packet contained in
an earlier Smacker frame.

The problem with this is that a Smacker stream need not contain data in
every Smacker frame and so the current i. audio packet present may come
from a different underlying stream than the last i. audio packet
contained in an earlier frame.

The sample hypnotix.smk* exhibits this. It has three audio tracks and
the first of the three has a longer first packet, so that the audio for
the first track is contained in only 235 packets contained in the first
235 Smacker frames; the end timestamp of this track is 166696 (about 7.56s
at a timebase of 1/22050); the other two audio tracks both have 253 packets
contained in the first 253 Smacker frames. Up until now, the 236th
packet of the second track being the first audio packet in the 236th
Smacker frame would get the end timestamp of the last first audio packet
from the last Smacker frame containing a first audio packet and said
last audio packet is the first audio packet from the 235th Smacker frame
from the first audio track, so that the timestamp is 166696. In contrast,
the 236th packet from the third track (whose packets contain the same number
of samples as the packets from the second track) has a timestamp of
156116 (because its timestamp is derived from the end timestamp of the
235th packet of the second audio track). In the end, the second track
ended up being 177360/22050 s = 8.044s long; in contrast, the third
track was 166780/22050 s = 7.56s long which also coincided with the
video.

This commit fixes this by not using timestamps from other tracks for
a packet's pts.

*: https://samples.ffmpeg.org/game-formats/smacker/wetlands/hypnotix.smkReviewed-by: NTimotej Lazar <timotej.lazar@araneo.si>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      6e5dbd62
    • A
      avformat/smacker: Stop caching and copying audio frames · 316dc067
      由 Andreas Rheinhardt 提交于 
      The layout of a Smacker frame is as follows: For some frames, the
beginning of the frame contained a palette for the video stream; then
there are potentially several audio frames, followed by the data for the
video stream.

The Smacker demuxer used to read the palette, then cache every audio frame
into a buffer (that gets reallocated to the desired size every time a
frame is read into this buffer), then read and return the video frame
(together with the palette). The cached audio frames are then returned
by copying the data into freshly allocated buffers; if there are none
left, the next frame is read.

This commit changes this: At the beginning of a frame, the palette is
read and cached as now. But audio frames are no longer cached at all;
they are returned immediately. This gets rid of copying and also allows
to remove the code for the buffer-to-AVStream correspondence.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      316dc067
    • A
      avformat/smacker: Check audio frame size · 2f687bc8
      由 Andreas Rheinhardt 提交于 
      The first four bytes of smacker audio are supposed to contain the number
of samples, so treat audio frames smaller than that as invalid.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      2f687bc8
    • A
      avformat/smacker: Avoid potential inifinite loop on error · 02bbb370
      由 Andreas Rheinhardt 提交于 
      When reading a new frame, the Smacker demuxer seeks to the next frame
position where it excepts the next frame; then it (potentially) reads
the palette, the audio packets associated with the frame and finally the
actual video frame. It is only at the end that the frame counter as well
as the position where the next frame is expected get updated.

This has a downside: If e.g. invalid data is encountered when reading
the palette, the demuxer returns immediately (with an error) and if the
caller calls av_read_frame again, the demuxer seeks to the position where
it already was, reads the very same palette data again and therefore will
return an error again. If the caller calls av_read_frame repeatedly
(say, until a packet is received or until EOF), this meight become an
infinite loop.

This could also happen if e.g. the size of one of the audio frames was
invalid or if the frame size was gigantic.

This commit changes this by skipping a frame if it turns out to be
invalid or an error happens otherwise. This ensures that EOF will be
returned eventually in the above scenario.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      02bbb370
    • A
      avformat/smacker: Don't increase packet counter prematurely · 5fcc49e0
      由 Andreas Rheinhardt 提交于 
      The Smacker demuxer buffers audio packets before it outputs them, but it
increments the counter of buffered packets prematurely: If allocating
the audio buffer fails, an error (most likely AVERROR(ENOMEM)) is returned.
If the caller decides to call av_read_frame() again, the next call will
take the codepath for returning already buffered audio packets and it
will fail (because the buffer that ought to be allocated isn't) without
decrementing the number of supposedly buffered audio packets (it doesn't
matter whether there would be enough memory available in subsequent calls).
Depending on the caller's behaviour this is potentially an infinite loop.

This commit fixes this by only incrementing the number of buffered audio
packets after having successfully read them and unconditionally reducing
said number when outputting one of them. It also changes the semantics
of the curstream variable: It is now the number of currently buffered
audio packets whereas it used to be the index of the last audio stream
to be read. (Index refers to the index in the array of buffers, not to
the stream index.)
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5fcc49e0
  3. 04 7月, 2020 5 次提交
  5. 03 7月, 2020 4 次提交
  7. 02 7月, 2020 19 次提交