Bug#843144: #843144 is a problem in ffmpeg

[Eriberto Mota]

Hi guys,

As curiosity, I tested Vokoscreen with current ffmpeg in
www.deb-multimedia.org and it worked fine.

Hope this help.

Regards,

Eriberto

Bug#843144: #843144 is a problem in ffmpeg

[Eriberto Mota]

Thanks a lot Nelson!

Eriberto


2016-11-05 18:51 GMT-02:00 Nelson A. de Oliveira :
> 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.08
> 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

Bug#843144: #843144 is a problem in ffmpeg

[Andreas Cadhalpun]

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.08
> 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/100
filter -> pts:4 pts_time:0.133467 exact:3.16 time_base:1001/3
Clipping frame in rate conversion by 0.84
encoder <- type:video frame_pts:4 frame_pts_time:0.133467 time_base:1001/3
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/100
filter -> pts:0 pts_time:0 exact:-0.08 time_base:1001/3
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/100
filter -> pts:0 pts_time:0 exact:0.38 time_base:1001/3
*** 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

Bug#843144: #843144 is a problem in ffmpeg

[Nelson A. de Oliveira]

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.08
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