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

[burek]

[00:23:54 CEST] <J_Darnley> I'm glad I could help waste time.
[00:28:06 CEST] <tmm1> Illya: looks like the short_event's event_name is what i was using too
[00:28:58 CEST] <beastd> J_Darnley: Thanks for wasting my time :)
[00:33:10 CEST] <Illya> tmm1: not sure if we should check for short_event's event_name, I guess if we're only checking the first then it might be ok. I'll leave it for now, finish iconv stuff then come back to it
[00:58:36 CEST] <BradleyS> i'll share a story that isn't on that site
[00:58:48 CEST] <BradleyS> family member works for apple retail
[00:59:16 CEST] <BradleyS> some country folk from a relatively isolated community brought their laptop in because it wasn't working
[00:59:47 CEST] <BradleyS> the employees opened it up in the back and found liquid damage, seemed coca-cola was spilled on the keyboard
[01:00:13 CEST] <BradleyS> so they brought the laptop out to the customer to show them the liquid damage, told them someone spilled coke on it
[01:00:33 CEST] <BradleyS> one of the teenage children (essentially an adult) licked the computer
[01:00:39 CEST] <BradleyS> "coke taste don't taste, pop"
[01:00:45 CEST] <BradleyS> (pop meaning father)
[01:00:59 CEST] <BradleyS> then the next child did the same, "coke taste don't taste"
[01:01:08 CEST] <BradleyS> and the third child.
[01:01:41 CEST] <BradleyS> the father in limited vocabulary stated that coca-cola was definitively not spilled on the computer, it must be something else wrong
[01:02:24 CEST] <BradleyS> my family member to this day cannot get over the fact that a customer (three!) licked the inside of a computer in his store
[01:02:43 CEST] <BradleyS> high tech diagnostic
[01:17:01 CEST] <Lucas93> Hi
[01:18:29 CEST] <Lucas93> Is this the right channel to ask/verify a possible memleak in libavcodec/qsvenc.c ? 
[01:19:02 CEST] <kierank> yes
[01:20:34 CEST] <Lucas93> Ok so I believe there's a leak in  libavcodec/qsvenc.c when closing the codec.
[01:21:22 CEST] <Lucas93> mfxExtAVCEncodedFrameInfo *enc_info and mfxExtBuffer **enc_buf are not free'd by ff_qsv_enc_close
[01:24:29 CEST] <BradleyS> a leak, hmm... have you tried licking it to see what's leaking out?
[01:24:59 CEST] <BradleyS> (would make more sense if you were here 20 mins ago :P )
[01:25:18 CEST] <Lucas93> Yeah not sure what you are taking about.
[01:25:42 CEST] <Lucas93> But I'm pretty sure it's memory.
[01:26:20 CEST] <BradleyS> i'm pretty sure you're correct
[01:26:21 CEST] <BradleyS> https://i.imgur.com/auXHAT0.png
[01:28:26 CEST] <Lucas93> lol
[01:28:51 CEST] <Lucas93> memory taste
[01:38:04 CEST] <J_Darnley> BradleyS: hah
[01:38:17 CEST] <BradleyS> it's your fault, you know
[01:38:21 CEST] <J_Darnley> indeed
[01:38:24 CEST] <BradleyS> :)
[01:38:40 CEST] <BradleyS> i've seen that site before but sure enough, i'm reading it again
[01:41:03 CEST] <J_Darnley> I'm wondering whether the newest update it says is before or after I last saw it.
[01:41:43 CEST] <J_Darnley> 2013?  Could be after.
[01:42:04 CEST] <BradleyS> "My husband tried to install a new networking card. He said he opened it up, and all he found was a TV tube and some electronic parts -- no slots at all."
[01:42:12 CEST] <BradleyS> some are real gems
[01:45:13 CEST] <J_Darnley> I could spend the next couple hours reading more but I need to sleep.
[01:45:15 CEST] <J_Darnley> Good night
[01:45:45 CEST] <BradleyS> o/
[13:19:17 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:5868e7f562fc: avfilter/vf_alphamere: use the name 's' for the pointer to the private context
[13:26:15 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:835fdf48e59b: avfilter/vf_showpalette: fix small cosmetics issue
[13:47:46 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:c9473229c9ec: avfilter/af_acopy: check for error cases and handle them
[13:47:47 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:a9500441a718: avfilter/vf_copy: check for error cases and handle them
[14:59:18 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:9cee8975c3fe: avfilter/asink_anullsink: cosmetics
[14:59:19 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:94b155e49bde: avfilter/copy: add forgotten check
[14:59:20 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:f66458cfc757: avfilter/vsink_nullsink: cosmetics
[17:04:15 CEST] <Chagall> hm, I wanted to write a description for the patch but it seems git sent a second email with it
[17:04:45 CEST] <Chagall> should I have written the text after the GIT: [patch metadata] line?
[17:51:16 CEST] <cehoyos> jamrial: The original ivf question was "Why is a timebase written that is not x/1?" I suspect other applications always write "x/1" and then write the number of frames as "duration". The difference between time_base and framerate was discussed in the user channel yesterday
[17:54:26 CEST] <Chagall> no, I was confused that it did not correspond to the inverse of the framerate because my reference was inaccurate
[17:54:31 CEST] <Chagall> not related to this though
[18:49:41 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:3bb170e530e3: avfilter/f_streamselect: add check case when nothing is done
[19:53:38 CEST] <cone-527> ffmpeg 03Carl Eugen Hoyos 07master:a650e8c8e957: lavf/avio: Print https warning also for avio_find_protocol_name().
[19:56:59 CEST] <cehoyos> durandal_1707: Could you comment on lavfi/movie: Use filter threads as decoding threads ?
[20:01:00 CEST] <durandal_1707> cehoyos: nope, i do not see such thing
[20:05:02 CEST] <cehoyos> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248909.html
[20:15:57 CEST] <durandal_1707> cehoyos: ask nicolas, i do not want to have more crap with that nicolas "guy"
[20:28:37 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:027a53dc4905: avfilter/vf_drawbox: reduce code duplication
[20:28:38 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:1b2ed0c392f1: avfilter/vf_drawbox: implement process_command
[20:44:35 CEST] <cone-527> ffmpeg 03Lou Logan 07master:61b7676bd5a6: cmdutils: trailing options may be ignored
[21:04:54 CEST] <durandal_1707> nobody cares for MLP/PCM-DVD in MPG?
[21:05:31 CEST] <JEEB> wasn't MLP meridian lossless?
[21:05:41 CEST] <JEEB> I thought that was primarily in MPEG-TS
[21:05:46 CEST] <JEEB> and not MPEG-PS
[21:05:54 CEST] <cehoyos> I believe there was a page with a description but couldn't find it yesterday: Wait a day or two and push
[21:06:57 CEST] <JEEB> oh...
[21:07:03 CEST] <JEEB> so this is bitstreamed MLP
[21:07:06 CEST] <JEEB> within PCM
[21:07:17 CEST] <cehoyos> DVD-A
[21:07:21 CEST] <JEEB> right
[21:07:38 CEST] <durandal_1707> JEEB: see mpv bug report about some unwatchable japenese song, it is DVD-PCM within 0xa1
[21:08:24 CEST] <JEEB> yea I saw you replying to a bug report but I thought it was just a demux issue and not a "probe bitstreamed formats" kind of thing
[21:12:38 CEST] <cehoyos> It is both
[21:13:08 CEST] <JEEB> in the sense that the demuxer does the probing, yes
[21:13:37 CEST] <cehoyos> the mpeg-ps demuxing depends on the codec_id
[21:13:46 CEST] <JEEB> well yes
[21:15:13 CEST] <JEEB> my current understanding just is that this is about probing the contents of the data within the packet as read from the MPEG-PS layer as opposed to reading identifiers in the container itself. for some reason I mostly just differentiate between those two activities
[21:16:02 CEST] <cehoyos> Where is the "border" (is that the right word?) between the demuxer layer and the content layer?
[21:16:27 CEST] <cehoyos> I ask because arguing that the actual content of pcm has data apart from the audio seems strange to me
[21:17:40 CEST] <JEEB> well, generally containers have a way of giving out payloads. such as if I recall correctly PES in MPEG-TS? or when you get samples in MP4
[21:18:26 CEST] <JEEB> and in case of audio DVD or so I wouldn't be surprised if the contents of the payloads would be PCM with bit streaming, in which case yes - the PCM would in itself be a container then
[21:18:39 CEST] <cehoyos> I thought this patch has nothing to do with the "payload" but I may misremember
[21:18:48 CEST] <JEEB> I might be incorrect as well :)
[21:18:56 CEST] <JEEB> with a quick look that's just what first came to my mind
[21:19:34 CEST] <JEEB> if it's actual non-payload data then great :) although it'd be great if there was a reference about that stuff
[21:19:47 CEST] <JEEB> I will guess H.222 2017 ed. wouldn't have this stuff?
[21:20:16 CEST] <cehoyos> But luckily, we are not in a situation where we have a "reference" but no sample but we have samples which should suffice!
[21:21:03 CEST] <kierank> there are mlp dvds
[21:21:03 CEST] <JEEB> well, I generally like to also know the "why" :)
[21:21:04 CEST] <kierank> I could buy one
[21:21:14 CEST] <JEEB> kierank: we have samples already I think
[21:21:49 CEST] <cehoyos> The why seems trivial to me: There are pcm, pcm-dvd and mlp in dvd-a
[21:22:55 CEST] <JEEB> yes, but at least looking at the patch I cannot grasp the structure or flags that are being read
[21:23:15 CEST] <JEEB> just that "read 24 bits and check the bottom 8 for being 0x80)
[21:23:56 CEST] <cehoyos> If it were simpler, I may have succeeded...
[21:24:11 CEST] <cehoyos> As said: There is a page, I didn't find it yesterday
[21:25:07 CEST] <JEEB> anyways, I'm not in the business of blocking the patch. I just cannot easily verify it other than "this certain sample now plays" :)
[21:25:32 CEST] <cehoyos> I should try to find my aob samples...
[21:26:20 CEST] <JEEB> also thanks for replying to that one movenc person. I've been meaning to take a look at his patch for weeks but unfortunately I've had other things pop up that've been taking priority
[21:26:41 CEST] <JEEB> thankfully I did have the time back then to note that his cause for needing the patch most likely was the sudden raise in the default ffmpeg.c time base
[21:27:08 CEST] <JEEB> many subtitle formats used to have 1:1000 as their time base, but now they're 1:1000000 or so by default
[21:27:35 CEST] <JEEB> (and regarding the fate test, which he seems to have made?)
[21:29:24 CEST] <cehoyos> I am not sure that this is the (sole) issue, I just wanted to threaten to push this if it fixes the ticket.
[21:30:19 CEST] <JEEB> well, if you have an empty subtitle sample until the following thing (be it end or start or so?) it's much harder to hit INT_MAX with the duration if your time base is 1:1000 compared to 1:1000000
[21:30:30 CEST] <durandal_1707> 3rd byte of PCM-DVD header is always 0x80, thats why
[21:30:55 CEST] <JEEB> I recently hit that when testing something I've been brewing for a while and hopefully will be able to post on the ML soon :)
[21:55:43 CEST] <cone-527> ffmpeg 03Carl Eugen Hoyos 07master:7ffa458d600e: lavfi/movie: Use filter thread count for decoding threads.
[21:56:57 CEST] <JEEB> durandal_1707: thanks for that explanation :) is that part of the SPDIF header in the PCM payload of MPEG-PS or is that a container layer thing?
[21:57:12 CEST] <JEEB> if it's the bit streaming part that might be simpler to reference, maybe?
[21:57:28 CEST] <durandal_1707> it is DVD-PCM headerr
[21:58:02 CEST] <JEEB> ok, sorry. then I just don't know enough context
[22:02:13 CEST] <wbs> is there some mailing list moderator around? I tried sending one mail to the list two hours ago, but it didn't make it through
[22:02:44 CEST] <durandal_1707> you are being banned?
[22:07:58 CEST] <cone-527> ffmpeg 03Carl Eugen Hoyos 07master:87b7e141a6fd: lavc/x264: Use FF_CODEC_CAP_INIT_THREADSAFE if x264 is new.
[22:18:57 CEST] <cone-527> ffmpeg 03Michael Niedermayer 07master:c4de49edc465: avformat/electronicarts: If no packet has been read at the end do not treat it as if theres a packet
[23:51:28 CEST] <jamrial> wbs: are you subscribed? the list is subscriber only now
[00:00:00 CEST] --- Wed Oct  2 2019