Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 16 Jun, 2019 1 commit
  3. 15 May, 2019 1 commit
  5. 20 Apr, 2019 1 commit
  7. 19 Apr, 2019 1 commit
  9. 28 Jan, 2019 1 commit
  11. 17 Jan, 2019 1 commit
  13. 22 Dec, 2018 1 commit
  15. 06 Nov, 2018 1 commit
  17. 01 Nov, 2018 1 commit
  19. 27 Oct, 2018 1 commit
  21. 24 Oct, 2018 1 commit
  23. 12 Oct, 2018 1 commit
  25. 09 Sep, 2018 1 commit
  27. 17 Aug, 2018 2 commits
  29. 21 May, 2018 1 commit
  31. 19 May, 2018 1 commit
    • Aman Gupta's avatar
      avformat: add fields to AVProgram/AVStream for PMT change tracking · 2b2f2f65
      Aman Gupta authored 
      These fields will allow the mpegts demuxer to expose details about
the PMT/program which created the AVProgram and its AVStreams.

In mpegts, a PMT which advertises streams has a version number
which can be incremented at any time. When the version changes,
the pids which correspond to each of it's streams can also change.

Since ffmpeg creates a new AVStream per pid by default, an API user
needs the ability to (a) detect when the PMT changed, and (b) tell
which AVStream were added to replace earlier streams.

This has been a long-standing issue with ffmpeg's handling of mpegts
streams with PMT changes, and I found two related patches in the wild
that attempt to solve the same problem:

The first is in MythTV's ffmpeg fork, where they added a
void (*streams_changed)(void*); to AVFormatContext and call it from
their fork of the mpegts demuxer whenever the PMT changes.

The second was proposed by XBMC in
https://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135036.html,
where they created a new AVMEDIA_TYPE_DATA stream with id=0 and
attempted to send packets to it whenever the PMT changed.
Signed-off-by: 's avatarAman Gupta <aman@tmm1.net>
      2b2f2f65
  33. 17 May, 2018 1 commit
  35. 09 May, 2018 1 commit
  37. 30 Apr, 2018 1 commit
  39. 26 Apr, 2018 2 commits
  41. 16 Apr, 2018 3 commits
  43. 03 Apr, 2018 1 commit
    • wm4's avatar
      avutil/pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL · d6fc031c
      wm4 authored 
      PSEUDOPAL pixel formats are not paletted, but carried a palette with the
intention of allowing code to treat unpaletted formats as paletted. The
palette simply mapped the byte values to the resulting RGB values,
making it some sort of LUT for RGB conversion.

It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
formats. The last one, GRAY8, is more common, but its treatment is
grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
from typical Y video planes was not mapped to the correct RGB values.
This cannot be fixed, because AVFrame.color_range can be freely changed
at runtime, and there is nothing to ensure the pseudo palette is
updated.

Also, nothing actually used the PSEUDOPAL palette data, except xwdenc
(trivially changed in the previous commit). All other code had to treat
it as a special case, just to ignore or to propagate palette data.

In conclusion, this was just a very strange old mechnaism that has no
real justification to exist anymore (although it may have been nice and
useful in the past). Now it's an artifact that makes the API harder to
use: API users who allocate their own pixel data have to be aware that
they need to allocate the palette, or FFmpeg will crash on them in
_some_ situations. On top of this, there was no API to allocate the
pseuo palette outside of av_frame_get_buffer().

This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
the pseudo palette optional. Nothing accesses it anymore, though if it's
set, it's propagated. It's still allocated and initialized for
compatibility with API users that rely on this feature. But new API
users do not need to allocate it. This was an explicit goal of this
patch.

Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.

Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
functions manually changed to not allocating a palette.
      d6fc031c
  45. 02 Apr, 2018 2 commits
  47. 31 Mar, 2018 2 commits
  49. 27 Mar, 2018 1 commit
  51. 25 Mar, 2018 1 commit
    • wm4's avatar
      avcodec: add a subcharenc mode that disables UTF-8 check · b7d0d912
      wm4 authored 
      This is for applications which want to explicitly check for invalid
UTF-8 manually, and take actions that are better than dropping invalid
subtitles silently. (It's pretty much silent because sporadic avcodec
error messages are so common that you can't reasonably display them in a
prominent and meaningful way in a application GUI.)
      b7d0d912
  53. 24 Mar, 2018 1 commit
  55. 22 Mar, 2018 1 commit
  57. 18 Mar, 2018 1 commit
    • wm4's avatar
      lavu/frame: add QP side data · 4b86ac27
      wm4 authored 
      This adds a way for an API user to transfer QP data and metadata without
having to keep the reference to AVFrame, and without having to
explicitly care about QP APIs. It might also provide a way to finally
remove the deprecated QP related fields. In the end, the QP table should
be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.

There are two side data types, because I didn't care about having to
repack the QP data so the table and the metadata are in a single
AVBufferRef. Otherwise it would have either required a copy on decoding
(extra slowdown for something as obscure as the QP data), or would have
required making intrusive changes to the codecs which support export of
this data.

The new side data types are added under deprecation guards, because I
don't intend to change the status of the QP export as being deprecated
(as it was before this patch too).
      4b86ac27
  59. 16 Mar, 2018 1 commit
  61. 10 Mar, 2018 1 commit
  63. 08 Mar, 2018 1 commit
    • Aman Gupta's avatar
      avcodec/mediacodecdec: add delay_flush option · 2a0eb868
      Aman Gupta authored 
      The default behavior of the mediacodec decoder before this commit
was to delay flushes until all pending hardware frames were
returned to the decoder. This was useful for certain types of
applications, but was unexpected behavior for others.

The new default behavior with this commit is now to execute
flushes immediately to invalidate all pending frames. The old
behavior can be enabled by setting delay_flush=1.

With the new behavior, video players implementing seek can simply
call flush on the decoder without having to worry about whether
they have one or more mediacodec frames still buffered in their
rendering pipeline. Previously, all these frames had to be
explictly freed (or rendered) before the seek/flush would execute.

The new behavior matches the behavior of all other lavc decoders,
reducing the amount of special casing required when using the
mediacodec decoder.
Signed-off-by: 's avatarAman Gupta <aman@tmm1.net>
Signed-off-by: 's avatarMatthieu Bouron <matthieu.bouron@gmail.com>
      2a0eb868
  65. 01 Mar, 2018 1 commit
  67. 15 Feb, 2018 1 commit