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

_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Reply via email to