feature: [supper custom output to io.Writer]

[pdxrlj]

✨ Describe the feature you'd like

like output, add new command OutPutTo()

🌧 Is your feature request related to a problem?

like output, add new command OutPutTo()

🔎 Describe alternatives you've considered

like output, add new command OutPutTo()

⚠ If implemented, do you think this feature will be a breaking change to users?

Yes

⚙ Additional context

No response

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

[lrstanley]

Can you provide a few example usecases where this would be beneficial, knowing that all log data is already captured (just not available as it's received)?

• Is it just for cases where you want to capture all logs for debugging?
• Are you looking to stream the output somewhere?
• Are you expecting all output? some output? (e.g. JSON, progress info, etc)
  • All output might be too verbose/not human-readable, when using features like progress tracking, because we use custom formatting for those lines to make it more machine-readable.
• What about stdout vs stderr? Multiple io.Writer inputs? One for each?
  • If one, would you expect some kind of prefix in the output so you know what lines are stdout vs errors?
• Are you expecting go-ytdlp to not process the output from yt-dlp when this io.Writer is provided?
• If go-ytdlp were to log data about it's operations, would you expect those to also go to the io.Writer, or only the output from yt-dlp?

[pdxrlj]

---

1. Core Requirements

You need streaming output of raw video/audio data (not logs) with the following features:

• Type Separation: Video and audio streams can be directed to separate io.Writer instances.
• Real-time Processing: Data should be available for analysis/transcoding during download (no need to wait for completion).

---

2. Proposed Design

(1) Stream Separation & Routing

• New Parameters: Extend DownloadOptions to include:

  type DownloadOptions struct {
      VideoOutputWriter io.Writer // Raw video stream output  
      AudioOutputWriter io.Writer // Raw audio stream output  
      // Existing options...
  }

• Behavior:
  • If VideoOutputWriter is set, only video streams are extracted (e.g., -f bestvideo) and written directly.
  • If AudioOutputWriter is set, only audio streams are extracted (e.g., -f bestaudio).
  • Both can be enabled simultaneously (e.g., for demuxing).

(2) Data Format Control

• Raw Passthrough: Forward unprocessed binary streams (e.g., MKV/MP4 fragments) from yt-dlp.
• Format Flexibility: Users specify formats via existing --format flags (e.g., bestvideo[ext=mp4]); the library acts as a pipe.

(3) Logs vs. Data Streams

• Logs: Continue using the existing io.Writer for text-based logs (progress, errors).
• Data Streams: New Video/AudioOutputWriter handles binary data only, decoupled from logs.

---

3. Example Use Cases

Case 1: Real-time Video Transcoding

file, _ := os.Create("output.h264") 
defer file.Close()

options := &ytdlp.DownloadOptions{
    URL:               "https://example.com/video",
    VideoOutputWriter: file,      // Stream to file
    Format:           "bestvideo[ext=mp4]", 
}
ytdlp.Download(options)

• Video data is piped to output.h264 for immediate processing (e.g., via ffmpeg).

Case 2: Audio/Video Demuxing

videoFile, _ := os.Create("video.raw")
audioFile, _ := os.Create("audio.raw")
defer videoFile.Close()
defer audioFile.Close()

options := &ytdlp.DownloadOptions{
    URL:               "https://example.com/video",
    VideoOutputWriter: videoFile,
    AudioOutputWriter: audioFile,
}
ytdlp.Download(options)

---

4. Considerations

1. Performance: Streaming may increase memory pressure; benchmark with large files.
2. Error Handling: Define behavior if Writer fails (e.g., abort or buffer retries).
3. Format Compatibility: Users must ensure --format matches their pipeline (e.g., prefer H264 for compatibility).

[lrstanley]

Stop using AI if you have no idea what you are trying to ask or do. This is also an XY problem.

In regards to what the AI spit out that you carelessly copy-pasted, yt-dlp can only have 1 output stream (stdout) for non-log content in the scenario where you ask yt-dlp to stream content:

1. This means if you want audio and video, they have to be in 1 container format (MKV for example).
   • If the original format isn't that container format, yt-dlp will write to a temporary file anyway, then stream it to that output stream, which defeats most of the purpose of streaming in the first place (temporary files, delay between starting and receiving the data, etc).
2. Logs are then output to stderr, which means you don't know what is actually regular output vs errors.

If yt-dlp is already going to use temporary files and be merging them directly, there is very little point. However, I may still look at implementing this for the edge case where the source stream doesn't need to be merged, assuming we can keep all of the other functionality that currently relies on stdout, to also work with stderr.

[BlueFox1616]

@lrstanley hey i wanted to ask is there currently any way to instead of downloading pass the audio to a reader and stream it ?