Re: MFC: different h264 profile and level output the same size encoded result
On 08/29/2016 01:49 PM, Andrzej Hajda wrote: Hi, On 08/27/2016 11:55 AM, Randy Li wrote: Hi: I have been reported that the setting the profile, level and bitrate through the v4l2 extra controls would not make the encoded result different. I tried it recently, it is true. Although the h264 parser would tell me the result have been applied as different h264 profile and level, but size is the same. You may try this in Gstreamer. gst-launch-1.0 -v \ videotestsrc num-buffers=500 ! video/x-raw, width=1920,height=1080 ! \ videoconvert ! \ v4l2video4h264enc extra-controls="controls,h264_profile=1,video_bitrate=100;" ! \ h264parse ! matroskamux ! filesink location=/tmp/1.mkv Is there any way to reduce the size of MFC encoded data? There is control called rc_enable (rate control enable), it must be set to one if you want to control bitrate. This control confuses many users, I guess it cannot be removed as it is already part of UAPI, but enabling it internally by the driver if user sets bitrate, profille, etc, would make it more saner. I see, thank you so much. A guy told me that the "frame_level_rate_control_enable=1" in _ extra-controls="encode,h264_level=10,h264_profile=4,frame_level_rate_control_enable=1,video_bitrate=2097152" would also make it works. But I really know there is a switch need to turn on. Regards Andrzej -- Randy Li The third produce department -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFC: different h264 profile and level output the same size encoded result
Hi, On 08/27/2016 11:55 AM, Randy Li wrote: > Hi: > >I have been reported that the setting the profile, level and bitrate > through the v4l2 extra controls would not make the encoded result > different. I tried it recently, it is true. Although the h264 parser > would tell me the result have been applied as different h264 profile and > level, but size is the same. > > You may try this in Gstreamer. > > gst-launch-1.0 -v \ > videotestsrc num-buffers=500 ! video/x-raw, width=1920,height=1080 ! \ > videoconvert ! \ > v4l2video4h264enc > extra-controls="controls,h264_profile=1,video_bitrate=100;" ! \ > h264parse ! matroskamux ! filesink location=/tmp/1.mkv > > Is there any way to reduce the size of MFC encoded data? > There is control called rc_enable (rate control enable), it must be set to one if you want to control bitrate. This control confuses many users, I guess it cannot be removed as it is already part of UAPI, but enabling it internally by the driver if user sets bitrate, profille, etc, would make it more saner. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Aug 29 04:00:15 CEST 2016 git branch: test git hash: fb6609280db902bd5d34445fba1c926e95e63914 gcc version:i686-linux-gcc (GCC) 5.4.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3428-gdfe27cf host hardware: x86_64 host os:4.6.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-i686: OK linux-4.5-i686: OK linux-4.6-i686: OK linux-4.7-i686: OK linux-4.8-rc1-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-x86_64: OK linux-4.5-x86_64: OK linux-4.6-x86_64: OK linux-4.7-x86_64: OK linux-4.8-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma-buf: Do a fast lockless check for poll with timeout=0
On Sun, Aug 28, 2016 at 09:33:54PM +0100, Chris Wilson wrote: > On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote: > > Currently we install a callback for performing poll on a dma-buf, > > irrespective of the timeout. This involves taking a spinlock, as well as > > unnecessary work, and greatly reduces scaling of poll(.timeout=0) across > > multiple threads. > > > > We can query whether the poll will block prior to installing the > > callback to make the busy-query fast. > > > > Single thread: 60% faster > > 8 threads on 4 (+4 HT) cores: 600% faster > > Hmm, this only really applies to the idle case. > reservation_object_test_signaled_rcu() is still a major bottleneck when > busy, due to the dance inside reservation_object_test_signaled_single() The fix is not difficult, just requires extending the seqlock to catch the RCU race (i.e. earlier patches). I'll resend that series in the morning. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma-buf: Do a fast lockless check for poll with timeout=0
On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote: > Currently we install a callback for performing poll on a dma-buf, > irrespective of the timeout. This involves taking a spinlock, as well as > unnecessary work, and greatly reduces scaling of poll(.timeout=0) across > multiple threads. > > We can query whether the poll will block prior to installing the > callback to make the busy-query fast. > > Single thread: 60% faster > 8 threads on 4 (+4 HT) cores: 600% faster Hmm, this only really applies to the idle case. reservation_object_test_signaled_rcu() is still a major bottleneck when busy, due to the dance inside reservation_object_test_signaled_single() -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: usb: dvb-usb: fix DIBUSB_MB usage of dib3000mc functions
From: Randy Dunlap The problem is that this driver uses a "common" driver supplement which calls a few dib3000mc*() functions but that driver is not "select"ed by DVB_USB_DIBUSB_MB. We can fix the build errors by selecting DVB_DIB3000MC (at the expense of around 8 KB on x86_64) just to add a few "library-like" functions. Or someone can split the required functions into a separate buildable file, but for such an ancient driver, I don't see the need to do this. Fixes these build errors: drivers/built-in.o: In function `dibusb_dib3000mc_frontend_attach': (.text+0x1a63bd): undefined reference to `dib3000mc_pid_parse' drivers/built-in.o: In function `dibusb_dib3000mc_frontend_attach': (.text+0x1a63c5): undefined reference to `dib3000mc_pid_control' drivers/built-in.o: In function `dibusb_dib3000mc_tuner_attach': (.text+0x1a6610): undefined reference to `dib3000mc_set_config' Signed-off-by: Randy Dunlap Reported-by: Fengguang Wu Cc: Joe Perches Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org --- drivers/media/usb/dvb-usb/Kconfig |1 + 1 file changed, 1 insertion(+) --- lnx-48-rc3.orig/drivers/media/usb/dvb-usb/Kconfig +++ lnx-48-rc3/drivers/media/usb/dvb-usb/Kconfig @@ -34,6 +34,7 @@ config DVB_USB_DIBUSB_MB depends on DVB_USB select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT select DVB_DIB3000MB + select DVB_DIB3000MC select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT help Support for USB 1.1 and 2.0 DVB-T receivers based on reference designs made by -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] dma-buf: Do a fast lockless check for poll with timeout=0
On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote:
> Currently we install a callback for performing poll on a dma-buf,
> irrespective of the timeout. This involves taking a spinlock, as well as
> unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
> multiple threads.
>
> We can query whether the poll will block prior to installing the
> callback to make the busy-query fast.
>
> Single thread: 60% faster
> 8 threads on 4 (+4 HT) cores: 600% faster
>
> Still not quite the perfect scaling we get with a native busy ioctl, but
> poll(dmabuf) is faster due to the quicker lookup of the object and
> avoiding drm_ioctl().
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
Reviewed-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-buf.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index cf04d249a6a4..c7a7bc579941 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -156,6 +156,18 @@ static unsigned int dma_buf_poll(struct file *file,
> poll_table *poll)
> if (!events)
> return 0;
>
> + if (poll_does_not_wait(poll)) {
> + if (events & POLLOUT &&
> + !reservation_object_test_signaled_rcu(resv, true))
> + events &= ~(POLLOUT | POLLIN);
> +
> + if (events & POLLIN &&
> + !reservation_object_test_signaled_rcu(resv, false))
> + events &= ~POLLIN;
> +
> + return events;
> + }
> +
> retry:
> seq = read_seqcount_begin(&resv->seq);
> rcu_read_lock();
> --
> 2.9.3
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf: Do a fast lockless check for poll with timeout=0
Currently we install a callback for performing poll on a dma-buf,
irrespective of the timeout. This involves taking a spinlock, as well as
unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
multiple threads.
We can query whether the poll will block prior to installing the
callback to make the busy-query fast.
Single thread: 60% faster
8 threads on 4 (+4 HT) cores: 600% faster
Still not quite the perfect scaling we get with a native busy ioctl, but
poll(dmabuf) is faster due to the quicker lookup of the object and
avoiding drm_ioctl().
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index cf04d249a6a4..c7a7bc579941 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -156,6 +156,18 @@ static unsigned int dma_buf_poll(struct file *file,
poll_table *poll)
if (!events)
return 0;
+ if (poll_does_not_wait(poll)) {
+ if (events & POLLOUT &&
+ !reservation_object_test_signaled_rcu(resv, true))
+ events &= ~(POLLOUT | POLLIN);
+
+ if (events & POLLIN &&
+ !reservation_object_test_signaled_rcu(resv, false))
+ events &= ~POLLIN;
+
+ return events;
+ }
+
retry:
seq = read_seqcount_begin(&resv->seq);
rcu_read_lock();
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
musb: isoc pkt loss with pwc
Hello Bin,
I would like to start new thread on my issue. Let me recall where the issue is:
There is 100% frame lost in pwc webcam driver due to lots of
zero-length packages coming from musb driver.
The issue is present in all kernels (including 4.8) starting from the commit:
f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
The issue is here both when DMA enabled and DMA disabled.
Attached here is a plot. The vertical axis designates the value of
rx_count variable from function musb_host_packet_rx(). One may see
that there are only two possibilities: 0 bytes and 956 bytes.
The horizontal axis is the last three digits of the timestamp when
musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
that my webcam is USB 1.1 and base time is 1 ms, then all frames
should be grouped close to some single value. (Repeating package
receive event every 1 ms won't change last tree digits considerably)
One may see that it is not true, in practice there are two groups. And
receive time strongly correlates with the package size. Packages
received near round ms are 956 bytes long, packages received near 400
us are 0 bytes long.
I don't know how exactly SOF and IN are synchronized in musb, could
someone give a hint? But from what I see the time difference between
subsequent IN package requests is sometimes more than 1 ms due to
heavy urb->complete() callback. After such events only zero length
packages are received. Surprisingly, that `synchronization' is
recovered sometimes in the middle of URB like the following:
[ 163.207363] musb int
[ 163.207380] rx_count 0
[ 163.207393] req pkt c9c76200 // Expected musb int at 163.208393
[ 163.207403] int end
// No interrupt at 163.208393
[ 163.209001] musb int
[ 163.209017] rx_count 956
[ 163.209108] req pkt c9c76200
[ 163.209118] int end
And then the series of 956 bytes long packages are received until URB
giveback will occasionally break it again.
Do I understand correctly, that SOF is generated every 1 ms by
hardware and should be followed by IN immediately?
If so, it is not clear to me how they should be aligned when the time
difference between to subsequent INs is greater than 1ms.
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Rplots.pdf
Description: Adobe PDF document
