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

burek burek021 at gmail.com
Sat Dec 22 03:05:04 EET 2018


[11:33:02 CET] <thardin> youtube has started delivering av1
[11:33:33 CET] <durandal_1707> old news
[11:56:10 CET] <durandal_1707> atomnuker: why you do not complete new channel layout API?
[12:08:03 CET] <cone-532> ffmpeg 03Paul B Mahol 07master:c49307e7847f: avfilter/af_sofalizer: use fabsf() instead of fabs()
[12:08:04 CET] <cone-532> ffmpeg 03Paul B Mahol 07master:47ba0854720e: avfilter/af_headphone: use fabsf() instead of fabs()
[13:00:42 CET] <JEEB> wat
[13:02:51 CET] <JEEB> I have a HLS key ending with .key
[13:02:59 CET] <JEEB> and the HLS demuxer says nope
[13:04:03 CET] <JEEB> http://up-cat.net/p/514b4f2b
[13:05:38 CET] <JEEB> or is that just really badly mentioning to me that the file protocol is less open than http?
[14:17:01 CET] <Compn> JEEB : encrypted
[14:17:25 CET] <Compn> ?
[14:17:48 CET] <Compn> i guess demuxer is saying it does not want to open some non hls (m3u8) file
[14:19:47 CET] <Compn> oof that vividas demuxer
[14:20:16 CET] <JEEB> Compn: yes, standard AES encrypted HLS stream that I was generating :P
[14:20:23 CET] <JEEB> and reading locally
[14:20:44 CET] <JEEB> there's seemingly an allowed_extensions AVOption that includes the key file
[14:21:00 CET] <JEEB> could also be limited to the file protocol, but the message received says nothing about that
[14:21:27 CET] <JEEB> > `-allowed_extensions <string>     .D....... List of file extensions that hls is allowed to access (default "3gp,aac,avi,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav")`
[14:25:13 CET] <Compn> http://helixproducts.real.com/hmdp/documentation/helixserver/1512_LR/html/Content/HelixHelp/HLS_Encryption_Basics.htm
[14:25:21 CET] <JEEB> I know how it works
[14:25:30 CET] <Compn> Key files use the playlist file name and end with the file extension .key.
[14:25:31 CET] <Compn> bah
[14:25:35 CET] <Compn> then add .key :P
[14:25:52 CET] <JEEB> the HLS specification AFAIK doesn't limit the file names for keys
[14:25:57 CET] <JEEB> let me check the RFC
[14:26:10 CET] <Compn> i was linking to helix specs for source :P
[14:26:18 CET] <Compn> I know you know how it works 
[14:26:22 CET] <Compn> hehe
[14:26:42 CET] <JEEB> https://tools.ietf.org/html/rfc8216#section-4.3.2.4
[14:27:14 CET] <JEEB> URI is just "The value is a quoted-string containing a URI that specifies how to obtain the key.  This attribute is REQUIRED unless the METHOD is NONE."
[14:27:45 CET] <JEEB> this is regarding the key files, but it doesn't limit the key files either https://tools.ietf.org/html/rfc8216#section-5
[14:28:01 CET] <JEEB> but yea, I have a hunch that these limits are only hit because I use file://
[14:28:05 CET] <JEEB> although I can't be 100% sure :P
[14:28:19 CET] <JEEB> as in, I'm locally testing a stream I'm generating on that box with ffprobe
[14:29:11 CET] <Compn> Playlists that
[14:29:11 CET] <Compn>    violate these rules are invalid; clients MUST fail to parse them.
[14:29:48 CET] <Compn> it lists m3u and m3u8 ....
[14:29:49 CET] <Compn>   File extension(s): .m3u8, .m3u (see Section 4)
[14:29:55 CET] <JEEB> that's for the playlists, yes
[14:30:01 CET] <Compn> oh this is a segment then ?
[14:30:02 CET] <JEEB> they don't limit the extensions for media
[14:30:05 CET] <JEEB> or keys
[14:30:15 CET] <Compn> okey
[14:30:22 CET] <JEEB> #EXT-X-KEY:METHOD=AES-128,URI="das_key.key"
[14:30:22 CET] Action: Compn scurries off
[14:30:26 CET] <JEEB> :P
[14:30:50 CET] <JEEB> otherwise it would have failed at loading the playlist or media
[14:31:02 CET] <JEEB> both of which were OK, as you can see by the default white list :P
[15:17:44 CET] <JEEB> ok so it is file:// specific http://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211796.html
[16:52:42 CET] <durandal_1707> can I get primaries and transfer characteristic from colorspace transformation from YCC to Y'U'V' to RGB ?
[17:02:48 CET] <funman> michaelni: i'm trying to make 420->422 faster by memcpy()ing the Y plane: https://pastebin.com/9teGMmAp
[17:03:04 CET] <funman> any suggestion besides the obvious need to check that pixel format matches?
[17:03:24 CET] <funman> https://github.com/kierank/ffmpeg-obe/commit/5a354020872bec61bea6be7604ec8809af463021 this is an old issue
[17:03:46 CET] <kierank> durandal_1707: ^
[17:03:50 CET] <kierank> you are pixel format expert
[17:04:00 CET] Action: durandal_1707 *hides*
[17:04:26 CET] <funman> shame that swscale doesnt use bufferrefs, would've been just moving pointer rather than memcpy
[17:04:52 CET] <funman> actually i wonder if a UV420 -> UV422 would make sense
[17:08:21 CET] <durandal_1707> funman: please rewrite swscale
[17:09:42 CET] <JEEB> wouldn't you just do something like zimg for most stuff :P
[17:10:06 CET] <JEEB> durandal_1707: also not sure you can get those two separate things from just two images
[17:10:26 CET] <funman> sure
[17:10:54 CET] <funman> also can't pass NULL pointer or 0 stride for Y, check_image_pointers doesn't like it
[17:11:02 CET] <durandal_1707> JEEB: this is about PhotoCD colors that predates all things in zimg
[17:11:14 CET] <JEEB> durandal_1707: those were two separate comments
[17:11:22 CET] <JEEB> first regarding "rewriting swscale"
[17:11:29 CET] <JEEB> second regarding the photocd thing
[17:11:56 CET] <JEEB> I think I might have some old old photocd CD somewhere
[17:12:06 CET] <JEEB> although I mostly remember them already containing JPEGs
[18:20:43 CET] <cone-779> ffmpeg 03Mohammad Izadi 07master:2744d6b364c0: Add HDR dynamic metadata struct (for SMPTE 2094-40) to libavutil
[00:00:00 CET] --- Sat Dec 22 2018


More information about the Ffmpeg-devel-irc mailing list