-v is too verbose with rtmpdump

[johnhawkinson]

• I've verified and I assure that I'm running youtube-dl 2017.04.03
• Question

Generally speaking, I always invoke youtube-dl with -v for verbose output. It helps me know what is going on and makes it easier for me to report bugs and submit pull requests. I generally expect -v will give me a screenful of data or so.

But when youtube-dl runs in verbose mode and invokes rtmpdump, it produces pages of output; in the case of an rtmp source that can go on for hours, it is voluminous, arguably infinite :). This sort of thing:

[debug] exe versions: ffmpeg git-2017-02-28-7f62368, ffprobe git-2017-02-28-7f62368, rtmpdump 2.4
...
[rtmpdump] DEBUG: HandleInvoke, server invoking <_result>
[rtmpdump] DEBUG: HandleInvoke, received result for method call <connect>
[rtmpdump] DEBUG: sending ctrl. type: 0x0003
[rtmpdump] DEBUG: Invoking createStream
[rtmpdump] DEBUG: RTMP_ClientPacket, received: invoke 29 bytes
[rtmpdump] DEBUG: (object begin)
[rtmpdump] DEBUG: Property: NULL
[rtmpdump] DEBUG: (object end)
[rtmpdump] DEBUG: HandleInvoke, server invoking <_result>
...

It seems to me that this isn't how it should go -- that the output from rtmpdump in verbose mode exceeds what is reasonable for verbose invokation of youtube-dl.

Is there an appetite to change this? I'm not sure what is best. Removing --verbose from rtmpdump's invokation? Or disconnecting stderr (is that how this works? It runs with --verbose even when youtube-dl is run without -v...) What kind of solution, if any, would the project maintainers accept?

Thanks.

[dstftw]

I don't see any problem here. Usually rtmp related errors occur right at the beginning due to incomplete/invalid input so it's unlikely to produce long output. If you are using -v all the time then you should be prepared for long outputs.

[johnhawkinson]

I would like a way to see the initialization setup but not see verbose data about the actual downloading process, which go on forever in the case of a continuous rtmp stream.

Maybe changing the behavior of -v isn't the right way to get there.

Does anyone have any ideas?

Usually rtmp related errors occur right at the beginning due to incomplete/invalid input so it's unlikely to produce long output

In the case of youtube-dl -v suffolk.edu/sjc they go on forever, once for each status update:

[download] 1.79MiB at 69.98KiB/s (00:26)
[rtmpdump] DEBUG: HandleCtrl, received ctrl. type: 31, len: 6
[rtmpdump] DEBUG: HandleCtrl, Stream BufferEmpty 1
[rtmpdump] DEBUG: HandleCtrl, received ctrl. type: 32, len: 6
[rtmpdump] DEBUG: HandleCtrl, Stream BufferReady 1
[download] 1.80MiB at 69.62KiB/s (00:26)
[rtmpdump] DEBUG: HandleCtrl, received ctrl. type: 31, len: 6
[rtmpdump] DEBUG: HandleCtrl, Stream BufferEmpty 1
[rtmpdump] DEBUG: HandleCtrl, received ctrl. type: 32, len: 6
[rtmpdump] DEBUG: HandleCtrl, Stream BufferReady 1
[download] 1.82MiB at 69.68KiB/s (00:26)
...