[Ffmpeg-devel-irc] ffmpeg.log.20180730

[burek]

[04:17:00 CEST] <duriangray> hi guys - quick question. I am trying to using ffmpeg to copy a stream. how do i access it?
[04:17:24 CEST] <duriangray> ffmpeg -i "http://myurl.com" -c copy -f mpegts "udp://localhost:1935"
[04:35:57 CEST] <duriangray> i can not access via VLC player for some reason
[05:23:41 CEST] <duriangray> av_interleaved_write_frame(): Broken pipeB time=00:00:10.00 bitrate=4641.1kbits/s speed=2.12x
[05:23:41 CEST] <duriangray> Error writing trailer of http://127.0.0.1:8080/publish/stream: Broken pipe
[12:33:30 CEST] <th3_v0ice>  What could cause this discrepancy between desired output being this:
[12:33:39 CEST] <th3_v0ice>  Stream #0:0: Video: h264, 1 reference frame ([7][0][0][0] / 0x0007), yuv420p, 1280x720 (0x0) [SAR 1:1 DAR 16:9], q=2-31, 29.97 fps, 29.97 tbr, 1k tbn
[12:33:49 CEST] <th3_v0ice> to actually being this: Stream #0:1[0x101]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 14.99 tbr, 90k tbn, 119.88 tbc. I am using the API.
[13:08:14 CEST] <Hola> Hi every one, I am facing an issue with fifo muxer and RTMP. Straight an example from the ffmpeg official wiki, which i am trying to use but I am getting some weird results.
[13:08:32 CEST] <Hola> The command from ffmpeg wiki for fifo muxer:   ffmpeg -re -i /home/user/Videos/movie.mp4 -acodec aac -vcodec libx264 -f fifo -fifo_format flv -map 0:v -map 0:a -drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 -max_recovery_attempts 20 -threads 1 rtmp://x.rtmp.youtube.com/live2/some-stream-key
[13:09:19 CEST] <Hola> I have done replacements and added one extra parameter "-max_recovery_attempts 20" which even if removed shows weird result.
[13:10:41 CEST] <Hola> First issue as I can see from output is the Bitrate is N/A and size as N/A. here is one line output as all the output lines have same BitRate and Size.     frame=   81 fps= 23 q=28.0 size=N/A time=00:00:03.49 bitrate=N/A speed=0.99x
[13:11:58 CEST] <Hola> In the Youtube streaming dashboard, it complains that " You need to change the video resolution. The current resolution is (65535x65535), which is not supported for this configuration. The expected video resolution is (2560x1440)."
[13:12:58 CEST] <Hola> If i put -f flv before rtmp url, then it works fine but then I can't use reconnectivity and connection recovery feature from fifo muxer. Any body here to help?
[13:59:45 CEST] <ChocolateArmpits> Hola, what version are you running?
[14:23:01 CEST] <Hola> ffmpeg version 4.0-static
[14:23:07 CEST] <Hola> ChocolateArmpits, here you go
[14:23:19 CEST] <Hola> its a static build.
[14:31:55 CEST] <ChocolateArmpits> Hola, does it work with all fifo-related parameters, except fifo_format removed?
[14:44:32 CEST] <Hola> ChocolateArmpits, i have to check that
[14:44:35 CEST] <Hola> let me get back to u
[14:47:08 CEST] <Hola> ok if i remove -fifo_format and use -f flv before rtmp and try to mimic the network connection issue, it gives me "av_interleaved_write_frame(): Broken pipe"
[14:49:03 CEST] <ChocolateArmpits> what I meant was more like this
[14:49:16 CEST] <ChocolateArmpits> ffmpeg -re -i /home/user/Videos/movie.mp4 -acodec aac -vcodec libx264 -f fifo -fifo_format flv -map 0:v -map 0:a  rtmp://x.rtmp.youtube.com/live2/some-stream-key
[14:53:24 CEST] <Hola> ChocolateArmpits, that didn't help. Same issue appearing. And even it fails with Error writing trailer of rtmp://x.rtmp.youtube.com/live2/xxxx: End of file
[14:54:15 CEST] <ChocolateArmpits> Hola, can you paste the output log ? obviously with the key removed
[14:54:15 CEST] <Hola> if i put those options then it tries to auto recover which is what I want. But the Bit Rate and Size is NA that causes the remote Youtube RTMP server to show weird resolution. (Thats my assumption :))
[14:56:42 CEST] <Hola> I have removed my stream key from log. but u can access log here . https://pastebin.com/j35sicX0
[14:57:16 CEST] <Hola> I disconnected my network for 10+ seconds and then re-enabled it.
[14:57:43 CEST] <Hola> If i put those reconnection parameters, then it does not break like the one in logs. It tries to reconnect successfully when network comes online.
[14:59:14 CEST] <ChocolateArmpits> but regardless of that, did youtube receive a compatible stream ?
[15:00:57 CEST] <soteri> Hi guys
[15:01:50 CEST] <soteri> Any of the maintainers of the project available to do some FFMPEG consulting for some issues my company is facing with our FFMPEG-based video-processing pipeline?
[15:02:39 CEST] <soteri> if you are please msg me personally so that we can have a quick chat about the issues we are facing and to see if you can assist in resolving these issues for us
[15:02:40 CEST] <Hola> ChocolateArmpits, here is the screen shot https://ibb.co/f5d4G8
[15:02:44 CEST] <Hola> same issue
[15:04:21 CEST] <ChocolateArmpits> Hola, can you try setting an appropriate resolution on the command line?
[15:04:46 CEST] <Hola> ok is it with -s 400x400?
[15:05:32 CEST] <ChocolateArmpits> yeah, just change the numbers to something that seems youtube-ish
[15:06:26 CEST] <Hola> ok
[15:07:14 CEST] <Hola> it does not have any effect.
[15:07:28 CEST] <Hola> same issue appearing.
[15:11:22 CEST] <Hola> It does not even use provided bitrate etc.
[15:13:53 CEST] <ChocolateArmpits> Hola, I think you should then try rather than streaming rtmp to youtube, try to do it locally
[15:15:32 CEST] <ChocolateArmpits> even if you raise the issue on the bug tracker, to have it solved faster it will be best to do all sorts of tests run under with debug loglevel
[15:15:56 CEST] <while> anyone know about concatenating png's as frames onto the end of an ogg theora/vorbis file?
[15:16:56 CEST] <ChocolateArmpits> while are the frames named in a predictable manner?
[15:17:07 CEST] <while> yes
[15:18:31 CEST] <ChocolateArmpits> then have two inputs, one of the theora file, the other as an image sequence using -f image2 and appropriate input options for it. Then use the concat multimedia filter to append the second video source to the first. You'll have to match the resolution and the pixel format of both inputs to match
[15:18:48 CEST] <while> thank you
[15:20:21 CEST] <while> and does the same principal hold for audio pieces (such as in .wav or .mp3)?
[15:20:57 CEST] <Hola> ChocolateArmpits, thanks for information. but do you feel its a bug?
[15:21:26 CEST] <ChocolateArmpits> Hola, I've had issues with fifo muxer and rtsp but on windows, that was solved after I filed a bug report
[15:22:18 CEST] <ChocolateArmpits> while, it's the same filter for audio as well. Look in the documentation https://ffmpeg.org/ffmpeg-filters.html#concat
[15:23:28 CEST] <ChocolateArmpits> Hola, here's the fixed ticket https://trac.ffmpeg.org/ticket/6308
[15:23:34 CEST] <ChocolateArmpits> for a reference
[15:24:06 CEST] <ChocolateArmpits> Hola, read this if you want to report bugs
[15:24:06 CEST] <ChocolateArmpits> http://ffmpeg.org/bugreports.html
[15:25:34 CEST] <Hola> all right - Thank you ChocolateArmpits for all the help :))
[15:25:38 CEST] <ChocolateArmpits> np
[15:31:19 CEST] <Hola> ChocolateArmpits, with more debug logs i found an issue : cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[15:31:32 CEST] <Hola> and its appearing again and again
[15:32:24 CEST] <ChocolateArmpits> Hola, dts is display timestamp upon decode, so it shouldn't be related if flv by itself works with youtube
[15:32:59 CEST] <ChocolateArmpits> though if you think your input is bad, you can try using testsrc lavfi video input
[15:33:07 CEST] <ChocolateArmpits> and sine lavfi filter for audio
[15:33:47 CEST] <Hola> ok, i will try that.
[15:33:47 CEST] <ChocolateArmpits> so
[15:33:48 CEST] <ChocolateArmpits> ffmpeg -f lavfi -re -i testsrc2=s=1280x720 -f lavfi -re -i sine -map 0:v -map 1:a
[15:36:05 CEST] <Hola> just tried it, same issue with fifo muxer.
[15:36:17 CEST] <Hola> I think i need to try master branch to see if its different
[15:36:31 CEST] <Hola> Thanks alot ChocolateArmpits :)
[18:04:03 CEST] <th3_v0ice> Could a decoder time_base somehow be screwed up? av_dump_format() shows that decoder time_base is 1001/60000, but when I start to decode its 1001/120000.
[18:04:42 CEST] <th3_v0ice> Problem occurs in the output file where the framerate is not 29.97fps but 15fps. If I divide the packet.pts and packet.dts in half, then it works properly.
[18:05:10 CEST] <th3_v0ice> Does anyone know what could be the problem?
[18:08:12 CEST] <kepstin> th3_v0ice: not sure what you mean - is the value stored in the avstream->time_base changing?
[18:10:30 CEST] <th3_v0ice> kepstin: Not in the avstream->time_base. Stream base doesnt change. But the AVCodecContext->time_base when I open the decoder context is at 1001/60000, but when I start to decode it changes to 1001/120000.
[18:11:29 CEST] <kepstin> th3_v0ice: you've read the comments on the AVCodecContext stuff? the time_base field there is deprecated, and there's some weird stuff involving the ticks_per_frame field in mpeg2 and h264.
[18:13:44 CEST] <kepstin> I think unless you do any conversions yourself, the timestamps on both the avpacket and avframe should be in the avstream timebase
[18:15:04 CEST] <kepstin> (the transcoding.c example explicitly converts from stream to codec timebase before decoding)
[18:15:09 CEST] <th3_v0ice> kepstin: Thanks for pointing this out! I have overlooked this information. It says that I should use the framerate instead. What would be the correct way to do that actually?
[18:15:31 CEST] <kepstin> easiest thing? completely ignore the codec context timebase for decoding and just leave everything in stream timebase
[18:15:59 CEST] <th3_v0ice> Haha, any other way? Just in case that this fails.
[18:16:25 CEST] <kepstin> other way is to do what the transcoding.c example does, and convert from stream timebase to codec timebase before sending the packet to the decoder
[18:17:17 CEST] <th3_v0ice> I was doing that already actually.
[18:18:22 CEST] <kepstin> but (iirc), the decoder should be simply passing through the pts provided on the input packets to the pts on the output frames.
[18:21:10 CEST] <th3_v0ice> But isnt the trancoding.c using the field that is deprecated?
[18:21:23 CEST] <th3_v0ice> the AVCodecContext->time_base?
[18:22:03 CEST] <kepstin> yes, it's an old example
[18:23:53 CEST] <th3_v0ice> Removing the av_packet_rescale_ts(packet, stream->time_base, codec->time_base) makes 50fps in the output file :)
[18:25:14 CEST] <kepstin> well, you have to check that all your other scaling on the encoding side is correct, too - that the encoder timebase is set to match what you're sending to it, and you're rescaling to the container timebase after encoding. (container can reject your requested timebase and tell you to use a different one)
[18:27:59 CEST] <th3_v0ice> Hmmm, that is actually the missing link that I was thinking about this whole time. So encoder->time_base and decoder->time_base should be identical?
[18:30:24 CEST] <kepstin> th3_v0ice: there's no reason for them to be the same, but if it simplifies your code, why not?
[18:30:53 CEST] <kepstin> (an example where they'll be different is if you're using filters, and there's a filter that changes timebase)
[18:31:35 CEST] <kepstin> in that case, you'd set the encoder timebase to the filter's output timebase, of course.
[18:38:04 CEST] <th3_v0ice> kepstin: Can I then specify the buffersink time_base?
[18:38:30 CEST] <th3_v0ice> Or how can I set the filter to change the time_base?
[18:39:52 CEST] <kepstin> for buffersink, you'd have to read the timebase out of the ctx->inputs[0]->time_base field
[18:40:04 CEST] <kepstin> that'll be the time_base of the frames you're getting from the buffersink api
[18:41:36 CEST] <th3_v0ice> Hmm, ok, but is it possible to get the filter to change the input time_base to output time_base? From buffersrc->time_base to buffersink->time_base?
[18:44:19 CEST] <kepstin> no, you should do that yourself. It's just a single function call to rescale pts values, way easier than setting up a filter chain...
[18:45:14 CEST] <th3_v0ice> Thanks for helping me man! I will rescale the values manually was just wondering if its possible to do with filters.
[18:45:26 CEST] <kepstin> what I meant was that some filters, as a side-effect of whatever other operation they do, also change the timebase
[18:46:04 CEST] <kepstin> e.g. the fps filter changes the video framerate (drop/duplicate frames), and also sets a new timebase calculated from the requested framerate.
[18:47:01 CEST] <th3_v0ice> Oh, ok. Thanks once again!
[18:47:09 CEST] <kepstin> so if you use filters, you have to remember that the output of the filters might be a different timebase from the input - which means you have to either set the encoder timebase to the value from the filter output, or rescale them
[18:48:34 CEST] <th3_v0ice> Ok
[18:49:50 CEST] <th3_v0ice> Thanks!
[19:30:36 CEST] <lungaro> i'm curious of taking a live video feed of a IP camera and saving it locally. Is anyone aware of a place to look for video cameras which support this?
[19:38:51 CEST] <CoreX> lungaro are you using ffmpeg to do it ?
[19:43:52 CEST] <lungaro> That's what I was thinking but am not sure tbh, I am a IP camera newb
[19:49:30 CEST] <DHE> there are lots of cameras as well. I've seen some that let you put in FTP credentials and it auto-uploads any time it sees movement... in which case no ffmpeg required.
[19:50:22 CEST] <lungaro> interesting, i'll have to do some more research then, I dont know where to find these cameras yet, but I suppose I should settle on WIFI/IP
[19:52:31 CEST] <DHE> I've seen cameras that support rtsp as well, and ffmpeg can connect to that just fine. etc.
[19:52:41 CEST] <lungaro> nice
[00:00:00 CEST] --- Tue Jul 31 2018