Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 03 Aug, 2019 1 commit
  3. 02 Aug, 2019 4 commits
  5. 01 Aug, 2019 2 commits
  7. 31 Jul, 2019 8 commits
  9. 30 Jul, 2019 4 commits
  11. 29 Jul, 2019 15 commits
  13. 28 Jul, 2019 5 commits
    • Mark Thompson's avatar
      lavfi: addroi filter · 20fed2f0
      Mark Thompson authored 
      This can be used to add region of interest side data to video frames.
      20fed2f0
    • Mark Thompson's avatar
      vaapi_encode: Add ROI support · 33871478
      Mark Thompson authored
      33871478
    • Shiyou Yin's avatar
      avcodec/mips: [loongson] refine process of setting block as 0 in h264dsp_mmi. · 62e6b634
      Shiyou Yin authored 
      In function ff_h264_add_pixels4_8_mmi, there is no need to reset '%[ftmp0]'
to 0, because it's value has never changed since the start of the asm block.
This patch remove the redundant 'xor' and set src to zero once it was loaded.

In function ff_h264_idct_add_8_mmi, 'block' is seted to zero twice.
This patch removed the first setting zero operation and move the second one
after the load operation of block.

In function ff_h264_idct8_add_8_mmi, 'block' is seted to zero twice too.
This patch just removed the second setting zero operation.

This patch mainly simplifies the implementation of functions above,
the effect on the performance of whole h264 decoding process is not obvious.
According to the perf data, proportion of ff_h264_idct_add_8_mmi decreased from
0.29% to 0.26% and ff_h264_idct8_add_8_mmi decreased from 0.62% to 0.59% when decoding
H264 format on loongson 3A3000(For reference only , not very stable.).
Reviewed-by: 's avatarReimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      62e6b634
    • Andreas Rheinhardt's avatar
      vp9_metadata: Improve spec-compliance and warnings · abb2e9ac
      Andreas Rheinhardt authored 
      The earlier version had three deficits:
1. It allowed to set the stream to RGB although this is not allowed when
the profile is 0 or 2.
2. If it set the stream to RGB, then it did not automatically set the
range to full range; the result was that one got a warning every time a
frame with color_config element was processed if the frame originally
had TV range and the user didn't explicitly choose PC range. Now one
gets only one warning in such a situation.
3. Intra-only frames in profile 0 are automatically BT.601, but if the
user wished another color space, he was not informed about his wishes
being unfulfillable.

The commit also improves the documentation about this.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      abb2e9ac
    • Andreas Rheinhardt's avatar
      av1/h264_metadata: Don't reinitialize data · 43a18884
      Andreas Rheinhardt authored 
      If the relevant elements (the color description elements for AV1 and the
VUI elements in general for H.264 (since 1156b507)) are absent, then their
correct values (usually meaning unknown) have already been inferred by
the reading process, so that it is unnecessary to initialize them again
in the av1/h264_metadata filters even when they were initially absent.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      43a18884
  15. 27 Jul, 2019 1 commit
    • Andreas Rheinhardt's avatar
      cbs_mpeg2: Fix parsing of picture and slice headers · d9182f04
      Andreas Rheinhardt authored 
      1. The extra information in slice headers was parsed incorrectly:
In the first reading pass to derive the length of the extra information,
one should look at bits n, n + 9, n + 18, ... and check whether they
equal one (further extra information) or zero (end of extra information),
but instead bits n, n + 8, n + 16, ... were inspected. The second pass
of reading (where the length is already known and the bytes between the
length-determining bits are copied into a buffer) did not record what
was in bits n, n + 9, n + 18, ..., presuming they equal one. And during
writing, the bytes in the buffer are interleaved with set bits and
written. This means that if the detected length of the extra information
was greater than the real length, the output was corrupted. Fortunately
no sample is known that made use of this mechanism: The extra information
in slices is still marked as reserved in the specifications. cbs_mpeg2
is now ready in case this changes.

2. Furthermore, the buffer is now padded and slightly different, but
very similar code for reading resp. writing has been replaced by code
used for both. This was made possible by a new macro, the equivalent
to cbs_h2645's fixed().

3. These changes also made it possible to remove the extra_bit_slice
element from the MPEG2RawSliceHeader structure. Said element was always
zero except when the detected length of the extra information was less
than the real length.

4. The extra information in picture headers (which uses essentially the
same syntax as the extra information in slice headers) has simply been
forgotten. This meant that if this extra information was present, it was
discarded during reading; and unfortunately writing created invalid
bitstreams in this case (an extra_bit_picture - the last set bit of the
whole unit - indicated that there would be a further byte of data,
although the output didn't contain said data).

This has been fixed; both types of extra information are now parsed via
the same code and essentially passed through.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      d9182f04