Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 28 Jun, 2019 3 commits
  3. 27 Jun, 2019 2 commits
  5. 26 Jun, 2019 13 commits
  7. 25 Jun, 2019 20 commits
  9. 24 Jun, 2019 2 commits
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Don't zero unnecessarily · 1215b3a5
      Andreas Rheinhardt authored 
      It is only necessary to zero the initial allocated memory used to store
the size of laced frames if the block used Xiph lacing. Otherwise no
unintialized data was ever used, so use av_malloc instead of av_mallocz.

Also use the correct type for the allocations.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      1215b3a5
    • Alexander Strasser's avatar
      configure: print_in_columns: Replace pr with awk · 99147312
      Alexander Strasser authored 
      Get rid of pr dependency and write the columns strictly
alphabetical without page size considerations (POSIX
specifies 66 lines as default).

Setting the page size via pr's -l option was considered,
but as there is issue #5680 which wants to avoid pr
mainly because it's not in busybox, we chose to replace
pr instead.

Before pr would attempt to write pages, thus if a page
boundary was reached, the output looked confusing as one
couldn't see there was a new page and the alphabetical
order was disrupted when scanning down one of the columns.

This change is based on a shell implementation submitted
before by Yejun.

Possible differences to the current version using pr:
1. pr implementations should truncate items to not overflow columns;
   depending on how it's done not truncating shall be better IMHO.
2. pr implementations might balance columns differently;
   we use minimum number of lines and might end up not
   using all columns or might have lesser entries in the
   last column(s)
3. we use spaces only for padding the columns; at least the GNU pr
   version on my system also by default stuffs in tabs in addition
   to a single space in between columns. I don't see that this
   behaviour is demanded by POSIX, though I might be very well
   overlooking things. Anyway for our use case I can't see a need
   for having the additional tabs, or why it would be better compared
   to padding with spaces only.

Fixes output for sizes with width < column width, too.

Fixes remaining part of ticket #5680

Contributor: Guo, Yejun <yejun.guo@intel.com>
      99147312