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

[burek]

[00:14:41 CEST] <cone-891> ffmpeg 03Danil Iashchenko 07master:9f1787513475: libavfilter: Add OpenCL convolution filter
[00:14:41 CEST] <cone-891> ffmpeg 03Mark Thompson 07master:213839edffbf: vf_avgblur_opencl: Don't run kernel on pixels outside the image
[00:14:41 CEST] <cone-891> ffmpeg 03drfer3 07master:29c663d50cbf: avfilter/vf_avgblur_opencl: fix error when clSetKernelArg fails
[00:14:41 CEST] <cone-891> ffmpeg 03Jun Zhao 07master:ac6e27d74f6a: kmsgrab: add category for kmsgrab
[00:35:10 CEST] <jkqxz> michaelni:  HDMI is not freely available, but you can find PDFs of the older 1.3 and 1.4 versions with Google.
[00:56:49 CEST] <cone-891> ffmpeg 03Timo Rothenpieler 07master:3914c8e0e6ba: avformat/hlsenc: initialize saveptrs
[01:15:16 CEST] <atomnuker> why are we getting so many emails on the ml now?
[01:15:27 CEST] <atomnuker> january + feburary + half of march were quiet
[01:18:19 CEST] <Chloe> atomnuker: I wonder how many of those email are under threads I started
[01:19:06 CEST] <nevcairiel> not that many
[01:19:15 CEST] <nevcairiel> a lot of patches coming in as well
[01:19:56 CEST] <Chloe> Itd be interesting to see how it relates to prior years
[02:13:27 CEST] <kierank> I don't understand the point of this sei injection code
[02:13:43 CEST] <kierank> if the code doesn't understand reordering
[03:40:34 CEST] <klaxa> hmm yeah after looking at them i think i'll replace my segment.* and buffer.* by lavutil's segment.h and fifo.h
[09:25:36 CEST] <gagandeep> i have sent the patch with updates in cfhd.c and fate reference combined
[09:25:54 CEST] <gagandeep> first mail i screwed up combining two commits
[09:26:12 CEST] <gagandeep> new mail has been sent just now
[09:28:14 CEST] <durandal_1707> gagandeep: have you sent final proposal?
[09:28:36 CEST] <gagandeep> yeah i have sent the draft proposal on gsoc, i would have liked if someone had seen it
[09:28:46 CEST] <durandal_1707> gagandeep: i asked for FINAL?
[09:28:54 CEST] <gagandeep> i have yet to submit final pdf
[09:29:01 CEST] <gagandeep> 8 hrs to go
[09:34:40 CEST] <gagandeep> kierank: can you look into the proposal draft
[09:35:07 CEST] <durandal_1707> so you gonna wait 7 hrs and 59 min?
[09:35:36 CEST] <gagandeep> durandal_1707: don't know what you mean by that?
[09:36:05 CEST] <gagandeep> it's info should have been provided by gsoc to ffmpeg
[09:36:20 CEST] <gagandeep> should i have sent the link to doc on ml last night
[09:40:20 CEST] <gagandeep> i just want to confirm if the parties involved have checked the proposal although it sticks to the timeline discussed  previously
[09:53:08 CEST] <nevcairiel> durandal_1707: bluray eac3 sample, freshly extracted from a disc https://files.1f0.de/samples/ww_eac3.eac3 .. i tried to pick a part with some more action so all the channel  hopefully have audio
[10:08:23 CEST] <durandal_1707> nevcairiel: i guess i will check only if channel_map is 1A00 and act accordingly - just hardcode stuff
[10:08:49 CEST] <nevcairiel> are you sure you're reading it right, the docs seem so easy
[10:08:49 CEST] <durandal_1707> are there eac3+ samples with atmos?
[10:08:57 CEST] <nevcairiel> technically yes, but i dont have any
[10:09:06 CEST] <nevcairiel> it exists on some UHD Blu-rays
[10:09:44 CEST] <durandal_1707> nevcairiel: if i had sample with different channel map then 0x1A00 it would help to resolve this
[10:10:08 CEST] <durandal_1707> but it appears every single of them is only 7.1 and thus 0x1A00
[10:10:30 CEST] <durandal_1707> it could support 8.1 just fine...
[10:10:42 CEST] <nevcairiel> 7.1 is the maximum on blu-ray anyway
[10:10:46 CEST] <nevcairiel> but in theory it could be 6.1
[10:10:51 CEST] <nevcairiel> no idea if that exists anywhere tho
[10:18:19 CEST] <CounterPillow> Every day until FFmpeg 4.0 is released, I will fart on my cat. Choose wisely.
[10:37:36 CEST] <nevcairiel> durandal_1707: i read the spec again and checked the chanmap value from the bitstream, and it seems reasonable to me, i just read it backwards at first
[10:38:11 CEST] <nevcairiel> 0001101000000000 is interpeted as bits 3, 4 and 6 set, which indicate left surround, right surround and Lrs/Rrs pair (ie. rear speakers)
[10:38:26 CEST] <nevcairiel> basically the exact layout i expected from bluray
[10:39:14 CEST] <nevcairiel> so in practice, replace side surround speakers, and add rear speakers
[10:40:15 CEST] <nevcairiel> the table is MSB-first, which was confusing me at first
[10:43:55 CEST] <nevcairiel> it makes sense if one reads it bit-by-bit, but not when reading it as a 16-bit number :)
[10:45:08 CEST] <durandal_1707> yea, i was stripping leading zeros
[10:47:08 CEST] <durandal_1707> so how implement this sanely? i mean other cases for which there is no samples.
[10:48:57 CEST] <nevcairiel> i dont suppose we have a function to get the index of a specific channel
[10:48:59 CEST] Action: nevcairiel checks
[10:49:34 CEST] <nevcairiel> actually we do
[10:52:36 CEST] <durandal_1707> gagandeep: perhaps you could put more stuff in proposal
[10:52:52 CEST] <durandal_1707> gagandeep: like other remaining stuff if time permits
[10:54:47 CEST] <kierank> gagandeep: you should delete fate test
[10:59:44 CEST] <nevcairiel> durandal_1707: my idea would be to build a final combined channel layout, which should be relatively easy (just need a table to make a channel_layout from chanmap, and OR that with the core), and then iterate over 0..nb_channels and for every channel check if its in the dependent frame and use that, or use the core channel if not in dependent, we have all the av_get_channel_layout* functions to get the required indices and stuff
[11:03:46 CEST] <nevcairiel> you already copy channels into the final output anyway, so that should be easy
[11:04:02 CEST] <nevcairiel> just need to somehow remember the channel layout of the core before the decoder overwrites it with the dependent frame stuff
[11:08:45 CEST] <gagandeep> kierank: delete fate test?
[11:09:16 CEST] <kierank> Of course, it's green
[11:09:45 CEST] <nevcairiel> wasnt the green just a pixel diff to show the difference
[11:11:25 CEST] <gagandeep> kierank: the difference in raw videos generated by ffmpeg i did is this
[11:11:26 CEST] <gagandeep> https://imgur.com/a/WbLaz
[11:11:56 CEST] <kierank> Ah it's a difference
[11:12:21 CEST] <kierank> Iirc libav put a fate test that didn't work
[11:12:52 CEST] <gagandeep> well the output had all white with text frames so it wasn't noticable
[11:13:09 CEST] <kierank> Ah ok
[11:13:10 CEST] <gagandeep> i was also perplexed seeing how the hell output is different with patch
[11:17:37 CEST] <gagandeep> durandal_1707: kierank has told me that implementing bayer could be troublesome, so right now i have kept that thing as stuff to be done in last
[11:26:45 CEST] <gagandeep> kierank: shall i submit the proposal finally
[11:30:20 CEST] <durandal_1707> nevcairiel: what is Lrs and Rrs ?
[11:37:44 CEST] <durandal_1707> probably bakc left and right
[11:37:59 CEST] <durandal_1707> but other names like Cs and Ts are too cryptic
[12:05:00 CEST] <nevcairiel> Left/right rear surround,
[12:05:06 CEST] <nevcairiel> so yeah, back
[12:05:29 CEST] <durandal_1707> and Cs, Ts
[12:06:08 CEST] <nevcairiel> center surround, top  surround, not sure we have flags for those
[12:06:49 CEST] <nevcairiel> oh center surround is back center
[12:06:58 CEST] <nevcairiel> top surround is maybe top center then?
[12:08:04 CEST] <nevcairiel> lsd/rsd is Left surround direct
[12:08:46 CEST] <nevcairiel> Vhl/vhr is top front
[12:09:37 CEST] <nevcairiel> SMPTE 428-3 describes them
[12:13:32 CEST] <nevcairiel> apparently we do have flags for all of them
[12:29:41 CEST] <durandal_1707> nevcairiel: what order of channels is in dependent substream/frame?
[12:30:00 CEST] <nevcairiel> durandal_1707:  the order as the bits in the chanmap
[12:30:04 CEST] <nevcairiel> for pairs, left first
[13:24:22 CEST] <durandal_1707> nevcairiel: i mean in extra 4.0 one, which is which?
[13:31:09 CEST] <nevcairiel> durandal_1707: like i said, its coded in the same order as the chanmap table defines the channel
[13:31:41 CEST] <nevcairiel> so in those BD streams left/right surround first, followed by left/right rear
[13:36:27 CEST] <durandal_1707> it appears it is different
[13:38:19 CEST] <nevcairiel> thats what the spec writes anyway
[13:48:27 CEST] <durandal_1707> got it
[13:56:19 CEST] <durandal_1707> nevcairiel: should i add core option name to decode only independent stream?
[13:57:01 CEST] <nevcairiel> someone might want that, not me though
[13:58:02 CEST] <durandal_1707> is issue if demuxer still returns 5.1?
[13:58:17 CEST] <nevcairiel> its not perfect but can be fixed later
[14:52:11 CEST] <durandal_1707> who gonna push those hevc neon asm patches?
[15:00:25 CEST] <durandal_1707> nevcairiel: are there any eac3 samples in wild that use multiple non-zero substream ids?
[15:13:52 CEST] <gagandeep> 'in the wild' haha
[15:21:39 CEST] <durandal_1707> gagandeep: yes on internet or darknet
[15:32:11 CEST] <durandal_1707> atomnuker: are you saying if I found in book that c = a^2 + b^2 it can not be used, how that is different from reading disasembled code?
[15:36:18 CEST] <atomnuker> durandal_1707: if you have an army of lawyers like nvidia does and even hint they you copied something you're going to jail
[15:38:46 CEST] <iive> there used to be a patent on using XOR to draw image cursor.
[15:40:39 CEST] <iive> and you may not go to jail, you may just go bankrupt from court and lawyer fees.
[15:40:52 CEST] <durandal_1707> atomnuker: so we would get what? DMCA request to remove such code?
[15:41:35 CEST] <kierank> gagandeep: on my phone, can't see your application I am afraid
[15:42:27 CEST] <durandal_1707> this just seems silly considering how lot of stuff in ffmpeg is already patented
[15:43:02 CEST] <gagandeep> Kierank: https://docs.google.com/document/d/1cRnlt8jU6A6n10WAb24fMO8y_E-SweU952FSFKUPyqQ/edit?usp=drivesdk&ouid=110884978300969187410
[15:43:04 CEST] <gagandeep> See if this works
[15:43:04 CEST] <gagandeep> I have stuck to the timeline discussed with you
[15:44:02 CEST] <durandal_1707> gagandeep: i read it, and it is looking good
[15:44:22 CEST] <kierank> Yes seems ok
[15:46:20 CEST] <gagandeep> durandal_1707: thanks , you've also been a lot of help in the past month
[15:49:44 CEST] <atomnuker> durandal_1707: its not patent stuff I'm worried about, its copyright
[15:50:13 CEST] <tguillem> Hi, did someone already tested the videotoolboxenc for realtime ? I'm trying to use it via VLC for chromecast but I have the feeling that it's even less realtime with the kVTCompressionPropertyKey_RealTime set to true.
[16:17:22 CEST] <tguillem> ok, It's really realime and size/bitrate are more than correct for streaming. I guess chromecast doesn't like video encoded by VT. Tweaking some options to identify the issue...
[16:28:44 CEST] <cone-284> ffmpeg 03James Almer 07master:d205c8f3bbde: avcodec/avpacket: remove unnecessary check in av_packet_make_writable()
[16:35:26 CEST] <nevcairiel> durandal_1707: dont think so, the only error i ever saw was dependent substreams
[17:58:03 CEST] <atomnuker> why does (av_)strtok modify the source pointer? tokenization is doable in-place, isn't it
[17:58:15 CEST] <atomnuker> *modify the source buffer
[18:02:05 CEST] <wm4> because that's how strtok works
[18:02:11 CEST] <wm4> there are better ways to parse strings
[18:21:12 CEST] <wm4> jamrial: I think a new side data could be added in a compatible way by adding awkward accessors that let the new API access the old one
[18:21:29 CEST] <wm4> so the side data code would internally have to access AVPacket/AVFrame etc.
[18:21:33 CEST] <wm4> not sure if worth the trouble
[18:28:10 CEST] <jamrial> it's worth the trouble if there's no other way to introduce a better side data api while trying to keep the old one working for a while
[18:28:30 CEST] <jamrial> wouldn't be the first time awkward compat code is added for something like this
[18:34:00 CEST] <wm4> well I have no better idea, but maybe I'm lacking creativity here
[18:43:58 CEST] <jamrial> durandal_1707: none of the fate suite eac3 samples are affected by the new bsf. are those "core" already?
[18:44:10 CEST] <nevcairiel> they are probably pure eac3
[18:44:25 CEST] <nevcairiel> not the blu-ray variant with core+substream
[18:45:07 CEST] <durandal_1707> jamrial: 5.1 is usually core
[18:45:32 CEST] <jamrial> right
[19:32:38 CEST] <peloverde> Is there a reason why we can't give the two rtmp muxers secondary names so you can use then both from the same binary?
[19:54:24 CEST] <peloverde> would people find naming them "rtmp,librtmp" and "rtmp,ffrtmp" respectively acceptable? or is that too icky?
[19:55:17 CEST] <nevcairiel> maybe it should stop being a special snowflake and librtmp just always called that
[19:55:22 CEST] <JEEB> hmm, noticed that a reset of a filter chain makes the filters forget what their previous output timestamp was :)
[19:55:32 CEST] <nevcairiel> all other libraries always have the prefix
[19:55:46 CEST] <JEEB> agreed
[19:59:15 CEST] <cone-284> ffmpeg 03James Almer 07master:95e33ea56599: doc/APIchanges: fix lavu version for the AVEncryptionInfo addition
[20:20:29 CEST] <durandal_1707> JEEB: yes, you call init/uninit
[20:21:00 CEST] <JEEB> this was with ffmpeg.c (the monster)
[20:21:04 CEST] <JEEB> so I will have to check that one
[20:21:27 CEST] <durandal_1707> how do you reset a filter?
[20:21:47 CEST] <JEEB> something happens when an ac3 stream switches from 5.1 to stereo
[20:21:58 CEST] <JEEB> all of the filter chain reconfigures itself or something
[20:22:03 CEST] <peloverde> None of the lib protocols use the lib prefixes they way codecs and containers do
[20:22:04 CEST] <durandal_1707> ah
[20:23:00 CEST] <JEEB> and since I'm doing AC3->AAC which have different audio packet sizes (1536 vs 1024 was it?) it then proceeds outputting the first audio frame with a PTS that actually goes backwards from the previous one :D
[20:23:20 CEST] <JEEB> because after reset it suddenly doesn't remember what PTS it last used
[20:23:35 CEST] <durandal_1707> yes, that is bug, pts shouldn't be reset
[20:23:54 CEST] <JEEB> also it might return INT64_MAX with the video, but I'll have to oduble-check
[20:24:03 CEST] <durandal_1707> JEEB: is that file or something else?
[20:24:09 CEST] <JEEB> it's thankfully a file
[20:24:16 CEST] <JEEB> so I could just iterate over it
[20:24:28 CEST] <JEEB> and see WTF is going on
[20:24:40 CEST] <JEEB> although originally that file came from broadcast input
[20:28:48 CEST] <durandal_1707> what file to use legally for EAC3 7.1 fate coverage?
[20:32:50 CEST] <atomnuker> some short sample from a movie if you can't find anything else
[20:34:34 CEST] <peloverde> also renaming a protocol without keeping the old name as a comma separated alternative is effectively an API change
[20:39:46 CEST] <atomnuker> can't we drop librtmp?
[20:40:19 CEST] <atomnuker> does it support something our native demuxer doesn't?
[20:40:34 CEST] <nevcairiel> probably, rtmp is a huge mess
[20:42:46 CEST] <atomnuker> worse than dash?
[20:44:48 CEST] <wm4> I'd rather drop the native demuxer lol
[20:44:56 CEST] <wm4> (no idea if librtmp is good)
[20:47:25 CEST] <JEEB> rtmp is actually simpler than DASH and librtmp hasn't been updated in a while afaik
[20:47:57 CEST] <JEEB> a lot of the stuff where people can't get things to work is due to librtmp and ffrtmp using different options for things
[20:48:20 CEST] <atomnuker> wm4: last release was 2 years ago
[20:48:42 CEST] <atomnuker> apparently, according to debian's changelog, probably its more than that
[20:48:49 CEST] <JEEB> most likely
[20:49:06 CEST] <JEEB> any changes are quite likely to be downstream patches
[20:50:12 CEST] <atomnuker> if it proves to have security issues we ought to drop it, neither debian nor arch have it enabled by default anyway
[20:54:15 CEST] <durandal_1707> nevcairiel: you used ffmpeg to extract eac3 (your uploaded sampe)? and you used seek? -c:a copy messes up big time
[20:54:36 CEST] <nevcairiel> durandal_1707: yeah unpatched ffmpeg with seek and copy into .eac3 file
[20:54:50 CEST] <nevcairiel> although i patched it to ignore timestamp issues
[20:57:00 CEST] <durandal_1707> nevcairiel: with such file, it get detected as crippled channel layout (missing channels), later it is synced, but ffmpeg does not support upmixing midstream
[21:05:53 CEST] <durandal_1707> michaelni: please fetch https://0x0.st/sBGf.eac3 rename it to: the_great_wall_7.1.eac3 and put it to fate server into eac3 directory
[21:11:11 CEST] <nevcairiel> durandal_1707: what source format? on mkv you may need to force the parser to be enabled
[21:11:16 CEST] <nevcairiel> i used a bluray m2ts
[21:13:04 CEST] <durandal_1707> same here
[21:13:40 CEST] <nevcairiel> and as said I had to disable some timestamp crap because two frames with the same timestamp drove it crazy
[21:13:51 CEST] <nevcairiel> but if the parser does its job now, that should be fixed i would think
[21:17:49 CEST] <durandal_1707> it splits after independent frame, parser change does not help
[21:18:15 CEST] <nevcairiel> then how does the decoder ever get both
[21:18:47 CEST] <peloverde> OBS is the most popular user oriented RTMP broadcast software and it uses librtmp. Which seems to imply people still care about it. 
[21:23:14 CEST] <durandal_1707> nevcairiel: it gets both, AVSTREAM_PARSE_FULL_RAW vs AVSTREAM_PARSE_FULL
[21:23:36 CEST] <durandal_1707> eac3 demuxer use raw parsing, mpegts doesnt
[21:23:43 CEST] <nevcairiel> i see
[21:23:48 CEST] <nevcairiel> no i dea what raw parsing does
[21:25:06 CEST] <durandal_1707> it is for cases when there is no container level timestamps
[21:25:21 CEST] <nevcairiel> and i guess the parser screws that up?
[21:26:55 CEST] <durandal_1707> ac3 parser is now correct, mpegts demuxer is not
[21:27:55 CEST] <durandal_1707> and probably only seeking is screwed
[21:28:21 CEST] <nevcairiel> well it has to be able to deal with a case where you start with a dependent frame
[21:28:34 CEST] <nevcairiel> bad cuts, seeks, etc
[21:28:44 CEST] <durandal_1707> what code?
[21:29:12 CEST] <nevcairiel> all teh code
[21:29:24 CEST] <durandal_1707> both parser and decoder?
[21:29:33 CEST] <nevcairiel> yes
[21:29:51 CEST] <nevcairiel> parsers dont drop data, so if it works properly it'll just slice after the dependent frame and then start a proper frame
[21:29:59 CEST] <nevcairiel> and the lonely dependent frame still gets to the decoder
[21:30:25 CEST] <durandal_1707> so just make decoder drop dependent frame with a warning?
[21:30:59 CEST] <nevcairiel> sure
[21:54:18 CEST] <durandal_1707> michaelni: please report when you upload that sample
[22:07:51 CEST] <Chloe> Does anyone other than michaelni have the target dec fuzz program setup?
[22:08:32 CEST] <JEEB> last I remember google's setup was part-closed source or something
[22:08:37 CEST] <JEEB> they had an open source version too
[22:08:44 CEST] <JEEB> but not sure if strictly related
[22:14:47 CEST] <jamrial> durandal_1707, michaelni: just uploaded it
[22:27:27 CEST] <wm4> Chloe: just leave it to google to fix it
[22:27:45 CEST] <wm4> they're one of the biggest tech companies at all... I'm sure they can bother to spend some time on it
[22:27:54 CEST] <durandal_1707> is HEVC fourcc in avi legit?
[22:28:01 CEST] <Chloe> wm4: last time google 'fixed' something it broke a ton of things, no?
[22:28:11 CEST] <jamrial> durandal_1707: i doubt it
[22:28:18 CEST] <nevcairiel> durandal_1707: as legit was h264 was, so basically not, but people insist on putting everything into avi
[22:28:21 CEST] <Chloe> (thinking edit lists)
[22:28:22 CEST] <JEEB> ^
[22:28:24 CEST] <JEEB> what nev said
[22:28:50 CEST] <jamrial> durandal_1707: "./ffmpeg -i the_great_wall_7.1.eac3" still reports the sample as 5.1, even if the decoding process ends up with 7.1 for the output
[22:29:02 CEST] <JEEB> I've had the same with DTS-HD MA
[22:29:07 CEST] <durandal_1707> jamrial: that is marginal misfeature
[22:29:30 CEST] <jamrial> JEEB: can't be, at least not since foo86's changes
[22:29:41 CEST] <JEEB> jamrial: could be what's written into mp4 with DTS
[22:29:47 CEST] <JEEB> it gets the core channel count first
[22:29:51 CEST] <JEEB> then decoded output is full
[22:30:05 CEST] <nevcairiel> the ac3 parser would probably need to be updated for that to combine the full layout, but thats a bit annoying and doesnt really stop decoding from working
[22:30:27 CEST] <JEEB> jamrial: although I think ffprobe/ffmpeg.c get it right
[22:30:28 CEST] <JEEB> let me check
[22:30:38 CEST] <JEEB> as in, if they probe they get it right
[22:31:13 CEST] <JEEB> yea, it gets it right
[22:31:30 CEST] <nevcairiel> both the parser and the decoder properly read dts-hd headers now
[22:32:03 CEST] <JEEB> I mostly noticed because my samples from shin godzilla show up as 2ch in mpv first :D
[22:32:24 CEST] <JEEB> (it's one of those perverted things with 3.1 audio)
[22:32:31 CEST] <nevcairiel> something being 2ch at first and then changing with HD extensions seems unusual
[22:32:37 CEST] <nevcairiel> you can put 3.1 in the core afterall
[22:33:42 CEST] <JEEB> https://kuroko.fushizen.eu/videos/shin_godzilla_sample.mp4
[22:34:02 CEST] <JEEB> (also if you feed the windows mixer that it will fail fabulously)
[22:34:18 CEST] <nevcairiel> thats why i have that magic to add silent channels
[22:34:24 CEST] <durandal_1707> well, i can just modify parser to not set channel layout for eac3 instead of doing all parsing stuff
[22:36:08 CEST] <nevcairiel> JEEB: i think the 2ch come from the container in that, the dts core is 3.1
[22:36:15 CEST] <JEEB> ok
[22:36:23 CEST] <JEEB> yea I did note that I expected that to be the case
[22:36:25 CEST] <JEEB> :D
[22:36:52 CEST] <JEEB> (and yes, that UHD BD has no HDR metadata for some reason)
[22:52:33 CEST] <durandal_1707> i disable setting channels, layout and bitrate from parser for eac3 and it now reports correct duration and layout with basic ffprobe usage
[22:52:53 CEST] <durandal_1707> is this correct way to do it? dca does similar
[22:53:07 CEST] <nevcairiel> in a perfect world the parser w ould be able to figure it out, but its better then setting wrong things
[22:53:41 CEST] <nevcairiel> the ac3 parser is a bit limited in what it can do because it uses this abstracted design that it shares with the aac parser
[22:58:01 CEST] <peloverde> IMO working with the parser from the AAC side, they should just be split. There is just as much effort spent fighting the re-use as it saves. 
[23:02:09 CEST] <durandal_1707> now the only thing missing is sample with dependent frames but without extended channel_map set at all
[23:10:21 CEST] <jamrial> both parsers should be split, yeah. especially now that the ac3 one can/should get a couple extra things
[23:16:57 CEST] <cone-131> ffmpeg 03Michael Niedermayer 07master:49a0b3f6bc96: doc/examples/hw_decode: Remove useless NULL check
[23:16:57 CEST] <cone-131> ffmpeg 03Michael Niedermayer 07master:b3e9f3f5f52d: doc/examples/hw_decode: Remove logically dead code in decode_write()
[23:25:14 CEST] <nevcairiel> durandal_1707: technically thats allowed and acmod just replaces it, but its probably not very useful
[23:29:37 CEST] <wm4> yeah, aac/ac3 sharing the parser code is just absurd
[23:30:49 CEST] <wm4> there's barely any shared code, even the aac_ac3_parser.c source file has a relatively large chunk that is under an if for a codec ID
[23:31:10 CEST] <wm4> well, 7 lines out of 99
[23:33:35 CEST] <wm4> could take the opportunity to remove this weird uint64_t state
[23:44:07 CEST] <rcombs> nevcairiel: and the AAC parser is limited in what it can do because AAC's bitstream format is insane
[23:44:40 CEST] <JEEB> all them extensions
[23:44:48 CEST] <rcombs> there's that, sure
[23:44:51 CEST] <JEEB> and stuff you need to decode the bit stream for
[23:44:57 CEST] <rcombs> but I mean how you can't determine the channel layout without decoding the whole thing
[23:45:05 CEST] <rcombs> well, you don't need to decompress, at least
[23:45:24 CEST] <rcombs> but you have to read everything because everything's variable-length and there are no high-level length codes
[00:00:00 CEST] --- Wed Mar 28 2018