Long recordings hang

[turlando]

Hello,

I'm using wf-recorder freshly compiled today from AUR (wf-recorder-git r91.7cb37c4-1) and when I make a recording longer than ~1h10m I get the following error:

% wf-recorder --audio alsa_output.pci-0000_00_1b.0.analog-stereo.monitor
selected region 0 0 0 0
Setting codec option: crf=20
Setting codec option: preset=ultrafast
Setting codec option: tune=zerolatency
Choosing pixel format yuv420p
[libx264 @ 0x7ff458001e40] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0x7ff458001e40] profile Constrained Baseline, level 4.2, 4:2:0, 8-bit
[libx264 @ 0x7ff458001e40] 264 - core 157 r2980 34c06d1 - H.264/MPEG-4 AVC codec - Copyleft 2003-2019 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=4 lookahead_threads=4 sliced_threads=1 slices=4 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=crf mbtree=0 crf=20.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=0
Output #0, mp4, to 'recording.mp4':
    Stream #0:0: Unknown: none (libx264)
    Stream #0:1: Unknown: none (aac)
[mp4 @ 0x7ff458000cc0] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
[mp4 @ 0x7ff458000cc0] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Using PulseAudio device: default
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 131
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 388
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 644
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 899
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 1160
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 1413
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 1670
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 1927
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 2182
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 2440
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 2697
[mp4 @ 0x7ff458000cc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 65970571 >= 2953
[...]

and keeps going like that.

Video is truncated at that point.

Is there anything I can do to help you debug this issue?

Thank you for your work.

[ammen99]

@turlando Does this happen every time, i.e each time you reach 1h10m ?

[turlando]

Yes, so far I tried three times and every time I got the same error.

I'm using mpv for playback. When I use the directional arrows to seek past the "break" point the player quits with an "Exiting... (End of file)" message. But when I jump using the on screen control bar past that point, the video is frozen, but I can still hear the audio.

The first video broke at 01:11:43, the second at 01:11:33 and the third at 01:11:35.

[ammen99]

Thanks for your input. These times seem very close to each other, and this probably indicates an overflow somewhere. I'll go over all of the timestamps that we store and check them.

[turlando]

Thank you again, let me know if you need anything else. :)

[ammen99]

Just did a small calculation, 01:11:37 seconds is 4297000000 microseconds, while 2**32 is 4294967296, I think this is definitely an overflow. I'll check where it happens and change everything to int64_t which should be big enough.

[ammen99]

Ah well of course, it was almost obvious, @turlando I think if you apply http://ix.io/2fFv you'll be able to record longer than 01:11:43 :)

EDIT: Would be nice if you can confirm that this fixes the issue. Otherwise, I'll just push the commit in a few days and mark this as closed, since I think the issue should be fixed now.

[turlando]

But wait! That means that I will not be able to record longer than 500,000 years! :)

Thank you. For sure I will have to record again next Monday but I will try to make a test this weekend. Either way I will let you know if the patch solves this issue.

[ammen99]

But wait! That means that I will not be able to record longer than 500,000 years! :)

Please try to reproduce the bug to see that it really happens :P

[turlando]

I just tried recording for 1h46m and it worked flawlessly. I confirm the patch fixed the issue.

Thank you for your effort :)