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

[burek]

[14:17:33 CEST] <JEEB> was cbs_h264
[14:17:41 CEST] <JEEB> the thing that printed out the structure of the H.264 stream?
[14:19:19 CEST] <JEEB> ah, trace_headers bsf
[15:05:47 CEST] <JEEB> http://up-cat.net/p/7a11a943
[15:06:05 CEST] <JEEB> 12 packets seem to fail in the sample
[15:55:55 CEST] <January> jamrial: hits a sigabrt with a 50 frame backtrace in av_malloc if I pass it buf_ref. Guess I'll start digging
[15:56:31 CEST] <jamrial> you mean to av_frame_new_side_data_from_buf()?
[15:56:49 CEST] <January> jamrial: yes
[16:02:44 CEST] <jamrial> that's odd
[16:04:53 CEST] <jamrial> it happens when you do https://pastebin.com/xqGA5FsF ?
[16:08:43 CEST] <January> jamrial: I wasn't making a53->buf_ref NULL, but making it null seems to fix the issue
[16:09:20 CEST] <January> I assume it was trying to realloc the memory in sei
[16:11:22 CEST] <jamrial> yeah, as i said, kinda weird semantics on that function. taking ownership of a reference instead of creating a new one for itself was probably a bad idea in hindsight
[16:13:59 CEST] <January> jamrial: hopefully i didnt miss anything this time
[16:24:32 CEST] <jamrial> January: looks good now
[18:18:36 CEST] <cone-724> ffmpeg 03Kieran Kunhya 07master:c85852d3de63: h264: Support multi-field closed captions by using AVBufferRef and not resetting per field
[18:22:07 CEST] <jamrial> January: can you add a test for this?
[18:25:56 CEST] <January> jamrial: I don't have any samples I can share, do you know of one?
[18:26:25 CEST] <JEEB> it's PAFF with A53 per field, right?
[18:26:35 CEST] <JEEB> you should be able to stick those SEIs into some PAFF sample
[18:27:24 CEST] <JEEB> or not A53, EIA 708
[18:28:05 CEST] <JEEB> meanwhile I should probably poke at the H.264 sample that borks the decoder completely for the rest of the playback session
[18:28:19 CEST] <JEEB> it seems like it keeps dropping references or something
[18:31:03 CEST] <jamrial> January: no, but maybe you can create one using tmm1's patch for h264_metadata_bsf?
[18:31:22 CEST] <jamrial> i don't recall if that was what his patch was meant to do
[20:12:40 CEST] <cone-724> ffmpeg 03James Almer 07master:96a7099f3ed5: avcodec/av1_parse: take trailing bits into account when initializing the GetBitContext
[20:12:41 CEST] <cone-724> ffmpeg 03James Almer 07master:8d5604a69aaa: avformat/av1: update ff_isom_write_av1c() to the latest revision of the spec
[20:19:36 CEST] <cone-724> ffmpeg 03James Almer 07master:728760de350c: Revert "avcodec/libaomdec: auto insert dump_extra bitstream filter"
[20:22:55 CEST] <cone-724> ffmpeg 03James Almer 07master:7b5f93d4e126: avformat: bump micro version after previous changes
[20:29:24 CEST] <cone-724> ffmpeg 03James Almer 07master:f00964e2f7ea: avformat/av1: filter out tile list OBUs from samples
[21:14:03 CEST] <January> jamrial: was i meant to bump lavc
[21:15:13 CEST] <jamrial> no, i don't think so
[21:15:30 CEST] <jamrial> we don't bump for bugfixes, in general
[21:17:07 CEST] <January> jamrial: I guess theres a whole debate whether it was a bugfix or a feature, should be fine if you think so though
[21:19:31 CEST] <jamrial> January: feel free to bump lavc micro if you want, in that case. i guess for something like this, a library user may want to make sure the version it's using has your change
[21:20:34 CEST] <January> jamrial: Ill bump when i add a test, havent had a chance to look at tmm1s patch yet
[21:24:44 CEST] <jamrial> January: actually, i think the patch was by jkqxz, and tmm1 wanted to use it for mediacodec
[21:24:52 CEST] <JEEB> 34
[21:25:04 CEST] <jamrial> and it may have been to extract a53, but not include
[21:25:42 CEST] <jamrial> they know better about this
[21:53:42 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:1e71cb2c8edc: avformat/mlvdec: read_string() received unsigned size, make the argument unsigned
[21:53:43 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:c2eec1762d37: avformat/rmdec: Fix EOF check in the stream loop in ivr_read_header()
[00:00:00 CEST] --- Sat Aug 18 2018