Roverr / rtsp-stream

Out of box solution for RTSP - HLS live stream transcoding. Makes RTSP easy to play in browsers.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Five bugs or improvements. :P

ziserendexin opened this issue · comments

I found some bugs or improvements.

  1. Should rebuild folderRestart after cleanUnused and restart.
  2. Shouldn't save URL info in list when ffmeg create fail (time out).
  3. Shouldn't save URL info in list when restart or get fail.
  4. Should redirect cmd.Stdout and cmd.Stderr to get more debug info. Instead of exit status 1
  5. Maybe should save original uri in http request.

This is detail info:

  1. Should rebuild folderRestart after cleanUnused at restart.

    recurrent:

    time="2019-11-01T07:58:18Z" level=info msg="./videos/873a0ced-1924-4438-b7ab-1369c3e05b72 has been restarted"
    time="2019-11-01T07:58:21Z" level=error msg="exit status 1"
    GET /stream/b45dd012-341c-4a7f-ac3e-784eeb88e183/index.m3u8 HTTP/1.1
    Host: 10.7.0.117:9094
    cache-control: no-cache
    404 page not found

    position:

    createDirectoryForURI(p.storeDir) in func (p Processor) NewStream

    id, path, err := createDirectoryForURI(p.storeDir)

    strm.cleanDir() in func (strm *Stream) CleanProcess()

    defer strm.cleanDir()

    But forget rebuild folder:

    func (p Processor) Restart(strm *Stream, path string)

    func (p Processor) Restart(strm *Stream, path string) error {

  2. Shouldn't save URL info in list when ffmeg create fail (time out).

    It's an unexist url.

    POST /start HTTP/1.1
    Host: 10.7.0.117:9094
    cache-control: no-cache
    
    {
    	"uri": "rtsp://10.25.144.106:554/live?camera=14999&user=duansishengtims&pass=E0QjCAJLEHFC" 
    }
    {
        "uri": "/stream/de00bf0e-661d-4105-8472-0f93f58ab22c/index.m3u8"
    }

    After second send http:

    time="2019-11-01T08:03:11Z" level=debug msg="Created stream with storepath ./videos/de00bf0e-661d-4105-8472-0f93f58ab22c"
    time="2019-11-01T08:03:11Z" level=error msg="Error happened during starting of ./videos/de00bf0e-661d-4105-8472-0f93f58ab22c/index.m3u8 || Error: exit status 1"
    time="2019-11-01T08:03:34Z" level=error msg="./videos/de00bf0e-661d-4105-8472-0f93f58ab22c/index.m3u8 timed out while waiting for file creation in manager start"
    time="2019-11-01T08:04:37Z" level=info msg="de00bf0e-661d-4105-8472-0f93f58ab22c is active, skipping cleaning process"
  3. Shouldn't save URL info in list when restart or get fail.

    If get 404 or something else error, we should delete info in list.

  4. Should redirect cmd.Stdout and cmd.Stderr to get more debug info. Instead of exit status 1

    like:

    https://stackoverflow.com/questions/18159704/how-to-debug-exit-status-1-error-when-running-exec-command-in-golang

    https://stackoverflow.com/questions/1877045/how-do-you-get-the-output-of-a-system-command-in-go

    But I like this way:

    cmd := exec.Command("ls", "-lah")
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr
    err := cmd.Run()
    if err != nil {
        log.Fatalf("cmd.Run() failed with %s\n", err)
    }

    I tried build this, and get error info in rtsp-stream.err.log .

    Add after here :

    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr
  5. Maybe should save original url in list which http request.


At last, I love this post/get mode. It help me a lot.

These are great suggestions, thank you! ✅ 🎉

I'm trying to find some time to actually refactor the whole codebase because right now it could use some decoupling (ok, a lot of decoupling... 😄 ). I think all of your suggestions have a great place in there.

However, I'm hesitant to add these changes right now because I feel like every change, even the little ones, makes the code quality considerable worse as I'm just hacking them into the code. I know that leaving these issues for now is also not the ideal solution, but I feel like it has to wait a little bit.

Ideally the refactor should happen sometime this month. End of December in worst case scenario.

These are great suggestions, thank you! ✅ 🎉

I'm trying to find some time to actually refactor the whole codebase because right now it could use some decoupling (ok, a lot of decoupling... 😄 ). I think all of your suggestions have a great place in there.

However, I'm hesitant to add these changes right now because I feel like every change, even the little ones, makes the code quality considerable worse as I'm just hacking them into the code. I know that leaving these issues for now is also not the ideal solution, but I feel like it has to wait a little bit.

Ideally the refactor should happen sometime this month. End of December in worst case scenario.

Building a good architecture is very important, waiting for your good news. 😘

Hey @ziserendexin
I ended up fixing the issues I believe. With releasing v1.5.1 now restarting a stream should not cause any problems with non-existent paths.
Same should be true with storing URLs for streams that failed to start.

Now with the restarting streams. Ideally when a user adds a new stream and it fails to start it should not be stored. This was definitely a bug. However if a stream once managed to start successfully, but either got an error or just got cleaned over time, I think it has a proper reason to stay stored. Now with invalidating this collection of stored streams over time is another question. Right now I don't see any problems with not doing any "decay" time.

Redirecting the cmd output is possible currently, you just have to use the RTSP_PROCESS_LOGGING=true env variable. This will create logs for all your steams under /var/log/rtsp-stream (also configurable).

The last suggestion cannot be implemented in its form. Receiving back the original URI would mean that the service can start leaking authentication information. I could see this working in an environment where clients can set encryption tokens for their streams. This would be a secret stored next to the stream and it would be used to tokenise the original URI. Therefore clients that know the original secret for the stream can decrypt the original URI as well.