Mark Thompson wrote:
On 27/09/16 16:48, Andy Furniss wrote:
Ok, thanks, so with that I am back to where I was before it stopped working.
In summary baseline works but JM ref decoder doesn't like the pocs.
b frames don't work properly, but then they don't with gst vaapi either. They
do work with gst omx.
Looking at output from printfs some differences I see vs gstreamer.
maxrefs is hardcoded to 2 which has sideffects =
Easily fixed:
<https://lists.libav.org/pipermail/libav-devel/2016-September/079372.html>.
Great, thanks.
enc_pic.pc.enc_b_pic_pattern = 1 vs 0 - seems harmless in practice.
There is code that for my h/w disables dual instance when maxrefs > 1 which
means half speed, but there seems to be a bottleneck elsewhere that makes avconv
3x slower than gstreamer anyway.
I'm not really sure how fast I should be expecting this stuff to work - can you
offer any numbers about how fast it goes for you? I only get ~30fps doing
1080p transcode on an R7 360, which compares rather badly to ~240fps on the
Skylake 6300 in the same machine.
I'll have to come back on this one tomorrow as it's late here.
I started to get some numbers but found a possible bug = I made a 1000
frame 15mbit 1080p50 mkv with ffmpeg/libx264.
Using it as source for transcode (s/w or h/w dec) it came out far too
low bitrate.
After re-applying debugging patch to mesa it turns out that framerate is
being set as 1000 in the encoder, I don't know if the file is duff or if
it's the patches.
more tomorrow.
gop, it seems that avconv with -g doesn't set h264->intra_idr_period in
handleVAEncSequenceParameterBufferType which gets used to set
context->desc.h264enc.gop_size and enc_pic.rc.gop_size
Hmm, this is an error on my part. I'll fix it, but I need to test a bit
further to be sure I'm not breaking anything else.
pocs gstreamer increments h264->CurrPic.TopFieldOrderCnt in 2s avconv 1s. The
code divides this by 2 in handleVAEncPictureParameterBufferType
That code is just wrong, isn't it? It works for pic_order_cnt_type == 2, but
it needs to look at the pic_order_cnt_lsb and delta_pic_order_cnt values on the
slice header for other cases. (Looking at gstreamer, it has POC type 0 (as I
do), but then the POC values match what POC type 2 would create in the
no-B-frame case, so this happens to work.)
My knowledge of low level detail is not so good.
I'll see if I can make a patch for this.
Thanks.
Thanks,
- Mark
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
