This message was deleted.
# helpdesk
s
This message was deleted.
a
It might be a memory issue, v1.2.0 waits until completion to write the file in order to put the headers at the beginning (this was changed in v1.4.2). If your recordings will always be long, another option would be to use segments, which will upload an HLS/m3u8 playlist of 6s segments
s
I'll try this. Thank you. @able-gigabyte-21598
I couldn't find a sample code related to HLS. Where should I look?
On the other hand, is there anything you can say about IVF-type recording? It makes a lot of sense to connect to the room as a user and record the broadcast. How can I handle this fast recording (or frame drop). I also looked at galene's code. it is coded in a very similar way.
a
HLS: https://github.com/livekit/protocol/blob/main/livekit_egress.proto#L88 replace
TrackCompositeEgressRequest_File
with
TrackCompositeEgressRequest_Segments
👍 1
we used to use the pion ivfwriter from our sdk (removed here: https://github.com/livekit/egress/commit/a1b7e24a9ab42542676f427e9433975ca9c2c921), however there were issues with sync/playback speed, and things like muting
d
Actually, if there is no sound, you should use Track egress. it's simpler and much less intensive computationally.
s
I am currently using "Track egress" and I have problems with long time (1 hour) recordings. I think if you test this you will find the same situation. That's why I found IVF healthier and more stable. But I will also try HLS. I think LiveKit has made a very good choice to record rooms with headless-chrome unlike other media servers. But I think this issue needs to be analyzed in more depth. Bigbluebutton uses the same method. I haven't encountered such a problem with BBB. Thank you again for your help.
c
HLS will not work with track egress as HLS requires transcoding
It would work with track composite