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

[burek]

[08:51:47 CET] <cone-914> ffmpeg 03Gyan Doshi 07master:e73688eff437: avfilter: rename scale.c,h to scale_eval
[10:05:34 CET] <cpplearner> Hmm, guys. I got some invalid dts (=negative) when av_read_frame() on some files. Hmm, with ffprobe -show_frames -of xml, it shows right timestamps... What should I do?
[10:22:08 CET] <JEEB> cpplearner: they're not necessarily invalid
[10:22:34 CET] <JEEB> for example audio encoder delay etc is sometimes shown as negative start time
[10:37:05 CET] <thardin> negative pts is also not unheard of
[10:38:17 CET] <JEEB> yea
[10:38:33 CET] <cpplearner> Hmm...
[10:39:35 CET] <cpplearner> For those files, I got this error when encoding...
[10:39:37 CET] <cpplearner>  Timestamps are unset in a packet for stream 1. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[10:39:50 CET] <cpplearner> and this... Packet with invalid duration -9223372036854775808 in stream 1
[10:39:53 CET] <mkver> Then the dts will be AV_NOPTS_VALUE.
[10:40:09 CET] <mkver> What container is it? Matroska?
[10:40:13 CET] <cpplearner> Yes.
[10:40:16 CET] <cpplearner> How did you know?
[10:40:17 CET] <cpplearner> =O
[10:40:34 CET] <JEEB> yes, NOPTS_VALUE is special
[10:41:05 CET] <mkver> Matroska does not store the dts, but only the pts. Hence the demuxer doesn't set the dts and it relies on other code to guess the dts.
[10:41:39 CET] <JEEB> yea, although in theory we could be calculating it since we know the order of packets (although I guess b-frame delay etc make this icky)
[10:41:59 CET] <cpplearner> Oh, okay... So, it's normal to have these errors on mkv encoding?
[10:42:06 CET] <cpplearner> mkv -> others
[10:43:07 CET] <JEEB> no, it's not normal in the sense that I would say the (API) user shouldn't have to care. currently though, yes. only PTS gets set.
[10:43:45 CET] <mkver> If I am not mistaken, then only a few packets at the beginning don't have proper dts; the rest are fine.
[10:44:11 CET] <JEEB> could be
[10:45:05 CET] <JEEB> cpplearner: also fyi av_read_frame() returns AVPackets, not AVFrames. -show_frames shows AVFrames. that naming is confusing, yes. I apologize for it.
[10:45:28 CET] <JEEB> so essentially your "DTS/PTS" got fixed by running a decoder on the stream
[10:45:55 CET] <cpplearner> Oh, I see. =O
[10:46:57 CET] <JEEB> (in the ffprobe that is)
[10:47:12 CET] <JEEB> what you get from lavf is visible with -show_packets
[10:47:29 CET] <cpplearner> Oh, thanks! I'll try it now! =)
[10:47:41 CET] <JEEB> so that should pretty much match what you get from the API, too
[12:09:12 CET] <cpplearner> Hmm, guys. I gdb-ed on files producing "Timestamps are unset in a packet for stream 1. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" messages, and found out that, once I got the encoded packet from encoder, I got this packet.
[12:09:25 CET] <cpplearner> $37 = {buf = 0x0, pts = -9223372036854775808, dts = -9223372036854775808, data = 0x0, size = 0, stream_index = 0, flags = 0, side_data = 0x0, side_data_elems = 0, duration = 0, pos = -1, convergence_duration = 0}
[12:10:17 CET] <cpplearner> Any thoughts?
[12:20:37 CET] <mkver> What encoder?
[12:34:02 CET] <mkver> Wait, this packet is actually an empty packet: It has neither data nor side-data. How did you check that you really got an encoded packet from the encoder? Maybe the encoder needs more input before returning any output.
[12:39:58 CET] <cpplearner> mkver: I really appreciate your help! =)
[12:40:10 CET] <cpplearner> I use h264_vaapi, and I checked like this:
[12:40:23 CET] <cpplearner> ret = avcodec_receive_packet(encoder_context, packet);
[12:40:29 CET] <cpplearner> if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
[12:40:35 CET] <cpplearner>     break;
[12:40:39 CET] <cpplearner> else if (ret < 0)
[12:40:43 CET] <cpplearner>     throw media_error("Failed to encode.");
[12:42:33 CET] <cpplearner> Hmm, I'm not sure what I did wrong... =/
[12:43:48 CET] <mkver> So ret was 0 when you looked at the packet with gdb?
[12:47:10 CET] <cpplearner> Hmm, I actually didn't check ret when gdb-ing. I'll try it now.
[12:57:04 CET] <cpplearner> I'll dig further. Thanks for your help.
[14:55:32 CET] <durandal_1707> BBB: have good news for me?
[14:56:04 CET] <BBB> I have 20 things on my todo list before I can look at the disassembly, sorry
[14:56:21 CET] <durandal_1707> o_O
[14:57:35 CET] <cpplearner> Guys, what's the relationship between encoder_context->time_base & output_stream->time_base?
[14:58:14 CET] <JEEB> you just need to adjust pts/dts/duration accordingly so that the time keeps the same
[14:58:21 CET] <JEEB> otherwise there is no relationship unless you want to make one
[14:58:36 CET] <JEEB> note that some containers force a time base
[14:58:38 CET] <JEEB> like MPEG-TS
[14:58:48 CET] <JEEB> so you will always have a stream time base of 1:90000
[14:58:53 CET] <JEEB> and for FLV it's 1:1000
[14:59:40 CET] <JEEB> av_packet_rescale_ts etc probably will become useful
[15:00:59 CET] <cpplearner> I'm encoding MKV, but its time_base 1, 1000. Is it normal?
[15:01:29 CET] <cpplearner> The thing is, when I ffprobe the encoded output, I got invalid pts/dts/duration.
[15:02:17 CET] <cpplearner> BUt, when I print them just before interleaved_write, by  `packet->pts * av_q2d(target_time_base)`, it looks okay.
[15:02:56 CET] <cpplearner> target_time_base = output_context->streams[index]->time_base
[15:04:02 CET] <cpplearner> And, when I print time_bases:
[15:04:04 CET] <cpplearner> stream: 1, 1000
[15:04:04 CET] <cpplearner> output_stream: 1001, 30000
[15:04:04 CET] <cpplearner> encoder_context: 1001, 30000
[15:05:07 CET] <cpplearner> I got lost. ='(
[15:07:34 CET] <cpplearner> This is what I get from ffprobe:
[15:07:35 CET] <cpplearner>  <packet codec_type="video" ... pts="118" pts_time="0.001311" dts="118" dts_time="0.001311" ...
[15:28:10 CET] <Lynne> durandal_1707: that disasm isn't nice to look at
[15:31:28 CET] <durandal_1707> Lynne: do you need asm?
[15:31:53 CET] <durandal_1707> i mean that what i posted is decompiled code
[16:14:01 CET] <cone-914> ffmpeg 03Andreas Rheinhardt 07master:67d4940a7795: avformat/id3v2: Fix double-free on error
[16:14:02 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:a0ae4b7df915: Remove redundant ;
[16:14:03 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:8bcb5fbab5e3: avcodec/truespeech: Fix an integer overflow in truespeech_synth()
[16:14:04 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:090ac5799751: avcodec/wmaprodec: Check if the channel sum of all internal contexts match the external
[16:14:05 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:93d52a181ec0: avcodec/truemotion2: Fix 2 integer overflows in tm2_low_res_block()
[16:14:06 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:5473c7825ea6: avcodec/wmaprodec: Check offset
[16:14:07 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:a9cbd25d89db: avcodec/wmaprodec: Set packet_loss when we error out on a sanity check
[16:14:08 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:6e15ba2d1f68: avcodec/apedec: Fix 2 integer overflows
[16:14:09 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:a2d6b2042ee3: avcodec/wmalosslessdec: Set FF_CODEC_CAP_INIT_CLEANUP
[16:14:10 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:7a1b30c871c8: avcodec/agm: Do not allow MVs out of the picture area as no edge is allocated
[16:14:11 CET] <cone-914> ffmpeg 03Limin Wang 07master:8558c231fb8d: swscale/swscale_unscaled: add AV_PIX_FMT_GBRAP10 for LE and BE conversion wrapper
[16:14:12 CET] <cone-914> ffmpeg 03Michael Niedermayer 07master:7e665e4a81e2: avformat/rmdec: Initialize and sanity check offset in ivr_read_header()
[20:14:46 CET] <BBB> kierank: I'll try to make them for the next meetings also... 
[20:17:00 CET] <jamrial> BBB: i don't think the email was by him
[20:17:05 CET] <durandal_1707> ffeetings
[20:17:09 CET] <BBB> huh?
[20:17:10 CET] <durandal_1707> another kierank
[20:17:23 CET] <BBB> oh oops
[20:17:24 CET] <BBB> sorry
[20:17:29 CET] <BBB> you are right
[20:17:43 CET] <BBB> is kieran also on IRC then?
[20:17:55 CET] <durandal_1707> probably not 
[20:29:58 CET] <cehoyos> Kieran O Leary is an Irish archivist.
[20:31:28 CET] <cehoyos> https://twitter.com/cally__ho/status/1202515293156913152
[20:36:32 CET] <durandal_1707> cehoyos: get twitter!
[20:36:39 CET] <JEEB> ah, mov cropping
[20:36:45 CET] <JEEB> I think I used to have a sample of that
[20:37:06 CET] <JEEB> http://www.cccp-project.net/beta/test_files/h263_adpcm_lolborders.mov
[20:37:08 CET] <JEEB> yup
[20:41:27 CET] <cehoyos> https://trac.ffmpeg.org/query?status=!closed&keywords=~crop
[20:45:10 CET] <JEEB> :)
[21:15:48 CET] <cpplearner> Hmm, I just noticed that encoder_context.time_base changes after the first receive_packet... Is it normal...?
[22:19:02 CET] <durandal_1707> how rl codes works?
[22:41:22 CET] <durandal_1707> it looks i have 194 values for skips
[22:45:57 CET] <Illya> durandal_1707: explain how it is not an LGPL violation, please
[22:49:42 CET] <durandal_1707> ask cehoyos, he is master of such stuff
[22:56:05 CET] <Illya> FFmpeg's check list makes it clear they are in violation https://www.ffmpeg.org/legal.html
[22:56:10 CET] <Illya> 3. Distribute the source code of FFmpeg, no matter if you modified it or not.
[23:00:25 CET] <Illya> They also do not include any the ffmpeg LGPL license in their third-party licenses section
[23:00:52 CET] <durandal_1707> nobody acts, so its waste of my and yours times
[23:03:13 CET] <Illya> Maybe one day we will get a kind lawyer willing to contribute to the project :^)
[23:06:55 CET] <durandal_1707> and money? very unlikely
[23:11:46 CET] <nevcairiel> the ffmpeg checklist is not exhaustive, its just the easiest method to comply
[23:12:59 CET] <nevcairiel> also, LGPL violations are boring, all they need to do is email you the sources, thats perfectly acceptable under the license, a public download is not required, and it doesnt even specify a reaction time either
[23:26:34 CET] <Illya> nevcairiel: I was just using the checklist as an example, I also read the license of course. And yeah, I guess there are complications with it--still it shouldn't be months with zero response. (And I'm pretty sure even if they don't supply the source quickly, they DO need to include the license)
[00:00:00 CET] --- Wed Dec 11 2019