Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 31 Jul, 2018 1 commit
  3. 07 Jul, 2018 1 commit
  5. 30 Jun, 2018 1 commit
  7. 28 Jun, 2018 1 commit
  9. 15 Jun, 2018 1 commit
  11. 13 Jun, 2018 2 commits
    • erankor's avatar
      qt-faststart - stco offset bug fix · dc16c9dd
      erankor authored 
      when the last offsets in the stco atom are close to 4GB, the addition of
the moov atom size can overflow, causing corruption near the end of the
mp4 file.
this patch upgrades all stco atoms to co64 when such an edge case is
detected. in order to accomplish this, the implementation was changed to
walk the atom tree, instead of searching for the strings 'stco'/'co64'.
this was required since when an stco atom is changed to co64, its size
changes, and the sizes of all containing atoms (moov, trak, etc.) have
to be updated as well.
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      dc16c9dd
    • erankor's avatar
      qt-faststart: add validation on ftyp atom size · ee09ffbf
      erankor authored 
      avoid trying to allocate an unreasonably sized buffer on corrupt files
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      ee09ffbf
  13. 30 May, 2018 4 commits
  15. 28 May, 2018 1 commit
    • Michael Niedermayer's avatar
      avcodec/allcodecs: Provide empty codec_list in allcodecs when ossfuzz is used · 42f40d36
      Michael Niedermayer authored 
      The last workaround is not sufficient to make oss fuzz work with the iterate API
as it did not provide a FFmpeg that external libs can be linked to.

This patch does not fully restore the pre iterate functionality. My attempts to
do this have so far failed.

The problem with this solution is that it renders the fuzzers virtual system
ffmpeg (libs) non functional. Which differs from a real system compared to the
virtual system tested by the fuzzer.
It should theoretically not matter as the system ffmpeg wouldnt be used.
But with more cases being fuzzed we likely will hit a case where a external
lib is involved and it does matter ...

Working around this may be possible with weak symbols but so far my attempts
failed

Alternatively multiple ffmpeg could be built, this becomes messy though
quickly as they need to be all linked together. That is we need a FFmpeg
that has the iterate API modified so it can work with the resources
available to ossfuzz. And at the same time we need a ffmpeg that has
its full functionality for any external libs which use ffmpeg and are
used by ffmpeg.
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      42f40d36
  17. 15 May, 2018 1 commit
  19. 02 Apr, 2018 1 commit
  21. 28 Jan, 2018 1 commit
  23. 06 Jan, 2018 4 commits
  25. 05 Jan, 2018 1 commit
  27. 13 Dec, 2017 1 commit
  29. 22 Nov, 2017 2 commits
  31. 25 Oct, 2017 2 commits
  33. 01 Oct, 2017 1 commit
  35. 04 Sep, 2017 1 commit
  37. 31 Aug, 2017 1 commit
    • Martin Storsjö's avatar
      Remove support for building for mingw32ce (Windows CE) · e41daa62
      Martin Storsjö authored 
      The toolchain for this target is unmaintained since many years.

While it has been continuously build tested on fate, it hasn't
actually been tested at runtime since many, many years (and back
then, only a few codecs in libavcodec were tested).

So far, keeping support for it has been mostly effortless, but
the compiler does seem to have issues with dllimported data symbols,
ending up as internal compiler errors in some cases. Instead of
jumping through further hoops to work around that, just remove the
target.
Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      e41daa62
  39. 21 Jun, 2017 1 commit
  41. 12 Jun, 2017 2 commits
  43. 29 May, 2017 1 commit
  45. 06 May, 2017 2 commits
  47. 04 May, 2017 1 commit
  49. 03 May, 2017 1 commit
  51. 01 May, 2017 1 commit
  53. 30 Apr, 2017 1 commit
  55. 27 Apr, 2017 1 commit
  57. 25 Apr, 2017 1 commit