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

[burek]

[02:32:21 CEST] <cone-698> ffmpeg 03Alex Agranovsky 07master:53e8bef25a78: mpjpeg: CRLF terminating a sequence of MIME headers should not cause an error
[04:06:38 CEST] <J_Darnley> :)
[04:06:53 CEST] <J_Darnley> Not bad for an evening's work.
[04:08:04 CEST] <J_Darnley> ¥Ö¥ê¥³¥ó¡«BLEACH CONCEPT COVERS¡«   becomes   Öê³ó^BLEACH CONCEPT COVERS^
[04:24:08 CEST] <cone-698> ffmpeg 03James Almer 07master:fd9ac48dc8ae: doc: mention libavcodec can decode Opus natively
[04:24:21 CEST] <jamrial> RiCON:  ^
[04:35:20 CEST] <cone-698> ffmpeg 03James Almer 07release/2.4:30f45124778c: doc: mention libavcodec can decode Opus natively
[04:35:21 CEST] <cone-698> ffmpeg 03James Almer 07release/2.5:628479b096fe: doc: mention libavcodec can decode Opus natively
[04:35:22 CEST] <cone-698> ffmpeg 03James Almer 07release/2.6:be9ec446a04e: doc: mention libavcodec can decode Opus natively
[04:35:23 CEST] <cone-698> ffmpeg 03James Almer 07release/2.7:763c0d25b1f4: doc: mention libavcodec can decode Opus natively
[04:35:24 CEST] <cone-698> ffmpeg 03James Almer 07release/2.8:ddbb8d5edadb: doc: mention libavcodec can decode Opus natively
[06:53:23 CEST] <TheRyuu> sent some patches to the ML which fix some (longstanding) issues with how mingw's binutils handles some security related linker flags
[06:54:14 CEST] <TheRyuu> sent them to libav a long time ago (oct 2014 it seems) in the hopes it would just get merged into both but I guess that never happened
[09:43:05 CEST] <wm4> "Jokes asides, may I remind everyone that what happened in that room stays in that room."
[09:43:08 CEST] <wm4> now what does this mean
[09:58:47 CEST] <durandal_1707> they are afraid of themself so must keep everything secret
[10:03:20 CEST] <JEEB> oh please :P
[10:03:53 CEST] <JEEB> TheRyuu: cool
[10:04:03 CEST] <JEEB> I will have to test 'em when I get back home
[10:05:18 CEST] <j-b> wm4: it's obvious, what it means, no?
[10:05:40 CEST] <nevcairiel> it means you have something to hide, which seems silly
[10:05:41 CEST] <wm4> it got really ugly? or you all have a secret plan how to merge again?
[10:06:38 CEST] <j-b> wm4: it did not go ugly at all.
[10:06:52 CEST] <j-b> but cleaning dirty laundry should be kept private.
[10:07:15 CEST] <j-b> nevcairiel: I'm quite sure you could get in the loop easily.
[10:07:40 CEST] <j-b> nevcairiel: but there are actually journalists during VDD and it's not a good idea to have rumours around
[10:25:31 CEST] <nevcairiel> in related topics, are there videos of the talks?
[10:26:06 CEST] <j-b> nevcairiel: yes.
[10:26:17 CEST] <j-b> nevcairiel: all were recorded, and 2 are uploaded already
[10:26:27 CEST] <nevcairiel> great
[10:26:28 CEST] <j-b> all will go up in the next days
[10:34:19 CEST] <TimNich> Quicker than the EBU then...
[10:35:55 CEST] <JEEB> nice
[10:36:00 CEST] <JEEB> the talks were quite good
[10:39:38 CEST] <ubitux> j-b: OTOH i think keeping things private about the reunification of the project from other developers is not exactly honest. a subset of the developers can not decide for everyone, so it might make sense to share the relevant bits of the talk to them (maybe the voting comittee for the ffmpeg side, not sure about libav) 
[10:40:08 CEST] <ubitux> that said, i'm not the good person to tell about this, nor i plan to since i don't really believe anything relevant happened anyway
[10:40:37 CEST] <j-b> ubitux: of course you can talk about other developers
[10:40:38 CEST] <ubitux> but "secrets" don't help this community
[10:40:45 CEST] <j-b> ubitux: the problem is outside of developers
[10:40:48 CEST] <ubitux> ah, well it wasn't obvious then
[10:40:52 CEST] <ubitux> alright then
[10:40:54 CEST] <wm4> well I'm fine with waiting for a while
[10:41:14 CEST] <j-b> ubitux: I'm wiating for people's homework, and believe me, I won't forget anyone that matters
[10:41:19 CEST] <j-b> and I will meet people IRL
[10:41:27 CEST] <j-b> ubitux: the mailing list has 5 journalists so far
[10:41:34 CEST] <TimNich> Surely perceived secrecy tends to cultivate rumours&
[10:41:44 CEST] <ubitux> j-b: i wasn't planing to do this publicly
[10:41:46 CEST] <j-b> including people who will speak on golem and phoronix
[10:41:51 CEST] <ubitux> more about private discussion
[10:41:59 CEST] <j-b> ubitux: of course, that's OK
[10:42:04 CEST] <ubitux> thx
[10:42:15 CEST] <j-b> it's more for people who just wanted to see the popcorn
[10:42:22 CEST] <j-b> or ridicule us further.
[10:42:39 CEST] <wm4> who are those journalists?
[10:42:52 CEST] <wm4> just for some open source magazines and such?
[10:42:56 CEST] <j-b> yes
[10:44:27 CEST] <j-b> a french one on general "digital technologies", a german one only on open source, a UK blogger on open source, a general french journalist
[11:24:14 CEST] <Daemon404> j-b, the first vdd with recorded talks!
[11:24:20 CEST] <Daemon404> (aside from wbs' streamed versions before)
[11:27:56 CEST] <durandal_1707> link?
[11:28:16 CEST] <Daemon404> you'd have to ask j-b
[11:31:15 CEST] <rcombs> adding an AV_OPT_SEARCH flag just needs a micro bump to lavu, right?
[11:32:26 CEST] <wm4> don't know if micro or minor
[11:32:47 CEST] <rcombs> yeah, I'm also unsure
[11:33:04 CEST] <rcombs> wm4: I'm adding a flag for av_opt_get to return NULL if the opt is NULL
[11:33:10 CEST] <rcombs> rather than av_strdup("")
[11:36:22 CEST] <rcombs> (and using that in hls.c instead of checking if strlen(buf) is 0)
[11:39:46 CEST] <wm4> so av_opt_get always returns a string?
[11:39:59 CEST] <rcombs> right
[11:41:07 CEST] <wm4> wouldn't have guessed from the docs or the function signature, heh
[11:41:43 CEST] <wm4> I don't know if a search flag would be appropriate for this, I wouldn't mind, but others have to know
[11:42:25 CEST] <rcombs> https://gist.github.com/070535a3cdee287d5bcf
[11:42:49 CEST] <ubitux> wm4: btw, about the patchset
[11:43:02 CEST] <ubitux> wm4: what you can do also is remove the drop dups by default
[11:43:11 CEST] <ubitux> except for srt
[11:43:25 CEST] <ubitux> and configurable with a private option, be it at srt or format level
[11:43:39 CEST] <rcombs> ubitux: I thought that was there for WebVTT
[11:43:40 CEST] <ubitux> your solution is fine anyway (you have write perms, right?)
[11:43:49 CEST] <wm4> ubitux: it could be moved to a separate function, which is called by srtdec only
[11:43:52 CEST] <wm4> yes
[11:44:01 CEST] <ubitux> rcombs: nope, it's for a heavily messed up srt 
[11:44:04 CEST] <rcombs> ubitux: as WebVTT duplicates events that fall across segment boundaries when muxed in HLS
[11:44:20 CEST] <rcombs> though I'd expect handling for that to belong in the HLS demuxer
[11:44:41 CEST] <ubitux> will it really work? the heuristic check for start time, duration and content
[11:45:28 CEST] <ubitux> wm4: yeah i don't know; current quick fix is fine
[11:46:09 CEST] <wm4> ubitux: also I have a vobsub which hides all subtitles, because this condition triggers: if ((startcode & 0x1f) != idx_pkt.stream_index)
[11:46:21 CEST] <wm4> with this comment before it /* the current chunk doesn't match the stream index (unlikely) */
[11:47:29 CEST] <wm4> the value seems to be offset by 1
[11:48:50 CEST] <wm4> so the start byte e.g. indicates 2, while idx_pkt.stream_index is 1
[11:50:32 CEST] <ubitux> :/
[11:51:00 CEST] <ubitux> so you have an index file for a given stream while the packet is not actually for that stream?
[11:51:26 CEST] <ubitux> this stuff is extremelly confusing, i'm a bit reluctant to have a look again at it
[11:51:31 CEST] <wm4> yeah... sample here: https://www.sendspace.com/file/136trd (sorry, it's 2 nested rar archives...)
[11:52:23 CEST] <wm4> sub->stream_index = s->nb_streams - 1;
[11:52:41 CEST] <wm4> shouldn't it use the index field?
[11:52:56 CEST] <wm4> the idx file says for the first stream: id: ar, index: 1
[12:02:37 CEST] <ubitux> wm4: mmh maybe it should be sub->stream_index = s->streams[s->nb_streams - 1]->id
[12:02:43 CEST] <wm4> yeah
[12:02:43 CEST] <ubitux> indeed
[12:02:49 CEST] <wm4> running fate on that right now
[12:02:58 CEST] <wm4> or actually no
[12:03:12 CEST] <wm4> what I did was comparing the start byte index with the header's stream id
[12:03:17 CEST] <ubitux> make fate-subtitles is your friend
[12:04:14 CEST] <michaelni> j-b, ive been told the FFmpeg flv demuxer has problems/bugs and that i should ask you about that, can you explain how to reproduce the issues or which tickets describe the issues ?
[12:05:20 CEST] <ubitux> wm4: and btw, many .vob/idx are created by mencoder
[12:05:49 CEST] <wm4> yeah, I still have another broken file that was definitely created by mencoder
[12:05:52 CEST] <ubitux> ...because ffmpeg is still unable to write some (because i have no idea how to make sure we create valid files for those, regarding timing - apparently Nicolas was saying there were design issue too)
[12:05:56 CEST] <wm4> (and the original DVD subs work)
[12:07:46 CEST] <ubitux> wm4: btw, unrelated but as you know, j-b doesn't like much/at all nicknames in git names; you might want to reconsider this
[12:07:59 CEST] <ubitux> (i'm not going to raise this again any time soon because ENOCARE)
[12:08:21 CEST] <ubitux> (just saying because it was mentioned @ VDD again)
[12:08:35 CEST] <Daemon404> wm4's realname is on his github anyway
[12:08:41 CEST] <Daemon404> if one is so inclined they can amend before push
[12:09:03 CEST] <ubitux> but he can write push now
[12:09:36 CEST] <wm4> actually michael asked for my key a long time ago (maybe was worried that I sent patches to Libav trollol)
[12:09:41 CEST] <wm4> ubitux: patch sent
[12:10:15 CEST] <wm4> if enough people care strongly enough about it, I can change my git author field (suggestions welcome)
[12:10:58 CEST] <ubitux> http://www.fakenamegenerator.com/
[12:11:05 CEST] <ubitux> you're now Karen W. Rouse
[12:11:07 CEST] <ubitux> nice to meet you
[12:11:53 CEST] <wm4> wow this thing is awesome
[12:12:04 CEST] <wm4> "Age    82 years old "
[12:12:13 CEST] <wm4> well still could use some tuning, who on the internet is that old?
[12:13:41 CEST] <Daemon404> wm4, vcmohan on doom9
[12:13:45 CEST] <Daemon404> stil writing filters for vs and avs
[12:14:45 CEST] <wm4> who what why
[12:23:08 CEST] Action: rcombs updates his internet-draft
[12:27:14 CEST] <rcombs> ubitux: happen to know the answer to my lavu version bump question?
[12:27:34 CEST] <nevcairiel> minor
[12:28:05 CEST] <nevcairiel> micro is usually not used very often, just for minor  behavior changes and the like
[12:36:24 CEST] <wm4> now I'll be hoping cehoyos won't close them as invalid /nag
[12:50:01 CEST] <cone-180> ffmpeg 03Ganesh Ajjanagadde 07master:a0e6e471db25: configure: silence error if tput not found
[13:02:45 CEST] <durandal_1707> should I call zimg filter zscale?
[13:03:25 CEST] <wm4> durandal_1707: sounds ok
[13:07:31 CEST] <Daemon404> ... this is a thing thats really happening?
[13:07:36 CEST] <Daemon404> :o
[13:14:04 CEST] <cone-180> ffmpeg 03wm4 07master:a47ad06baf6c: avformat/vobsub: compare correct packet stream IDs
[13:15:50 CEST] <wm4> michaelni: you shouldn't have pushed that... I wanted to add the track issue number
[13:16:07 CEST] <Daemon404> too late now
[13:16:11 CEST] <Daemon404> just reply to the bug i guess.
[13:26:23 CEST] <michaelni> wm4, oops, sorry
[13:47:22 CEST] <cone-180> ffmpeg 03wm4 07master:c216324a7f95: avformat/subtitles: make dropping duplicate events optional
[13:47:23 CEST] <cone-180> ffmpeg 03wm4 07master:5c93e57f5c07: avformat/vobsub: do not attempt to check duplicate subtitles
[13:47:24 CEST] <cone-180> ffmpeg 03wm4 07master:265d2a73d6da: avformat/assdec: do not drop duplicate subtitles
[13:47:25 CEST] <cone-180> ffmpeg 03wm4 07master:4ed5a73a7ebc: avcodec/dvdsubdec: fix indentation
[13:56:46 CEST] <wm4> where's compn when you need him?
[13:56:59 CEST] <Daemon404> in paris
[14:01:47 CEST] <atomnuker> nah, he's flying today
[14:02:06 CEST] <Daemon404> o ok
[14:44:39 CEST] <zylthinking> Is a bug in aac decoder that: when I use my get_buffer2, then I get frame->nb_samples == 2048, but indeed it should be 1024, the document says nb_samples is per channel
[14:46:34 CEST] <wm4> zylthinking: it might request more than it will actually return
[14:46:44 CEST] <zylthinking> and sample_fmt == AV_SAMPLE_FMT_FLTP, while,  if I use the default get_buffer2, and the pcm turns out only having one channel; both channel are in the data[0], the second plane is following the fitst
[14:46:58 CEST] <zylthinking> first
[14:47:12 CEST] <wm4> uh what
[14:48:53 CEST] <zylthinking> e.g. I get frame->extended_data[1] == NULL  && channels == 2
[14:50:03 CEST] <wm4> then the sample format is definitely not AV_SAMPLE_FMT_FLTP
[14:53:06 CEST] <zylthinking> it is AV_SAMPLE_FMT_FLTP, but frame->extended_data[1] is NULL,  all data is in frame->extended_data[0]
[14:53:43 CEST] <wm4> then this would be either a major bug which surprisingly nobody else noticed yet, or you did something wrong
[14:53:58 CEST] <zylthinking> the 2nd planar is at frame->extended_data[0] + bytes_of(planar 0)
[14:55:01 CEST] <wm4> data[1] should definitely point to it
[14:56:17 CEST] <zylthinking> yes
[14:56:47 CEST] <zylthinking> I think
[14:57:06 CEST] <wm4> show your code
[14:58:39 CEST] <zylthinking> I am looking for a web site to paste the code, 
[15:00:00 CEST] <fritsch> pastebin.com
[15:00:02 CEST] <fritsch> sprunge.us
[15:01:14 CEST] <wm4> sprunge.us is preferable
[15:01:26 CEST] <wm4> (no ads etc.)
[15:03:07 CEST] <zylthinking> I cant access the pastebin.com, the second I get a man manual?
[15:03:42 CEST] <fritsch> click on: ?<lang>
[15:03:54 CEST] <wm4> no, the link below
[15:03:58 CEST] <fritsch> yeah :-)
[15:04:12 CEST] <fritsch> use this "form" <- there
[15:04:59 CEST] <wm4> I wanted to suggest privatepaste.com, but apparently it died recently
[15:05:50 CEST] <zylthinking> http://sprunge.us/iCic
[15:08:10 CEST] <zylthinking> there are 3 functions, the ffmpeg_open is the init, frame_buffer_get is my get_buffer2, and the 3rd is the place where that extended_data[1] == null is detected
[15:09:04 CEST] <wm4> so you're saying it runs "packed = 1;"?
[15:09:39 CEST] <zylthinking> yes
[15:09:51 CEST] <wm4> is this with get_buffer2 set or not?
[15:09:58 CEST] <zylthinking> while, I get extended_data[1] == null with  //context->get_buffer2 = frame_buffer_get;, so it is not the fault of frame_buffer_get
[15:10:12 CEST] <zylthinking> it does not been set
[15:11:18 CEST] <nevcairiel> i never bothered to sanity check the data pointers and my code never crashed
[15:11:24 CEST] <nevcairiel> i call shenanigans
[15:11:24 CEST] <zylthinking> the frame_buffer_get is another problem, e.g. I dont know where is the error, my get_buffer2 does not work, some noise in the result pcm
[15:11:50 CEST] <wm4> btw. you shouldn't check AVCodecContext.sample_fmt, just AVFrame.format (but that's unlikely to be the problem here)
[15:12:07 CEST] <nevcairiel> equally, you should check the channel count in AVFrame
[15:12:33 CEST] <nevcairiel> there is no guarantees otherwise
[15:12:43 CEST] <zylthinking> AVFrame->channel is 2
[15:15:06 CEST] <zylthinking> I have print it but deleted it 
[15:43:14 CEST] <zylthinking> and I found just now that: frame->nb_samples in aac get_buffer2 is doubled too, same issue with extended_data[1] == NULL ones and this cause the moise in the result of pcm using frame_buffer_get 
[16:19:14 CEST] <rcombs> what nick does Nicolas George go by here?
[16:19:40 CEST] <Daemon404> he does not use irc.
[16:19:59 CEST] <ubitux> rcombs: Cigaes when he's on irc, which is only on rare occasions
[16:23:22 CEST] <rcombs> thanks
[16:25:41 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/chromakey/libavfilter/vf_chromakey.c#L99 is this realy worth the effort of moving some dereferencing in from of the loop? It seems like something the compiler would do anyway.
[16:26:12 CEST] <ubitux> bench it
[16:26:21 CEST] <ubitux> also doing a p += linesize to save a mult
[16:27:11 CEST] <wm4> ubitux: that mencoder vobsub sample is weird... if I change the dvdsub packet reassembly code to something incorrect, it works
[16:27:39 CEST] <ubitux> vobsub is always weird, but that's most likely because of my lack of understanding of it
[16:28:01 CEST] <wm4> so if I never concat more than 2 packets, it works
[16:33:17 CEST] <wm4> but of course this makes sub2video fail
[17:00:53 CEST] <BtbN> So... my attempt at optimizing that code makes it significantly slower.
[17:00:59 CEST] <BtbN> Better leave it to the compiler i guess.
[17:03:10 CEST] Action: ubitux wonders why av_strtod is in lavu/eval.h
[17:10:33 CEST] <durandal_1707> where is set how data is aligned?
[17:12:17 CEST] <durandal_1707> I get error that its not 64 byte aligned
[17:13:12 CEST] <wm4> your question is so wonderfully unspecific and badly formulated
[17:14:49 CEST] <Daemon404> zimg probably requires memory alignment.
[17:15:59 CEST] <BtbN> ubitux, gcc is doing more black magic than I ever could with the original code. It even optimized out the multiplications with y.
[17:25:27 CEST] <durandal_1707> actually both alignments are 32
[17:26:40 CEST] <Daemon404>   * Generally, the image stride must be a multiple of the alignment
[17:26:40 CEST] <Daemon404>   * imposed by the target CPU architecture, which is up to 64 bytes on
[17:26:41 CEST] <Daemon404>   * x86 and AMD64. The stride may be negative.
[17:27:01 CEST] <durandal_1707> src()->data(0) is not 32 aligned
[17:27:29 CEST] <ubitux> BtbN: i guess it's starting to get pretty good
[17:27:37 CEST] <durandal_1707> I dont get linesize assert
[17:31:35 CEST] <durandal_1707> indeed its only 16 aligned wtf
[17:35:55 CEST] <durandal_1707> something sucks here...
[17:44:32 CEST] <durandal_1707> If I don't use lavfi it works
[17:45:20 CEST] <durandal_1707> guess I need to alloc and copy in this case or simply abort
[17:47:23 CEST] <durandal_1707> hmm its 10 times slower than swscale
[17:51:30 CEST] <wm4> how did you determine this?
[18:10:40 CEST] <durandal_1707> Resize to hd720 matrixbench
[18:27:18 CEST] <JEEB> seems like some versions don't have all of the simd available yet
[18:28:20 CEST] <durandal_1707> I have git version build on i3
[18:33:16 CEST] <JEEB> granted, z will never be faster than swscale as it tries to do things right, but it seems like the difference tested with simd is less than 2x (120 vs 190fps with threads on bilinear)
[18:35:04 CEST] <wm4> ubitux: sent a patch for the vobsub crap
[18:35:33 CEST] <wm4> this was odd, 2 reports on different vobsub issues on the same day, both which made them "invisible"
[18:36:23 CEST] <durandal_1707> JEEB: what you used to test?
[18:36:45 CEST] <JEEB> ask lachs0r for details on #mpv
[18:37:52 CEST] <JEEB> i think the version is 1.1.1
[18:38:10 CEST] <JEEB> which is probably an older api version
[19:34:35 CEST] <cone-559> ffmpeg 03James Almer 07master:91fcb10f0815: x86/vp9dsp: add missing header include
[19:38:00 CEST] <jamrial> ugh
[19:39:06 CEST] <cone-559> ffmpeg 03James Almer 07master:7086154aaa24: x86/vp9dsp: fix local header include
[21:01:37 CEST] <rcombs> nevcairiel: > AAC without extradata is invalid
[21:01:45 CEST] <rcombs> nevcairiel: in Matroska, [citation needed]
[21:02:05 CEST] <nevcairiel> read the codec spec :p
[21:02:10 CEST] <rcombs> AFAICT from http://matroska.org/technical/specs/codecid/index.html AAC isn't supported to have CodecPrivate
[21:02:16 CEST] <rcombs> "The private data is void"
[21:02:22 CEST] <rcombs> am I reading that wrong?
[21:02:29 CEST] <nevcairiel> yes
[21:02:45 CEST] <nevcairiel> those are the deprecated tags that code the information into the codec id
[21:03:04 CEST] <nevcairiel> technically you would still need the extradata to actually construct that codec id
[21:03:34 CEST] <nevcairiel> but the correct one would be simple A_AAC with codec private
[21:03:36 CEST] <nevcairiel> see http://haali.su/mkv/codecs.pdf
[21:03:39 CEST] <rcombs> ahh
[21:03:56 CEST] <JEEB> classic
[21:04:05 CEST] <JEEB> information not in the official spot but in codecs.pdf
[21:04:11 CEST] <JEEB> welcome to le matroska
[21:04:32 CEST] <j-b> complain to robux to fix the spec
[21:04:36 CEST] <j-b> he does it nicely
[21:05:02 CEST] <rcombs> nevcairiel: well, the issue is that the extradata is generated by the bsf when the first packet is written, which happens after the matroska header is written
[21:06:02 CEST] <wm4> note that A_AAC/... is enough (or can be?) to reconstruct the extradata, while A_AAC alone has not enough information
[21:06:07 CEST] <wm4> (I guess.)
[21:06:29 CEST] <nevcairiel> wm4: the long form is limited though for more complex coding fe atures
[21:06:51 CEST] <nevcairiel> and reconstructing the init data needs quite complex handling in the demuxer
[21:06:59 CEST] <nevcairiel> wouldnt be sure everyone does that
[21:07:04 CEST] <rcombs> the MOV encoder, when encoding MPEG-DASH, has a similar issue around& uh, I think it was E-AC-3
[21:07:27 CEST] <nevcairiel> rcombs: i'm not against fixing it properly, but not just reverting some commit that would once again create broken files
[21:08:47 CEST] <rcombs> yeah, the header needs a bit of data that the muxer determines based on the first packet
[21:09:10 CEST] <rcombs> so it delays writing the header until the first packet has been muxed, I think into an in-memory buffer
[21:09:19 CEST] <rcombs> which is& not fun
[21:09:32 CEST] <rcombs> see the "delay_moov" flag
[21:09:33 CEST] <nevcairiel> i think mov does that to some degree, yes
[21:10:03 CEST] <rcombs> so, to handle this properly matroska would need to do something similar for AAC
[21:10:34 CEST] <nevcairiel> I would rather think about fixing that in a more generic fashion
[21:10:51 CEST] <rcombs> also, not sure if I've mentioned lately but fuck BSFs
[21:11:00 CEST] <nevcairiel> like somehow enabling bsfs to generate extradata before starting muxing
[21:11:19 CEST] <wm4> there seem to be plenty of situations where something seems to rely on pre-provided info, while it really should wait for some real data
[21:11:32 CEST] <wm4> wasn't there something with ffmpeg.c and lavfi recently?
[21:11:33 CEST] <rcombs> because telling the user to explicitly enable them is dumb
[21:12:10 CEST] <nevcairiel> yes automagic would be nice
[21:12:16 CEST] <JEEB> ye
[21:12:35 CEST] <nevcairiel> delaying writing the header for all sorts of formats is rather complex however
[21:12:44 CEST] <rcombs> I find it really amusing that like half of these kinds of bitstream issues are handled within the demuxer
[21:13:07 CEST] <rcombs> like, converting annexb to mp4, or pulling out the eac3 meta for mov, etc&
[21:13:15 CEST] <rcombs> and the other half require the user to do something
[21:13:53 CEST] <nevcairiel> one idea of a solution would be to implement a split function in the aac parser that tries to fill the extradata field
[21:14:01 CEST] <nevcairiel> not sure if that would work, but its an idea
[21:14:17 CEST] <rcombs> hmm, seems pretty sane for this case
[21:14:30 CEST] <rcombs> would probably handle eac3 for mov as well
[21:14:49 CEST] <nevcairiel> technically adts aac should not have any extradata, so i'm not sure if that wouldnt have negative side-effects however
[21:15:38 CEST] <rcombs> hopefully muxers expecting adts wouldn't write extradata?
[21:15:51 CEST] <nevcairiel> generic code is generic
[21:15:54 CEST] <wm4> why does the concept of extradata even exist
[21:16:01 CEST] <wm4> stupid multimedia
[21:16:07 CEST] <nevcairiel> because many many codecs use such a concept
[21:16:25 CEST] <nevcairiel> and its not too bad, global init data isnt too arcane of a concept
[21:16:27 CEST] <rcombs> it makes enough sense for e.g. H264's SPS/PPS stuff
[21:16:42 CEST] <rcombs> though it's dumb if you have those in the bitstream as well
[21:16:44 CEST] <nevcairiel> i mean you could inline and repeat that info on every key frame
[21:16:52 CEST] <nevcairiel> but you may not always want that
[21:17:16 CEST] <rcombs> unnecessarily redundant if you're not some streaming format like mpegts
[21:17:17 CEST] <nevcairiel> why AAC really needed that I'm not sure
[21:17:41 CEST] <nevcairiel> the headers are so simple for them
[21:18:08 CEST] <wm4> surely these few bytes would be harmless compared to the extra complexity and mess
[21:18:28 CEST] <nevcairiel> AAC is even more evil with its three bitstream formats
[21:18:35 CEST] <nevcairiel> raw + extra, ADTS, and LATM/LAOS
[21:19:07 CEST] <rcombs> raise your hand if you forgot about LATM
[21:19:09 CEST] Action: rcombs raises hand
[21:21:17 CEST] <jamrial> we still need a latmtoacs bsf
[21:21:46 CEST] <rcombs> or just do that in the demuxers/muxers that expect/don't expect it
[21:22:14 CEST] <jamrial> there's a two years old ticket about it, even. #2439
[21:22:32 CEST] <nevcairiel> i think thats a bit more complex
[21:22:37 CEST] <nevcairiel> even has its own codec id and everything
[21:24:30 CEST] <rcombs> nevcairiel: would you be against allowing writing the invalid files for now if `-strict experimental` is passed?
[21:24:37 CEST] <nevcairiel> no
[21:24:40 CEST] <nevcairiel> wait
[21:24:40 CEST] <nevcairiel> yes
[21:24:44 CEST] <nevcairiel> yes against :P
[21:24:48 CEST] <nevcairiel> should read question properly
[21:25:08 CEST] <nevcairiel> intentionally creating broken files is stupid
[21:27:19 CEST] <rcombs> well, if you know it's only going to be read by lavf (this is a streaming use-case), it's better than failure
[21:27:37 CEST] <rcombs> but I'll check out doing it in the parser
[21:27:40 CEST] <nevcairiel> if you control both ends, stream mpegts
[21:27:44 CEST] <nevcairiel> :P
[21:29:06 CEST] <nevcairiel> and you know that people will just blanket that option and generate files no matter what use-case
[21:30:10 CEST] <wm4> I'm not sure if there were ever cases of "-strict experimental" where it was certain that the result wasn't corrupted
[21:30:17 CEST] <wm4> so that's just business as usual
[21:30:19 CEST] <jamrial> seeing how the aac enconder has needed it all this time, i can see some people using it out of habit
[21:30:23 CEST] <jamrial> even when non needed
[21:32:38 CEST] <wm4> kierank: also, lol
[21:33:07 CEST] <kierank> wm4: ...
[21:48:07 CEST] <rcombs> nevcairiel: well, doing it in the parser seems to work
[21:48:10 CEST] <rcombs> at least, it makes the muxer happy
[21:48:43 CEST] <rcombs> now running fate, and then will test some things more specifically to see if it breaks anything else
[21:48:49 CEST] <nevcairiel> would still need some careful checking that there are no fixed assumptions that ADTS has to have a null extradata
[21:49:07 CEST] <rcombs> maybe add something like AVSTREAM_PARSE_GENERATE_EXTRADATA?
[21:49:55 CEST] <nevcairiel> how do you do the generation, anyway?
[21:49:57 CEST] <rcombs> though if we're going to do that, we may as well move the whole adts->asc conversion to the parser and have some way of signaling that it's desired
[21:50:05 CEST] <nevcairiel> from what I remember from the split function, it cannot write to extradata directly
[21:50:08 CEST] <rcombs> I just copied the code out of the bsf
[21:50:23 CEST] <nevcairiel> its supposed to tell the code an  offset of which data should be copied into extradata
[21:51:17 CEST] <nevcairiel> although I suppose there is no harm in actually writing it
[21:51:49 CEST] <rcombs> it doesn't break fate, at least
[21:55:06 CEST] <rcombs> needs better error handling, too
[23:12:51 CEST] <J_Darnley> heh, I didn't think it would be this fun working with character encoding.
[23:51:52 CEST] <JEEB> durandal_1707: I have a feeling that YCbCr<->RGB conversions might fail since you're not setting coeffs (+ unspecified is the default so I'm not sure if you have to set it)
[23:53:53 CEST] <JEEB> will try to test that thing soon
[00:00:00 CEST] --- Tue Sep 22 2015