Please file a bug then, attach the command and source stream too...
Developers might not be immediately available to look into every issue.but as long as there is a bug report
we will track it sooner or later...

On 11.11.2015 14:34, Nikita Orlov wrote:
Sorry, will start new thread in future.

I tried exactly avenc. I don`t how is it bug or not. Is it possible to ask you 
do make same experiment as I did.
I can prepare all source data and commands that I have used.

11.11.2015, 15:27, "Sreerenj" <sreerenj.balachand...@intel.com>:
HI Nikita,

Please always start a new thread for a new query in future :)

Try with avcenc in libva:
http://cgit.freedesktop.org/vaapi/libva/tree/test/encode/avcenc
If issue persists, file a bug against libva:
https://bugs.freedesktop.org/enter_bug.cgi?product=libva

If you have issue with gstreamer-vaapi but not with avcenc, then file a
bug against gstreamer-vaapi:
https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi

On 11.11.2015 14:07, Nikita Orlov wrote:
  Hello Sreerenj!

  I have another question, before I asked it in this mailing list, but had no 
responce.
  I have used vaapi tools and gstreamer-vaapi for encoding sample FullHD video 
(Big buck bunny) from yuv420 source.
  I have used different settings, but I can`t get reasonable bitrate (1Mbit/s) 
for FullHD video with normal quality.
  Even for 10Mbit/s quality was not very good (there were artefacts sometimes).

  I have tried same hw encoding on Windows, using Handbrake tool. It works much 
better and I got 1Mbit/s good quality encoding.
  My conclusion was that the problem is not in hardware, but with software.

  I tried followings CPUs: Haswell 4770K, 4770T, 4790T, Broadwell desktop i5. 
Same result. All my Haswell cpus have HD4600 gpu,
  Broadwell has some more improved, but same result.

  Maybe you can help me and share some of your expirience. Or encode some 
sample 1920x1080 video and check output?

  11.11.2015, 14:38, "William Katsak" <william.kat...@ericsson.com>:
  Hello,

  Thanks very much for your reply. The way you described it is what I inferred 
from the source.

  What I had expected was that setting the capsfilter would tell the encoder to 
use whatever tools are available that are part of the specified profile. For 
example, if my vainfo reports these:

         VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
         VAProfileH264Main : VAEntrypointEncSlice
         VAProfileH264High : VAEntrypointEncSlice

  I would have liked to be able to specify profile=high, and have whatever 
tools are part of VAProfileH264Main selected. Indeed, I think this is how 
x264enc works (and maybe gstreamer-omx too?).

  I will open the bug report shortly, but, I wanted to, ask something else: If 
I need to approximate the behaviour for some experiments, is it reasonable to 
just ask for whatever tools are part of each profile? Is there any way to see 
exactly what would be part of each profile (other than checking the standard)? 
Is the set of options exported to gstreamer inclusive of everything in the 
VAProfiles?

  Thanks so much again,
  Bill Katsak
  ________________________________________
  From: Libva [libva-boun...@lists.freedesktop.org] on behalf of Sreerenj 
[sreerenj.balachand...@intel.com]
  Sent: Wednesday, 11 November 2015 5:40 AM
  To: libva@lists.freedesktop.org
  Subject: Re: [Libva] gstreamer-vaapi strange issue

  Hi,

  Right now gst-vaapi-encoder doesn't have support to negotiate the custom
  profile set via capsfilter. But we are
  selecting an appropriate profile based on other coding tools. We start
  from "constrained-baseline" as the default choice,
  then if user ask for b frame encoding or cabac entropy coding, it will
  switch to "main" profile.. Similarly asking for 8x8 dct
  will switch the profile to "high"..

  Basically if you are not choosing any of those coding tools, it could be
  enough to use constrained-baseline..
  Any decoder which can support main profile should be able enough to
  decode the constrained-baseline too.
  Similarly high profile decoder can decode main profile too..

  But adding a provision for selecting profiles as per user's choice seems
  fine for me.
  If you can file a bug against gstreamer-vaapi
  (https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi)
  asking for this feature,
  we can discuss it there..

  On 10.11.2015 20:23, William Katsak wrote:
    I've been looking at the source this afternoon, and my interpretation of it 
is that specifying the profile via caps is only serving a restrictive role, vs. 
a configuration role. Obviously, I need to study it more, but is this true? To 
target a different profile, do we need to specifically specify which encoding 
tools that we want to use?

    Thanks,
    Bill

    ________________________________________
    From: Libva [libva-boun...@lists.freedesktop.org] on behalf of William 
Katsak [william.kat...@ericsson.com]
    Sent: Tuesday, 10 November 2015 10:33 AM
    To: libva@lists.freedesktop.org
    Subject: [Libva] gstreamer-vaapi strange issue

    Hello,

    I am not sure if this the right list for this, but I am seeing a strange 
issue with gstreamer-vaapi on Intel Haswell.

    I am doing some experimentation using gstreamer-vaapi on an Intel i3-4370 
CPU. I am running libva 1.6.1, and libva Intel driver 1.6.0 on Ubuntu 15.04.

    My issue is that I cannot seem to get the thing to do anything except 
constrained baseline, despite asking it to do other profiles.

    If I do something like this:

    gst-launch-1.0 filesrc 
location=/ramdisk/bbb_sunflower_1080p_30fps_normal.mp4 ! qtdemux ! vaapidecode 
! vaapiencode_h264 ! video/x-h264,profile=high ! qtmux ! filesink 
location=/ramdisk/tmp.mov

    It appears to work fine, but if I check with this:

    avprobe -show_streams /ramdisk/tmp.mov

    the output will indicate:
    profile=Constrained Baseline

    However, if I change the encode element to:
    vaapiencode_h264 dct8x8=1
    it does change the output profile.

    My question is, is this correct behavior? Do we need dct8x8 to do anything 
higher than Constrained Baseline? If so, why? Is this a fundamental detail of 
H.264, or is this an implementation detail?

    Thanks in advance for any help or pointers that you might able to give me.
    -Bill

    _______________________________________________
    Libva mailing list
    Libva@lists.freedesktop.org
    http://lists.freedesktop.org/mailman/listinfo/libva
    _______________________________________________
    Libva mailing list
    Libva@lists.freedesktop.org
    http://lists.freedesktop.org/mailman/listinfo/libva
  --
  Thanks
  Sree

  ---------------------------------------------------------------------
  Intel Finland Oy
  Registered Address: PL 281, 00181 Helsinki
  Business Identity Code: 0357606 - 4
  Domiciled in Helsinki

  This e-mail and any attachments may contain confidential material for
  the sole use of the intended recipient(s). Any review or distribution
  by others is strictly prohibited. If you are not the intended
  recipient, please contact the sender and delete all copies.
  _______________________________________________
  Libva mailing list
  Libva@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/libva
  _______________________________________________
  Libva mailing list
  Libva@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/libva
  --
  Nikita Orlov
  Skype: nik_stet
  QQ: 2717846083
--
Thanks
Sree

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
Nikita Orlov
Skype: nik_stet
QQ: 2717846083

--
Thanks
Sree

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Libva mailing list
Libva@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libva

Reply via email to