Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#843144: #843144 is a problem in ffmpeg
710 views
Skip to first unread message
Nelson A. de Oliveira
Nov 5, 2016, 5:00:02 PM11/5/16
to
reassign 843144 ffmpeg
found 843144 7:3.1.5-1
thanks
Hi!
I am hitting this same issue but from what I could inspect, it's
something related with ffmpeg (and not vokoscreen)
For example, directly calling ffmpeg like this, it fails:
ffmpeg -f x11grab -draw_mouse 1 -framerate 25 -video_size 1920x1080 -i
:0+0,0 -pix_fmt yuv420p -c:v libx264 -preset veryfast -q:v 1 -s
1920x1080 video.mkv
The above example is basically what vokoscreen is using.
We can see a lot of frames being dropped.
When using -report it's possible to see a lot of messages like this:
=====
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
Clipping frame in rate conversion by 0.000008
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
(...)
=====
While this work:
ffmpeg -f x11grab -draw_mouse 1 -r 25 -s 1920x1080 -i :0.0+0 -vcodec
libx264 video.mkv
Tested with ffmpeg 7:3.1.5-1 and latest 7:3.2-2.
I am unsure if this could be a problem with some lib that ffmpeg uses
(and I don't know how to test this)
Thank you!
Best regards,
Nelson
found 843144 7:3.1.5-1
thanks
Hi!
I am hitting this same issue but from what I could inspect, it's
something related with ffmpeg (and not vokoscreen)
For example, directly calling ffmpeg like this, it fails:
ffmpeg -f x11grab -draw_mouse 1 -framerate 25 -video_size 1920x1080 -i
:0+0,0 -pix_fmt yuv420p -c:v libx264 -preset veryfast -q:v 1 -s
1920x1080 video.mkv
The above example is basically what vokoscreen is using.
We can see a lot of frames being dropped.
When using -report it's possible to see a lot of messages like this:
=====
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
Clipping frame in rate conversion by 0.000008
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
(...)
=====
While this work:
ffmpeg -f x11grab -draw_mouse 1 -r 25 -s 1920x1080 -i :0.0+0 -vcodec
libx264 video.mkv
Tested with ffmpeg 7:3.1.5-1 and latest 7:3.2-2.
I am unsure if this could be a problem with some lib that ffmpeg uses
(and I don't know how to test this)
Thank you!
Best regards,
Nelson
Andreas Cadhalpun
Nov 6, 2016, 3:20:02 PM11/6/16
to
Control: tags -1 pending
Hi,
On 05.11.2016 21:51, Nelson A. de Oliveira wrote:
> I am hitting this same issue but from what I could inspect, it's
> something related with ffmpeg (and not vokoscreen)
>
> For example, directly calling ffmpeg like this, it fails:
>
> ffmpeg -f x11grab -draw_mouse 1 -framerate 25 -video_size 1920x1080 -i
> :0+0,0 -pix_fmt yuv420p -c:v libx264 -preset veryfast -q:v 1 -s
> 1920x1080 video.mkv
>
> The above example is basically what vokoscreen is using.
> We can see a lot of frames being dropped.
>
> When using -report it's possible to see a lot of messages like this:
>
> =====
> cur_dts is invalid (this is harmless if it occurs once at the start per stream)
> [rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
> Clipping frame in rate conversion by 0.000008
> cur_dts is invalid (this is harmless if it occurs once at the start per stream)
> [rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
> (...)
> =====
This isn't much use for debugging. More informative output is obtained with adding
'-loglevel debug -debug_ts':
$ ffmpeg -loglevel debug -debug_ts -f x11grab -i :0.0 -f framecrc -
[...]
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:133464 frame_pts_time:0.133464 best_effort_ts:133464 best_effort_ts_time:0.133464 keyframe:1 frame_type:1 time_base:1/1000000
filter -> pts:4 pts_time:0.133467 exact:3.999916 time_base:1001/30000
Clipping frame in rate conversion by 0.000084
encoder <- type:video frame_pts:4 frame_pts_time:0.133467 time_base:1001/30000
encoder -> type:video pkt_pts:4 pkt_pts_time:0.133467 pkt_dts:4 pkt_dts_time:0.133467
Last message repeated 1 times
muxer <- type:video pkt_pts:4 pkt_pts_time:0.133467 pkt_dts:4 pkt_dts_time:0.133467 size:1228800
0, 4, 4, 1, 1228800, 0x54c249aa
The first 4 frames are encoded correctly.
demuxer -> ist_index:0 type:video next_dts:166830 next_dts_time:0.16683 next_pts:166830 next_pts_time:0.16683 pkt_pts:0 pkt_pts_time:0 pkt_dts:0 pkt_dts_time:0 off:0 off_time:0
demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:0 pkt_pts_time:0 pkt_dts:0 pkt_dts_time:0 off:0 off_time:0
But then for some reason pts is suddenly 0 again, causing all following frames
to be dropped.
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:0 frame_pts_time:0 best_effort_ts:0 best_effort_ts_time:0 keyframe:1 frame_type:1 time_base:1/1000000
filter -> pts:0 pts_time:0 exact:-0.000008 time_base:1001/30000
demuxer -> ist_index:0 type:video next_dts:1 next_dts_time:1e-06 next_pts:1 next_pts_time:1e-06 pkt_pts:1 pkt_pts_time:1e-06 pkt_dts:1 pkt_dts_time:1e-06 off:0 off_time:0
demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:1 pkt_pts_time:1e-06 pkt_dts:1 pkt_dts_time:1e-06 off:0 off_time:0
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:1 frame_pts_time:1e-06 best_effort_ts:1 best_effort_ts_time:1e-06 keyframe:1 frame_type:1 time_base:1/1000000
filter -> pts:0 pts_time:0 exact:0.000038 time_base:1001/30000
*** dropping frame 5 from stream 0 at ts 0
> While this work:
>
> ffmpeg -f x11grab -draw_mouse 1 -r 25 -s 1920x1080 -i :0.0+0 -vcodec
> libx264 video.mkv
Using the '-r' option here is at most a work-around, as it simply tells ffmpeg
to ignore the timestamps from the input stream and assume a constant frame rate.
> Tested with ffmpeg 7:3.1.5-1 and latest 7:3.2-2.
> I am unsure if this could be a problem with some lib that ffmpeg uses
> (and I don't know how to test this)
The actual problem is a missing build-dependency on libxcb-shm0-dev, which
used to be pulled in via libopencv-dev (which also pulled in 170 MB of
unnecessary other dependencies).
It seems to me that it should fail so weirdly without libxcb-shm enabled,
but since simply adding this build-dependency is enough to fix it, I'm
not really interested in debugging this further.
If someone wants to look deeper into this, configuring ffmpeg with
'--enable-libxcb --disable-lixcb-shm' should make the problem easy to
reproduce.
Anyway, the next Debian upload will have the build-dependency added,
so tagging this bug as pending.
Best regards,
Andreas
Hi,
On 05.11.2016 21:51, Nelson A. de Oliveira wrote:
> I am hitting this same issue but from what I could inspect, it's
> something related with ffmpeg (and not vokoscreen)
>
> For example, directly calling ffmpeg like this, it fails:
>
> ffmpeg -f x11grab -draw_mouse 1 -framerate 25 -video_size 1920x1080 -i
> :0+0,0 -pix_fmt yuv420p -c:v libx264 -preset veryfast -q:v 1 -s
> 1920x1080 video.mkv
>
> The above example is basically what vokoscreen is using.
> We can see a lot of frames being dropped.
>
> When using -report it's possible to see a lot of messages like this:
>
> =====
> cur_dts is invalid (this is harmless if it occurs once at the start per stream)
> [rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
> Clipping frame in rate conversion by 0.000008
> cur_dts is invalid (this is harmless if it occurs once at the start per stream)
> [rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
> (...)
> =====
'-loglevel debug -debug_ts':
$ ffmpeg -loglevel debug -debug_ts -f x11grab -i :0.0 -f framecrc -
[...]
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:133464 frame_pts_time:0.133464 best_effort_ts:133464 best_effort_ts_time:0.133464 keyframe:1 frame_type:1 time_base:1/1000000
filter -> pts:4 pts_time:0.133467 exact:3.999916 time_base:1001/30000
Clipping frame in rate conversion by 0.000084
encoder <- type:video frame_pts:4 frame_pts_time:0.133467 time_base:1001/30000
encoder -> type:video pkt_pts:4 pkt_pts_time:0.133467 pkt_dts:4 pkt_dts_time:0.133467
Last message repeated 1 times
muxer <- type:video pkt_pts:4 pkt_pts_time:0.133467 pkt_dts:4 pkt_dts_time:0.133467 size:1228800
0, 4, 4, 1, 1228800, 0x54c249aa
The first 4 frames are encoded correctly.
demuxer -> ist_index:0 type:video next_dts:166830 next_dts_time:0.16683 next_pts:166830 next_pts_time:0.16683 pkt_pts:0 pkt_pts_time:0 pkt_dts:0 pkt_dts_time:0 off:0 off_time:0
demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:0 pkt_pts_time:0 pkt_dts:0 pkt_dts_time:0 off:0 off_time:0
But then for some reason pts is suddenly 0 again, causing all following frames
to be dropped.
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:0 frame_pts_time:0 best_effort_ts:0 best_effort_ts_time:0 keyframe:1 frame_type:1 time_base:1/1000000
filter -> pts:0 pts_time:0 exact:-0.000008 time_base:1001/30000
demuxer -> ist_index:0 type:video next_dts:1 next_dts_time:1e-06 next_pts:1 next_pts_time:1e-06 pkt_pts:1 pkt_pts_time:1e-06 pkt_dts:1 pkt_dts_time:1e-06 off:0 off_time:0
demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:1 pkt_pts_time:1e-06 pkt_dts:1 pkt_dts_time:1e-06 off:0 off_time:0
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:1 frame_pts_time:1e-06 best_effort_ts:1 best_effort_ts_time:1e-06 keyframe:1 frame_type:1 time_base:1/1000000
filter -> pts:0 pts_time:0 exact:0.000038 time_base:1001/30000
*** dropping frame 5 from stream 0 at ts 0
> While this work:
>
> ffmpeg -f x11grab -draw_mouse 1 -r 25 -s 1920x1080 -i :0.0+0 -vcodec
> libx264 video.mkv
to ignore the timestamps from the input stream and assume a constant frame rate.
> Tested with ffmpeg 7:3.1.5-1 and latest 7:3.2-2.
> I am unsure if this could be a problem with some lib that ffmpeg uses
> (and I don't know how to test this)
used to be pulled in via libopencv-dev (which also pulled in 170 MB of
unnecessary other dependencies).
It seems to me that it should fail so weirdly without libxcb-shm enabled,
but since simply adding this build-dependency is enough to fix it, I'm
not really interested in debugging this further.
If someone wants to look deeper into this, configuring ffmpeg with
'--enable-libxcb --disable-lixcb-shm' should make the problem easy to
reproduce.
Anyway, the next Debian upload will have the build-dependency added,
so tagging this bug as pending.
Best regards,
Andreas
Eriberto Mota
Nov 8, 2016, 9:10:03 AM11/8/16
to
Thanks a lot Nelson!
Eriberto
Eriberto
Eriberto Mota
Nov 8, 2016, 10:10:02 AM11/8/16
to
Hi guys,
As curiosity, I tested Vokoscreen with current ffmpeg in
www.deb-multimedia.org and it worked fine.
Hope this help.
Regards,
Eriberto
As curiosity, I tested Vokoscreen with current ffmpeg in
www.deb-multimedia.org and it worked fine.
Hope this help.
Regards,
Eriberto
Andreas Cadhalpun
Nov 8, 2016, 2:10:04 PM11/8/16
to
Hi Eriberto,
On 08.11.2016 16:06, Eriberto Mota wrote:
> As curiosity, I tested Vokoscreen with current ffmpeg in
> www.deb-multimedia.org and it worked fine.
>
> Hope this help.
Thanks for trying to help.
This specific issue is caused by a missing build-dependency
and already fixed in git[1].
Best regards,
Andreas
1: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/commit/?id=81d4013cae3ca131640a6cbb304a5f17d01e6355
On 08.11.2016 16:06, Eriberto Mota wrote:
> As curiosity, I tested Vokoscreen with current ffmpeg in
> www.deb-multimedia.org and it worked fine.
>
> Hope this help.
This specific issue is caused by a missing build-dependency
and already fixed in git[1].
Best regards,
Andreas
1: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/commit/?id=81d4013cae3ca131640a6cbb304a5f17d01e6355
Eriberto Mota
Nov 8, 2016, 2:20:03 PM11/8/16
to
Hi Andreas,
I saw your last comment. I just did a simple test using other ffmpeg.
Thanks for your work.
Regards,
Eriberto
I saw your last comment. I just did a simple test using other ffmpeg.
Thanks for your work.
Regards,
Eriberto
0 new messages