androidmedia encoder problems

[Sebastian Dröge]

On So, 2014-02-09 at 08:38 +0800, cee1 wrote:
> 2014-02-09 3:05 GMT+08:00 Sebastian Dröge <sebastian at centricular.com>:
> > On Fr, 2014-02-07 at 20:28 +0800, cee1 wrote:
> >> 2014-02-04  <stic at free.fr>:
> >> > Hi Sebastian,
> >> >
> >> > as you previously said, do you think you will have soon some time to review this patch ?
> >> > That would be really so great because it is almost working well, there are just few things that I am not able to manage myself to make it better and more stable.
> >> > And I would really like to be able to use it.
> >> Hi,
> >>
> >> Back from vacation, go through the thread, I've some questions:
> >> 1. I don't find any settings of  stream-format in MediaFormat[1].
> >> Assuming the amcvideoenc(h264) generates stream in byte-stream format?
> >
> > It will output whatever the codec decides to output... we'll have to
> > check with different devices. But I would for now assume that it always
> > outputs byte-stream.
> >
> >> 2. We can get codec_data from csd-0 and csd-1 by a function similar as
> >> reassembleAVCC?
> >
> > That's what existing code using MediaCodec suggests, yes.
> >
> >> 2. The csd-0 and csd-1 array can't be processed because of a JNI
> >> problem? (i.e. With valid lengths but NULL addresses)
> >
> > Maybe it's not a direct array but a normal one. Has to be tried.
> >
> >> 3. The buffer marked with flag '0x00000002' is not in byte-stream
> >> format? so it needs to be converted to byte-stream and put in the
> >> stream. That means it needs to add some workaround code for this
> >> codec?
> >
> > I don't know. Can you give the content of such a buffer? With
> > gst_util_dump_mem() for example.
> 
> Well, for the device I tested, a buffer with '0x2'(i.e.
> BUFFER_FLAG_CODEC_CONFIG) flag can be used directly. (BTW, the device
> doesn't return INFO_OUTPUT_FORMAT_CHANGED, hence can't retrieve csd-0
> and csd-1 from a returned MediaFormat)

csd-0 and csd-1 seem to contain the PPS and the SPS with start codes. To
get avc stream format you need to put them into a avcC struct, which
contains those two NALs and some stuff around it. And no start codes.

> What I mentioned is for  stic at free.fr's case:
> """
> >> here is the content of the buffer when flag is 0x00000002 (now it has a size of 20):
> >> 01-27 12:24:58.842: I/GLib+stdout(21360): 00000000 (0x4fc7c000): 00 00 00 01 67 42 80 28 e9 07 86 72 00 00 00 01  ....gB.(...r....
> >> 01-27 12:24:58.842: I/GLib+stdout(21360): 00000010 (0x4fc7c010): 68 ee 06 f2                                      h...
> 
> > Ok, putting that in codec_data is wrong. The avcC does not contain start
> > codes and also has some other info in front of the SPS and PPS. See
> > gst_h264_parse_make_codec_data() in
> > gst-plugins-bad/gst/videpoarse/gsth264parse.c
> 
> > You will have to handle this as stream-format=byte-stream and put the
> > codec data buffer into the stream instead of the caps. Or convert this
> > to avcC and make sure the other parts of the output are avc compatible
> > too.
> """
> This buffer is in avcC format?

No it isn't, that's probably byte-stream. It contains start codes and
contains a SPS and a PPS NAL.

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-android/attachments/20140209/a0218689/attachment.pgp>