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

[burek]

[01:57:22 CEST] <classsic> Hi, somebody can pointme on error: "Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly"
[02:41:32 CEST] <kode54> classsic: are you programming your own ffmpeg libavformat multiplexing?
[02:41:43 CEST] <kode54> the transport packets should have timestamps on them
[02:42:04 CEST] <kode54> if it's just parsing a file from disk, then it's some sort of legacy format that isn't being read with proper timestamps
[02:42:50 CEST] <kode54> (for example, H.264 and similar video streams encode the IBBBBPBBBBPBBB etc sequence really as IPPPPPBBBBBBBBBBBBBI.... etc
[02:43:08 CEST] <kode54> then they use container timestamps to detangle the encode/decode order into the playback order
[02:43:40 CEST] <kode54> basically, it encodes first the I frame, then all the forward prediction frames, then all the bidirectional prediction frames
[07:52:12 CEST] <Tatsh> anyone know why when i add `-f alsa -i hw:1,0` to a command, the video output becomes yuv420p(progressive), where as before it was yuv420p ?
[10:54:31 CEST] <termos> hmm I'm having a hard time setting "enable_er" flag on h264 decoding, am I suppose to set it. Tried setting it on the AVOptions for avformat_open_input and av_opt_set_int-ing it on the codec_context->priv_data
[15:32:52 CEST] <Randolf> I'm using "ffmpeg -f concat -safe 0 -i files.lst ..." to join a number of .AVI files from my camera, and it's working well.  (On the same command line I'm also overlaying a mostly-transparent PNG and a timestamp, which is also working well.)  How can I add a half-second-long gap of black silence between each of the videos?  Thanks.
[15:33:49 CEST] Action: Randolf is using ffmpeg 3.4.6 on Ubuntu Linux 18.04.01 LTS.
[15:36:56 CEST] <BtbN> You should update that ffmpeg, it's old.
[15:37:19 CEST] <BtbN> Otherwise, create a compatible video clip (exact same codecs and parameters) and put it in between the segments?
[15:40:43 CEST] <Randolf> BtbN: Oh, okay.  I guess Ubuntu's "apt" system is sorely outdated.  I'll bug them about that.
[15:41:04 CEST] <BtbN> They won't do any updates, they prefer to be "stable".
[15:41:20 CEST] <DHE> if you run a 1.5 year old OS, you get 1.5 year old software packages
[15:41:29 CEST] <DHE> doubly so for an LTS branch
[15:42:24 CEST] <DHE> (not necessarily a bad thing in general, just be aware of it)
[15:42:30 CEST] <Randolf> BtbN: I was reading various options on Google for that, but found none that actually worked.  Even generating a .avi or .mp4 using ffmpeg resulted in a video clip that isn't compatible with the .AVI files my camera created (lots of errors show up on the screen when I try to include this in my files.lst file), so I'll just have to create the black video clip with my camera.
[15:43:02 CEST] <Randolf> DHE: That makes sense.
[15:43:13 CEST] <BtbN> That'd probably be the easiest option. Put the cap on, mute the mic, and record for a few seconds.
[15:43:24 CEST] <Randolf> BtbN: Yup.
[15:46:40 CEST] <Randolf> Thanks for all your help everyone.
[17:32:08 CEST] <giaco> hello
[17:32:59 CEST] <giaco> I need some help to workaround TCP h264 client issues
[17:35:30 CEST] <giaco> i have a TCP stream at http://192.168.0.1/videostream.asf, I can successfully play it with ffplay, but after a while the client stops receiving any data and the image freeze
[17:35:51 CEST] <giaco> Client (ffmpeg) doesn't complain and wait endlessly
[17:36:16 CEST] <giaco> if I stop and restart ffplay it streams correctly for some more time, then problem repeats
[17:37:07 CEST] <giaco> what's the problem? TCP? Streaming server? HTTP? Client? How can I profile and workaround this?
[17:40:19 CEST] <kepstin> hard to say without any other details or logs, but the issue is probably that the server just stopped sending data, but without actually closing the connection (otherwise ffplay would have exited)
[17:45:36 CEST] <kepstin> could also possibly be a clock desync issue. i forget whether ffplay has a mode to display video as fast as its received rather than retime it to the local clock.
[17:47:04 CEST] <kepstin> consider using mpv with the --untimed option
[17:48:20 CEST] <kepstin> (if the stream has audio, you might also need one of the --video-sync display-* options)
[18:22:49 CEST] <InTheWings> Lavc58.42.100 throws "[vc1 @ 0x61b0000bd080] Failed to open codec in avformat_find_stream_info" for every raw VC-1 samples. Was not happening with Lavf58.20.100
[18:23:46 CEST] <InTheWings> example https://streams.videolan.org/samples/archive/all/vc1%2Bvc1%2B%2B%2Bartifacts4.vc1
[18:25:49 CEST] <kepstin> huh, that's weird. despite the message it still plays in ffplay.
[18:43:43 CEST] <InTheWings> seems it was parsing extradata earlier, not it's late
[18:46:08 CEST] <InTheWings> codec starts now with invalid state (no extradata) when using libaformat. Unsure if there's a way to get the parameters update
[18:46:17 CEST] <shreds> Hi! I've been using ffmpeg for a while for various projects in the past but now I'm stuck on something. I have a crappy server serving video over m3u8. I can dump it to mp4 totally fine but after a few minutes FFMPEG says "ffmpeg EOF on sink link / No more output streams to write to, finishing." and stops normally. The thing is, the stream shouldn't end. I guess it's because of a crappy connection or something. My
[18:46:18 CEST] <shreds> question is: is there any way of adding a timeout so FFMPEG can wait until the video output works again?
[18:48:20 CEST] <shreds> here's an example of commands I send to ffmpeg: ffmpeg -v trace -i https://live_feed.com/chunklist_b2592000.m3u8 -movflags frag_keyframe+empty_moov -f mp4 test_file.mp4
[18:52:50 CEST] <shreds> I'm trying -timeout at the moment
[19:02:14 CEST] <giaco> kepstin: thanks for the answer
[19:10:16 CEST] <BtbN> shreds, the server is signalling that the stream ended it seems
[19:10:34 CEST] <BtbN> also, why are you re-encoding without specifiying any parameters on the codecs?
[19:11:11 CEST] <shreds> i just want to copy whatever source uses
[19:11:15 CEST] <shreds> I just found out about -reconnect -reconnect_at_eof -reconnect_streamed and -reconnect_max trying these out atm
[19:11:27 CEST] <BtbN> Well, then tell it to just copy the streams?
[19:11:28 CEST] <kepstin> shreds: if you want to copy, you explicitly have to tell ffmpeg to do so
[19:11:37 CEST] <shreds> I added -c:v copy -c:a copy
[19:11:43 CEST] <BtbN> Just use -c copy
[19:11:55 CEST] <shreds> ok -c copy will be enough for both audio and video?
[19:12:15 CEST] <BtbN> The whole point of it is that it affects everything.
[19:12:16 CEST] <furq> -c with no stream specifier applies to all streams
[19:13:01 CEST] <shreds> I see!
[19:13:35 CEST] <shreds> now looks like ffmpeg -v trace -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -timeout 999999 -t 999999 -i https:/live_feed.com/f386e3b206814e1f8c8c1c71c0f8e748/chunklist_b2592000.m3u8 -c copy -movflags frag_keyframe+empty_moov test.mp4
[19:13:51 CEST] <shreds> (don't mind the huge timeouts, just trying for the sake of it)
[19:13:52 CEST] <kepstin> shreds: i don't think the reconnect otpions apply to hls
[19:14:08 CEST] <shreds> oh :( reconnect_at_eof sounded like what I needed
[19:14:28 CEST] <shreds> since my problem is the feed going EOF on sink link / No more output streams to write to, finishing.
[19:14:32 CEST] <kepstin> hls is already doing periodic polling of the playlist file, reconnecting each time if needed
[19:14:42 CEST] <shreds> I'm starting to believe it's my internet connection dropping out
[19:14:45 CEST] <shreds> ok I see
[19:15:29 CEST] <kepstin> so the problem is that the playlist has either stopped updating (and you hit the -max_reload limit, which defaults to 1000) or the server has explicitly indicated eof
[19:16:12 CEST] <giaco> if I have a video+audio stream over TCP and I need to stream it over an unreliable link (3G), how should I configure the client (ffmpeg/ffplay) to get a best effort service?
[19:16:40 CEST] <shreds> @kepstin the stream should never end since it's an always online camera feed. so I'm wondering whether it's my net dropping or theirs
[19:16:52 CEST] <shreds> when I check the stream via VLC I never have issues
[19:16:55 CEST] <giaco> I mean. What can I do when I have TCP instead of UDP as server but I want to get something out of it?
[19:17:05 CEST] <shreds> or whatever player i.e. mpv
[19:17:20 CEST] <kepstin> shreds: ffmpeg logs would be helpful
[19:17:34 CEST] <shreds> @kepstin gimme a sec I'll send some
[19:19:18 CEST] <kepstin> giaco: you're probably gonna need a more robust client that supports reconnecting / buffering in that case.
[19:20:19 CEST] <giaco> kepstin: is ffmpeg/ffplay capable? Do you have any suggestion?
[19:20:47 CEST] <kepstin> giaco: streaming using a segmented format (hls, dash) rather than over a single tcp stream to allow the player more control might be a good idea.
[19:21:11 CEST] <kepstin> other than that i can't really say, since you haven't really said much about what your actual requirements are...
[19:23:43 CEST] <giaco> kepstin: but what if I don't have control on the camera? Let me explain. I have one of those cheap chinese ip cameras. The only endpoint I have is a http stream. I could put a raspberry between the camera and the gateway, but I still need to learn how to handle a unrealiable device over TCP. I need an intelligent client and I'm looking at a properly nfigured ffmpeg, but I'm not sure
[19:24:14 CEST] <shreds> @kepstin here's my latest attempt's log: https://gist.github.com/tbergeron/d8be3b3c46c6966f0829c744b29bbf0d thx for the help btw
[19:25:16 CEST] <shreds> always stops around 20mb of data
[19:27:34 CEST] <kepstin> shreds: huh, that's icecast, not hld. That's weird, normally an .m3u8 input indicates hls
[19:27:38 CEST] <kepstin> not nls*
[19:27:59 CEST] <kepstin> that said, i can't tell because you've redacted the input url
[19:29:50 CEST] <shreds> I tried with multiple input URLs, even copied random feed URLs I found off the web to try and the same always happen no matter the format. For example this is a local TV feed in my province: https://teleqmmd.mmdlive.lldns.net/teleqmmd/f386e3b206814e1f8c8c1c71c0f8e748/chunklist_b2592000.m3u8 same happens with that one
[19:30:10 CEST] <shreds> and yes I just realized that's icecast when I noticed "Ice-MetaData: 1"
[19:30:44 CEST] <BtbN> The error you posted indicates a clean EOF though, no connection error. Unless the icecast client interprets it as such
[19:31:28 CEST] <shreds> I'll try to provide a better example
[19:31:33 CEST] <kepstin> shreds: that example link is an HLS livestream, hmm.
[19:32:26 CEST] <kepstin> shreds: i've confirmed that it works fine with ffmpeg as an input, it's successfully reloading the playlist and getting new segments :/
[19:34:39 CEST] <shreds> yeah just noticed that one is different! :-/ I'm trying with that one to see if it records longer than my initial m3u8/icecast one. I'll provide logs
[19:35:32 CEST] <shreds> for now it seems to work, had to remove "-movflags frag_keyframe+empty_moov" though
[19:35:34 CEST] <kepstin> please don't use -v trace, it's too  noisy
[19:35:43 CEST] <kepstin> -v verbose is a good start
[19:35:56 CEST] <shreds> ok I agree lol it's kinda crazy
[19:37:02 CEST] <kepstin> i suggest avoiding mp4, it's not a good format for live stuff in general. consider using mkv, or even mpegts
[19:39:02 CEST] <shreds> ok I'll follow your guidelines since you seem to know ffmpeg way better than me hehe do I just need to change the output filename or specify also -f mkv or something like that?
[19:39:18 CEST] <shreds> I've been reading the docs for a week or so and there's still so much stuff left to learn woah
[19:41:56 CEST] <kepstin> changing the output filename to .mkv would be sufficient here, yeah.
[19:42:03 CEST] <shreds> awesome thx
[19:42:17 CEST] <kepstin> (if you don't specify a -f option, ffmpeg automatically guesses the output format from the filename)
[19:43:10 CEST] <shreds> that's good to know!
[19:45:58 CEST] <kepstin> if you don't specify a -c option, ffmpeg automatically picks some codecs (which probably aren't the ones you wanted) and re-encodes everything using the default settings (which probably aren't what you want).
[19:46:25 CEST] <kepstin> so, it's best practise to always specify the -c option and any appropriate options for the codec you picked :)
[19:48:30 CEST] <shreds> oh damn ok! I understand now why it's so important to specify them! :O
[19:48:36 CEST] <shreds> wow didn't know that but it makes so much sense
[19:51:53 CEST] <shreds> makes so much sense, it even seems to have improved what I'm trying to do. now with -c copy it seems to pick up the right codecs and don't crash so far ( logs http://ix.io/1XVv )
[19:53:12 CEST] <Chagall> it would be nice if going from one container to another would prioritize -vcodec copy when possible
[19:54:45 CEST] <Chagall> i.e. use the same codec without having to write it out when the input codec is not the default for the output container
[19:58:14 CEST] <shreds> @kepstin had no errors for the past 20 mins :O first time I can write more than 20mb of video! thx the -c copy and mkv tip really helped I believe, you rock!
[19:59:02 CEST] <kepstin> shreds: it's possible that without -c copy, it was simply running too slow due to transcoding the video, so the next segment it tried to read had already been deleted
[19:59:53 CEST] <shreds> makes so much sense when you think about it this way, I was worried I had stumbled upon an esoteric bug but I'm getting my hopes up at the moment hehe
[20:07:07 CEST] <giaco> what is better for point-to-point stream: mpegts + udp or rtp?
[20:07:43 CEST] <giaco> with rtp I need one port for each stream, right?
[20:07:57 CEST] <giaco> do I have any alternative?
[20:21:20 CEST] <jpb> giaco: check to see if rtsp is available on the device.  if so, that's probably the easiest to use
[20:26:52 CEST] <giaco> jpb: it is not. I've been doing reverse engineering for hours but no luck. I'e found http+mjpeg, http+h264 and a proprietary udp protocol but no rtsp
[21:51:40 CEST] <shreds> @kepstin here's an update: ffmpeg doesn't stop anymore which is GREAT! but the resulting mkv in VLC: has no sound and displayed duration is wrong. Jumping forward/backward is almost impossible. Maybe I should try straight mpegts? does that problem ring a bell to you?
[21:52:56 CEST] <shreds> Duration is weird, the duration should say 1 hour but in VLC it says 11 minutes and in Plex it says 2 hours LOL
[21:57:58 CEST] <kepstin> duration on any file as its being written can't be determined reliably
[21:58:08 CEST] <kepstin> once you stop ffmpeg, it'll update the duration in the file header
[21:58:50 CEST] <kepstin> seeking is pretty meh in files without indexes, regardless of format, but i dunno if mpegts might work better for your use case.
[21:58:59 CEST] <kepstin> would have to see ffmpeg output to say what's up with the audio
[21:59:59 CEST] <shreds> *I mean once I stopped ffmpeg and it has been written on the disk
[22:00:22 CEST] <shreds> I'll run another test and send the output log
[22:01:31 CEST] <kepstin> if you stop ffmpeg properly (by hitting 'q' in the console, or by sending it SIGINT - e.g. Ctrl-C in the console) then it should update the file with a seek index and duration.
[22:01:39 CEST] <kepstin> before exiting
[22:02:55 CEST] <shreds> ok hum that should be okay I guess, I had called "kill <pid> on it (without -9) so I guess it should send SIGINT to that process properly?
[22:03:23 CEST] <kepstin> hmm, that does SIGTERM, not SIGINT. Those might be handled differentlly
[22:03:47 CEST] <shreds> oh maybe!
[22:04:04 CEST] <kepstin> try kill -sINT (kill -2)
[22:04:24 CEST] <furq> just kill -INT works
[22:04:36 CEST] <furq> it should always be 2 though
[22:06:03 CEST] <shreds> ok I'll try kill -2 <pid> maybe that'll make ffmpeg properly finish the file thx
[22:14:35 CEST] <shreds> @kepstin here's the log of my last test: http://ix.io/1XWj
[22:14:38 CEST] <shreds> seems to work with -2!
[22:14:51 CEST] <shreds> my test is shorter but jumping in the video works and audio too
[22:16:12 CEST] <shreds> resulting video plays MUCH better wow thanks
[23:02:11 CEST] <void09> anyone had success with either croppign a video or pan scan it without re-encoding (or manually adjusting player settings) ?
[23:02:41 CEST] <void09> i tried mkvtoolnix, but no player i tried respects the header info about crop pixels. only changing aspect ratio works.
[23:03:17 CEST] <JEEB> yea because those values have a history for just using it to fix the H.264 video stream
[23:03:39 CEST] <JEEB> and in that case you should just fix the H.264 stream
[23:03:50 CEST] <JEEB> and thus I think the only thing that added support was Haali's demuxer?
[23:04:05 CEST] <JEEB> maybe vlc also keeps that info, but not sure
[23:04:13 CEST] <void09> i tried vlc/mplayer/mpv/smplayer
[23:04:29 CEST] <void09> so what is the solution to this ? none ?
[23:05:00 CEST] <void09> it would be nice to have these adjustments embedded in the file as meta data, and players apply them
[23:05:28 CEST] <JEEB> is this about 4:3 blu-ray stuff that's encoded as 16:9 due to blu-ray rules? :P
[23:05:59 CEST] <Chagall> I thought 4:3 blu-ray is legal, just not widely used
[23:06:06 CEST] <JEEB> hmm
[23:06:11 CEST] <JEEB> I would have to peek into the PDF
[23:06:19 CEST] <void09> no, it's a tvrip: https://ptpimg.me/112913.png
[23:06:21 CEST] <JEEB> IIRC it said only 16:9 is legal
[23:07:00 CEST] <void09> converted that one to 4:3 and it looks proper, but like this : https://ptpimg.me/2383w4.png
[23:07:33 CEST] <void09> it can be zoomed in to almost perfect 16:9
[23:07:39 CEST] <void09> pan-scanned*
[23:07:57 CEST] <Chagall> JEEB: https://en.wikipedia.org/wiki/Blu-ray#Video
[23:08:11 CEST] <Chagall> ah, display aspect ratio is still 16:9
[23:08:30 CEST] <JEEB> yea, SD can be 720xYYY
[23:08:36 CEST] <JEEB> with a non-1:1 AR
[23:08:51 CEST] <JEEB> basically they added bw compat against DVD mastered content
[23:08:59 CEST] <JEEB> so you can use the same extras etc
[23:09:06 CEST] <Chagall> I assumed the 1440x1080 res could display in 4:3
[23:09:32 CEST] <void09> this is what I am aiming for, to be displayed in the player, without touching video settings : https://ptpimg.me/k69q72.png
[23:09:33 CEST] <Chagall> the SD support is nice but sadly some companies prefer releasing shitty upscales
[23:10:09 CEST] <JEEB> I like the 720p60/1.001 support most :P
[23:10:53 CEST] <JEEB> and yea just found one of the tables
[23:11:15 CEST] <JEEB> Allowed combinations of parameters for 1920x1080 video format
[23:11:50 CEST] <JEEB> only 16:9 aspect ratio for display approved, but you can have 1920x1080 or 1440x1080
[23:12:01 CEST] <void09> no ideas ? :\
[23:12:09 CEST] <JEEB> same for the 720p format in the spec
[23:13:20 CEST] <kepstin> the 1440x1080p anamorphic format is probably for compat with avchd
[23:13:35 CEST] <JEEB> quite likely
[23:14:11 CEST] <cehoyos> Or dvb
[23:15:31 CEST] <JEEB> avchd was heavily utilized by blu-ray writers recording digital tv in japan, so quite likely it came from that way too
[23:15:53 CEST] <JEEB> mostly due to japan being one of the few countries where empty BD media actually made sense cash-wise
[00:00:00 CEST] --- Tue Oct  8 2019