Issue 1703 in webm: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation

[cmeng… via monorail]

Status: Untriaged
Owner: ----
Labels: Type-Bug Pri-2
Components: libvpx

New issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703

Please provide any additional information below.

aTalk is trying to add vp9 codec support for its media call; but facing problems.
aTalk projects sources are available on: https://github.com/cmeng-git/atalk-android

The libvpx is built from source v1.8.2 with the following options:
ANDROID_NDK=/opt/android/android-ndk-r18b

./configure --extra-cflags="-isystem ${NDK_SYSROOT}/usr/include/${NDK_ABIARCH} -isystem ${NDK_SYSROOT}/usr/include" \
--libc=${NDK_SYSROOT} \
--prefix=${PREFIX} \
--target=${TARGET} \
${CPU_DETECT} \
--as=yasm \
--enable-pic \
--disable-docs \
--enable-static \
--enable-libyuv \
--disable-examples \
--disable-tools \
--disable-debug \
--disable-unit-tests \
--enable-realtime-only \
--enable-vp8 \
--enable-vp9 \
--disable-webm-io

The vp9 classes can be found in project directory: org.atalk.impl.neomedia.codec.video.vp9
The call test setup is between aTalk and Conversations clients.
1. When the vp8 video codec is used, there is no problem in encode or decode of the video contents:

2. When the vp9 video code is used, below are the observed problems, and the
captured aTalk debug log:

a. During vp9 encode, aTalk makes call to vpx_codec_encode() in libvpx, but it returns with error "Invalid parameter". From vpx_encoder.c source, the error return is based on:
if (!ctx || (img && !duration))
res = VPX_CODEC_INVALID_PARAM;

However I am unable to figure out why based on the check conditions.

b. During vp9 decode, aTalk calls vpx_codec_decode(), but gets errors:
- Bitstream not supported by this decoder, then
- Unspecified internal error

Appreciate if any one can provide some helps on where can be the possible problem,
and solution if available.

========= aTalk debug log ==========
2020-07-15 06:27:47.218 1150-4452/org.atalk.android D/aTalk: [93506] net.sf.fmj.media.Log.profile() Profile: parsing: 248 ms
2020-07-15 06:27:47.312 1150-4449/org.atalk.android D/aTalk: [93503] net.sf.fmj.media.Log.comment() Getting the supported output formats for:
2020-07-15 06:27:47.317 1150-4449/org.atalk.android D/aTalk: [93503] net.sf.fmj.media.Log.comment() YUV Video Format: Size = [width=720, height=1280] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2020-07-15 06:27:47.323 1150-4449/org.atalk.android D/aTalk: [93503] net.sf.fmj.media.Log.comment() # of nodes visited: 34
2020-07-15 06:27:47.329 1150-4449/org.atalk.android D/aTalk: [93503] net.sf.fmj.media.Log.comment() # of formats supported: 20
2020-07-15 06:27:47.334 1150-4449/org.atalk.android D/aTalk: [93503] net.sf.fmj.media.Log.profile() Profile: getSupportedOutputFormats: 108 ms
2020-07-15 06:27:47.355 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.comment() Building flow graph for: null
2020-07-15 06:27:47.362 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.comment() Building Track: 0
2020-07-15 06:27:47.367 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.comment() Input: YUV Video Format: Size = [width=720, height=1280] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2020-07-15 06:27:47.369 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.comment() Custom options specified.
2020-07-15 06:27:47.371 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.comment() An output format is specified: VP9/RTP
2020-07-15 06:27:47.373 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.comment() An output content type is specified: raw.rtp
2020-07-15 06:27:47.423 1150-4495/org.atalk.android D/(VPXEncoder.java:203)#doOpen: VP9 encoder opened successfully
2020-07-15 06:27:47.427 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write()
2020-07-15 06:27:47.431 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2020-07-15 06:27:47.433 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@b791b38
2020-07-15 06:27:47.435 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.VPXEncoder@e2bd711
2020-07-15 06:27:47.437 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() format: YUV Video Format: Size = [width=720, height=1280] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2020-07-15 06:27:47.440 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.VPXEncoder@e2bd711
2020-07-15 06:27:47.444 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.Packetizer@c57f076
2020-07-15 06:27:47.449 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() format: VP9, 720x1280, FrameRate=2.0
2020-07-15 06:27:47.452 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.Packetizer@c57f076
2020-07-15 06:27:47.454 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() connects to: com.sun.media.multiplexer.RTPSyncBufferMux@df98677
2020-07-15 06:27:47.455 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write() format: VP9/RTP
2020-07-15 06:27:47.459 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.write()
2020-07-15 06:27:47.463 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.profile() Profile: graph building: 104 ms
2020-07-15 06:27:47.467 1150-4495/org.atalk.android D/aTalk: [93510] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms

2020-07-15 06:27:48.005 1150-4506/org.atalk.android W/(VPXEncoder.java:310)#doProcess: Failed to encode a frame: Invalid parameter
2020-07-15 06:27:48.009 1150-4506/org.atalk.android W/(VPXEncoder.java:310)#doProcess: Failed to encode a frame: Invalid parameter
2020-07-15 06:27:48.066 1150-4506/org.atalk.android W/(VPXEncoder.java:310)#doProcess: Failed to encode a frame: Invalid parameter
....


2020-07-15 06:27:52.402 1150-4559/org.atalk.android I/aTalk: [93542] net.sf.fmj.media.Log.info() Starting RTPSourceStream.
2020-07-15 06:27:52.414 1150-4559/org.atalk.android D/aTalk: [93542] net.sf.fmj.media.Log.profile() Profile: parsing: 6 ms
2020-07-15 06:27:52.427 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.comment() Building flow graph for: null
2020-07-15 06:27:52.432 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.comment() Building Track: 0
2020-07-15 06:27:52.437 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.comment() Input: VP9/RTP, fmtps={}
2020-07-15 06:27:52.446 1150-4563/org.atalk.android D/(VPXDecoder.java:130)#doOpen: VP9 decoder opened successfully
2020-07-15 06:27:52.449 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write()
2020-07-15 06:27:52.451 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2020-07-15 06:27:52.453 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@e629598
2020-07-15 06:27:52.455 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.DePacketizer@51e31f1
2020-07-15 06:27:52.457 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() format: VP9/RTP, fmtps={}
2020-07-15 06:27:52.459 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.DePacketizer@51e31f1
2020-07-15 06:27:52.460 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.VPXDecoder@278e1d6
2020-07-15 06:27:52.462 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() format: VP9
2020-07-15 06:27:52.464 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.VPXDecoder@278e1d6
2020-07-15 06:27:52.465 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.SwScale@af3df0a
2020-07-15 06:27:52.469 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() format: AVFRAME, class org.atalk.impl.neomedia.codec.video.AVFrame, pixFmt 0
2020-07-15 06:27:52.474 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.SwScale@af3df0a
2020-07-15 06:27:52.476 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer@387337b
2020-07-15 06:27:52.481 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write() format: RGB, 32-bit, Masks=255:65280:16711680, LineStride=-1, class [I
2020-07-15 06:27:52.484 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.write()
2020-07-15 06:27:52.485 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.profile() Profile: graph building: 57 ms
2020-07-15 06:27:52.486 1150-4563/org.atalk.android D/aTalk: [93545] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms

2020-07-15 06:27:52.523 1150-4572/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Bitstream not supported by this decoder
2020-07-15 06:27:52.584 1150-4572/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Bitstream not supported by this decoder
2020-07-15 06:27:52.668 1150-4572/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Unspecified internal error
2020-07-15 06:27:52.759 1150-4572/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Unspecified internal error
....

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[cmeng… via monorail]

Comment #1 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c1

Hi James Zern,

> It would be best if you could file a bug at crbug.com/webm. To debug the decode issue it would be helpful if you could capture a stream so the error can be reproduced with command line tools.

Actually I have yet to come to verify the data stream. As mentioned in the my previous info
libvpx already returns with
VPX_CODEC_INVALID_PARAM based on test conditions based on below test i.e.

> if (!ctx || (img && !duration))
> res = VPX_CODEC_INVALID_PARAM;

However I am unable to figure out, basing on the three test conditions, libvpx already returns error before even performing the data encode;
I have checked and confirmed that all the three pass in parameters contain valid values.
I am hoping someone can provide some hints on the possible causes of the error which I may no be aware of.

As for the video stream, it is captured from the android device's camera; it is displayed properly in the preview windows. So I presume there is no error in the stream data. Actually I am not sure how to capture the video stream as requested by you.

If your are OK, alternatively you can download aTalk source, build and install on two android devices (one can be AVD). Then you can break point at

org.atalk.android W/(VPXEncoder.java:310)#doProcess: Failed to encode a frame: Invalid parameter

The full file path directory is "org.atalk.impl.neomedia.codec.video.vp9"

[ji… via monorail]

Comment #2 on issue 1703 by ji...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c2

I did a quick code search in your github repo and vpx_codec_encode is called here

https://github.com/cmeng-git/atalk-android/blob/5f1f142c2c91a64b18fed9aa32aac42d725c277c/aTalk/jni/vpx/org_atalk_impl_neomedia_codec_video_VPX.c#L210

ctx, img and duration used in that condition that fails are all passed into that function. So there is some initialization work your application needs to do before you pass those into vpx_codec_encode.

If you can show us how they are initialized we can probably start to look what's wrong with them.

Here is an example about how they are initialized before being passed into vpx_codec_encode:

https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.8.2/examples/vpx_temporal_svc_encoder.c#897

[cmeng… via monorail]

Comment #3 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c3

The encoder parameters are initialized in the file org.atalk.impl.neomedia.codec.video.vp9.VPXEncoder#doOpen()
and all the jni native calls are defined aTalk/jin/vpx/org_atalk_impl_neomedia_codec_video_VPX.c.
You also need to refer to org.atalk.impl.neomedia.codec.video.VPX.

If you need to find out other info on VP9 codec, perform a global search at java root with serach string "VPX"

[كاظم راجح‎]

نتاتتتا

بتاريخ 2020 7 30 18:43، كتبها "ji… via monorail" <monorail+norep...@chromium.org>:

You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss+unsubscribe@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webm-discuss/0000000000003b41f505abad0b9d%40google.com.

[jz… via monorail]

Updates:
Cc: mar...@google.com kys...@google.com
Owner: ji...@google.com
Status: Assigned

Comment #4 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c4

(No comment was entered for this change.)

[jz… via monorail]

Comment #5 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c5

Is this still an issue? From a quick look at the log, there may be something wrong with either the encoder configuration or how the encode call is being made.

[cmeng… via monorail]

Comment #6 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c6

The problem remains unresolved. The encoder call method is very similar to VP8, where it is working OK.

Quote from previous discussion:

However I am unable to figure out, basing on the three test conditions, libvpx already returns error before even performing the data encode;
I have checked and confirmed that all the three pass in parameters contain valid values.
I am hoping someone can provide some hints on the possible causes of the error which I may no be aware of.

[jz… via monorail]

Updates:
Labels: Needs-Feedback

Comment #7 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c7

There have been a couple releases since this report, though no issues that may have been similar to this report. If you avoid supplying your own configuration and use the result of vpx_codec_enc_config_default() are you able to encode VP9?
As Jerome mentioned in comment #2 there are examples of the encoder's usage that may help.

[cmeng… via monorail]

Comment #8 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c8

Recently I made some minor clean up in the vpxEncoder file in aTalk v2.6.0; just found out that VP9 encoder is now working with vpx v1.8.2 release. But there is still problem in the VP9Decoder. Intent to take a look again to see if I am able to resolve the problem this round.

[cmeng… via monorail]

Comment #9 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c9

Sorry, mistake in my previous comment. Both the VP9 encoder/decoder are still no working. I mistaken the encoder is working as the camera preview is being shown in v2.6.0. Actually they are unrelated processes. The encoder error happens when aTalk is trying to doProcess() # VPX.codec_encode but failed with
W/(VPXEncoder.java:307)#doProcess: Failed to encode a frame: Invalid parameter


int result = VPX.codec_encode(
context,
img,
(byte[]) inputBuffer.getData(),
offsetY,
offsetU,
offsetV,
frameCount,
1,
0,
VPX.DL_REALTIME);
if (result != VPX.CODEC_OK) {
Timber.w("Failed to encode a frame: %s", VPX.codec_err_to_string(result));
outputBuffer.setDiscard(true);
return BUFFER_PROCESSED_OK;
}

==========VP9 Encoder doProcess()==========


protected int doProcess(Buffer inputBuffer, Buffer outputBuffer)
{
int ret = BUFFER_PROCESSED_OK;
byte[] output;
if (leftoverPackets) {
if (VPX.codec_cx_pkt_get_kind(pkt) == VPX.CODEC_CX_FRAME_PKT) {
int size = VPX.codec_cx_pkt_get_size(pkt);
output = validateByteArraySize(inputBuffer, size, false);
VPX.memcpy(output, VPX.codec_cx_pkt_get_data(pkt), size);
outputBuffer.setOffset(0);
outputBuffer.setLength(size);
outputBuffer.setTimeStamp(inputBuffer.getTimeStamp());
}
else {
//not a compressed frame, skip this packet
ret |= OUTPUT_BUFFER_NOT_FILLED;
}
}
else {
frameCount++;

YUVFormat format = (YUVFormat) inputBuffer.getFormat();
Dimension formatSize = format.getSize();
int width = formatSize.width;
int height = formatSize.height;

if (width > 0 && height > 0
&& (width != this.width || height != this.height))
updateSize(width, height);

//setup img
int strideY = format.getStrideY();
if (strideY == Format.NOT_SPECIFIED)
strideY = width;
int strideUV = format.getStrideUV();
if (strideUV == Format.NOT_SPECIFIED)
strideUV = width / 2;
VPX.img_set_stride0(img, strideY);
VPX.img_set_stride1(img, strideUV);
VPX.img_set_stride2(img, strideUV);
VPX.img_set_stride3(img, 0);

int offsetY = format.getOffsetY();
if (offsetY == Format.NOT_SPECIFIED)
offsetY = 0;
int offsetU = format.getOffsetU();
if (offsetU == Format.NOT_SPECIFIED)
offsetU = offsetY + width * height;
int offsetV = format.getOffsetV();
if (offsetV == Format.NOT_SPECIFIED)
offsetV = offsetU + (width * height) / 4;

int result = VPX.codec_encode(
context,
img,
(byte[]) inputBuffer.getData(),
offsetY,
offsetU,
offsetV,
frameCount,
1,
0,
VPX.DL_REALTIME);
if (result != VPX.CODEC_OK) {
Timber.w("Failed to encode a frame: %s", VPX.codec_err_to_string(result));
outputBuffer.setDiscard(true);
return BUFFER_PROCESSED_OK;
}

iter[0] = 0;
pkt = VPX.codec_get_cx_data(context, iter);
if (pkt != 0
&& VPX.codec_cx_pkt_get_kind(pkt) == VPX.CODEC_CX_FRAME_PKT) {
int size = VPX.codec_cx_pkt_get_size(pkt);
long data = VPX.codec_cx_pkt_get_data(pkt);
output = validateByteArraySize(outputBuffer, size, false);
VPX.memcpy(output, data, size);
outputBuffer.setOffset(0);
outputBuffer.setLength(size);
outputBuffer.setTimeStamp(inputBuffer.getTimeStamp());
}
else {
//not a compressed frame, skip this packet
ret |= OUTPUT_BUFFER_NOT_FILLED;
}
}

pkt = VPX.codec_get_cx_data(context, iter);
leftoverPackets = pkt != 0;

if (leftoverPackets)
return ret | INPUT_BUFFER_NOT_CONSUMED;
else
return ret;

[cmeng… via monorail]

Comment #10 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c10

I have migrated aTalk to use vpx version 1.10.0. aTalk VP8 encode/decode for video call is still working without problem. However, still facing the same problem for VP9 codec.

During aTalk video call using VP9 codec between my samsung Note-10 and J730; on both the devices, the vp9 encoders seem to be open successfully. Both crashes after that; see debug log below:

// ====================== Open VP9 Encoder =============
2021-04-23 13:42:30.179 16763-22386/org.atalk.android D/(VPXEncoder.java:192)#doOpen: VP9 encoder opened successfully
2021-04-23 13:42:30.180 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write()
2021-04-23 13:42:30.181 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2021-04-23 13:42:30.182 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@b789209
2021-04-23 13:42:30.183 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.VPXEncoder@acb1c0e
2021-04-23 13:42:30.184 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() format: YUV Video Format: Size = [width=480, height=720] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2021-04-23 13:42:30.185 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.VPXEncoder@acb1c0e
2021-04-23 13:42:30.186 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.Packetizer@bdb662f
2021-04-23 13:42:30.187 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() format: VP9, 480x720, FrameRate=2.0
2021-04-23 13:42:30.188 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.Packetizer@bdb662f
2021-04-23 13:42:30.189 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() connects to: com.sun.media.multiplexer.RTPSyncBufferMux@ce7043c
2021-04-23 13:42:30.190 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write() format: VP9/RTP
2021-04-23 13:42:30.190 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.write()
2021-04-23 13:42:30.191 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.profile() Profile: graph building: 44 ms
2021-04-23 13:42:30.192 16763-22386/org.atalk.android D/aTalk: [215232] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms

// ============== Errors on both devices after the codec opened ========
// ---------------On Note-10: ----------
2021-04-23 13:42:31.381 16763-22406/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x778f1c8000 in tid 22406 (Loop thread: ne), pid 16763 (g.atalk.android)
2021-04-23 13:42:31.569 22800-22800/? A/DEBUG: pid: 16763, tid: 22406, name: Loop thread: ne >>> org.atalk.android <<<
2021-04-23 13:42:31.572 22800-22800/? A/DEBUG: #01 pc 00000000001bee10 /data/app/~~ZW_4T7XAD7dyH_WvPX7jtA==/org.atalk.android-jGpHAJrL66y51_sgBpWinA==/lib/arm64/libjnvpx.so (BuildId: 175c3c0e0357432bc826432d123d22ec07b4d2da)

//---------------- on J730: --------------
--------- beginning of crash
2021-04-23 13:22:22.140 19786-20150/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xc46d6000 in tid 20150 (Loop thread: ne), pid 19786 (g.atalk.android)
2021-04-23 13:22:22.344 20215-20215/? A/DEBUG: pid: 19786, tid: 20150, name: Loop thread: ne >>> org.atalk.android <<<
2021-04-23 13:22:22.346 20215-20215/? A/DEBUG: #01 pc 001a53a1 /data/app/org.atalk.android-tO8iU4YQMvrDQkVvR279pA==/lib/arm/libjnvpx.so (vp9_copy_and_extend_frame+2716)

Any comment to the problem is much appreciated

[jz… via monorail]

Comment #11 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c11

The encoder shouldn't crash, though it's unclear from the log what the cause is. Was there any resolution change in the stream?

Can you try building vpxenc for android and running it with the same settings? You can use configure --target=arm64-android-gcc and set CC/CXX to clang in the ndk. Something like CC=<path-to-ndk>/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang ... ./configure --target=arm64-android-gcc should work.

[cmeng… via monorail]

Comment #12 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c12

The android libvpx.so are built using the scripts in: https://github.com/cmeng-git/vpx-android; believe it is already using the same settings as you have recommended. The app aTalk use for the testing can be found in: https://github.com/cmeng-git/atalk-android

During testing the aTalk media call with either VP8 or VP9 codec, all other app call settings remain unchanged e.g. video setting is 720x480 and device is in portrait mode. If you refer to the online source under sub-directory: org.atalk.impl.neomedia.codec.video for VP8/VP9, with the exception of the VP8/VP9 constants, the sources for both the codecs are exactly the same. They are also being executed the same manner.

However VP8 encoder/decoder works, but VP9 encoder failed with the above error message. Note: I have not test the VP9 decoder.
When using the libvpx v1.8.2, it has difference error as stated in the previous comments i.e. Invalid parameter. From libvpx source, seems it rejected the passed in parameter ctx.

[cmeng… via monorail]

Comment #13 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c13

I have just tested media call between aTalk and Conversations. The media call works when using the VP8 codec in both encode and decode.
Using VP9 codec has the following problem:

========= aTalk media call with Conversations (VP8 decode no problem) =================

2021-04-24 08:47:38.712 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2021-04-24 08:47:38.713 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@5460f55
2021-04-24 08:47:38.714 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp8.DePacketizer@83e9d6a
2021-04-24 08:47:38.715 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() format: VP8/RTP, fmtps={}
2021-04-24 08:47:38.716 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp8.DePacketizer@83e9d6a
2021-04-24 08:47:38.716 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp8.VPXDecoder@9b825b
2021-04-24 08:47:38.719 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() format: VP8
2021-04-24 08:47:38.720 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp8.VPXDecoder@9b825b
2021-04-24 08:47:38.721 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.SwScale@f5d113f
2021-04-24 08:47:38.723 17912-22712/org.atalk.android D/aTalk: [221736] net.sf.fmj.media.Log.comment() RTP video buffer size: 21 pkts, 18496 bytes.
2021-04-24 08:47:38.725 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() format: AVFRAME, class org.atalk.impl.neomedia.codec.video.AVFrame, pixFmt 0
2021-04-24 08:47:38.726 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.SwScale@f5d113f
2021-04-24 08:47:38.726 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer@b9bba0c
2021-04-24 08:47:38.727 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write() format: RGB, 32-bit, Masks=255:65280:16711680, LineStride=-1, class [I
2021-04-24 08:47:38.727 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.write()
2021-04-24 08:47:38.728 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.profile() Profile: graph building: 27 ms
2021-04-24 08:47:38.728 17912-22830/org.atalk.android D/aTalk: [221784] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms


========= aTalk media call with Conversations (VP9 decode problem) : Bitstream not supported by this decoder =================

2021-04-24 08:49:27.852 17912-23316/org.atalk.android D/(VPXDecoder.java:130)#doOpen: VP9 decoder opened successfully
2021-04-24 08:49:27.853 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write()
2021-04-24 08:49:27.854 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2021-04-24 08:49:27.854 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@d77b4e6
2021-04-24 08:49:27.855 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.DePacketizer@4fa4a27
2021-04-24 08:49:27.855 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() format: VP9/RTP, fmtps={}
2021-04-24 08:49:27.856 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.DePacketizer@4fa4a27
2021-04-24 08:49:27.856 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.VPXDecoder@253a4d4
2021-04-24 08:49:27.856 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() format: VP9
2021-04-24 08:49:27.857 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.VPXDecoder@253a4d4
2021-04-24 08:49:27.859 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.SwScale@bfbce28
2021-04-24 08:49:27.860 17912-23164/org.atalk.android D/aTalk: [221903] net.sf.fmj.media.Log.comment() RTP video buffer size: 21 pkts, 15824 bytes.
2021-04-24 08:49:27.861 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() format: AVFRAME, class org.atalk.impl.neomedia.codec.video.AVFrame, pixFmt 0
2021-04-24 08:49:27.862 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.SwScale@bfbce28
2021-04-24 08:49:27.864 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer@df72741
2021-04-24 08:49:27.866 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write() format: RGB, 32-bit, Masks=255:65280:16711680, LineStride=-1, class [I
2021-04-24 08:49:27.867 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.write()
2021-04-24 08:49:27.868 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.profile() Profile: graph building: 25 ms
2021-04-24 08:49:27.869 17912-23316/org.atalk.android D/aTalk: [221932] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms
2021-04-24 08:49:27.885 17912-23327/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Bitstream not supported by this decoder
2021-04-24 08:49:27.887 17912-23327/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Bitstream not supported by this decoder
2021-04-24 08:49:27.901 17912-23327/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Unspecified internal error
2021-04-24 08:49:28.059 17912-23327/org.atalk.android W/(VPXDecoder.java:177)#doProcess: Discarding a frame with decode error: Unspecified internal error

Any advice to fix .Bitstream not supported by this decoder

[jz… via monorail]

Comment #14 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c14

> The android libvpx.so are built using the scripts in:
> https://github.com/cmeng-git/vpx-android; believe it is already using the
> same settings as you have recommended. The app aTalk use for the testing can
> be found in: https://github.com/cmeng-git/atalk-android

Thanks, but what I'd like to try to do is reproduce this behavior outside of the application so it's easier to debug in the library. Using a captured sequence as input to vpxenc with the encoder settings from the application would be helpful.

> Any advice to fix .Bitstream not supported by this decode

It's possible a frame was corrupted or decoding started on a non-keyframe, but let's try to look at one issue at a time and focus on the crash you reported.

[cmeng… via monorail]

Comment #15 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c15

With reference to the libvpx example i.e. vp9_lossless_encoder.c, I was trying to setup atalk VP9Encoder as similar as possible; with the exception that aTalk get the encoded frame to be streamed to the receiver end. See all the attached files. I also duplicated all the changes if applicable to VP8Encoder. So far VP8Encoder continues to work without problem.

Below are all the related files pertaining to VP9Encoder, with the libvpx registers captured image when the abortion happened, or in running.
During the doProcess(Buffer inputBuffer, Buffer outputBuffer), I have verified that the inputBuffer, and the libvpx registers contain similar data/values as when doing VP8 frame encoding. So I assume the problem is not due to incorrect input IMG_FMT_I420 data or encoder setup.

It seems that the frame encoding is also OK as shown in the captured log i.e.
(VP9Encoder.java:285)#doProcess: Encode a VP9 frame: Success 518400 [width=480, height=720] 0 345600 432000

The problem happen when aTalk is trying to retrieve the encoded packet; the return pkt is always null.

iter[0] = 0;
pkt = VPX.codec_get_cx_data(context, iter);

When I refer to the libvpx code, it seems it also uses the same approach to retrieve the pkt without problem.
Any comment why pkt is always return null in aTalk case


=========== aTalk debug logcat ============
2021-05-03 11:14:57.014 29399-10231/org.atalk.android I/SurfaceView: applySurfaceTransforms: postScaleX = 1.0 postScaleY = 1.0
2021-05-03 11:14:57.131 29399-10551/org.atalk.android D/aTalk: [2627] net.sf.fmj.media.Log.profile() Profile: parsing: 305 ms
2021-05-03 11:14:57.166 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.comment() Building flow graph for: null
2021-05-03 11:14:57.176 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.comment() Building Track: 0
2021-05-03 11:14:57.186 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.comment() Input: YUV Video Format: Size = [width=480, height=720] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2021-05-03 11:14:57.197 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.comment() Custom options specified.
2021-05-03 11:14:57.207 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.comment() An output format is specified: VP9/RTP
2021-05-03 11:14:57.218 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.comment() An output content type is specified: raw.rtp
2021-05-03 11:14:57.302 29399-10590/org.atalk.android D/(VP9Encoder.java:198)#doOpen: VP9 encoder opened successfully
2021-05-03 11:14:57.316 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write()
2021-05-03 11:14:57.339 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2021-05-03 11:14:57.352 29399-10519/org.atalk.android V/aTalk: [2601] net.sf.fmj.media.rtp.RTCPReporter.run() RTCP reporting for running again after 6379.556114494531 ms.
2021-05-03 11:14:57.359 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@de674de
2021-05-03 11:14:57.370 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder@46f96bf
2021-05-03 11:14:57.382 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() format: YUV Video Format: Size = [width=480, height=720] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2021-05-03 11:14:57.393 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder@46f96bf
2021-05-03 11:14:57.404 29399-29399/org.atalk.android D/SensorManager: TYPE_PROXIMITY (8): 5.000000
2021-05-03 11:14:57.405 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.Packetizer@a2b918c
2021-05-03 11:14:57.417 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() format: VP9, 480x720, FrameRate=2.0
2021-05-03 11:14:57.428 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.Packetizer@a2b918c
2021-05-03 11:14:57.439 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() connects to: com.sun.media.multiplexer.RTPSyncBufferMux@92dd0d5
2021-05-03 11:14:57.450 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write() format: VP9/RTP
2021-05-03 11:14:57.460 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.write()
2021-05-03 11:14:57.471 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.profile() Profile: graph building: 295 ms
2021-05-03 11:14:57.482 29399-10590/org.atalk.android D/aTalk: [2629] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 1 ms
2021-05-03 11:14:57.512 29399-9228/org.atalk.android I/(TransportManager.java:413)#sendHolePunchPacket: Send NAT hole punch packets to port for media: VIDEO
2021-05-03 11:14:57.520 29399-9228/org.atalk.android D/(CallPeerMediaHandlerJabberImpl.java:1121)#processContent: ### Process media content for: sender = both: video => MediaStreamTarget with dataAddress 192.168.1.37:54467/udp and controlAddress 192.168.1.37:54467/udp
2021-05-03 11:14:57.566 29399-9228/org.atalk.android D/(CallPeerMediaHandler.java:946)#initStream: Initializing video stream for par...@atalk.sytes.net <par...@atalk.sytes.net/Conversations.lxYf>; status=Connected
2021-05-03 11:14:57.582 29399-9228/org.atalk.android I/(MediaHandler.java:797)#registerDynamicPTsWithStream: Dynamic PT map: 101=rtpmap:-1 telephone-event/8000; 96=rtpmap:-1 opus/48000/2 fmtp:useinbandfec=1; 103=rtpmap:-1 iLBC/8000; 97=rtpmap:-1 SILK/24000; 98=rtpmap:-1 SILK/16000; 100=rtpmap:-1 speex/32000; 102=rtpmap:-1 speex/16000; 104=rtpmap:-1 speex/8000; 105=rtpmap:-1 VP9/90000;
2021-05-03 11:14:57.583 29399-9228/org.atalk.android I/(MediaHandler.java:809)#registerDynamicPTsWithStream: PT overrides []
2021-05-03 11:14:57.589 29399-9228/org.atalk.android I/(CallPeerMediaHandler.java:1591)#start: Starting callPeer media handler for: video true
2021-05-03 11:14:57.613 29399-10613/org.atalk.android W/(VP9Encoder.java:285)#doProcess: Encode a VP9 frame: Success 518400 [width=480, height=720] 0 345600 432000
2021-05-03 11:14:57.614 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.639 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.662 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.705 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.751 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.808 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.904 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.923 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.956 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:57.987 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.021 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.055 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.091 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.121 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.167 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.467 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.504 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.521 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.554 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.587 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.620 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.657 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.689 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:58.756 29399-10613/org.atalk.android W/(VP9Encoder.java:301)#doProcess: Discard non-compressed frame packet: 0
2021-05-03 11:14:59.021 29399-10615/org.atalk.android A/libc: vp9/encoder/vp9_bitstream.c:399: assertion "*tok < tok_end" failed

Attachments:
VP9Encoder.java 14.5 KB
VPX.java 31.4 KB
VPX.c 18.5 KB
vpx_c.jpg 138 KB

[jz… via monorail]

Comment #16 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c16

If you can capture the source to a raw file (yuv or y4m) and give the settings being used in the encoder I think it might be easier to debug the assertion in the library using vpxenc. Some settings may affect whether you get a packet for each frame, such as rc_dropframe_thresh.

[ji… via monorail]

Comment #17 on issue 1703 by ji...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c17

You can also take a look at context.pkt_list and see if there is any data. The packet is read from there here[1].

[1]https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.10.0/vpx/src/vpx_encoder.c#362

[cmeng… via monorail]

Comment #18 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c18

I tried to make some simple changes to the existing VPX.c to test the new function; but unable to proceed due to too many undefined references (see below).

aTalk libvpx was build with the scripts as defined in:
https://github.com/cmeng-git/vpx-android

Is that possible the observed problem is due to the compiled library is incomplete i.e. missing config options


/* ================================
* Method: codec_get_cx_data
*/
JNIEXPORT jlong JNICALL
Java_org_atalk_impl_neomedia_codec_video_VPX_codec_1get_1cx_1data
(JNIEnv *env,
jclass clazz,
jlong context,
jlongArray iterArray)
{
jlong *iter_ptr = (*env)->GetLongArrayElements(env, iterArray, NULL);

const vpx_codec_cx_pkt_t *pkt;
pkt = vpx_codec_get_cx_data((vpx_codec_ctx_t *) (intptr_t) context,
(vpx_codec_iter_t *) iter_ptr);

if (!pkt) {
vpx_codec_alg_priv_t *priv = get_alg_priv((vpx_codec_ctx_t * )(intptr_t) context);
struct vpx_codec_pkt_list *list = priv->pkt_list.head;
pkt = vpx_codec_pkt_list_get(list, (vpx_codec_iter_t *) iter_ptr);
}

(*env)->ReleaseLongArrayElements(env, iterArray, iter_ptr, 0);
return (jlong) (intptr_t) pkt;
}

=============================

However accessing to the required functions make too many references not defined in the global libvpx include files; and create problem during AS build i.e.

vpx/VPX.c:257:9: error: unknown type name 'vpx_codec_alg_priv_t'; did you mean 'vpx_codec_priv_t'?
vpx_codec_alg_priv_t *priv = get_alg_priv((vpx_codec_ctx_t * )(intptr_t) context);
^~~~~~~~~~~~~~~~~~~~
vpx_codec_priv_t
vpx/android/arm64-v8a/include/vpx/./vpx_codec.h:184:31: note: 'vpx_codec_priv_t' declared here
typedef struct vpx_codec_priv vpx_codec_priv_t;
^
vpx/VPX.c:257:38: warning: implicit declaration of function 'get_alg_priv' is invalid in C99 [-Wimplicit-function-declaration]
vpx_codec_alg_priv_t *priv = get_alg_priv((vpx_codec_ctx_t * )(intptr_t) context);
^
vpx/VPX.c:257:31: warning: incompatible integer to pointer conversion initializing 'vpx_codec_priv_t *' (aka 'struct vpx_codec_priv *') with an expression of type 'int' [-Wint-conversion]
vpx_codec_alg_priv_t *priv = get_alg_priv((vpx_codec_ctx_t * )(intptr_t) context);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vpx/VPX.c:258:47: error: incomplete definition of type 'struct vpx_codec_priv'
struct vpx_codec_pkt_list *list = priv->pkt_list.head;
~~~~^
vpx/android/arm64-v8a/include/vpx/./vpx_codec.h:184:16: note: forward declaration of 'struct vpx_codec_priv'
typedef struct vpx_codec_priv vpx_codec_priv_t;
^
vpx/VPX.c:259:15: warning: implicit declaration of function 'vpx_codec_pkt_list_get' is invalid in C99 [-Wimplicit-function-declaration]
pkt = vpx_codec_pkt_list_get(list, (vpx_codec_iter_t *) iter_ptr);
^
vpx/VPX.c:259:13: warning: incompatible integer to pointer conversion assigning to 'const vpx_codec_cx_pkt_t *' (aka 'const struct vpx_codec_cx_pkt *') from 'int' [-Wint-conversion]
pkt = vpx_codec_pkt_list_get(list, (vpx_codec_iter_t *) iter_ptr);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4 warnings and 2 errors generated.
make: *** [/home/cmeng/workspace/android/atalk-android/aTalk/build/intermediates/ndkBuild/playstoreDebug/obj/local/arm64-v8a/objs-debug/jnvpx/VPX.o] Error 1

[cmeng… via monorail]

Comment #19 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c19

In parallel, I also performed the aTalk libvpx decode function. Again it is not working. Attached are two relevant class used for the decode.
Attached below is the actual aTalk debug log.

The debug log contains a dump of the first 32 bytes of received inputBuffer data. I found that the initial few bytes seem to stay pretty constant, difference from vp8 inputBuffer which contains random data.

Does vp9 buffer contains some payload description header data?
Else is there any clue as where are the possible problem?

By the way, how libvpx gets the VP9 decode parameter/info to decode the received data e.g. resolution, keyFrame, SID, TID etc


// ========== aTalk libvpx decode debug log ==========
2021-05-05 12:43:31.010 3783-7746/org.atalk.android D/(VP9Decoder.java:137)#doOpen: VP9 decoder opened successfully
2021-05-05 12:43:31.018 3783-7746/org.atalk.android D/(DePacketizer.java:136)#doOpen: Opened VP9 dePacketizer
2021-05-05 12:43:31.036 3783-7762/org.atalk.android D/aTalk: [19276] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2021-05-05 12:43:31.066 3783-7762/org.atalk.android D/aTalk: [19276] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@f55be30
2021-05-05 12:43:31.294 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.DePacketizer@3bedfcf
2021-05-05 12:43:31.369 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() format: VP9/RTP, fmtps={}
2021-05-05 12:43:31.442 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.DePacketizer@3bedfcf
2021-05-05 12:43:31.496 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.VP9Decoder@9908d5c
2021-05-05 12:43:31.570 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() format: VP9
2021-05-05 12:43:31.653 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.VP9Decoder@9908d5c
2021-05-05 12:43:31.744 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.SwScale@fd1bfe2
2021-05-05 12:43:31.763 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() format: AVFRAME, class org.atalk.impl.neomedia.codec.video.AVFrame, pixFmt 0
2021-05-05 12:43:31.806 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.SwScale@fd1bfe2
2021-05-05 12:43:31.845 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer@f91bf73
2021-05-05 12:43:31.877 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write() format: RGB, 32-bit, Masks=255:65280:16711680, LineStride=-1, class [I
2021-05-05 12:43:31.910 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.write()
2021-05-05 12:43:31.942 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.profile() Profile: graph building: 1262 ms
2021-05-05 12:43:31.973 3783-7746/org.atalk.android D/aTalk: [19274] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms
2021-05-05 12:43:32.127 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 18021C03 C0010401 82498342 0021B03B F4703824 1C199C10 03505FD5 F773F93F 0 3400
2021-05-05 12:43:32.129 3783-7783/org.atalk.android W/(VP9Decoder.java:189)#doProcess: VP9: Discarding frame with decode error: Bitstream not supported by this decoder [B@ec66865 0 3400
2021-05-05 12:43:32.165 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 18021C03 C0010401 82498342 0021B03B F4763824 1C19A010 03385FD5 F1FF27E4 0 3289
2021-05-05 12:43:32.175 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 6271680D B5C04058 0C07AB2D 81413D8A 74000004 00727F1D F47DC691 0 889
2021-05-05 12:43:32.204 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 6271680D D7C043D8 0C07BB4F 83413D8A 74000004 002A7F0D F28F29A7 0 1106
2021-05-05 12:43:32.226 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 6271680D A7C045D8 0C07A14A 85C13D8A 74000004 001C73BF 3DE98A00 0 783
2021-05-05 12:43:32.236 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 6271680D 8AC04698 0C07B14D 83413D8A 74000004 001A73BF 47B4DE94 0 587
2021-05-05 12:43:32.243 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 6271680D 89C04958 0C07D940 82413D8A 74000004 0012738E CE36BA60 0 948
2021-05-05 12:43:32.249 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 6271680D BAC04798 0C07D947 83C13D8A 74000004 000C7367 D9000000 0 1043
2021-05-05 12:43:32.280 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 189C5A03 58701556 0301F6D0 61504F62 9D000001 00078073 B37F15F2 0 492
2021-05-05 12:43:32.499 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 E0B1400D 67C076D8 0C07DF33 81412F8A 64000004 001673BF A6F1D198 0 798
2021-05-05 12:43:32.501 3783-7783/org.atalk.android W/(VP9Decoder.java:189)#doProcess: VP9: Discarding frame with decode error: Unspecified internal error [B@ec66865 0 798
2021-05-05 12:43:34.065 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 E1014D0D A0C05918 0C07EF2E 80C1468A E4000004 002873B9 5FC9F13F 0 2212
2021-05-05 12:43:34.066 3783-7783/org.atalk.android W/(VP9Decoder.java:189)#doProcess: VP9: Discarding frame with decode error: Unspecified internal error [B@167693a 0 2212
2021-05-05 12:43:36.131 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 982C4FE3 5CB01C06 0301FC4A A0304BE2 99000001 000A8073 BD7F4FF1 0 2499
2021-05-05 12:43:36.133 3783-7783/org.atalk.android W/(VP9Decoder.java:189)#doProcess: VP9: Discarding frame with decode error: Unspecified internal error [B@7f3a9eb 0 2499
2021-05-05 12:43:38.197 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 E081340D F7C07E18 0C02099C 4FA00000 20008073 A71004FB 20000000 0 968
2021-05-05 12:43:38.198 3783-7783/org.atalk.android W/(VP9Decoder.java:189)#doProcess: VP9: Discarding frame with decode error: Unspecified internal error [B@7f3a9eb 0 968
2021-05-05 12:43:40.772 3783-7783/org.atalk.android W/(VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 86004092 98485463 6AF01646 0301FB4A A0304A22 83000001 80038073 C190F57B 0 2320
2021-05-05 12:43:40.779 3783-7783/org.atalk.android W/(VP9Decoder.java:189)#doProcess: VP9: Discarding frame with decode error: Unspecified internal error [B@7472348 0 2320

Attachments:
DePacketizer.java 32.8 KB
VP9Decoder.java 10.5 KB

[ji… via monorail]

Comment #20 on issue 1703 by ji...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c20

> By the way, how libvpx gets the VP9 decode parameter/info to decode the received data e.g. resolution,
> keyFrame, SID, TID etc

That information is written in the bitstream/frame headers.

[jz… via monorail]

Comment #21 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c21

> However accessing to the required functions make too many references not
> defined in the global libvpx include files; and create problem during AS
> build i.e.

> vpx/VPX.c:257:9: error: unknown type name 'vpx_codec_alg_priv_t'; did you mean 'vpx_codec_priv_t'?
vpx_codec_alg_priv_t *priv = get_alg_priv((vpx_codec_ctx_t * )(intptr_t) context);

This isn't part of the public API. You should use vpxenc.c or the other
examples for a reference. The API functions are defined in the header files
under vpx/ [1].

[1] https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.10.0/vpx/

[cmeng… via monorail]

Comment #22 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c22

I was trying to investigate your proposal i.e.

[1]https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.10.0/vpx/src/vpx_encoder.c#362

The calling method i.e.
const vpx_codec_cx_pkt_t *vpx_codec_pkt_list_get(struct vpx_codec_pkt_list *list, vpx_codec_iter_t *iter)

requires a pass in parameter i.e. struct vpx_codec_pkt_list *list,
and I was trying to make reference to this pass-in parameter using known context via calling to

vpx_codec_alg_priv_t *priv = get_alg_priv((vpx_codec_ctx_t * )(intptr_t) context);

I am not sure how to get this parameter without make reference to the above.

> That information is written in the bitstream/frame headers.

Are these the parameters embedded in the beginning of the inputBuffer as captured in the log above i.e..

VP9Decoder.java:185)#doProcess: VP9: Decode a frame: 18021C03 C0010401 82498342 0021B03B

[cmeng… via monorail]

Comment #23 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c23

Continue testing on VP9 encoder with the latest modified source as attached; but still unable to get the VP9 encoder to work. The retrieved pkt is always null, although the encode returns status is OK.

The image data that passed in to the vpx_codec_encode contains actually only the video raw image coded in IMG_FMT_I420 format.
The info pertaining to the input raw data is actually required to be specified via vpx_image_t img as shown in the code below.

unsigned char *buf
= (unsigned char *) (*env)->GetByteArrayElements(env, bufArray, NULL);
vpx_image_t *img = (vpx_image_t *) (intptr_t) jimg;
img->planes[VPX_PLANE_Y] = (buf + offsetY);
img->planes[VPX_PLANE_U] = (buf + offsetU);
img->planes[VPX_PLANE_V] = (buf + offsetV);
img->planes[VPX_PLANE_ALPHA] = 0;

The same source modification is also applied to the VP8Encoder, and it works as before without problem.
Unless there is a different in API call to the vp9 encoder call as compared to vp8 encoder, it seems the problem is due to libvpx in vp9 encode.
I am not able to proceed further as it is beyond my knowledge to do it.

Attachments:
VP9Encoder.java 15.8 KB

[James Zern]

On Sat, May 8, 2021 at 9:59 PM cmeng… via monorail <monorail+norepl...@chromium.org> wrote:

Comment #23 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c23

Continue testing on VP9 encoder with the latest modified source as attached; but still unable to get the VP9 encoder to work. The retrieved pkt is always null, although the encode returns status is OK.

The image data that passed in to the vpx_codec_encode contains actually only the video raw image coded in IMG_FMT_I420 format.
The info pertaining to the input raw data is actually required to be specified via vpx_image_t img as shown in the code below.

unsigned char *buf
= (unsigned char *) (*env)->GetByteArrayElements(env, bufArray, NULL);
vpx_image_t *img = (vpx_image_t *) (intptr_t) jimg;
img->planes[VPX_PLANE_Y] = (buf + offsetY);
img->planes[VPX_PLANE_U] = (buf + offsetU);
img->planes[VPX_PLANE_V] = (buf + offsetV);
img->planes[VPX_PLANE_ALPHA] = 0;

The same source modification is also applied to the VP8Encoder, and it works as before without problem.
Unless there is a different in API call to the vp9 encoder call as compared to vp8 encoder, it seems the problem is due to libvpx in vp9 encode.
I am not able to proceed further as it is beyond my knowledge to do it.

As was mentioned if you can extract the raw input and encoder settings you might be able to reproduce it in one of the examples. That will help us diagnose the issue.

 

Attachments:
VP9Encoder.java 15.8 KB

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

--

You received this message because you are subscribed to the Google Groups "WebM Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webm-discuss/000000000000cddd2a05c1de8483%40google.com.

[cmeng… via monorail]

Comment #24 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c24

Have released aTalk v2.6.1, but vp9 encode/decode still remain unresolved.
I made reference to google exoplayer source, I found that it calls the function below after vpx_codec_dec_init() in vpx_jni.cc.

vpx_codec_err_t vpx_codec_set_frame_buffer_functions(
vpx_codec_ctx_t *ctx, vpx_get_frame_buffer_cb_fn_t cb_get,
vpx_release_frame_buffer_cb_fn_t cb_release, void *cb_priv);

This function is not being called in aTalk vp8 encode/decode, which is currently working.
Please advise if this function call is a must for vp9 encode/decode to work properly.

Any example in c source implementation if this function call is required.

[MahanStreamer Management]

Hello there,

In the example VP9 decoder source code on Github there is this snippet:

if (num_external_frame_buffers > 0) {
ext_fb_list.num_external_frame_buffers = num_external_frame_buffers;
ext_fb_list.ext_fb = (struct ExternalFrameBuffer *)calloc(
num_external_frame_buffers, sizeof(*ext_fb_list.ext_fb));
if (vpx_codec_set_frame_buffer_functions(&decoder, get_vp9_frame_buffer,
release_vp9_frame_buffer,
&ext_fb_list)) {
fprintf(stderr, "Failed to configure external frame buffers: %s\n",
vpx_codec_error(&decoder));
goto fail;
}
}

Link: https://github.com/webmproject/libvpx/blob/705bf9de8c96cfe5301451f1d7e5c90a41c64e5f/vpxdec.c#L814

This function only seems to be called if you have any external frame
buffers. I assume this function would set up processing and callbacks
for those external frame buffers. I don't know if you have any of
those in your code.

----
Thanks, and "keep coding son",
Mahanstreamer Management

> You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.

> To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webm-discuss/0000000000007cbe5f05c309875b%40google.com.

[James Zern]

Using external frame buffers is optional though it can provide a
performance benefit, reducing the number of copies. Before doing this
I think it would be helpful to find the cause of your encode issue.

> > Any example in c source implementation if this function call is required.
> >
> > --
> > You received this message because:
> > 1. The project was configured to send all issue notifications to this address
> >
> > You may adjust your notification preferences at:
> > https://bugs.chromium.org/hosting/settings
> >
> > --
> > You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.
> > To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webm-discuss/0000000000007cbe5f05c309875b%40google.com.
>
> --
> You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.

> To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webm-discuss/CABkmHE%3DP%3DGgL9AX7iAzwes7gN8Jw_D5doTS3tojHpQLsE_0rUA%40mail.gmail.com.

[ChongMeng Eng]

Thanks for all the inputs. Confirmed aTalk is not using external frame currently.

With the help from the following link, aTalk is now able to debug into the libvpx  jni library.

https://codelab.wordpress.com/2014/11/03/how-to-use-standard-output-streams-for-logging-in-android-apps/

Just managed to get vp9 decoder working on aTalk. The problem is that aTalk incorrectly calculates the VP9 Payload Descriptor length. This causes

an extra 8 bytes not stripped off from the start of the input frame buffer for decode.

I found that libvpx source groups the "Invalid frame marker" and returns to the caller as VPX_CODEC_UNSUP_BITSTREAM.

vpx_internal_error(&cm->error, VPX_CODEC_UNSUP_BITSTREAM, "Invalid frame marker");

This gives some problem in aTalk initial debug, until I found that tool to debug into the libvpx.

aTalk will now proceed to debug the vpx encoder.  

[ChongMeng Eng]

Following are the latest vp9 encode debug status; need some advice how to resolve the problem.

Attached at the end are the aTalk logcat results. All the debug messages tagged wiht vpx_jni are from the libvpx manually inserted fprintf(stderr, ....) statements or exception.

The investigation are based on 3 files in libvpx i.e. #1: vp9_cx_iface.c, #2: vp9_encoder.c and #3: vp9_lookahead.c:

1. The start of the problem happens in #1.encoder_encode() where vp9_get_compressed_data() return -1

2.  In #2.vp9_get_compressed_data(), where source == null when execute

      source = vp9_lookahead_pop(cpi->lookahead, flush);

3 The actual cause is In #3; it was found that vp9_lookahead_pop does not proceed to fill buf due to invalid test conditions i.e.

   fprintf: vpx_jni: vp9_lookahead_pop: ctx: 1; ctx->Sz: 1; drain: 0;  ctx->max_sz: 26; MAX_PRE_FRAMES: 1

   when I forced ctx->max_sz = 2, in vp9_lookahead_init(), the value in defined vp8; then the returned buf is not NULL.

   However aTalk crashes due to assert i.e. libc: vp9/encoder/vp9_bitstream.c:399: assertion "*tok < tok_end" failed

I am not sure what is the correct way to resolve the above issues, any assistance is much appreciated. 

/------------------------------------------------------------------------------------------

// ==== modified vp9_lookahead_pop for testing ========//

struct lookahead_entry *vp9_lookahead_pop(struct lookahead_ctx *ctx, int drain) {
  struct lookahead_entry *buf = NULL;

  fprintf(stderr, "vp9_lookahead_pop: ctx: %d; ctx->Sz: %d; drain: %d; ctx->max_sz: %d; MAX_PRE_FRAMES: %d\n", (ctx != NULL), ctx->sz, drain, ctx->max_sz,  MAX_PRE_FRAMES);
  if (ctx && ctx->sz && (drain || ctx->sz == ctx->max_sz - MAX_PRE_FRAMES)) {
    buf = pop(ctx, &ctx->read_idx);
    ctx->sz--;
  }
  return buf;
}

// ============= aTalk logcat output =============== //

2021-05-31 14:30:46.852 4372-11400/org.atalk.android D/vpx_jni: VPX encode using: WebM Project VP9 Encoder v1.10.0

2021-05-31 14:30:46.865 4372-11400/org.atalk.android D/(VP9Encoder.java:215)#doOpen: VP9 encoder opened successfully

2021-05-31 14:30:46.889 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()     

2021-05-31 14:30:46.920 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.comment() Here's the completed flow graph:

2021-05-31 14:30:46.950 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()       net.sf.fmj.media.parser.RawPushBufferParser@c3d0c

2021-05-31 14:30:46.983 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()          connects to: org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder@317d655

2021-05-31 14:30:47.019 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()          format: YUV Video Format: Size = [width=480, height=720] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1

2021-05-31 14:30:47.050 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()       org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder@317d655

2021-05-31 14:30:47.082 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()          connects to: org.atalk.impl.neomedia.codec.video.vp9.Packetizer@f32586a

2021-05-31 14:30:47.114 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()          format: VP9, 480x720, FrameRate=2.0

2021-05-31 14:30:47.142 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()       org.atalk.impl.neomedia.codec.video.vp9.Packetizer@f32586a

2021-05-31 14:30:47.163 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()          connects to: com.sun.media.multiplexer.RTPSyncBufferMux@b5c215b

2021-05-31 14:30:47.182 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()          format: VP9/RTP

2021-05-31 14:30:47.203 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.write()     

2021-05-31 14:30:47.221 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.profile() Profile: graph building: 746 ms

2021-05-31 14:30:47.240 4372-11400/org.atalk.android D/aTalk: [136078] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 1 ms

2021-05-31 14:30:47.274 4372-10454/org.atalk.android I/(TransportManager.java:413)#sendHolePunchPacket: Send NAT hole punch packets to port for media: VIDEO

2021-05-31 14:30:47.288 4372-10454/org.atalk.android D/(CallPeerMediaHandlerJabberImpl.java:1121)#processContent: ### Process media content for: sender = both: video => MediaStreamTarget with dataAddress [fe80::362d:dff:fe00:ae96]:5019/udp and controlAddress [fe80::362d:dff:fe00:ae96]:5019/udp

2021-05-31 14:30:47.309 4372-11405/org.atalk.android D/vpx_jni: vp9_lookahead_pop: ctx: 1; ctx->Sz: 1; drain: 0;  ctx->max_sz: 2; MAX_PRE_FRAMES: 1

    vp9_get_compressed_data=>vp9_lookahead_pop(

2021-05-31 14:30:47.309 4372-11405/org.atalk.android D/vpx_jni: ); source: 1

    current_video_frame; cm->show_frame: 1 cm->new_fb_idx: 0

    

    --------- beginning of crash

2021-05-31 14:30:47.314 4372-11417/org.atalk.android A/libc: vp9/encoder/vp9_bitstream.c:399: assertion "*tok < tok_end" failed

  

[ChongMeng Eng]

No sure if my understanding below is correct:

ctx->max_sz = 26 is actually the size of the super-frame. The data compression is only started after this number of frames - 1 have been acquired.

I found that if I allow the #3 to acquired all the 25 frames, then the buf is filled as expected.

But aTalk clashes again due to the following assert error in libvpx. Any reason?

2021-05-31 17:37:52.642 15121-24353/org.atalk.android W/(VP9Encoder.java:305)#doProcess: Skip incomplete compressed frame packet: 0: 24 (frameCount)

2021-05-31 17:37:52.642 15121-24345/org.atalk.android D/vpx_jni: vpx_codec_cx_pkt_t: 1 0

2021-05-31 17:37:52.673 15121-24345/org.atalk.android D/vpx_jni: vp9_lookahead_pop: ctx: 1; ctx->Sz: 25; drain: 0;  ctx->max_sz: 26; MAX_PRE_FRAMES: 1

2021-05-31 17:37:52.673 15121-24345/org.atalk.android D/vpx_jni: vp9_get_cdata; source: 1 (source if not NULL)

    current_video_frame; cm->show_frame: 1 cm->new_fb_idx: 0

2021-05-31 17:37:52.684 15121-24345/org.atalk.android D/vpx_jni: vp9/encoder/vp9_bitstream.c:399: assertion "*tok < tok_end" failed

    

    --------- beginning of crash

2021-05-31 17:37:52.685 15121-24381/org.atalk.android A/libc: vp9/encoder/vp9_bitstream.c:399: assertion "*tok < tok_end" failed

[James Zern]

Hi,

On Mon, May 31, 2021 at 2:43 AM ChongMeng Eng <cmen...@gmail.com> wrote:

No sure if my understanding below is correct:

ctx->max_sz = 26 is actually the size of the super-frame. The data compression is only started after this number of frames - 1 have been acquired.

I found that if I allow the #3 to acquired all the 25 frames, then the buf is filled as expected.

This is expected if you use lagged encoding. You can set this to 0 if you want to avoid the delay:

https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.10.0/vpx/vpx_encoder.h#362

 

But aTalk clashes again due to the following assert error in libvpx. Any reason? 

This may have to do with the input and encoder settings. If you can extract the input stream to a yuv/y4m it would be helpful in debugging this issue through vpxenc or one of the other examples. You can also try configuring libvpx with --enable-bitstream-debug which may give a little more information.

I'm glad you got something to work, note you can also debug into native code using android studio:

https://developer.android.com/studio/debug

[ChongMeng Eng]

> This is expected if you use lagged encoding. You can set this to 0 if you want to avoid the delay:

Thank for the info, aTalk has now disabled this option.

// =================================================

> This may have to do with the input and encoder settings.

Further tracing indicates that aTalk crashes during vp9_bitstream#encode_tiles_mt(); 

I inserted some printf statements in encode_tiles_mt(), at the following locations to pinpoint the crash entry point i.e.

static size_t encode_tiles_mt(VP9_COMP *cpi, uint8_t *data_ptr) {

...

if (i < num_workers - 1) {
  fprintf(stderr, "encode_tiles_mt #1; num_worker: %d\n", i); 
  winterface->launch(worker);
  fprintf(stderr, "encode_tiles_mt #2\n");
} else {
  winterface->execute(worker);
}

...

}

Below is the aTalk logcat trace. If I set --disable-multithread in configure, then  encode_tiles_mt #2 is not output

It seems that libvpx crash when performing  the statement i.e.  winterface->launch(worker) => winterface->execute(worker);

Any hint what are the possible incorrect encode settings that may cause the crash.

I found that multithread is only used in vp9 encode/decode,  but not in vp8. Both vp8 encode/decode work in aTalk.

// ---------------- aTalk logcat ----------

2021-06-04 08:31:49.706 15386-22344/org.atalk.android D/vpx_jni: vp9_pack_bitstream; wb->bit_buffer (18): 83 49 83 42 00 1d f0 2c f0 00 e0 90 70 60 00 40 00 00 

2021-06-04 08:31:49.706 15386-22344/org.atalk.android D/vpx_jni: encode_tiles_mt #1; num_worker: 0

2021-06-04 08:31:49.706 15386-22344/org.atalk.android D/vpx_jni: encode_tiles_mt #2

2021-06-04 08:31:49.706 15386-22344/org.atalk.android D/vpx_jni: write_mode_b => tok: 446265966672; tok_end; 446265966672

2021-06-04 08:31:49.706 15386-22344/org.atalk.android D/vpx_jni: vp9/encoder/vp9_bitstream.c:400: assertion "*tok < tok_end" failed

    

    --------- beginning of crash

2021-06-04 08:31:49.706 15386-22356/org.atalk.android A/libc: vp9/encoder/vp9_bitstream.c:400: assertion "*tok < tok_end" failed

// -----------------------

// =================================================

> you can also debug into native code using android studio: 

Currently libvpx.a is built in Ubuntu using external shell scripts before integrated in the aTalk apk. Even if I enabled with debug option in libvpx build, android studio still does not allow me to step trace into the libvpx. I am not sure if the problem lies with the external build libvpx.a or below test failed.

My samsung Note 10, failed the following test i.e. unknown key error. Not sue if this is to do with the device security setting.

• The device has ptrace enabled.

  To check whether ptrace is enabled, run the following command on the ADB shell that is connected to your device:

  sysctl kernel.yama.ptrace_scope

  If ptrace is enabled, the command will print the value 0 or an an unknown key error. If ptrace is not enabled, it will print a value other than 0.

[jz… via monorail]

Comment #25 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c25

Adding some detail from the mail thread:

[jz… via monorail]

Comment #26 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c26

Please provide a sample stream and encoder settings to help reproduce this outside of your application. This looks like a valid encoder issue, but it will be easier to debug using vpxenc for example.

[cmeng… via monorail]

Comment #27 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c27

> Please provide a sample stream and encoder settings

For the sample stream, I am not sure how to capture and save the stream in valid media format. The data media stream is streamed/converted to YUV420 from the camera, with the help of ffmpeg. The stream packets are then submitted to libvpx for encoding.

For the setting, you can refer to the 4 file below in particular VP9Encoder.java#doOpen().

The whole aTalk source v2.6.1 can be found in github site:
https://github.com/cmeng-git/atalk-android

// ============================
I just built aTalk to run on genymotion Note10+ emulator, found there are more debug info as captured in the aTalk logcat below for two test instances.
On the debug message it shows Frame 4294967295 not found for thread 1:

============ aTalk logcat instace #1 ==========

--------- beginning of crash
2021-06-05 07:36:00.531 13722-14030/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 14030 (Loop thread: ne), pid 13722 (g.atalk.android)
2021-06-05 07:36:00.713 13722-13973/org.atalk.android V/aTalk: [690] net.sf.fmj.media.rtp.RTCPReporter.run() RTCP reporting for running again after 5537.440253252016 ms.
2021-06-05 07:36:01.128 14037-14037/? A/DEBUG: pid: 13722, tid: 14030, name: Loop thread: ne >>> org.atalk.android <<<
2021-06-05 07:36:01.130 14037-14037/? A/DEBUG: #00 pc 001a4380 /data/app/org.atalk.android-KzGVliiNZBg81gc261FLzQ==/lib/x86/libjnvpx.so (BuildId: 45e152dc213e6fe7be6ac2d7d5706f4a9baa724b)
2021-06-05 07:36:01.261 14037-14037/? I/crash_dump32: type=1400 audit(0.0:1026): avc: denied { open } for path="/dev/__properties__/u:object_r:hwservicemanager_prop:s0" dev="tmpfs" ino=8398 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:hwservicemanager_prop:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 07:36:01.273 14037-14037/? I/crash_dump32: type=1400 audit(0.0:1028): avc: denied { read } for name="libwebviewchromium32.relro" dev="sdb2" ino=105 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:shared_relro_file:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 07:36:01.301 14037-14037/? I/crash_dump32: type=1400 audit(0.0:1031): avc: denied { open } for path="/dev/__properties__/u:object_r:device_config_runtime_native_prop:s0" dev="tmpfs" ino=8385 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:device_config_runtime_native_prop:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 07:36:01.531 13722-14033/org.atalk.android D/EGL_emulation: eglCreateContext: 0xc6360d60: maj 1 min 0 rcv 1
2021-06-05 07:36:01.531 13722-13722/org.atalk.android W/g.atalk.androi: Long monitor contention with owner GLThread 747 (14033) at void java.lang.Object.wait(long, int)(Object.java:-2) waiters=0 in void android.opengl.GLSurfaceView$GLThread.requestRenderAndNotify(java.lang.Runnable) for 464ms
2021-06-05 07:36:01.301 14037-14037/? I/crash_dump32: type=1400 audit(0.0:1032): avc: denied { getattr } for path="/dev/__properties__/u:object_r:device_config_runtime_native_prop:s0" dev="tmpfs" ino=8385 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:device_config_runtime_native_prop:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 07:36:02.010 13722-14033/org.atalk.android D/jnawtrenderer: JAWTRenderer_paint:244: GL_EXTENSIONS= GL_EXT_debug_marker GL_EXT_robustness GL_OES_blend_func_separate GL_OES_blend_equation_separate GL_OES_blend_subtract GL_OES_byte_coordinates GL_OES_compressed_paletted_texture GL_OES_point_size_array GL_OES_point_sprite GL_OES_single_precision GL_OES_stencil_wrap GL_OES_texture_env_crossbar GL_OES_texture_mirored_repeat GL_OES_EGL_image GL_OES_element_index_uint GL_OES_draw_texture GL_OES_texture_cube_map GL_OES_draw_texture GL_OES_framebuffer_object GL_OES_depth24 GL_OES_depth32 GL_OES_fbo_render_mipmap GL_OES_rgb8_rgba8 GL_OES_stencil1 GL_OES_stencil4 GL_OES_stencil8 GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_APPLE_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image_external_essl3 GL_OES_vertex_array_object GL_KHR_texture_compression_astc_ldr ANDROID_EMU_gles_max_version_3_1
2021-06-05 07:36:02.675 13722-14003/org.atalk.android W/AudioTrack: restartIfDisabled(43): releaseBuffer() track 0xc884e900 disabled due to previous underrun, restarting
2021-06-05 07:36:02.874 626-14046/system_process W/ActivityTaskManager: Force finishing activity org.atalk.android/.gui.call.VideoCallActivity
2021-06-05 07:36:03.475 626-724/system_process W/InputDispatcher: channel '68e66e4 org.atalk.android/org.atalk.android.gui.call.VideoCallActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x9


============ aTalk logcat instace #2 ==========
--------- beginning of crash
2021-06-05 08:03:46.969 15858-16204/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 16204 (Loop thread: ne), pid 15858 (g.atalk.android)
2021-06-05 08:03:47.075 15858-16205/org.atalk.android D/jnawtrenderer: JAWTRenderer_paint:244: GL_EXTENSIONS= GL_EXT_debug_marker GL_EXT_robustness GL_OES_blend_func_separate GL_OES_blend_equation_separate GL_OES_blend_subtract GL_OES_byte_coordinates GL_OES_compressed_paletted_texture GL_OES_point_size_array GL_OES_point_sprite GL_OES_single_precision GL_OES_stencil_wrap GL_OES_texture_env_crossbar GL_OES_texture_mirored_repeat GL_OES_EGL_image GL_OES_element_index_uint GL_OES_draw_texture GL_OES_texture_cube_map GL_OES_draw_texture GL_OES_framebuffer_object GL_OES_depth24 GL_OES_depth32 GL_OES_fbo_render_mipmap GL_OES_rgb8_rgba8 GL_OES_stencil1 GL_OES_stencil4 GL_OES_stencil8 GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_APPLE_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image_external_essl3 GL_OES_vertex_array_object GL_KHR_texture_compression_astc_ldr ANDROID_EMU_gles_max_version_3_1
2021-06-05 08:03:47.440 16210-16210/? A/DEBUG: pid: 15858, tid: 16204, name: Loop thread: ne >>> org.atalk.android <<<
2021-06-05 08:03:47.441 16210-16210/? A/DEBUG: #00 pc 001a4380 /data/app/org.atalk.android-KzGVliiNZBg81gc261FLzQ==/lib/x86/libjnvpx.so (BuildId: 45e152dc213e6fe7be6ac2d7d5706f4a9baa724b)
2021-06-05 08:03:47.442 15858-16141/org.atalk.android W/g.atalk.androi: JNI critical lock held for 43.974ms on Thread[103,tid=16141,Runnable,Thread*=0xc79b8600,peer=0x14386b58,"Loop thread: net.sf.fmj.media.parser.RawPullBufferParser$FrameTrack@6384122"]
2021-06-05 08:03:47.481 16210-16210/? I/crash_dump32: type=1400 audit(0.0:1263): avc: denied { open } for path="/dev/__properties__/u:object_r:hwservicemanager_prop:s0" dev="tmpfs" ino=8398 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:hwservicemanager_prop:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 08:03:47.489 16210-16210/? I/crash_dump32: type=1400 audit(0.0:1264): avc: denied { getattr } for path="/dev/__properties__/u:object_r:hwservicemanager_prop:s0" dev="tmpfs" ino=8398 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:hwservicemanager_prop:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 08:03:47.517 16210-16210/? I/crash_dump32: type=1400 audit(0.0:1265): avc: denied { read } for name="libwebviewchromium32.relro" dev="sdb2" ino=105 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:shared_relro_file:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 08:03:47.621 16210-16210/? I/crash_dump32: type=1400 audit(0.0:1268): avc: denied { open } for path="/dev/__properties__/u:object_r:device_config_runtime_native_prop:s0" dev="tmpfs" ino=8385 scontext=u:r:crash_dump:s0:c39,c256,c512,c768 tcontext=u:object_r:device_config_runtime_native_prop:s0 tclass=file permissive=1 app=org.atalk.android
2021-06-05 08:03:48.523 15858-16180/org.atalk.android W/AudioTrack: restartIfDisabled(65): releaseBuffer() track 0xe4ddee80 disabled due to previous underrun, restarting
2021-06-05 08:03:49.267 626-16218/system_process W/ActivityManager: Process org.atalk.android has crashed too many times: killing!
2021-06-05 08:03:49.267 626-16218/system_process W/ActivityTaskManager: Force finishing activity org.atalk.android/.gui.call.VideoCallActivity
2021-06-05 08:03:49.284 626-16218/system_process W/ActivityTaskManager: Force finishing activity org.atalk.android/.gui.aTalk

Attachments:
vpx_jni.c 20.5 KB
Packetizer.java 3.9 KB
VP9Encoder.java 16.1 KB
VPX.java 32.0 KB

[cmeng… via monorail]

Comment #28 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c28

Back to testing on real device Samsung Note 10:

Below is the new aTalk logcat after cleaning up the fprintf(...) statements in the below 3 files, you may make reference to the files where the fprintf's are being inserted; A dump of the wb->bit_buffer data seems the write_uncompressed_header and write_compressed_header are ok include the video frame size.

However based on the online document i.e.
http://downloads.webmproject.org/docs/vp9/vp9-bitstream_superframe-and-uncompressed-header_v1.0.pdf
found that the write_uncompressed_header() does not have the else statement (see below); not sure if any bit need to be written into the uncompressed header when cm->error_resilient_mode is set as per aTalk vp9 encode setting.

if (!error_resilient_mode) {
refresh_frame_context u(1)
frame_parallel_decoding_mode u(1)
} else {
refresh_frame_context = 0
frame_parallel_decoding_mode = 1
}

// ================ aTalk logcat ===================
2021-06-05 10:44:33.916 11331-14562/org.atalk.android D/(VP9Encoder.java:168)#doOpen: VP9 encode video size: [width=480, height=720]
2021-06-05 10:44:34.174 11331-14562/org.atalk.android D/vpx_jni: VPX encode using: WebM Project VP9 Encoder v1.10.0
2021-06-05 10:44:34.191 11331-14562/org.atalk.android D/(VP9Encoder.java:216)#doOpen: VP9 encoder opened successfully
2021-06-05 10:44:34.246 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write()
2021-06-05 10:44:34.262 11331-14466/org.atalk.android V/aTalk: [182620] net.sf.fmj.media.rtp.RTCPReporter.run() RTCP reporting for running again after 4562.258716338411 ms.
2021-06-05 10:44:34.281 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2021-06-05 10:44:34.312 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@4a986c7
2021-06-05 10:44:34.339 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder@82934f4
2021-06-05 10:44:34.367 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() format: YUV Video Format: Size = [width=480, height=720] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2021-06-05 10:44:34.387 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder@82934f4
2021-06-05 10:44:34.405 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp9.Packetizer@66141d
2021-06-05 10:44:34.424 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() format: VP9, 480x720, FrameRate=2.0
2021-06-05 10:44:34.442 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp9.Packetizer@66141d
2021-06-05 10:44:34.459 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() connects to: com.sun.media.multiplexer.RTPSyncBufferMux@1059692
2021-06-05 10:44:34.474 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write() format: VP9/RTP
2021-06-05 10:44:34.490 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.write()
2021-06-05 10:44:34.512 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.profile() Profile: graph building: 799 ms
2021-06-05 10:44:34.524 11331-14562/org.atalk.android D/aTalk: [182650] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 1 ms
2021-06-05 10:44:34.575 11331-14321/org.atalk.android I/(TransportManager.java:413)#sendHolePunchPacket: Send NAT hole punch packets to port for media: VIDEO
2021-06-05 10:44:34.590 11331-14321/org.atalk.android D/(CallPeerMediaHandlerJabberImpl.java:1121)#processContent: ### Process media content for: sender = both: video => MediaStreamTarget with dataAddress 192.168.1.37:44753/udp and controlAddress 192.168.1.37:44753/udp
2021-06-05 10:44:34.606 11331-14589/org.atalk.android D/vpx_jni: VP9 cx_data_sz: 1036800; ctx->cx_data_sz/2: 518400;
vp9_get_compressed_data #1; cm->show_frame: 1 cm->new_fb_idx: 0
vp9_get_com
2021-06-05 10:44:34.606 11331-14589/org.atalk.android D/vpx_jni: pressed_data #2 (One pass encode); cpi->use_svc: 0
encode_frame_to_data_rate; frame_flags: 0x0000; show_existing_frame: 1
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: encode_frame_to_data_rate #2; KEY_FRAME: 1; dest: 0x00; size: 0
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: Framee width: 480(0x01df); height: 720(0x02cf)
vp9_pack_bitstream; uncompressed_hdr_size: 18; first_part_size: 2
vp9_pack_bitst
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: ream; wb->bit_buffer (20):83 49 83 42 00 1d f0 2c f0 00 e0 90 70
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: 60 00 40
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: 00 40 00
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: 00
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: encode_tiles_mt #1; num_worker: 0
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: encode_tiles_mt #2
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: write_mode_b => tok: 446116761680; tok_end; 446116761680
2021-06-05 10:44:34.617 11331-14589/org.atalk.android D/vpx_jni: vp9/encoder/vp9_bitstream.c:402: assertion "*tok < tok_end" failed

--------- beginning of crash
2021-06-05 10:44:34.618 11331-14616/org.atalk.android A/libc: vp9/encoder/vp9_bitstream.c:402: assertion "*tok < tok_end" failed

Attachments:
vp9_cx_iface.c 78.8 KB
vp9_bitstream.c 49.8 KB
vp9_encoder.c 298 KB

[cmeng… via monorail]

Comment #29 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c29

I believe the problem is not due to incorrect frame data input for vp9 encode. I have captured both the frame data during vp8 and vp9 encode as shown below. Both are in YUV420 and indicated a correct buffer size for frame size of 480x720 => 518400. I believe you can use stream data from an online media file.

If the vp9 encode fault is not because of encoder configuration setting, the problem may be when libvpx is operated under android OS environment.
If you would like to test libvpx using aTalk, please let me known. I need to release some source update to gitbub, and provide you a brief instruction on how to build aTalk for testing.

// ================= frame data for vpx encode ==============
2021-06-05 12:19:28.070 12512-15242/org.atalk.android D/(VP8Encoder.java:251)#doProcess: VP8: Encoding a frame #0: 56555651 4B2E282C 2E2A2A29 2C292422 1F1F1E24 313C4845 45454749 4A4A4D54 size: 518400
2021-06-05 12:19:28.113 12512-15242/org.atalk.android D/(VP8Encoder.java:251)#doProcess: VP8: Encoding a frame #1: 5C5B5A56 4D392B2F 31303030 2E2A2326 21202427 31454C49 4F4C4B4D 4D4D5059 size: 518400
2021-06-05 12:19:28.139 12512-15242/org.atalk.android D/(VP8Encoder.java:251)#doProcess: VP8: Encoding a frame #2: 66615F5A 593B2D33 32332F34 312D2D2D 2724242D 3A484B4E 4F505054 5455565C size: 518400
2021-06-05 12:19:28.171 12512-15242/org.atalk.android D/(VP8Encoder.java:251)#doProcess: VP8: Encoding a frame #3: 68636262 5D3A3033 35323233 32302D2A 2723232B 3C485355 54575757 56595C61 size: 518400
2021-06-05 12:19:28.195 12512-15242/org.atalk.android D/(VP8Encoder.java:251)#doProcess: VP8: Encoding a frame #4: 66676461 61472731 35353534 34302D2D 2C232631 404F5A57 54595754 585B5960 size: 518400

2021-06-05 12:53:22.426 14964-26816/org.atalk.android D/(VP9Encoder.java:275)#doProcess: VP9: Encoding a frame #1: 61605A56 54462E30 322E2E2C 2B282627 242D3740 524D4849 48494B4C 4F504C59 size: 518400
2021-06-05 12:53:22.452 14964-26816/org.atalk.android D/(VP9Encoder.java:275)#doProcess: VP9: Encoding a frame #2: 635E5D5D 56473430 3032302D 2B292322 2529343F 47484E49 4A484C4D 4E4F5358 size: 518400
2021-06-05 12:53:22.483 14964-26816/org.atalk.android D/(VP9Encoder.java:275)#doProcess: VP9: Encoding a frame #3: 605E5D58 59462B32 3033322E 2B2A2422 232A3443 494B4948 48484B4E 4E4D4C58 size: 518400
2021-06-05 12:53:22.528 14964-26816/org.atalk.android D/(VP9Encoder.java:275)#doProcess: VP9: Encoding a frame #4: 655F5C5C 57473531 3234332B 2C2A2325 26283142 4F4A4646 4A4A4A4A 4F4E4E4E size: 518400
2021-06-05 12:53:22.560 14964-26816/org.atalk.android D/(VP9Encoder.java:275)#doProcess: VP9: Encoding a frame #5: 605D5F5B 53492934 37332A2F 2A262628 222B2E40 4A494945 4E4A4949 504F4B54 size: 518400

[cmeng… via monorail]

Comment #30 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c30

Following are the observations with more fprintf() statements inserted into the vp9_bitstream.c file as attached; this is to understand the process of frame encoding. With the two inserted fprintf() statements in function write_mode(), it was found that the function did completed the iteration over rows and cols of the input frame, as it printed the inserted statement i.e.:
encode_tiles_mt #3 tile_col: 2;
before it failed again.

However I realized that the row/col loop-ends are not the frame actual width and length, but divided by MI_BLOCK_SIZE i.e. 8 (the frame size is 480x720).
Not sure if this is correct.

I also observed that if I commented out the two fprintf() statements in the write_modes() function, then it will not print
encode_tiles_mt #3 tile_col: 2; but end with assertion error as before i.e.
2021-06-06 09:55:52.846 29296-31824/org.atalk.android D/vpx_jni: bitstream.c:402: assertion "*tok < tok_end" failed

Not sure if the above observation is due to function re-entry because of a race condition during the iteration.

// =============== aTalk logcat in vp9_bitstream#wirite_modes ============
2021-06-06 09:38:05.145 15016-24763/org.atalk.android D/vpx_jni: Frame width: 480(0x01df); height: 720(0x02cf)

vp9_pack_bitstream; uncompressed_hdr_size: 18; first_part_size: 2

vp9_pack_bitstream; wb->bit_buffer (20):83 49 83 42 00 1d f0 2c f0 00 e0 90 70 60 00 40 00 40 00 00
2021-06-06 09:38:05.145 15016-24763/org.atalk.android D/vpx_jni: encode_tiles_mt #1; num_worker: 0
2021-06-06 09:38:05.145 15016-24763/org.atalk.android D/vpx_jni: encode_tiles_mt #2
mi_row: 0; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 8; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 16; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 24; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 32; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 40; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 48; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 56; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 64; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 72; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 80; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

mi_row: 88; mi_row_end: 90;
mi_col: 32; tile->mi_col_end: 60
mi_col: 40; tile->mi_col_end: 60
mi_col: 48; tile->mi_col_end: 60
mi_col: 56; tile->mi_col_end: 60

encode_tiles_mt #3 tile_col: 2

2021-06-06 09:38:05.147 15016-24763/org.atalk.android D/vpx_jni: mi_row: 0; mi_row_end: 90;
mi_col: 0; tile->mi_col_end: 32
mi_col: 8; tile->mi_col_end: 32
mi_col: 16; tile->mi_col_end: 32
mi_col: 24; tile->mi_col_end: 32

2021-06-06 09:38:05.686 1027-1133/? I/WindowManager: Reparenting to original parent: Surface(name=ActivityRecord{76a5f58 u0 org.atalk.android/.gui.call.VideoCallActivity t50586})/@0x76798b1, destroy=true, surface=Surface(name=baa1c46 org.atalk.android/org.atalk.android.gui.call.VideoCallActivity)/@0x823fb40
2021-06-06 09:38:05.687 1027-1133/? I/SurfaceControl: release : mNativeObject = 486793180096 - Surface(name=Surface(name=baa1c46 org.atalk.android/org.atalk.android.gui.call.VideoCallActivity)/@0x823fb40 - animation-leash)/@0xded8b6c / android.view.SurfaceControl$Transaction.remove:3449 com.android.server.wm.SurfaceAnimator.removeLeash:418 com.android.server.wm.SurfaceAnimator.reset:384 com.android.server.wm.SurfaceAnimator.lambda$getFinishedCallback$0$SurfaceAnimator:110
2021-06-06 09:38:05.690 642-1026/? I/Layer: id=158875 removeFromCurrentState Surface(name=baa1c46 org.atalk.android/org.atalk.android.gui.call.VideoCallActivity)/@0x823fb40 - animation-leash#0 (128)
2021-06-06 09:38:05.691 642-1694/? I/SurfaceFlinger: id=158875 Removed Surface(name=baa1c46 org.atalk.android/org.atalk.android.gui.call.VideoCallActivity)/@0x823fb40 - animation-leash#0 (128)
2021-06-06 09:38:05.703 642-642/? I/Layer: id=158875[1] Destroyed Surface(name=baa1c46 org.atalk.android/org.atalk.android.gui.call.VideoCallActivity)/@0x823fb40 - animation-leash#0
2021-06-06 09:38:05.721 12417-27291/org.atalk.android D/AudioTrack: stop(17919): called with 4222 frames delivered
2021-06-06 09:38:06.005 12417-27532/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 27532 (Loop thread: ne), pid 12417 (g.atalk.android)
2021-06-06 09:38:06.204 27660-27660/? A/DEBUG: pid: 12417, tid: 27532, name: Loop thread: ne >>> org.atalk.android <<<
2021-06-06 09:38:06.205 27660-27660/? A/DEBUG: #00 pc 0000000000129518 /data/app/~~5TBtyPuNVDvKZVyvqLZblA==/org.atalk.android-UVrrlYKcZ4OXBLYXq79GWA==/lib/arm64/libjnvpx.so (BuildId: 5ca130205d8969742c2a2f008e2e02e3e8a6522d)
2021-06-06 09:38:06.228 12417-27380/org.atalk.android D/aTalk: [190843] net.sf.fmj.media.Log.comment() Computed latency for video: 31 ms
2021-06-06 09:38:06.632 12417-27135/org.atalk.android I/aTalk: [190765] org.ice4j.ice.Agent.log() ICE state changed from Completed to Terminated. Local ufrag 9usk21f7fg2o2b
2021-06-06 09:38:06.936 1027-6773/? W/ActivityManager: Missing app error report, app = org.atalk.android crashing = true notResponding = false
2021-06-06 09:38:06.947 1027-27888/? W/ActivityManager: crash : org.atalk.android,10319
2021-06-06 09:38:06.951 1027-27888/? W/ActivityTaskManager: Force finishing activity org.atalk.android/.gui.call.VideoCallActivity

Attachments:
vp9_bitstream.c 50.1 KB

[cmeng… via monorail]

Comment #31 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c31

Found that aTalk also crashes when libvpx vp9_encoder is allowed to proceed to execute vp9_compute_frame_low_motion(cpi); as shown below:

static void encode_frame_to_data_rate(
...
if (oxcf->pass == 0 && !frame_is_intra_only(cm) &&
(!cpi->use_svc ||
(cpi->use_svc &&
!cpi->svc.layer_context[cpi->svc.temporal_layer_id].is_key_frame &&
cpi->svc.spatial_layer_id == cpi->svc.number_spatial_layers - 1))) {
vp9_compute_frame_low_motion(cpi);
}
}

Within the function vp9_ratectrl#vp9_compute_frame_low_motion(cpi), it too iterates over row/col; the problem again seems to be a race condition/call synchronous problem in the for 'col' loop.

// ============= aTalk crashes during vp9_compute_frame_low_motion(cpi) =======
2021-06-07 13:09:40.466 13086-15536/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8 in tid 15536 (Loop thread: ne), pid 13086 (g.atalk.android)
2021-06-07 13:09:40.627 15603-15603/? A/DEBUG: pid: 13086, tid: 15536, name: Loop thread: ne >>> org.atalk.android <<<
2021-06-07 13:09:40.628 15603-15603/? A/DEBUG: #00 pc 0000000000067c3c /data/app/~~ao0ZOeFpRegMbO83Wu48AQ==/org.atalk.android-JOvZFUqD4P34OkLh808rUQ==/lib/arm64/libjnvpx.so (vp9_compute_frame_low_motion+176) (BuildId: f83ace734dcb662ebeaa86e18cb5bfbe603e5027)

[jz… via monorail]

Comment #32 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c32

> For the sample stream, I am not sure how to capture and save the stream in
> valid media format. The data media stream is streamed/converted to YUV420
> from the camera, with the help of ffmpeg. The stream packets are then
> submitted to libvpx for encoding.

The libvpx tools can work with raw yuv files or you can convert one to y4m using ffmpeg. You only need to dump the Y, U and V planes in that order to a file to create it keeping note of the video dimensions.

[cmeng… via monorail]

Comment #33 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c33

Attached below is the raw data captured on aTalk during VP9Encoder#doProcess() call; The file contains a total of 25 frames in yuv420 format at a resolution of 480x720 or frame size is 518400. i.e camera in portrait mode.

Below is the small routine that I used; not sure it this is correct.

// =================
The routine used to save the inputBuffer data:
protected int doProcess(Buffer inputBuffer, Buffer outputBuffer)
{
.......
if (frameCount < 25) {
if (fos != null) {
try {
fos.write((byte[]) inputBuffer.getData());
Timber.d("VP9: Encoding a frame #%s: %s %s", frameCount, bytesToHex((byte[]) inputBuffer.getData(), 32), inputBuffer.getLength());
if (frameCount == 24) {
fos.close();
Timber.d("File fos write completed:");
}
} catch (IOException e) {
Timber.e("fos write exception: %s", e.getMessage());
}
}
}
..............
}

Attachments:
yuv420_480x720.jpg 12.4 MB

[cmeng… via monorail]

Comment #34 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c34

Inserted at end shows the aTalk logcat with the changes made to vp9_bitstream.c (attached)
According to vpx_thread.h i.e. VPxWorkerInterface declaration

typedef struct {
// Must be called first, before any other method.
void (*init)(VPxWorker *const worker);
....
} VPxWorkerInterface;

So I inserted the required statement i.e.

static size_t encode_tiles_mt(VP9_COMP *cpi, uint8_t *data_ptr) {

....

if (i < num_workers - 1) {

winterface->init(worker); // inserted the init statement
winterface->launch(worker);
fprintf(stderr, "encode_tiles_mt #1; num_workers: %d; i: %d\n", num_workers, i);
} else {
winterface->execute(worker);
fprintf(stderr, "encode_tiles_mt #2; i: %d\n", i);
}
.......
}

This seems to have resolved the earlier assertion error i.e.

2021-06-06 09:55:52.846 29296-31824/org.atalk.android D/vpx_jni: bitstream.c:402: assertion "*tok < tok_end" failed

/-----------------
Further tracing found that aTalk crashes again on another vp9_bitstream execution location i.e.
partition = partition_lookup[bsl][m->sb_type];

From he fprintf statement,
fprintf(stderr, "\nwrite_modes_sb #0; bsl: %d; m-sbType: %lu;\n", bsl, m);
it seems that m pointer is assigned a null from:
m = cm->mi_grid_visible[mi_row * cm->mi_stride + mi_col];

This causes aTalk to crash due to m->sb_type access; I am unable to find the location where mi_grid_visible[] is being initialized.

// =====
static void write_modes_sb(
VP9_COMP *cpi, MACROBLOCKD *const xd, const TileInfo *const tile,
vpx_writer *w, TOKENEXTRA **tok, const TOKENEXTRA *const tok_end,
int mi_row, int mi_col, BLOCK_SIZE bsize,
unsigned int *const max_mv_magnitude,
int interp_filter_selected[MAX_REF_FRAMES][SWITCHABLE]) {


if (mi_row >= cm->mi_rows || mi_col >= cm->mi_cols) return;

.....
m = cm->mi_grid_visible[mi_row * cm->mi_stride + mi_col];

fprintf(stderr, "\nwrite_modes_sb #0; bsl: %d; m-sbType: %lu;\n", bsl, m);
partition = partition_lookup[bsl][m->sb_type];
fprintf(stderr, "write_modes_sb #01; partition: %d\n", partition);

.....
}
===/

// ============= aTalk logcat with attached vp9_bitstream.c ==============
2021-06-13 06:32:58.804 3103-24254/org.atalk.android D/vpx_jni: VP9 cx_data_sz: 1036800; ctx->cx_data_sz/2: 518400;

vp9_get_compressed_data #1; cm->show_frame: 1 cm->new_fb_idx: 0

vp9_get_compressed_data #2 (One pass encode); cpi->use_svc: 0

encode_frame_to_data_rate; frame_flags: 0x0000; show_existing_frame: 1

2021-06-13 06:32:58.820 3103-24254/org.atalk.android D/vpx_jni: encode_frame_to_data_rate #1; KEY_FRAME: 1; dest: 0x00; size: 0
2021-06-13 06:32:58.820 3103-24254/org.atalk.android D/vpx_jni: Frame width: 480(0x01df); height: 720(0x02cf)

vp9_pack_bitstream; uncompressed_hdr_size: 18; first_part_size: 2
vp9_pack_bitstream; wb->bit_buffer (20):83 49 83 42 00 1d f0 2c f0 00 e0 90 70 60 00 40 00 40 00 00

2021-06-13 06:32:58.821 3103-24254/org.atalk.android D/vpx_jni: encode_tiles_mt #1; num_workers: 2; i: 0
mi_row: 0; mi_row_end: 90; mi_col_end: 60; mi_col:32,
write_modes_sb #0; bsl: 4; m-sbType: 0;
2021-06-13 06:32:59.063 3103-24272/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 24272 (Loop thread: ne), pid 3103 (g.atalk.android)
2021-06-13 06:32:59.152 3103-24195/org.atalk.android D/aTalk: [248024] net.sf.fmj.media.Log.comment() RTP video buffer size: 93 pkts, 99176 bytes.
2021-06-13 06:32:59.239 24307-24307/? A/DEBUG: pid: 3103, tid: 24272, name: Loop thread: ne >>> org.atalk.android <<<
2021-06-13 06:32:59.242 24307-24307/? A/DEBUG: #00 pc 000000000012852c /data/app/~~yantpdaetuDmYYpdmFWqgA==/org.atalk.android-jZvETKOaRHRAVjWfUwkjug==/lib/arm64/libjnvpx.so (BuildId: f8ba2fdb68cb76d7a5865d344e5292dc5ad8eb75)

Attachments:
vp9_bitstream.c 50.6 KB

[jz… via monorail]

Updates:
Labels: -Needs-Feedback

Comment #35 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c35

Jerome can you take a closer look at comment #33 and #34?

[ji… via monorail]

Comment #36 on issue 1703 by ji...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c36

Hi,

I'm looking at the codec settings here[1] and you may have some settings missing:

- cfg.g_threads is not set (I noticed you already have a setter defined). To better debug it should be set to 1
- You used lossless mode. For realtime video application you should not use lossless mode.
- cfg.g_lag_in_frames should be set to 0
- You should use codec control VP8E_SET_CPUUSED to set speed >= 7 for realtime video application

Also,

when the crash in comment #34 happens, what's the value of mi_row, cm->mi_stride and mi_col? This will help us determine what goes wrong there.

[1]https://github.com/cmeng-git/atalk-android/blob/bb4d6702ea954fac350698eb63e5fe027015620d/aTalk/src/main/java/org/atalk/impl/neomedia/codec/video/vp9/VP9Encoder.java#L192

[cmeng… via monorail]

Comment #37 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c37

Thanks for the update: I have changed aTalk source as per recommended i.e.

- cfg.g_threads is set to 1
- Disabled use of lossless mode. For realtime video application you should not use lossless mode.
- cfg.g_lag_in_frames is set to 0
- codec control VP8E_SET_CPUUSED to set speed = 7 for realtime video application

Since aTalk v2.6.1, it has moved the development to based on the latest libvpx release i.e. v1.10.0.

After the above changes, I was facing a new strange problem. The problem seems not related to the above changes.
Actually there were some changes to the development environments since my last test; not sure if any of the following is causing the observed problems.

a. Recently I have just upgraded android studio from v4.2.1 to v4.2.2
b. Rebuild Conversations based on latest master source
c. My Note10 device has been upgraded with new security patch.

The observed problem is as shown in the below aTalk logcat during vpx encoder init i.e. ABI version mismatch 25 != 24:

// ----------------------------------
2021-07-03 06:04:40.686 23958-25050/org.atalk.android D/vpx_jni: VP9 vpx_codec_enc_init_ver: ver = 25 (VPX_ENCODER_ABI_VERSION = 24)

--------- beginning of crash
2021-07-03 06:04:40.687 23958-25049/org.atalk.android E/AndroidRuntime: FATAL EXCEPTION: FMJ Thread: net.sf.fmj.media.ProcessEngine@f177b4b[ net.sf.fmj.media.ProcessEngine@f177b4b ] ( realizeThread)
Process: org.atalk.android, PID: 23958
java.lang.RuntimeException: Failed to initialize encoder, libvpx error:
ABI version mismatch
at org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder.doOpen(VP9Encoder.java:207)
at org.atalk.impl.neomedia.codec.AbstractCodec2.open(AbstractCodec2.java:360)
at net.sf.fmj.media.BasicFilterModule.doRealize(BasicFilterModule.java:82)
at net.sf.fmj.media.PlaybackEngine.buildTrackFromGraph(PlaybackEngine.java:579)
at net.sf.fmj.media.ProcessEngine$ProcGraphBuilder.buildTrackFromGraph(ProcessEngine.java:262)
at net.sf.fmj.media.ProcessEngine$ProcGraphBuilder.buildCustomGraph(ProcessEngine.java:239)
at net.sf.fmj.media.ProcessEngine$ProcGraphBuilder.buildGraph(ProcessEngine.java:252)
at net.sf.fmj.media.ProcessEngine$ProcTControl.buildTrack(ProcessEngine.java:688)
at net.sf.fmj.media.PlaybackEngine.doRealize1(PlaybackEngine.java:1135)
at net.sf.fmj.media.ProcessEngine.doRealize(ProcessEngine.java:1197)
at net.sf.fmj.media.RealizeWorkThread.process(BasicController.java:1145)
at net.sf.fmj.media.StateTransitionWorkThread.run(BasicController.java:1224)
2021-07-03 06:04:40.687 23958-25049/org.atalk.android E/(UtilActivator.java:90)#uncaughtException: An uncaught exception occurred in thread = Thread[FMJ Thread: net.sf.fmj.media.ProcessEngine@f177b4b[ net.sf.fmj.media.ProcessEngine@f177b4b ] ( realizeThread),9,system] and message was: Failed to initialize encoder, libvpx error:
ABI version mismatch
java.lang.RuntimeException: Failed to initialize encoder, libvpx error:
ABI version mismatch
at org.atalk.impl.neomedia.codec.video.vp9.VP9Encoder.doOpen(VP9Encoder.java:207)
at org.atalk.impl.neomedia.codec.AbstractCodec2.open(AbstractCodec2.java:360)
at net.sf.fmj.media.BasicFilterModule.doRealize(BasicFilterModule.java:82)
at net.sf.fmj.media.PlaybackEngine.buildTrackFromGraph(PlaybackEngine.java:579)
at net.sf.fmj.media.ProcessEngine$ProcGraphBuilder.buildTrackFromGraph(ProcessEngine.java:262)
at net.sf.fmj.media.ProcessEngine$ProcGraphBuilder.buildCustomGraph(ProcessEngine.java:239)
at net.sf.fmj.media.ProcessEngine$ProcGraphBuilder.buildGraph(ProcessEngine.java:252)
at net.sf.fmj.media.ProcessEngine$ProcTControl.buildTrack(ProcessEngine.java:688)
at net.sf.fmj.media.PlaybackEngine.doRealize1(PlaybackEngine.java:1135)
at net.sf.fmj.media.ProcessEngine.doRealize(ProcessEngine.java:1197)
at net.sf.fmj.media.RealizeWorkThread.process(BasicController.java:1145)
at net.sf.fmj.media.StateTransitionWorkThread.run(BasicController.java:1224)

// ---------------------------------

Then I moved to use the libvpx master source i.e.
https://github.com/webmproject/libvpx/archive/refs/tags/v1.10.0-94-g350b0b47f.tar.gz

The above problem is resolved with the above new master source.
However I still need to make the changes to the new source as commented previously i.e. add winterface->init(worker);
Otherwise Fatal signal 11 (SIGSEGV) will be thrown.

// ------------------------

static size_t encode_tiles_mt(VP9_COMP *cpi, uint8_t *data_ptr) {
....
if (i < num_workers - 1) {
winterface->init(worker); // inserted the init statement
winterface->launch(worker);
fprintf(stderr, "encode_tiles_mt #1; num_workers: %d; i: %d\n", num_workers, i);
} else {
winterface->execute(worker);
fprintf(stderr, "encode_tiles_mt #2; i: %d\n", i);
}
.......
}

// --------------------

Your new proposed changes i.e.
- cfg.g_threads is set to 1
- VP8E_SET_CPUUSED = 7

The two changes above has made vpx encoding working; Conversations can now display the received vp9 stream. But the encoding frame rate is very very slow. Take a few seconds for camera changes to appear on Conversations.

However now the vpx decoder is not working any more. The decoded is closed after is was opened successfully, due to some internal error as reported by ffmpeg
Not sure if this is due to test environment changes above.

// ------------------------

2021-07-03 08:41:02.423 14197-15736/org.atalk.android D/(VP9Decoder.java:104)#doClose: Closing decoder
java.lang.Exception
at org.atalk.impl.neomedia.codec.video.vp9.VP9Decoder.doClose(VP9Decoder.java:104)
at org.atalk.impl.neomedia.codec.AbstractCodec2.close(AbstractCodec2.java:271)
at net.sf.fmj.media.BasicFilterModule.doClose(BasicFilterModule.java:58)
at net.sf.fmj.media.PlaybackEngine.doClose(PlaybackEngine.java:793)
at net.sf.fmj.media.BasicController.close(BasicController.java:223)
at net.sf.fmj.media.PlaybackEngine.internalErrorOccurred(PlaybackEngine.java:1755)
at net.sf.fmj.media.BasicFilterModule.process(BasicFilterModule.java:281)
at net.sf.fmj.media.BasicModule.connectorPushed(BasicModule.java:133)
at net.sf.fmj.media.BasicOutputConnector.writeReport(BasicOutputConnector.java:131)
at net.sf.fmj.media.SourceThread.process(BasicSourceModule.java:692)
at net.sf.fmj.media.util.LoopThread.run(LoopThread.java:85)
// --------------------------

aTalk is also facing another serious problem with system crashes very frequently during testing. Not sure what is the root cause of the problem.
Need further investigations.

By the way, Is cfg.g_threads = 1 is meant for debug, and can be omitted in final aTalk release.

// ---------------------------
2021-07-03 07:15:21.353 16900-18223/org.atalk.android D/vpx_jni: [0703/071521.346266:ERROR:elf_dynamic_array_reader.h(61)] tag not found

--------- beginning of crash
2021-07-03 07:15:21.375 16900-18240/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2 in tid 18240 (Loop thread: ne), pid 16900 (g.atalk.android)
2021-07-03 07:15:21.544 18278-18278/? A/DEBUG: pid: 16900, tid: 18240, name: Loop thread: ne >>> org.atalk.android <<<
2021-07-03 07:15:21.545 18278-18278/? A/DEBUG: #00 pc 0000000000131870 /data/app/~~6mcej_Yqq5SNjBldxsMioA==/org.atalk.android-OkWaH1vR0Z1E8WyltUHWEA==/lib/arm64/libjnvpx.so (vp9_encode_frame+2184) (BuildId: 0c77856520dbfcab1a79d8bc6103f38eadae62ef)

// ------------------

[cmeng… via monorail]

Comment #38 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c38

Revert to use libvpx v1.10.0 release source. To resolve the problem of 'ABI version mismatch'; I have to patch the vpx_encoder.h file i.e.

// --------------------------
/*!\brief Current ABI version number
*
* \internal
* If this file is altered in any way that changes the ABI, this value
* must be bumped. Examples include, but are not limited to, changing
* types, removing or reassigning enums, adding/removing/rearranging
* fields to structures
*/
#define VPX_ENCODER_ABI_VERSION \
(15 + VPX_CODEC_ABI_VERSION + \
VPX_EXT_RATECTRL_ABI_VERSION) /**<\hideinitializer*/

----------------------- //

After the above patches, it is verified that libvpx encoder is also working on v1.10.0 release, with your earlier proposed changes i.e.

- cfg.g_threads is set to 1
- VP8E_SET_CPUUSED = 7

Experimenting with setting cfg.g_threads to 0; then aTalk crashes start to appear.

ERROR:elf_dynamic_array_reader.h(61)] tag not found

Even after I return the cfg.g_threads value to '1', the above problem persists.
The only way to resolve the problem is to perform an android studio clean, after that it is working again.
Look like the problem is coming from android studio unable to detect and rebuild the changed file.
I have a similar build problem earlier due to the same AS problem.

However the libvpx decoder is not working as commented in my previous post.

[cmeng… via monorail]

Comment #39 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c39

Found the cause of the libvpx decoder problem. It is due to aTalk incorrect casting of a parameter during debug log message printing.
Both the libvpx decoder and encoder are now working on aTalk (with lib.

When making media call using two aTalk devices, the received video playback speed is OK. The problem of slow video encoding commented earlier is actually caused by Conversations.

After all the external noise under controlled, found that add winterface->init(worker); patch is not further required.
Hopefully this round observation is not again due to AS.

Thanks to all the libvpx team members for all the assistance rendered to me.

[cmeng… via monorail]

Comment #40 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c40

Need your advice on the following:

During a media call, when an android sender device is rotated i.e. from portrait to landscape, the aTalk vp9 encoded video width & height must be swapped to match the camera rotated stream data.

The following attached method is called when aTalk detected an orientation has changed. A similar routine is also used in the case when vp8 codec is deployed.
However it is fount, the called method will cause vp9 encoder hence aTalk to crash with
"scoped_ptrace_attach.cc(27)] ptrace: Operation not permitted"

Please advice what is the proper way to swamp video width & height while the vp9 encoder is running; without crashing the encoder.

// --------------
2021-07-05 12:38:45.504 2084-5925/org.atalk.android D/vpx_jni: [0705/123845.503533:ERROR:scoped_ptrace_attach.cc(27)] ptrace: Operation not permitted (1)
2021-07-05 12:39:09.478 2084-5868/org.atalk.android A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2 in tid 5868 (Loop thread: ne), pid 2084 (g.atalk.android)
2021-07-05 12:39:09.548 2084-5868/org.atalk.android A/libc: crash_dump helper failed to exec
---------//

// ----------- update encode video size ------
/**
* Updates the input width and height the encoder should expect.
* Re-initialize the encoder context. Needed when the input size changes.
*
* @param w new width
* @param h new height
*/
private void updateSize(int w, int h)
{
mWidth = w;
mHeight = h;
img = VPX.img_alloc(img, VPX.IMG_FMT_I420, mWidth, mHeight, 1);
if (img == 0)
throw new RuntimeException("Failed to re-initialize VP8 encoder");

if (cfg != 0) {
VPX.codec_enc_cfg_set_w(cfg, w);
VPX.codec_enc_cfg_set_h(cfg, h);
}

if (context != 0) {
VPX.codec_destroy(context);

int ret = VPX.codec_enc_init(context, INTERFACE, cfg, flags);
if (ret != VPX.CODEC_OK)
throw new RuntimeException("Failed to re-initialize VP9 encoder, libvpx error:\n"
+ VPX.codec_err_to_string(ret));

[ji… via monorail]

Comment #41 on issue 1703 by ji...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c41

I'd recommend to force a key frame in your case, when the frame size is changed. You can do so by passing the flag into the encoder[1]. The flag to force a key frame is VPX_EFLAG_FORCE_KF.

You don't need to re-initialize the encoder. But you'll need to change the config with the new frame width and height by calling vpx_codec_enc_config_set.

[1]https://chromium.googlesource.com/webm/libvpx/+/refs/heads/main/vpx/vpx_encoder.h#1019

[cmeng… via monorail]

Comment #42 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c42

Thanks for your input.
I implemented on aTalk VP9 encoder based on your recommendations, it is working.

However when I did the same for VP8 encoder, the proposed approach does not work. Still has to perform a vpx_codec_enc_init() (commented code) to get VP8 encoder to encode the changed resolution. aTalk throws an invalid parameter error message.

2021-07-16 09:45:39.969 8050-12606/org.atalk.android D/(VP8Encoder.java:233)#doProcess: VP8 encode video size changed: [width=720, height=1280]=>[width=1280, height=720]
2021-07-16 09:45:39.974 8050-12606/org.atalk.android W/(VP8Encoder.java:255)#doProcess: Failed to encode a frame: Invalid parameter

/**
* Updates the input width and height the encoder should expect.

* Force keyframe generation; needed when the input size changes.

*
* @param w new width
* @param h new height
*/
private void updateSize(int w, int h)
{
mWidth = w;
mHeight = h;
img = VPX.img_alloc(img, VPX.IMG_FMT_I420, mWidth, mHeight, 1);
if (img == 0)
throw new RuntimeException("Failed to re-initialize VP8 encoder");

if (cfg != 0) {
VPX.codec_enc_cfg_set_w(cfg, w);
VPX.codec_enc_cfg_set_h(cfg, h);
}

VPX.codec_enc_config_set(vpctx, cfg);
flags |= VPX.EFLAG_FORCE_KF;

// if (vpctx != 0) {
// VPX.codec_destroy(vpctx);
//
// int ret = VPX.codec_enc_init(vpctx, INTERFACE, cfg, flags);
// if (ret != VPX.CODEC_OK)
// throw new RuntimeException("Failed to re-initialize VP8 encoder, libvpx error:\n"
// + VPX.codec_err_to_string(ret));
// }
}

// ============================

When I used VP8 codec for aTalk media call in my android device SM-J730GM device,
android locat keep dumping the following warning messages; These warning message does not appear for SM-N975F (Note-10) i.e. with fast processor

2021-07-16 09:02:34.306 21260-22190/org.atalk.android W/g.atalk.androi: JNI critical lock held for 20.495ms on Thread[119,tid=22190,Runnable,Thread*=0xc5ca7200,peer=0x14acd490,"Loop thread: net.sf.fmj.media.parser.RawPushBufferParser$FrameTrack@90e3f48"]
2021-07-16 09:02:34.387 21260-22190/org.atalk.android W/g.atalk.androi: JNI critical lock held for 17.545ms on Thread[119,tid=22190,Runnable,Thread*=0xc5ca7200,peer=0x14acd490,"Loop thread: net.sf.fmj.media.parser.RawPushBufferParser$FrameTrack@90e3f48"]
2021-07-16 09:02:34.423 21260-22190/org.atalk.android W/g.atalk.androi: JNI critical lock held for 17.148ms on Thread[119,tid=22190,Runnable,Thread*=0xc5ca7200,peer=0x14acd490,"Loop thread: net.sf.fmj.media.parser.RawPushBufferParser$FrameTrack@90e3f48"]

There is no such warning messages when the VP9 codec is used. The warning messages persist even if I included the following setting in VP8 encode init routine.

// cfg.g_lag_in_frames should be set to 0 for realtime
VPX.codec_enc_cfg_set_lag_in_frames(cfg, 0);

// Must be enabled together with VP8E_SET_CPUUSED for realtime encode
VPX.codec_enc_cfg_set_threads(cfg, 1);

// Must be defined together with g_threads for realtime encode
VPX.codec_control(vpctx, VPX.VP8E_SET_CPUUSED, 7);

[cmeng… via monorail]

Comment #43 on issue 1703 by cmeng...@gmail.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c43

It seems that dynamic change of video resolution is not allowed/implemented in VP8 encoder, based on the aTalk logcat dump below:

2021-07-16 13:39:35.404 30405-31265/org.atalk.android D/(VP8Encoder.java:227)#doProcess: VP8 encode video size changed: [width=720, height=1280]=>[width=1280, height=720]
2021-07-16 13:39:35.425 30405-31265/org.atalk.android W/(VP8Encoder.java:249)#doProcess: Failed to encode a frame: Invalid parameter
2021-07-16 13:39:35.436 30405-31333/org.atalk.android D/vpx_jni: vp8e_set_config: 1280 x 720 (720 x 1280)
Cannot increase width or height larger than their initial values

// ========== vp8_cx_iface.c =============
static vpx_codec_err_t vp8e_set_config(vpx_codec_alg_priv_t *ctx,
const vpx_codec_enc_cfg_t *cfg) {
vpx_codec_err_t res;

fprintf(stderr, "vp8e_set_config: %d x %d (%d x %d)\n", cfg->g_w, cfg->g_h, ctx->cfg.g_w, ctx->cfg.g_h);

if (cfg->g_w != ctx->cfg.g_w || cfg->g_h != ctx->cfg.g_h) {
if (cfg->g_lag_in_frames > 1 || cfg->g_pass != VPX_RC_ONE_PASS) {
fprintf(stderr, "Cannot change width or height after initialization: %d %d\n", cfg->g_lag_in_frames, cfg->g_pass );
ERROR("Cannot change width or height after initialization");
}
if ((ctx->cpi->initial_width && (int)cfg->g_w > ctx->cpi->initial_width) ||
(ctx->cpi->initial_height && (int)cfg->g_h > ctx->cpi->initial_height)) {
fprintf(stderr, "Cannot increase width or height larger than their initial values\n");
ERROR("Cannot increase width or height larger than their initial values");
}
}

/* Prevent increasing lag_in_frames. This check is stricter than it needs
* to be -- the limit is not increasing past the first lag_in_frames
* value, but we don't track the initial config, only the last successful
* config.
*/
if ((cfg->g_lag_in_frames > ctx->cfg.g_lag_in_frames))
ERROR("Cannot increase lag_in_frames");

res = validate_config(ctx, cfg, &ctx->vp8_cfg, 0);

if (!res) {
ctx->cfg = *cfg;
set_vp8e_config(&ctx->oxcf, ctx->cfg, ctx->vp8_cfg, NULL);
vp8_change_config(ctx->cpi, &ctx->oxcf);
}

return res;

[jz… via monorail]

Updates:
Status: Done

Comment #44 on issue 1703 by jz...@google.com: libvpx 1.8.2 failed to decode or encode for vp9 but not vp8 in aTalk implementation
https://bugs.chromium.org/p/webm/issues/detail?id=1703#c44

> It seems that dynamic change of video resolution is not allowed/implemented in VP8 encoder, based on the aTalk logcat dump below:

Unlike VP9, you'd need to insert a keyframe to allow for the resolution to change.

I think the open issues from this bug have been addressed. If you have any additional questions you can contact webm-d...@webmproject.org or if you run into any new issues please feel free to file another bug.