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
_______________________________________________
Libva mailing list
Libva@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libva

Reply via email to