Hello, The bug report is at: https://bugzilla.gnome.org/show_bug.cgi?id=757941
Thanks again, Bill ________________________________________ From: Libva [[email protected]] on behalf of William Katsak [[email protected]] Sent: Wednesday, 11 November 2015 6:38 AM To: Sreerenj; [email protected] Subject: Re: [Libva] gstreamer-vaapi strange issue 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 [[email protected]] on behalf of Sreerenj [[email protected]] Sent: Wednesday, 11 November 2015 5:40 AM To: [email protected] 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 [[email protected]] on behalf of William Katsak > [[email protected]] > Sent: Tuesday, 10 November 2015 10:33 AM > To: [email protected] > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/libva > _______________________________________________ > Libva mailing list > [email protected] > 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/libva _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
