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

[burek]

[11:22:51 CEST] <Guest48> Hey guys. I'm a developer, running into an issue with ffmpeg. Where would be right place for looking for answers on a more deeper level (watching raw RTSP data with ngrep and finding issues in comparison to libraries that do work with udp_multicast)? 
[11:25:30 CEST] <Guest48> With VLC (connecting to same RTSP server) the data is virtually identical to the data exchanged by ffmpeg, while using udp_multicast, with the exception that I can see that ffmpeg does not request the URL I request rtsp://xx.xx.xx.xx/live.sdp append with ?TrackID=1, as where VLC does).
[11:29:28 CEST] <JEEB> Guest48: VLC utilizes live555 for the rtsp I think, while FFmpeg's libavformat has its own implementation based on the UDP/RTP things - I think in libavformat/rtsp.c
[11:30:17 CEST] <Guest48> Aight @JEEB, thanks. Hadn't tried HEAD yet, so let me give that a go first.
[11:31:07 CEST] <JEEB> Guest48: the command line application can list you the same AVOptions you will see in that C file with -h demuxer=rtsp . which is a bit messy but at least there's a way to list those AVOptions from the application as well :)
[11:31:42 CEST] <JEEB> also do note that it then probably utilizes the UDP protocol underneath, and that has its own options
[11:32:18 CEST] <JEEB> in other words, if you can access the UDP multicast stream with just the UDP protocol, you should then attempt to see if it's some specific option
[11:32:30 CEST] <JEEB> like source registration etc
[11:32:42 CEST] <JEEB> and if such flags are needed, look if you can pass them from the rtsp or rtp levle
[11:32:45 CEST] <JEEB> *level
[11:39:46 CEST] <Guest48> @JEEB; yeah, I hear you, but I have to ask the RTSP server to tell the switch that the data has to come to that specific client/IP. Beside of course I can request that in a different way, but then I have another problem, because that would mean I would need to give ffmpeg a lot of meta data about the stream, which is alright, but that doesn't seem to work too smoothly either: ffprobe -analyzeduration 0 -probesize 32 -framerate 25 -rtsp_transport
[11:39:47 CEST] <Guest48>  tcp -i rtsp://10.10.10.144/live.sdp --> Option framerate not found ~~ cannot find anything at trac.ffmpeg.org, other than dating back to 2012 at the latest.
[11:40:18 CEST] <Guest48> Same thing happens when I add video_size; then it tells me that I *didn't* specify video_size.
[11:40:57 CEST] <JEEB> those options really aren't for that. what you are most likely later seeing is the fact that you didn't get any video packets
[11:41:13 CEST] <JEEB> thus the decoder was never able to initialize properly
[11:41:23 CEST] <Guest48> Well, it happens with rtsp_transport tcp as well.
[11:41:40 CEST] <JEEB> yes, then it just means that for whatever reason you're not getting the stream you think you are getting
[11:41:43 CEST] <Guest48> And it does work if I remove the low probesize and analyzeduration options.
[11:41:51 CEST] <JEEB> yes
[11:42:00 CEST] <JEEB> you need to probably read more than 32 bytes of data
[11:42:08 CEST] <JEEB> to initialize a H.264 or whatever decoder
[11:43:32 CEST] <Guest48> @JEEB, yeah, so that's exactly the challenge to beat here, because I am attempting to increase the start time by providing as much data as required, but it seems that it doesn't "like that" (which is unrelatedd to tcp_transport udp_multicast, by the way).  ;)
[11:43:47 CEST] <Guest48> data=meta data*
[11:44:04 CEST] <JEEB> Guest48: that will not get you H.264 etc stream resolutions etc
[11:44:17 CEST] <JEEB> the framework itself will work without any data if you are trying to minimize the amount of read data
[11:44:25 CEST] <JEEB> not sure if the command line applications handle that though
[11:44:36 CEST] <JEEB> heck, in the API you can skip probing altogether
[11:44:49 CEST] <JEEB> keep reading packets and at some point you just have more data on your input stream parameters :P
[11:46:44 CEST] <JEEB> thus I have a feeling that you're probably misunderstanding the problem if you're trying to just feed a resolution and a frame rate to ffprobe to get it to show that info. it's the decoder state it's printing there
[11:47:04 CEST] <JEEB> the libavformat/libavcodec APIs work just fine without you probing first
[11:47:12 CEST] <JEEB> not sure if the command line apps do
[11:47:15 CEST] <Guest48> Yeah, please forgive me for the confusion; replace ffprobe with ffmpeg; same result.
[11:48:12 CEST] <Guest48> @JEEB; yeah, but I am developing on a "a little bit a" higher level language; so the API is not direct available me. ;)
[11:48:29 CEST] <Guest48> I was hoping I could "keep it simple". ;)
[11:48:40 CEST] <JEEB> anyways, this doesn't seem to be a FFmpeg itself development discussion
[11:48:46 CEST] <JEEB> so please let's move FFmpeg usage discussion to #ffmpeg
[11:48:55 CEST] <Guest48> Yeah, I gotcha.
[11:49:00 CEST] <Guest48> Thanks anyway, @JEEB.
[17:08:28 CEST] <thardin> the heck, got spam to a mostly dead email cribbed from ffmpeg commits
[17:08:47 CEST] <thardin> I guess it's not too unexpected
[17:12:09 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:b4bf7226aff2: avcodec/vp3: Check that theora is theora
[17:12:09 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:58c7f419ce75: avcodec/vp3: Check for end of input in vp4_unpack_vlcs()
[17:12:09 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:db6ed2b82864: avcodec/vp8: do vp7_fade_frame() later
[17:30:33 CEST] <durandal_1707> when new release is going to appear?
[17:31:06 CEST] <durandal_1707> also when irc bot will be fixed?
[17:33:50 CEST] <durandal_1707> if nothing happens soon, i will demand from current leader to sidestep from all its current positions
[17:35:16 CEST] <thardin> please send the codes
[17:35:59 CEST] <durandal_1707> codes of what?
[17:39:39 CEST] <Lynne> sssh, you got your double fft now
[17:40:30 CEST] <durandal_1707> yes, thank you very much, how to thank you?
[17:43:11 CEST] <Lynne> dunno, finish a decoder?
[17:43:36 CEST] <cone-715> ffmpeg 03James Almer 07master:0c7cfd2c1919: avformat/av1: add color config values to AV1SequenceParameters
[17:43:37 CEST] <cone-715> ffmpeg 03James Almer 07master:68e48e5d97c1: avformat/av1: split off sequence header parsing from the av1C writing function
[17:43:38 CEST] <cone-715> ffmpeg 03James Almer 07master:0d597a69bad6: avformat/av1: rename some AV1SequenceParameters fields
[17:43:39 CEST] <cone-715> ffmpeg 03James Almer 07master:9a44ec94100a: avformat/av1: combine high_bitdepth and twelve_bit into a single bitdepth value
[17:43:40 CEST] <cone-715> ffmpeg 03James Almer 07master:ce6a98e83061: avformat/dashenc: update stream extradata from packet side data
[17:43:41 CEST] <cone-715> ffmpeg 03James Almer 07master:1cf2f040e34b: avformat/dashenc: fix writing the AV1 codec string in mp4 mode
[17:43:47 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:7d74b36f1577: avformat/vividas: Check if extradata was read successfully
[17:43:48 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:171286f6a4fa: avformat/vividas: Check buffer size before allocation
[17:43:49 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:3addf0d4825b: avcodec/clearvideo: fix invalid shift in tile size check
[17:43:50 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:38f2ecc07be7: avformat/vividas: forward errors from track_header()
[17:43:51 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:97ae13ba240f: avformat/vividas: Check that value from ffio_read_varlen() does not overflow
[17:43:52 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:076dd1473b10: avcodec/interplayvideo: Avoid ff_get_buffer() during init
[17:44:14 CEST] <jamrial> michaelni: huh, a race
[17:44:29 CEST] <durandal_1707> ac4, imm5, siren? or something else?
[17:44:36 CEST] <michaelni> jamrial, seems so
[17:46:46 CEST] <nevcairiel> ac4
[17:47:35 CEST] <durandal_1707> it will not be complete as cant get samples with full coverage
[17:48:34 CEST] <durandal_1707> i could just finish last transform step that adds high spectrum audio data
[17:51:00 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:8e41675e1868: avformat/vividas: Check if extradata was read successfully
[17:51:01 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:c3ef24d9baf6: avformat/vividas: Check buffer size before allocation
[17:51:02 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:5dc94924d0fb: avcodec/clearvideo: fix invalid shift in tile size check
[17:51:03 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:8bac648359b7: avformat/vividas: forward errors from track_header()
[17:51:04 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:07357cd93355: avformat/vividas: Check that value from ffio_read_varlen() does not overflow
[17:51:06 CEST] <cone-715> ffmpeg 03Michael Niedermayer 07master:a3adc3b6a0a8: avcodec/interplayvideo: Avoid ff_get_buffer() during init
[20:15:33 CEST] <durandal_1707> anything new happened since i was missing?
[20:16:11 CEST] <Lynne> nope, but set up a repeater or a client somewhere
[20:16:31 CEST] <durandal_1707> that costs
[20:17:07 CEST] <Lynne> no old raspberry pi gathering dust?
[20:17:26 CEST] <durandal_1707> not that lucky
[20:19:13 CEST] <durandal_1707> all android irc clients sucks,  consumes battery a lot
[20:21:35 CEST] <durandal_1707> so we still do not have volunteer for uploading stuff?
[20:23:43 CEST] <durandal_1707> i can do it, once i get back access to private key
[20:46:27 CEST] <Illya> jkqxz: do you know what happened to the Vulkan filtering stuff? Looks like atomnuker just stopped working on it?
[21:54:22 CEST] <Lynne> last I heard still no one had implemented that modifiers extension to import/export reliably that google sluggishly released
[21:55:13 CEST] <Lynne> oh and there was something about things working by luck or with tearing because there's no synchronization yet
[21:55:57 CEST] <durandal_1707> which filters you use not?
[22:30:52 CEST] <cone-378> ffmpeg 03Michael Niedermayer 07master:9af8ce754b70: avcodec/hnm4video: Forward errors of decode_interframe_v4()
[22:30:58 CEST] <Illya> durandal_1707: I didn't have any particular filters in mind but was just wondering since I've been looking a lot at vulkan lately
[22:31:27 CEST] <Illya> Lynne: ok thanks. I'll maybe take a look at it when I've finished my current work
[22:47:00 CEST] <Lynne> no need really, drm devs did implement a public interface to create semaphores that you can import/export to/from vulkan
[22:47:31 CEST] <Lynne> only problem: they're completely decoupled from anything else, objects, frames, etc.
[22:49:23 CEST] <Lynne> it was probably made for driver devs but if drm doesn't give you apis to bind from/to drm objects then what will?
[00:00:00 CEST] --- Sun Aug  4 2019