alexeidt / vidio Goto Github PK

Is it possible that we can combine this with electron js ( golang to node.js module

Can we recording of enter screen in electron.js based app using webrtc screen sharing api & then stream then recorded video to any rtmp server in real-time.

Issue

Running video.Read() on Docker seems to run into the issue where the following loop ends after the first iteration:

for frameCount := 0; video.Read(); frameCount++  {

  // ... do some logic on frames

}

Not sure where I am going wrong, running the binary on macOS seems to give me no issues, but running on both alpine:latest and ubuntu:latest gives me this issue.

Things I tried

• Using different base images
• Copying video file directly into the container

What my docker image looks like

# Use the official Golang image as the base image
FROM golang:1.18 AS builder

# Set the working directory inside the container
WORKDIR /app

# Copy the Go module files
COPY go.mod go.sum ./

# Download and cache the Go module dependencies
RUN go mod download

# Copy the source code into the container
COPY . .

# Build the Go application
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o vidstreamsplit .


# Use a minimal Alpine image as the base image for the final image
FROM ubuntu:latest

# Install FFmpeg and AWS CLI
RUN apt update && apt install -y ffmpeg 

# Set the working directory inside the container
WORKDIR /app

# Copy the built binary from the previous stage
COPY --from=builder /app/vidstreamsplit .

# Make the binary executable
RUN chmod +x vidstreamsplit

# Copy the scripts directory into the container
COPY scripts ./scripts

# Make all the scripts in the scripts package executable
RUN chmod +x scripts/*.sh

Please let me know if you've run into this issue before. Happy to take a look and try to submit a change if you could point me in the write direction.

By using the example code to read a video and write the output directly and save the frames, I am getting all frames and the output video scrambled for certain input videos. This seems to only happen in portrait videos as far as I can tell.
This is an example frame, as you can see it looks like the stride is off:

I'll submit a PR with the fix that I am using

This package works great for me and is much faster for my use case than PyAV! Sadly, this package is missing a feature that my Python program had: the ability to copy over audio from the video I'm modifying. Since you're using the FFmpeg CLI directly, the best way to do this would likely be to open up another subprocess to handle audio, and then use named pipes in order to mux video and audio together at once.

I come again with a proposal for a new API, which, I could implement if it receives positive feedback. What I mean is the possibility to open a video starting from a specific frame. The ability to open such a file with a " leap" would be very helpful when working with video using multiple threads/goroutines: each goroutine would create its own process in which it would work with its video chunk.

I also wonder how such a solution would compare performance-wise with a solution where there is one process with access to the file, and the work with the frame would be done in a pool of goroutines.

I am curious to hear the opinions of those interested.
Best regards!

Yesterday i forked the Vidio repository in order to experiment with the Read() function.
One of the projects on which I'm working is using Vidio in a few separate steps:

• First we open a video file to perform an analysis step on all frames and later the program is processing the data and is returning a collection of frame numbers.
• Then I needed to repeat the iteration over the whole video in order to access and export the specified frames.

The iteration over the whole video takes a lot of time due to the frameBuffer writing operation. Here is a solution that I tried to implement:

I created a ReadOffset(n int) function, that skips n frames and writes the n+1 frame to the frameBuffer. The io.ReadFull involves the creation of a buffer and the main goal was to prevent allocations and unnecessary writing. The usage of io.SkipN with the source set to video.pipe and destination io.Discard performed the same on the benchmark and profiling that i performed. Later, I thought about using the Seek() operation, but the pipe is ReadCloser and not ReadSeekCloser, and a cast would not help, because we are not waiting for the command to end, so the length is changing and some unexpected bahabiour may occur.

All these problems lead to the idea of introducing a separate API. I think that accessing a specific frame is a common operation and iteration over the whole video file is overkill, especially when we know the specific frame numbers. Also, these kinds of changes:

• DO NOT expose the underlying FFMpeg implementation details, so the API would still seem FFMpeg agnostic
• DO NOT change the existing API so no breaking changes will be made
• allow to increase efficiency of applications using Vidio

I though about functions like

GetFrame(filename string, index int) *image.RGBA

GetFrames(filename string, index ...int) []*image.RGBA

The underlying FFMpeg API can use the select flag. Example flag value to export frames 2, 5 and 10:

... select='eq(n\,1)+eq(n\,4)+eq(n\,9)' ...

I would appreciate your opinion on this case and would be happy to implement these changes if my proposal is accepted.

Thank you for creating and maintaining this library.
Best regards!

	var vdo *vidio.Video
	vdo, err = vidio.NewVideo(filepath)
	if err != nil {
		return
	}

err:
no video data found in /tmp/upload/acd9bc2b5543f08633.rm

and the file exists.

I have a route which receives a video through an http post, basically what I want is to validate the extension of this video to only work with mp4 videos. Can I do this?

I thought about opening a pull request with a feature implementation I wanted to propose, but I think, first I'm gonna consult it via an issue.
I thought about the possibility of passing additional FFmpeg flags and parameters to VideoWriter. This could be achieved, for example, by adding a map[string]string or a []string to the Options struct. This change wouldn't introduce any breaking-changes but may open new possibilities, more use-cases and would make the library generally more versatile.