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

[burek]

[11:53:13 CEST] <cone-430> ffmpeg 03Paul B Mahol 07master:4f4334bcbcf1: avfilter/vf_waveform: fix typos which caused crash
[17:11:53 CEST] <kierank> this guy does better job than all of google
[17:12:21 CEST] <durandal_1707> lol
[17:12:27 CEST] <kierank> he finds real issues instead of stupid google issues
[17:12:29 CEST] <kierank> like integer overflow
[17:17:39 CEST] <jamrial> kierank: probably because google isn't fuzzing lavfi :p
[17:17:51 CEST] <kierank> jamrial: I know I was trolling google
[17:17:56 CEST] <jamrial> heh
[17:25:03 CEST] <cone-845> ffmpeg 03Paul B Mahol 07master:ccf4ab8c9aca: avfilter/vf_edgedetect: check if height is big enough
[18:19:07 CEST] <cone-845> ffmpeg 03Paul B Mahol 07master:0749082eb93e: avfilter/vf_bm3d: fix heap-buffer overflows
[18:19:08 CEST] <cone-845> ffmpeg 03Paul B Mahol 07master:365083556ea7: avfilter/vf_bm3d: fix possible infinite loop
[18:38:33 CEST] <cone-845> ffmpeg 03Paul B Mahol 07master:99f8d32129dd: avfilter/vf_convolution: fix undefined behaviour
[20:30:33 CEST] <durandal_1707> VDD is bust
[20:35:13 CEST] <Lynne> southern spain > japan, empty hotels, normal temperatures, much better food, much cheaper, better laws, etc.
[20:37:42 CEST] <j-b> Then, let's do Southern Spain next year.
[20:48:26 CEST] <rcombs> I'm gonna be in tokyo anyway
[21:18:50 CEST] <BradleyS> is anyone aware of an issue with the release build where ffmpeg might detect a subtitle stream in mpeg as mp3?
[21:18:53 CEST] <BradleyS> Stream #0:2[0x12e]: Audio: mp3, 0 channels, fltp
[21:18:59 CEST] <BradleyS> https://github.com/HandBrake/HandBrake/issues/2355
[21:20:12 CEST] <BradleyS> sample included
[21:27:47 CEST] <JEEB> if you don't get any data and there is no real identifier for the stream I think the default for probing can end up being mp3
[21:27:58 CEST] <JEEB> because with zero bytes it seems to pop up first
[21:28:38 CEST] <BradleyS> that would make sense
[21:29:08 CEST] <BradleyS> the op indicates it does seem to be working in other softwares, though we've found various tools don't see it at all
[22:03:45 CEST] <rcombs> JEEB: maybe the probing shouldn't be able to return anything at all on 0 bytes
[22:04:15 CEST] <rcombs> BradleyS: anyway, increase the max probe size
[22:04:30 CEST] <BradleyS> did, have you different results?
[22:07:48 CEST] <rcombs> oh huh it's actually not 0 bytes
[22:08:36 CEST] <rcombs> BradleyS: do you know what this stream is supposed to be
[22:08:47 CEST] <rcombs> ATSC CCs?
[22:08:49 CEST] <BradleyS> cc
[22:09:10 CEST] <rcombs> (those usually aren't in a separate stream, bit odd)
[22:09:25 CEST] <BradleyS> indeed
[22:10:57 CEST] <rcombs> might need an update to set_codec_from_probe_data
[22:11:15 CEST] <rcombs> BradleyS: but, is this actually how the stream comes down off the tuner? or is EyeTV doing something dumb
[22:11:34 CEST] <BradleyS> good question, can't say as i don't have one
[22:13:02 CEST] <JEEB> yea I haven't yet seen CCs in a separate stream
[22:13:14 CEST] <rcombs> lavf doesn't even have a standalone CC demuxer
[22:13:20 CEST] <JEEB> mostly because everything in the ecosystem seems to be taking them in from the video streams
[22:13:32 CEST] <rcombs> probably because the format doesn't have internal timestamps
[22:13:37 CEST] <JEEB> yea
[22:13:48 CEST] <rcombs> so it doesn't really fit into the probing infrastructure
[22:14:18 CEST] <rcombs> BradleyS: if you can get a direct capture off a tuner that exhibits this behavior, then I might look into adding something to deal with this
[22:14:32 CEST] <rcombs> but if it only comes from EyeTV then I'm not inclined to add support for their nonstandard weirdness
[22:15:08 CEST] <rcombs> (I _wish_ ATSC captions were a separate stream; it'd make them a lot easier to deal with, but they're not and trying to make them be that doesn't really help anything)
[22:16:22 CEST] <BradleyS> okay, care to comment on the github issue or shall i?
[22:17:04 CEST] <rcombs> go ahead
[22:17:10 CEST] <BradleyS> thanks for the help
[22:27:54 CEST] <nevcairiel> i've only ever seen CC data seperate in mov
[22:28:01 CEST] <nevcairiel> not in a transport stream
[22:28:32 CEST] <nevcairiel> does it even have a stream identifier?
[22:28:58 CEST] <rcombs> no
[22:29:21 CEST] <rcombs> which is why this fails
[22:29:30 CEST] <nevcairiel> well we might just now have it
[22:29:49 CEST] <rcombs> >stream=2 stream_type=0 pid=12e prog_reg_desc=
[22:30:46 CEST] <cehoyos> Did you find data in the sample stream? I was unable to.
[22:30:51 CEST] <cehoyos> CC data
[22:31:15 CEST] <rcombs> ffprobe -show_packets turns up _something_
[22:31:40 CEST] <rcombs> not sure what, though
[22:31:42 CEST] <rcombs> >buf = "\x80??EyTV"
[22:35:48 CEST] <kierank> BradleyS: happens all the time when ffmpeg ignores pmt
[22:35:50 CEST] <kierank> and probes
[22:36:02 CEST] <kierank> everything is an mp3
[22:36:27 CEST] <BradleyS> i don't blame fraunhofer for attempting world domination
[22:36:47 CEST] <nevcairiel> obviously the pmt doesnt include any information about that stream
[22:37:04 CEST] <nevcairiel> well, other then that it exists
[22:37:11 CEST] <kierank> it has to have information
[22:37:42 CEST] <nevcairiel> yeah because every file ever is perfectly valid
[22:37:46 CEST] <nevcairiel> you should know better
[22:37:56 CEST] <kierank> it's got to have an id
[22:37:57 CEST] <kierank> at least
[22:38:00 CEST] <kierank> you can't have a pmt without it
[22:38:28 CEST] <kierank> either it's a ghost pid and not in the pmt or it's in the pmt and you get something
[22:38:39 CEST] <kierank> maybe wrong 
[22:38:43 CEST] <nevcairiel> it has a pid, but that alone doesnt tell you anything about the contents of the stream
[22:39:17 CEST] <kierank> is it present in pmt?
[22:40:16 CEST] Action: JEEB recommends DVB Inspector for debugging such things
[22:40:23 CEST] <kierank> yes
[22:40:24 CEST] <kierank> and tsreader
[22:45:23 CEST] <nevcairiel> the stream is not in the pmt at all apparently
[23:13:04 CEST] <cone-845> ffmpeg 03Paul B Mahol 07master:07050d7bdc32: avfilter/vf_fieldorder: fix heap-buffer overflow
[23:30:44 CEST] <cone-845> ffmpeg 03Paul B Mahol 07master:19587c9332f5: avfilter/vf_lenscorrection: fix division by zero
[23:44:01 CEST] <cone-845> ffmpeg 03Paul B Mahol 07master:e835a9d30263: avfilter/vf_libvmaf: fix filtering of >8 bit data
[00:00:00 CEST] --- Mon Oct 14 2019