Fix panic for MP4 stream with audio after v1.3 #338
Comments
|
Have your fix help with this problem? |
Yes. The issue can be illustrated with the following code, assuming go2rtc writes video/audio stream concurrently from 2 goroutines. package main
import (
"fmt"
"net/http"
"strings"
"sync"
)
func main() {
http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
wg := &sync.WaitGroup{}
const n = 10
wg.Add(n)
defer wg.Wait()
w.WriteHeader(200)
//mu := &sync.Mutex{}
for i := 0; i < n; i++ {
go func(i int) {
defer wg.Done()
//mu.Lock()
//defer mu.Unlock()
s := fmt.Sprintf("w%d|", i)
s = strings.Repeat(s, 1024) + "\n"
d := []byte(s)
for {
w.Write(d)
}
}(i)
}
})
http.ListenAndServe(":8001", nil)
} |
It seems there are really two separate causes for the two observations above. The invalid memory access panic is likely caused by ResponseWriter being de-initialized by net/http on http handler return. Example code like below illustrates this. http.HandleFunc("/boo", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
go func() {
tick := time.NewTicker(time.Second)
for range tick.C {
n, err := w.Write([]byte("c"))
log.Printf("n %d, err: %v", n, err)
if err == nil {
if f, ok := w.(http.Flusher); ok {
f.Flush()
}
}
}
}()
<-time.NewTimer(3 * time.Second).C
}) |
It seems net/http will deinit w on handler return and using it at that time will cause invalid memory access panic. This can be reproduced when doing page refresh Ref: AlexxIT#338
It seems net/http will deinit w on handler return and using it at that time will cause invalid memory access panic. This can be reproduced when doing page refresh Ref: AlexxIT#338
It seems net/http will deinit w on handler return and using it at that time will cause invalid memory access panic. This can be reproduced when doing page refresh Ref: AlexxIT#338
|
Can you show how you config |
It's plain rtsp |
|
Ok. I caught the problem once on my setup. And have returned the mutex. But not sure about your second patch yet. |
|
The mutex is there for serializing writes to http.ResponseWriter. The example code above should prove that this serialization is necessary. I'd say in the least that it's very unlikely that the mutex should cause any new issue. |
AlexxIT
changed the title
I am wondering maybe it's caused by http.ResponseWriter being written concurrently from multiple goroutine.
The source is a
ffmpeg:rtsp://.../stream1with h264 video and pcma audio track./api/stream.mp4?src=tl_ipc44gw_main&video=h264,h265&audio=aac,opus,mp3,pcma,pcmu/api/stream.mp4?src=tl_ipc44gw_main. It seems in this case go2rtc defaults to audio=aac and the resulting mp4 stream is has only a video track present.go2rtc runs as a armv7 container image (alexxit/go2rtc:master, alexxit/go2rtc@sha256:5e890220e10a482bf25032a99d86a3ab441a7def3a7d218aec92f1e0f57f8333).
The issue exhibits itself in two ways in the log.
The text was updated successfully, but these errors were encountered: