Vah265lpenc produces wrong DTS on each key frame it inserts

Hello!

The pipeline I’m using is (omitted audio part but it’s there):
mpegtsmux name=muxer alignment=7
! queue max-size-buffers=0 max-size-bytes=0 max-size-time=1000000000
! udpsink host=192.168.11.29 port=5797 buffer-size=26214400 enable-last-sample=false

decklinkvideosrc device_number=0 mode=1080i50 do_timestamp=true
! video/x-raw,format=UYVY
! queue
! vapostproc
! vadeinterlace method=compensated
! video/x-raw(memory:VAMemory),format=NV12,interlace-mode=progressive
! vah265lpenc rate-control=cbr cpb-size=4000 bitrate=4000 aud=true key-int-max=0 b-frames=0 mbbrc=1 trellis=true
! h265parse config-interval=1
! queue leaky=no max-size-buffers=0 max-size-time=1000000000 min-threshold-time=40000000
! muxer.

When I use ffmpeg to receive the stream I’m getting warnings like this:

[vost#0:0/copy @ 0x606683b4d900] Non-monotonic DTS; previous: 130448, current: 130448; changing to 130449. This may result in incorrect timestamps in the output file.
[vost#0:0/copy @ 0x606683b4d900] Non-monotonic DTS; previous: 220448, current: 220448; changing to 220449. This may result in incorrect timestamps in the output file.
[vost#0:0/copy @ 0x606683b4d900] Non-monotonic DTS; previous: 310449, current: 310449; changing to 310450. This may result in incorrect timestamps in the output file.


My search has resulted in that these DTS get broken each time vah265lpenc produces key frame. It’s confirmed by setting parameter key-int-max to values like 50, 150, etc… and check that messages appear each 1 second, each 3 seconds or so. Also values shown display periods of 90000 (for 50 frames and 1 second) or 270000 (for 150 frames and 3 seconds).

h265parse is unable to fix the “issue”. Element h265timestamper complains about seeing some “multilayer extension” and ignores rest of the buffer. No other means I’ve tried help.

Now I have two questions really:

  • Having such a warnings does not make it feels OK, but… I’ve looked at result produced by ffmpeg and I didn’t see any video glitches nor audio breaks. I have no access to any “real” decoder so I cannot check if they play the stream well, but people who has an access haven’t reported any issues. Is it real issue or just minor glitch which is easily ignored by real players?
  • If it is real - they what I can try to fix it? At the very last I can try to intercept buffers produces by the encoder and make binary fixes (sounds crazy…).

Thanks

would be great if you could open a bug in share a segment of the video you want to encode.

why do you add `vadeinterlace`?? why do you set the caps between the va elements?

in the gitlab issue be sure to add the proper logs.

Thanks!

It appears that the issue with these DTS isn’t an issue. Real issue with the pipeline as that PCR are not sent as it is required by TR 101 290.

Fixed pipeline is:
mpegtsmux name=muxer alignment=7 pcr-interval=1800 bitrate=4500000

! udpsink host=192.168.11.29 port=5797 buffer-size=26214400 sync=true enable-last-sample=false

! vah265lpenc rate-control=cbr cpb-size=1000 bitrate=4000 i-frames=0 aud=false key-int-max=0 b-frames=0 mbbrc=1 trellis=true

! queue max-size-buffers=0 max-size-time=1000000000
! muxer.

(omitted unaltered lines)

These changes do following:

  • make video encoder to not put AUD into stream - it would be done by parser and be done better, also use bitrate more smoothly (CBP-SIZE to 1/4 of bitrate)
  • make queue to not hold buffers for 40ms and instead put them through right away
  • make mpegtsmux to place PCR into each passing frame (to make PCR period of around 20-40msec in compliance with TR) and make overall bitrate be the more the less stable
  • make udp-sink send packets more equally spread over time