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

[burek]

[00:11:56 CEST] <nevcairiel> I'm surprised that HEVC interlaced gets mentioned as rarely as it does, seems like we won and noone really cares about it
[00:13:34 CEST] <nevcairiel> the reason ffmpeg outputs it half-height is technically not a bug, but a missing feature, since hevc interlaced streams are quite simply half-height frames and metadata :D
[00:22:07 CEST] <mkver> Yes, the fact that HEVC is different in this regard with most (all?) the other codecs that have dedicated interlaced modes is the reason why I am interested in what counts as height for interlaced HEVC.
[00:22:35 CEST] <mkver> with -> compared to
[00:22:40 CEST] <nevcairiel> its different because they really didn't want to do interlaced, but in the last minute some industry people forced that metadata thing in
[00:23:10 CEST] <mkver> Yes. Would have been good if interlaced had been abandonded long ago.
[00:23:48 CEST] <nevcairiel> at one point someone tried to add interlaced support, but the first iteration of the patch was flawed and then apparently abandoned
[00:23:53 CEST] <nevcairiel> never heard anything of it ever  again
[00:24:09 CEST] <Lynne> needing both container and codec metadata sounds fragile too
[00:25:14 CEST] <nevcairiel> majority of players don't care or need container metadata for such things
[00:25:52 CEST] <nevcairiel> hevc was designed with broadcast in mind, which means mpegts, and as such  barely any metadata
[00:26:16 CEST] <nevcairiel> mkv just wants to have nice values in their headers, but its not required for hevc, and will be ignored by most players
[00:27:59 CEST] <mkver> Probably yes. Anybody who wants to support interlaced HEVC and tests actual files will indeed find out that mkv's header dimensions are unreliable.
[00:29:30 CEST] <nevcairiel> Container dimensions are honestly quite meaningless on encoded bitstreams that have their own codec dimensions anyway. No matter if right or wrong. If it matches, its fine, if it doesn't match .. you can't exactly use container dimensions to decode a video of mismatching dimensions, so you still ignore it.
[00:31:12 CEST] <mkver> Yes, they are normative in the standards, but are actually only informative (as far as encoded pictures are concerned; this does not apply to aspect ratio stuff).
[00:31:54 CEST] <mkver> Huh, the way the picture display orientation SEI is parsed is all wrong.
[00:32:18 CEST] <nevcairiel> even with aspect ratio its mostly a guessing game which value is actually correct, container vs. bitstream
[00:33:03 CEST] <nevcairiel> i think i made it use container for mkv and mp4 and bitstream for everything else, or some shit like that
[00:33:35 CEST] <mkver> True for mkv and mp4.
[00:45:21 CEST] <cone-130> ffmpeg 03Limin Wang 07master:5fc8d87ba695: libavfilter/vf_cover_rect.c: free the allocated frame
[01:20:54 CEST] <mkver> Good night!
[03:00:33 CEST] <cone-130> ffmpeg 03Ruiling Song 07master:83f9da77684e: avfilter/vf_gblur: add x86 SIMD optimizations
[03:00:34 CEST] <cone-130> ffmpeg 03Ruiling Song 07master:8f4963ad25ac: checkasm/vf_gblur: add test for horiz_slice simd
[05:51:40 CEST] <vtorri99978666> michaelni hello
[05:51:58 CEST] <vtorri99978666> michaelni do you plan to release 4.2 soon ?
[05:52:10 CEST] <vtorri99978666> michaelni for the name , Srinivasa Ramanujan :)
[12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:4896fa18add7: avcodec/h264_parse: Use 64bit for expectedpoc and expected_delta_per_poc_cycle
[12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:914d6a7c1a7a: avcodec/interplayvideo: check decoding_map_size with video_data_size
[12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:640e401aedb3: tests/ref/fate/nuv-rtjpeg: Preserve the original timestamps
[12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:e5f92f3fbadb: avcodec/v4l2_m2m_dec: Fix memleak on ff_v4l2_m2m_codec_init() failure
[12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:442375fee7f1: avcodec/mjpegdec: Check for non ls PAL8
[12:08:26 CEST] <cone-451> ffmpeg 03Peter Ross 07master:a212c8da48fe: avcodec/vp3: spin off get_eob_run and get_coeff coeff functions
[12:08:27 CEST] <cone-451> ffmpeg 03Peter Ross 07master:43dbdee26491: VP4 video decoder
[12:08:28 CEST] <cone-451> ffmpeg 03Peter Ross 07master:8913af7d94d4: avformat/riff: add VP4 fourcc
[12:25:24 CEST] <JEEB> nice, vp4
[12:30:38 CEST] <j-b> very cool
[12:30:56 CEST] <j-b> little usage, but very cool
[12:41:11 CEST] <thardin> does this complete the entirely collection of duck codecs?
[12:48:59 CEST] <pross> vp3.0 is missing
[12:50:13 CEST] <kurosu> Does vp10 count as a duck codec?
[12:51:09 CEST] <pross> vp 10 was quickly shelved, and became av1, no?
[12:51:50 CEST] <kurosu> And besides that, that's post-google
[12:52:33 CEST] <kurosu> (but duckduckgo got to complain)
[12:54:49 CEST] <pross> i am waiting for a post-google world
[13:05:25 CEST] <cone-451> ffmpeg 03Peter Ross 07master:f4c35a458f9d: fate: add VP4 test
[15:29:03 CEST] <cone-451> ffmpeg 03James Almer 07master:f66bd0e8de2e: configure: add missing dnn dependency to derain filter
[15:55:42 CEST] <cone-451> ffmpeg 03James Almer 07master:b8f1542dcbad: avfilter/vf_gblur: add missing preprocessor check
[18:26:57 CEST] <tmm1> verizon fios in the usa just started broadcasting 4k hevc content, and it looks like ffmpeg is unable to decode it (Error parsing NAL unit #3. PPS id out of range: 0)
[18:27:50 CEST] <tmm1> lots of "First slice in a frame missing." too
[18:29:33 CEST] <kierank> tmm1: sure it's not partially encrypted?
[18:31:35 CEST] <tmm1> not encrypted, this is after cablecard decrypted it
[18:31:37 CEST] <tmm1> https://tmm1.s3.amazonaws.com/fios-hevc-usa.mpg
[18:58:39 CEST] <nevcairiel> PPS id out of range is usually an indication of a bad cut or otherwise missing SPS/PPS data
[18:59:33 CEST] <JEEB> tmm1: if you look with the trace_headers bsf see if there are any PPS/SPS things
[18:59:57 CEST] <nevcairiel> actually plays for me
[19:00:02 CEST] <nevcairiel> there are errors at the start
[19:00:04 CEST] <nevcairiel> but then its fine
[19:00:17 CEST] <nevcairiel> errors at the start of a broadcast recording are normal, tbh
[19:00:22 CEST] <JEEB> yea
[19:00:37 CEST] <JEEB> ok, if it plays then it is probably OK and the GOP is just longer than tmm1 has expected or something :)
[19:02:04 CEST] <tmm1> hm i'm using ffplay from master and it doesn't play back 
[19:03:37 CEST] <nevcairiel> i never use ffplay, so *shrug*
[19:04:46 CEST] <JEEB> tmm1: after a while brings up video for me with my older mpv
[19:05:12 CEST] <mkver> And remuxing it to Matroska fails: Error parsing AAC extradata, unable to determine samplerate.
[19:05:22 CEST] <mkver> So it's maybe the audio that's making problems?
[19:05:32 CEST] <nevcairiel> i g et both audio and video during playback
[19:05:39 CEST] <nevcairiel> but the fate of badly cut broadcast streams
[19:05:49 CEST] <nevcairiel> you have to deal with corrupt data at the beginning
[19:05:53 CEST] <JEEB> yea
[19:06:02 CEST] <JEEB> or not corrupt but not necessary start-of-packets
[19:06:12 CEST] <JEEB> tmm1: swdec works as well, I will attempt to rebuild now to make sure current master works
[19:06:15 CEST] <jamrial> trace_headers shows sps+pps+vps in the first packet
[19:06:32 CEST] <JEEB> ok, so then it's waiting for IRAP
[19:06:45 CEST] <JEEB> both swdec and hwdec work for me
[19:06:55 CEST] <JEEB> (with my earlier build from this year)
[19:11:10 CEST] <mkver> Decoding audio results in "Sample rate index in program config element does not match the sample rate index configured by the container." and "Too large remapped id is not implemented. Update your FFmpeg version ..." together with the typical "upload sample" stuff.
[19:11:33 CEST] <JEEB> mkver: that goes normal after a while
[19:11:35 CEST] <nevcairiel> i get that too
[19:11:36 CEST] <tmm1> hmm mpv is actually playing it fine for me too
[19:11:39 CEST] <nevcairiel> but it just plays after
[19:11:48 CEST] <tmm1> wonder what i was doing yesterday then..
[19:11:55 CEST] <tmm1> maybe it wasn't working with vtdec on my mac
[19:12:59 CEST] <JEEB> I think VT might need a different format or something - not sure
[00:00:00 CEST] --- Thu Jun 13 2019