<Lynne>
it seems like it fixes quite a lot of issues
<Lynne>
it correctly parses the duration for m4a files generated by fdkaac, and it allows some extra frames in messed up fate samples to become visible
jamrial_ has quit []
durandal_1707 has quit [Ping timeout: 272 seconds]
durandal_1707 has joined #ffmpeg-devel
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
Xaldafax has quit [Quit: Bye...]
psilokos__ has joined #ffmpeg-devel
psilokos__ has quit [Ping timeout: 272 seconds]
rvalue has quit [Ping timeout: 240 seconds]
rvalue has joined #ffmpeg-devel
KnightNero has joined #ffmpeg-devel
KnightNero has quit [Quit: Connection closed]
kurosu has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Krowl has quit [Read error: Connection reset by peer]
<durandal_1707>
FFmpeg is messed up
<JEEB>
what isn't?
<durandal_1707>
LibAV
<durandal_1707>
NihAV
<durandal_1707>
HaxAV
<elenril>
1707AV
<durandal_1707>
AKAV
<elenril>
sounds like an advance high-tech weapon
Krowl has joined #ffmpeg-devel
<durandal_1707>
AntonKhirnovAV®
<galad>
IperUraniumAV, the only one recommended by Platon
<durandal_1707>
øAV®
<JEEB>
ΩAV
<durandal_1707>
current FFmpeg == MiNiAV
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 260 seconds]
psilokos__ has joined #ffmpeg-devel
<haasn>
MiniDSP support when?
<Daemon404>
Lynne, thanks for the heads up, ill try and reply to it when i get to the airport in a few hrs
<Daemon404>
not sure how i feel about being the local mp4 guy, seems cursed
<Daemon404>
guess i dug my own grave
<JEEB>
reminds me that I need to check the handbrake patch for the env light metadata
<elenril>
Daemon404: at least you're not the flv guy
<elenril>
or the mxf guy
<durandal_1707>
elenril is sonic guy
<JEEB>
gotta go faster
<Daemon404>
elenril, fai4
<Daemon404>
fair even
jamrial has joined #ffmpeg-devel
durandal_1707 has quit [Ping timeout: 255 seconds]
<cone-115>
ffmpeg Lynne release/2.8:661a11fcc48e: configure: update copyright year
<cone-115>
ffmpeg Michael Niedermayer release/2.8:26e78a28f93d: avcodec/g729postfilter: Limit shift in long term filter
<cone-115>
ffmpeg Michael Niedermayer release/2.8:9bcb8caac3bd: avcodec/vp3: Check width to avoid assertion failure
<cone-115>
ffmpeg Michael Niedermayer release/2.8:a42455839aae: avcodec/huffyuvdec: Fix undefined behavior with shift
<cone-115>
ffmpeg Michael Niedermayer release/2.8:d001bd939439: avcodec/escape124: Check that blocks are allocated before use
<cone-115>
ffmpeg Michael Niedermayer release/2.8:e9fbbed49ef4: libavcodec/lcldec: width and height should not be unsigned
<cone-115>
ffmpeg Michael Niedermayer release/2.8:5e2e0254b0fd: avcodec/lcldec: Support 4:1:1 and 4:2:2 with odd width
<cone-115>
ffmpeg Michael Niedermayer release/2.8:6cdf6f0221c7: avcodec/lcldec: More space for rgb24
<cone-115>
ffmpeg Michael Niedermayer release/2.8:2e43c0f994ae: avcodec/vorbisdec: Check codebook float values to be finite
<cone-115>
ffmpeg Michael Niedermayer release/2.8:2adc725f1890: avcodec/pngdec: Do not pass AVFrame into global header decode
<cone-115>
ffmpeg Michael Niedermayer release/2.8:63c9aed5abd5: avcodec/utils: the IFF_ILBM implementation assumes that there are a multiple of 16 allocated
<cone-115>
ffmpeg Michael Niedermayer release/2.8:c31def00a503: avcodec/tak: Check remaining bits in ff_tak_decode_frame_header()
<cone-115>
ffmpeg Michael Niedermayer release/2.8:42cc45f5f251: avformat/wavdec: Check that smv block fits in available space
<cone-115>
ffmpeg Michael Niedermayer release/2.8:b5f4fc9aa95f: avcodec: Ignoring errors is only possible before the input end
<cone-115>
ffmpeg Michael Niedermayer release/2.8:3b811d871e71: avcodec/hevcdec: Avoid null pointer dereferences in MC
<cone-115>
ffmpeg Michael Niedermayer release/2.8:3249dc8ebfdf: avcodec/utils: fix 2 integer overflows in get_audio_frame_duration()
<cone-115>
ffmpeg Michael Niedermayer release/2.8:65312adc4161: avutil/softfloat: fix av_sincos_sf()
<cone-115>
ffmpeg Michael Niedermayer release/2.8:26a85ac7b747: avutil/softfloat: Basic documentation for av_sincos_sf()
<cone-115>
ffmpeg Michael Niedermayer release/2.8:6503cf3cf5cf: avcodec/jpeg2000dec: Check for reduction factor and image offset
<cone-115>
ffmpeg Michael Niedermayer release/2.8:52d1fffb0d7c: avcodec/xvididct: Fix integer overflow in idct_row()
<cone-115>
ffmpeg Michael Niedermayer release/2.8:e741f3d3b728: avcodec/tta: fix signed overflow in decorrelate
<cone-115>
ffmpeg Michael Niedermayer release/2.8:bf4369e0adc9: avcodec/mpeg4videodec: more unsigned in amv computation
<cone-115>
ffmpeg Michael Niedermayer release/2.8:abf72c71c190: avcodec/huffyuvdec: avoid undefined behavior with get_vlc2() failure
<cone-115>
ffmpeg Michael Niedermayer release/2.8:00a7db846c4f: avformat/format: Stop reading data at EOF during probing
<cone-115>
ffmpeg Michael Niedermayer release/2.8:933a6e2c1991: avcodec/celp_math: avoid overflow in shift
<cone-115>
ffmpeg Michael Niedermayer release/2.8:82fda5020c3c: avcodec/xvididct: Fix integer overflow in idct_row()
<cone-115>
ffmpeg Michael Niedermayer release/2.8:6c7ec3ed517f: avformat/sbgdec: Check for period overflow
<cone-115>
ffmpeg Michael Niedermayer release/2.8:8b4273ba8e72: avformat/westwood_vqa: Check chunk size
<cone-115>
ffmpeg Michael Niedermayer release/2.8:3f76a88922b8: avcodec/lcldec: Make PNG filter addressing match the code afterwards
<cone-115>
ffmpeg Michael Niedermayer release/2.8:2265582b3ae8: avformat/avs: Check if return code is representable
<cone-115>
ffmpeg Michael Niedermayer release/2.8:43949192e4e1: avcodec/escape124: Do not return random numbers
<cone-115>
ffmpeg Michael Niedermayer release/2.8:8373b84fffaf: avformat/jacosubdec: Check timeres
<cone-115>
ffmpeg Michael Niedermayer release/2.8:4c295a05a3a5: avformat/rpl: Check for number_of_chunks overflow
<cone-115>
ffmpeg Michael Niedermayer release/2.8:eddc8a2da6c6: avformat/tta: Better totalframes check
<cone-115>
ffmpeg Michael Niedermayer release/2.8:c731c8ce951c: avformat/wavdec: Check left avio_tell for overflow
<cone-115>
ffmpeg Michael Niedermayer release/2.8:bd7a703e94d1: avformat/matroskadec: Check prebuffered_ns for overflow
<cone-115>
ffmpeg Michael Niedermayer release/2.8:e240d3017428: avformat/tmv: Check video chunk size
<cone-115>
ffmpeg Michael Niedermayer release/2.8:1459e82b1c73: avcodec/xvididct: Make c* unsigned to avoid undefined overflows
<cone-115>
ffmpeg Michael Niedermayer release/2.8:8ba64279ce8d: Update for FFmpeg 2.8.22
<cone-115>
ffmpeg Elias Carotti master:644b2235c5bb: avcodec/libx264: Add the SSE computation for libx264.
MrZeus has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 255 seconds]
Xaldafax has joined #ffmpeg-devel
durandal_1707 has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 255 seconds]
ccawley2011 has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
dellas has quit [Remote host closed the connection]
<Mikhail_AMD>
AMF
<kierank>
CIA
Krowl has joined #ffmpeg-devel
<durandal_1707>
NSF
<durandal_1707>
NSFW
<Lynne>
jamrial: so, have skip samples be replaced by global side data?
<Lynne>
how would that be combined with a decoder wanting additional samples being skipped?
<jamrial>
it's an option
<Lynne>
the decoder would also output side data, which would be added to the global?
<jamrial>
that would potentially be written to the container, i think
MrZeus_ has joined #ffmpeg-devel
cone-115 has quit [Quit: transmission timeout]
MrZeus has quit [Ping timeout: 240 seconds]
<j-b>
2.8
<j-b>
seriously...
<gnafu>
Hey, Linux was on 2.6 for like 12 years :-P.
<psykose>
6.1: hand wave
<psykose>
2.8: champagne glass
<j-b>
2.8 is dead since a long long time
<durandal_1707>
ffmpeg 0.11 is still alive
<jamrial>
we really need a point release for 6.0
<durandal_1707>
6.SDR
Mikhail_AMD has quit [Quit: Konversation terminated!]
<durandal_1707>
6.1 late few months, and all because leader is slow in fixing security issues and instead working on SDR
<j-b>
jamrial: do it.
<j-b>
branch and do it.
<j-b>
But I think we'll go directly to 7.0 in Jan
<j-b>
we're already mid-oct
<jamrial>
j-b: i said 6.0 point release, not 6.1 :p
<j-b>
jamrial: sorry, I'm an idiot.
durandal_1707 has quit [Ping timeout: 255 seconds]
durandal_1707 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<haasn>
why does libavutil/avutil.h have a bunch of random #includes in the middle of the file?
<haasn>
and why deos libavutil/common.h include "mem.h" randomly at the end of the file?
<haasn>
8076c4731f1ba281bbd5e342867492aa477ff309
<haasn>
how did e3b355c0be85ec47ee8b3d7790ad4c4fa26827c0 from not get merged for 2 whole years?
<haasn>
am I suffering from a stroke? nothing makes sense today
<JEEB>
looking at the 8076c4731f1ba281bbd5e342867492aa477ff309 diff, I'd guess there is a whole bunch of system-specific checks and defines in there in between. but not sure if mem.h still needs to be that much in the middle of the file
Krowl has quit [Read error: Connection reset by peer]
<haasn>
more like "towards the end of the file"
Mikhail_AMD has joined #ffmpeg-devel
<Lynne>
elenril: so decoders get packets with a new duplicate of the skip samples side data?
<Lynne>
not sure how else to override it
<Lynne>
the generic setting is a good idea, but I'd also want decoder-side addition, for he-aac's 3010 sample delay
<Lynne>
which is not accounted for even in containers, as it's algorithmic-specific
<elenril>
I don't see why should there be a decoder private option when there's already a generic mechanism for the caller to set whatever delay it desires
<Lynne>
sure, I agree with that
<Lynne>
that can just be added directly to skip_samples in the place where I currently add skip_samples2
<Lynne>
I'm asking separately about the decoder adding its own delay in addition to that, and demuxer side data
MrZeus_ has quit [Ping timeout: 260 seconds]
<elenril>
so decoder looks at side data, and modifies it if it wants
<mkver>
haasn: It hate the fact that avutil.h includes anything at all; it should be a (mostly) lead header. But unfortuntely this could break things for users (it is documented that avutil.h includes the core of libavutil, so we can't simply tell users that they should never have relied on implicit inclusions).
<mkver>
common.h should be the header that includes the common other headers, all other headers should be minimal.
<mkver>
And most stuff in common.h should be moved out of it into a new header for misc math functions, but i don't really know a good name for it. Everything but one is about integer math, so intmath.h is not entirely correct.
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<mkver>
Anyway, there used to be two issues with the mem.h inclusion in the middle of common.h: mem.h used to have an inline function that can return an error code and therefore needed to include error.h, but error.h used MKTAG which used to be provided by common.h, so there was an inclusion cycle and so the headers only worked if they were included in a specific order. This is no longer an issue (see 580e168a945b65100ec2c25433f33bfacf
<mkver>
e9f7be).
<mkver>
See also 2dd8acbe800f6ea3b72ebe730f8ed95a5c3dd407 (moving MKTAG) as well as bd50e715a95ca58e10ed79e2d4bf796467339460 for an even weirder issue in the history of common.h.
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<Lynne>
elenril: thanks, that makes sense
<Lynne>
err, global side data or first frame's side data?
<Lynne>
I presume (and hope) that's the latter
<elenril>
yes, I don't think the semantics for AV_PKT_DATA_SKIP_SAMPLES is well-defined for global side data
<elenril>
i.e. should it apply to the first frame? or any time after seeking?
<elenril>
maybe jamrial has an opinion here
<mkver>
haasn: What's your reason for looking into this?
<haasn>
mkver: I was surprised why av_gcd was available on #include <libavutil/common.h> in older ffmpeg but not newer
<jamrial>
elenril: well, it definitely shouldn't apply to the entire stream, so that already makes me wonder if it should be allowed in avctx side data at all
<elenril>
jamrial: does it appear there currently?
<jamrial>
i don't think so
<elenril>
I didn't understand why you mentioned global side data in your email
<jamrial>
no demuxer exports it within avstream->codecpar afaik
AbleBacon has joined #ffmpeg-devel
<jamrial>
elenril: i mentioned it because i didn't think it through. using it as replacement for avctx skip_samples seemed like the proper solution, but i realize now the latter isn't even public
<elenril>
makes it easier to kill it
<elenril>
nevcairiel, BtbN: should d3d11va_transfer_data() be using av_image_copy_uc_from() for download, like dxva2 does?
<BtbN>
I have no idea, never looked into that
<elenril>
I'm looking at reports of ddagrab->hwdownload being slow
<BtbN>
I mean, it being slower than a pure hardware path is kinda expected
<BtbN>
I never noticed it being unreasonably slow though
<elenril>
the claim is that hwdownload is the bottleneck
<elenril>
for 4k@60fps
<BtbN>
For 4K, I could totally see that, purely on RAM bandwidth
<BtbN>
And PCIe bus bandwidth
<elenril>
the bandwidth here is ~2GB/s
<elenril>
that's nothing for DDR4
<durandal_1707>
so its bottleneck?
<elenril>
PCIE 3.0x16 is 15.75GB/s, so that should be plenty as well
<elenril>
but av_image_copy_uc_from() was added for a reason, so I'm wondering if it applies here as well
<BtbN>
I mean, it can't be much work to just try it? I never looked at the d3d11va code there, no idea how it currently copies stuff
<elenril>
I don't have a real windows machine
<durandal_1707>
kierank ^
<BtbN>
I don't have anything I could 4K-ddagrab
<BtbN>
I guess I could do pointless super-resolution stuff
<BtbN>
Or just null-sink the frames, and see if 1440p speeds up
<elenril>
will windows allow you to grab at arbitrary rates?
<durandal_1707>
ref set still not merged 100% ? what a shame!
<BtbN>
you can set ddagrab to whatever rate you like
<BtbN>
The filter effectively polls dda at that rate, and if nothing changed, dda just won't give you a frame, so it returns the previous one again
clarkh1 has quit [Read error: Connection reset by peer]
<BtbN>
now I have no idea if the bottleneck is just something else
<elenril>
hmm
<BtbN>
The d3d11 frame download path does a fully copy of the texture on the GPU, so it might be plain slow as it is
<BtbN>
I'm not at all sure why it even does that
<BtbN>
I guess because the texture in the frame might not be D3D11_CPU_ACCESS_READ
<BtbN>
so a possible optimization would be to set that flag in ddagrab, and then check for it in the download path, and skip the copy if it's set
<JEEB>
yea
<BtbN>
That likely has other drawbacks though
cone-228 has joined #ffmpeg-devel
<cone-228>
ffmpeg Michael Niedermayer master:70f5fa63258f: avformat/mxfdec: Check klv offset
<cone-228>
ffmpeg Michael Niedermayer master:5feceed0082c: avcodec/hevc_ps: Check cpb_cnt_minus1 before storing it
<cone-228>
ffmpeg Sean McGovern master:d799ad24045f: libavutil/ppc/cpu.c: check that AT_HWCAP2 is defined
<elenril>
such as?
<durandal_1707>
should i make ultimate mlp/truehd encoder?
<elenril>
why not ac4
<durandal_1707>
$$$$$
<elenril>
I'm sure someone could sponsor that
<durandal_1707>
nobody came
<elenril>
stop playing the genocide route then
<durandal_1707>
what?
<elenril>
my references are too highbrow for this channel it seems
<Lynne>
yeah, I don't get it either
<durandal_1707>
my IQ is only 100
<elenril>
Lynne: it's undertale
<elenril>
play the genocide route and you'll understand
<durandal_1707>
is that anime or video game?
<elenril>
video game
<durandal_1707>
no time to waste on blockbuster video games
<Lynne>
not a fan of it, didn't like how it started
<durandal_1707>
how it starts?
<elenril>
I mostly like it
<elenril>
it is quite overhyped though
darkapex has quit [Ping timeout: 252 seconds]
<durandal_1707>
the only video game i play is called FFmpeg
<elenril>
isn't your nickname a video game reference?
darkapex has joined #ffmpeg-devel
<Lynne>
and heroes of might and magic 2
<elenril>
3 > 2
<durandal_1707>
elenril: that was era before I found FFmpeg
<elenril>
sad
<elenril>
play some rain world
<durandal_1707>
ENOTIME
mkver has quit [Ping timeout: 255 seconds]
mkver has joined #ffmpeg-devel
<jamrial>
elenril: isn't "nobody came" from the flowey fight? so neutral/pacifist
<elenril>
i remember it from the genocide route
<elenril>
....which I should finish at some point
<elenril>
I'm any good at bullet hell
<elenril>
+not
<durandal_1707>
stop this special small talk about things i can not relate at all
<elenril>
go play the game then
<durandal_1707>
why should i waste precious time on stupid video games
<elenril>
so it can teach you empathy
<durandal_1707>
when master elenril could explain its narrative in few sentences
<elenril>
spoilers are sinful
<durandal_1707>
and please explain to me how is empathy related to $$$$$ in ac4 decoder vs mlp/truehd encoder
<elenril>
empathy allows you to communicate with people more effectively
<elenril>
which makes it easier to obtain $$$$$
<durandal_1707>
lol, i communicate very well, and nobody comes
<durandal_1707>
and playing video hazard games can make you only less human and more evil
<pross>
"durandal_1707: the only video game i play is called FFmpeg" -- that explains all the codecs now :)
noonien has quit [Ping timeout: 258 seconds]
___nick___ has quit [Ping timeout: 246 seconds]
<Lynne>
emacs is said to contain everything
<Lynne>
even has games
kurosu has quit [Quit: Connection closed for inactivity]
<durandal_1707>
emacs games are not video games
<Lynne>
yeah, I guess snake and tetris lack the narritives that make modern games a game
<drv>
> eat shovel
<durandal_1707>
context?
* elenril
gives durandal_1707 an MpegEncContext
<jamrial>
that's evil
dellas has quit [Remote host closed the connection]
* durandal_1707
gives elenril libavcodec's sonic encoder encoded audio to listen
navi has quit [Quit: WeeChat 4.0.4]
dionisis has quit [Quit: WeeChat 3.8]
ccawley2011 has quit [Read error: Connection reset by peer]
dionisis has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
<Lynne>
anyone got xhe-aac samples?
<Lynne>
real usac samples, I mean
<Lynne>
I'll accept razor1911-cracked encoders too
<nevcairiel>
elenril: re d3d1va copy, i dont think it makes a giant difference for d3d11, because in contrast to dxva2, it doesnt map hardware memory, but you have to allocate a host buffer first that you copy the surface into (hopefully with hardware DMA) before you can map it. but otherwise would need really test it
<nevcairiel>
(and you probably dont want to use a host-allocated buffer for the actual grabbing, if it even lets you)
<JEEB>
Lynne: I would expect the reference suite to have that. for encoders there's the reference code and I think that one company whose MPEG-H dec/enc I found also had AAC USAC there, I think?