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

[burek]

[03:06:19 CEST] <cone-544> ffmpeg 03Kevin Mark 07master:4af496473a06: FATE: Add test for libavfilter/scale2ref
[03:06:19 CEST] <cone-544> ffmpeg 03Sysiphus 07master:caf7d6178a4d: avformat/hls: Check local file extensions
[03:21:40 CEST] <jamrial> lol
[03:32:16 CEST] <kevmark> I have no idea what's going on in that thread but that's a quality commit right there
[03:40:02 CEST] <Compn> its a CYA commit
[03:40:12 CEST] <Compn> hey... we tried :P
[03:40:35 CEST] <Compn> not me but the royal "we"
[03:41:26 CEST] <kevmark> CYA as in "hey, we patched it" yes? haha
[03:54:52 CEST] <kierank> jb_pissed is going to love that
[04:35:01 CEST] <cone-544> ffmpeg 03James Almer 07master:933dd62288ba: x86/aacpsdsp: optimize ff_ps_mul_pair_single_sse
[07:11:12 CEST] <cone-544> ffmpeg 03Rostislav Pehlivanov 07master:10b7adf79d70: fate: add test for the Dirac low delay profile
[07:15:18 CEST] <atomnuker> hls sucks and no one should ever use it
[07:17:46 CEST] <kevmark> As someone without push access to the ffmpeg git should I be signing off on my patches? The developer's guide seems to imply that I should
[07:18:20 CEST] <kevmark> Or is signing off only for devs with commit access?
[07:41:43 CEST] <atomnuker> nah, its for yourself
[07:42:10 CEST] <atomnuker> some don't sign patches and that's okay too
[07:48:09 CEST] <kevmark> Okay, thanks
[08:15:35 CEST] <rcombs> holy fuck
[08:15:41 CEST] <rcombs> the DASH people have gone off the deep end
[08:16:01 CEST] <rcombs> they wrapped WebVTT in MP4
[08:16:20 CEST] <rcombs> but couldn't figure out how to have lines overlap, so you have to split them
[08:16:49 CEST] <rcombs> and include a "continuation" if a previous line is still supposed to run while the new one does, which duplicates its content
[08:17:06 CEST] <rcombs> (this, in a format that requires a full index!)
[08:17:28 CEST] <rcombs> and you have to code empty regions
[08:18:04 CEST] <rcombs> and to distinguish between "continuation" cues and regular cues and empty cues (a category unto themselves!), they PUT ATOMS IN THE MDAT
[08:18:29 CEST] <ritsuka> so, same way as tx3g
[08:21:19 CEST] <rcombs> looks like it's similar but not quite identical
[08:21:27 CEST] <rcombs> but who thought tx3g was a good model for anything
[08:21:37 CEST] <JEEB> I looked mostly at the ttml side which seemed more sane
[08:21:41 CEST] <rcombs> and how the hell am I supposed to parse/generate this
[08:21:59 CEST] <JEEB> since there was an id for each line
[08:22:17 CEST] <rcombs> my current reaction is to tell the people asking me for it to go jump in a lake
[08:22:38 CEST] <JEEB> :D
[08:22:48 CEST] <rcombs> why the hell would you want to put WebVTT in MP4 anyway
[08:23:02 CEST] <rcombs> I could maybe see it if was a track in a mux
[08:23:12 CEST] <rcombs> but this is for single-track files for DASH
[08:23:28 CEST] <rcombs> and they apparently end up parsing this shit in JS
[08:23:40 CEST] <ritsuka> :|
[08:23:40 CEST] <rcombs> do they not know you can transfer text files over HTTP
[08:23:55 CEST] <rcombs> seriously, that's the only use-case I can find
[08:24:07 CEST] <rcombs> also the format manages to have more overhead than the WebVTT text format
[08:24:25 CEST] <rcombs> yup, they muxed a text-based format into binary and _it got bigger_
[08:24:33 CEST] <rcombs> only MP4
[13:56:54 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:c0702ab83018: Revert "avformat/hls: Check local file extensions"
[13:56:55 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:189ff4219644: avformat/hls: Check local file extensions
[14:18:08 CEST] <kierank> LOL
[14:31:48 CEST] <cbsrobot> trac seems down
[14:56:58 CEST] <BtbN> works for me
[15:00:59 CEST] <cbsrobot> yeah works again, not sure what happend
[15:06:07 CEST] <BBB> J_Darnley: do you have a tree I can pull so I can work on your patches?
[15:51:28 CEST] <J_Darnley> BBB: I will push to my gitlab in a moment.
[15:51:42 CEST] <BBB> ty
[15:56:29 CEST] <J_Darnley> BBB: https://gitlab.com/J_Darnley/ffmpeg/commits/mpeg2_asm
[16:19:11 CEST] <BBB> J_Darnley: ty
[16:19:14 CEST] <BBB> will check it out
[17:08:27 CEST] <jamrial> michaelni: can you replace id3v1.aac with http://0x0.st/6k0.aac ?
[17:38:02 CEST] <atomnuker> tdjones: very nice, it works perfectly
[17:49:09 CEST] <tdjones> atomnuker: Thank you
[17:49:57 CEST] <tdjones> I am trying to move all samples into venc->samples before processing so that overlapping actually works correctly. However, it makes it incompatible with the aac psych.
[17:50:25 CEST] <tdjones> There seems to be two options, (1) write a temp (real simple) psych system until I incorporate with the model you are using for opus or (2) rewrite the internal samples array so that each channel is a pointer to samples rather than storing it linearly and using arithmetic. I'm not sure what the better route probably is
[18:09:23 CEST] <cone-248> ffmpeg 03Tyler Jones 07master:610864dc36e2: avcodec/vorbisenc: Include fdsp
[18:09:24 CEST] <cone-248> ffmpeg 03Tyler Jones 07master:79941602a317: avcodec/vorbisenc: Use fdsp for applying windows
[18:09:25 CEST] <cone-248> ffmpeg 03Tyler Jones 07master:25260b5161af: avcodec/vorbisenc: Include bufqueue and afqueue
[18:09:26 CEST] <cone-248> ffmpeg 03Tyler Jones 07master:29c13fed68ac: avcodec/vorbisenc: Use a bufqueue in encoding with smaller lengths
[18:09:27 CEST] <cone-248> ffmpeg 03Rostislav Pehlivanov 07master:7fc1be9a01c5: vorbisenc: signal samples to skip
[18:09:57 CEST] <atomnuker> rcombs, JEEB: one of you *did* test whether the native aac encoder correctly signals the samples to skip at the end, right?
[18:13:18 CEST] <atomnuker> (I ask because when I try to measure the number of samples to skip I'm always a frame more which doesn't seem right)
[18:13:49 CEST] <atomnuker> also CRAP WHY IS OUR OPUS/VORBIS MUXER NOT INSERING END_TRIMMING, this is a huge undersight
[18:14:15 CEST] <JEEB> atomnuker: not the end stuff
[18:14:34 CEST] <JEEB> only encoder delay is what I check
[18:19:29 CEST] <atomnuker> tdjones: I'd suggest writing to a temporary buffer so you can still use the AAC psy system until mine is ready
[18:19:51 CEST] <atomnuker> what you'll likely need to do however is extend the psy system I'm writing for vorbis
[18:19:55 CEST] <cone-248> ffmpeg 03Vittorio Giovara 07master:2ef9fc997dba: ffprobe: Use pixdesc API to provide color space names
[18:20:37 CEST] <atomnuker> more specifically, use the per-frame statistics to translate to bit distribution in the encoder
[18:21:12 CEST] <atomnuker> since the one I'm writing for opus is fundamentally different (and much more complicated because the black box bit alloc algorithm) than vorbis
[18:22:04 CEST] <atomnuker> where you can just say "eh, this band's bits are going to be a log of its tonality" and it would be alright
[18:23:03 CEST] <atomnuker> since the psychoacoustic system already does low passing you'll not hugely overshoot the bitrate on a per-frame basis and the rate control system will do the right thing
[18:25:42 CEST] <atomnuker> but in opus you have to know how many bits you'd like to use beforehand so you either have to use heuristics (like libopus) to make a guess or deliberately touch the number of bits away from equalibrium and feed it through an rc system
[18:27:27 CEST] <atomnuker> (actually in vorbis you'd use the log of the 1/tonality since vorbis does well with tonal values but bad with noise while opus does well with noise but bad with tones)
[18:28:41 CEST] <RiCON> atomnuker: i thought this was known "<TD-Linux> jmspeex, now we just need preskip and end trimming in ffmpeg and libav :)"
[18:30:05 CEST] <tdjones> atomnuker: Using a temporary buffer felt wasteful to me, but I wasn't sure if there were actually any better alternatives. I'll do that until/unless I figure something better.
[18:31:00 CEST] <tdjones> I'll take a look and see how easily I can extend the opus psy for vorbis
[18:54:36 CEST] <TD-Linux> RiCON, it's a bit more subtle than that, there are bits which work and bits which don't. I think remuxing preserves the values, and correct playback happens with mpv (but not ffmpeg.c)
[18:57:24 CEST] <JEEB> yea, if you encode wav to AAC in mp4 and then output wav out of ffmpeg.c with that mp4 file it will note that wav doesn't support negative timestamps and will output the padding as well
[18:57:30 CEST] <michaelni> jamrial, replaced
[18:58:07 CEST] <TD-Linux> for the case of opus there's a nice (decoding) test case here https://people.xiph.org/~greg/opus_testvectors/correctness_trimming_nobeeps.opus
[18:59:41 CEST] <atomnuker> yep, tested that sample and it works
[19:00:58 CEST] <TD-Linux> I assume in mpv (ffmpeg -i f.opus f.wav doesn't work for me)
[19:02:15 CEST] <atomnuker> ye
[19:02:18 CEST] <atomnuker> *yes
[19:05:29 CEST] <jamrial> michaelni: thanks
[19:33:27 CEST] <atomnuker> BBB: will you push the new vp9 avx2 soon?
[19:55:13 CEST] <BBB> yes
[19:55:29 CEST] <BBB> I mean its just one intra pred function right?
[19:55:33 CEST] <BBB> the impact isnt that massive yet
[21:14:49 CEST] <tmm1> mateo`: looks like i maybe need to pass seq header/extension into mediacodec csd-0 for mpeg2 decoding
[22:26:32 CEST] <BBB> https://nokiatech.github.io/heif/ <- hevc to the rescue!
[22:27:27 CEST] <atomnuker> its hell
[22:27:48 CEST] <atomnuker> defines a container format based on but incompatible apparently with isobmff
[22:28:02 CEST] <atomnuker> can contain jpeg h264 or hevc
[22:28:06 CEST] <BBB> but it has new patents so it must be better
[22:28:23 CEST] <BBB> we all know that it can only be better if its more expensive
[22:28:23 CEST] <atomnuker> absolutely
[22:28:38 CEST] <BBB> only worthless trash is cheaper and competes on economic terms
[22:28:59 CEST] <BBB> plus we all know how succesful hevc is already :D
[22:29:07 CEST] <atomnuker> there's the old saying: "there's nothing more dangerous than something free"
[22:43:31 CEST] <jamrial> so now there are three hevc based image formats. the still picture profile, bpg, and heif
[22:44:12 CEST] <atomnuker> there's a still picture profile?
[22:44:42 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:1e6ee86d9254: avcodec/cavs: Fix runtime error: signed integer overflow: -12648062 * 256 cannot be represented in type 'int'
[22:44:43 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:d7cbeab4c138: avcodec/tiff: Avoid loosing allocated geotag values
[22:44:44 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:4705edbbb96e: avcodec/mjpegdec: Check that reference frame matches the current frame
[22:45:36 CEST] <jamrial> yeah, part of the hevc spec. seems to be one of the profiles heif uses as well
[22:47:53 CEST] <BBB> I think this is supposed to complement the still image profile
[22:48:00 CEST] <BBB> as a container layer around it
[22:48:08 CEST] <BBB> (after all, you can never have too many layers)
[22:48:19 CEST] <BBB> no manager was ever fired for having more layers
[22:57:14 CEST] <TD-Linux> can I stream it over HLS
[23:12:28 CEST] <kevmark> atomnuker, the "based on (but incompatible with)" really got me
[23:15:48 CEST] <kevmark> Even in their technical comparison with other image formats some things don't seem right to me. They say WebP doesn't have "Multiple-of-90-degree rotations" but isn't that a part of Exif? Which WebP supports?
[00:00:00 CEST] --- Tue Jun  6 2017