Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 25 Jun, 2019 9 commits
  3. 24 Jun, 2019 3 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
    • Bela Bodecs's avatar
      avformat/hlsenc: better error log message for var_stream_map content · 2045dd00
      Bela Bodecs authored 
      When multiple variant streams are specified by var_stream_map option,
%v is expected either in the filename or in the last sub-directory name,
but only in one of them. When both of them contains %v string, current
error message only states half of the truth.
And even %v may appears several times inside the last sub-directory name
or in filename pattern.
This patch clarifies this in the log message and in the doc also.
Signed-off-by: 's avatarBela Bodecs <bodecsb@vivanet.hu>
      2045dd00
  5. 23 Jun, 2019 11 commits
  7. 22 Jun, 2019 1 commit
  9. 21 Jun, 2019 12 commits
  11. 20 Jun, 2019 3 commits
  13. 19 Jun, 2019 1 commit
    • Bodecs Bela's avatar
      av_format/hlsenc: fix %v handling by format_name function · 09a48539
      Bodecs Bela authored 
      Hi All,

When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the
input pattern buffer, so you must allocate it before calling format_name
function. It also means, that it is silently assumed that the result
string will NOT be
longer that the pattern string. It is true most of the time, because %v
may appear only once in the pattern string and number of variant streams
is less than 100 in practical cases. But theoretically it will fail if
specified number of variant streams is greater than 100 (i.e. longer
than 2 digits).
This patch fixes this behaviour by altering format_name function to
allocate the
result buffer and return it to the caller.

Please, review this patch.

best,

Bela
>From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001
From: Bela Bodecs <bodecsb@vivanet.hu>
Date: Mon, 17 Jun 2019 14:31:36 +0200
Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function

When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the input pattern
buffer, so you must allocate it before calling format_name function. It
also means, that it is silently assumed that the result string will NOT
be longer that the pattern string. It is true most of the time, because
%v may appear only once in the pattern string and number of variant
streams is less than 100 in practical cases. But theoretically it will
fail if specified number of variant streams is greater than 100. This
patch fixes this behaviour by altering format_name function to allocate
the result buffer and return it to the caller.
Signed-off-by: 's avatarBela Bodecs <bodecsb@vivanet.hu>
      09a48539