michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
ccawley2011_ has quit [Read error: Connection reset by peer]
Marth64 has quit [Quit: Leaving]
thilo has quit [Ping timeout: 252 seconds]
thilo has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
Marth64 has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Mirarora has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 265 seconds]
realies1 has joined #ffmpeg-devel
realies has quit [Ping timeout: 252 seconds]
realies1 is now known as realies
jamrial has quit []
Marth64 has quit [Quit: Leaving]
^Neo has quit [Ping timeout: 248 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 244 seconds]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 246 seconds]
rvalue- is now known as rvalue
ngaullier has joined #ffmpeg-devel
<meego>
NanananaLeader: thanks for the detailed feedback! FWIW we indeed do offline/2-pass normalization (scanning, then applying a flat gain). It also had been a while since we last tested ebur128 filter, and on giving it another shot this morning i see it gives 200x (truepeak), 900x (sample), 1000x (none). That's really good!
<meego>
NanananaLeader: I'm not sure why we were using loudnorm in the first place. I think it was because it outputs JSON. We missed the perf impact <facepalm>
<meego>
We're still willing to sponsor porting librempeg's performance improvements on loudnorm to ffmpeg if anyone has interest. Going from x200 to x300 is still a very healthy 50% bump!
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
abdu has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
cone-245 has joined #ffmpeg-devel
<cone-245>
ffmpeg Jonathan Baudanza master:c0fbb6d5b7aa: avformat/rtpdec: int overflow in start_time_realtime
abdu has quit [Ping timeout: 240 seconds]
<cone-245>
ffmpeg Jonathan Baudanza release/7.1:d72536008ac3: avformat/rtpdec: int overflow in start_time_realtime
abdu has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 276 seconds]
j45_ is now known as j45
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
ccawley2011 has quit [Read error: Connection reset by peer]
<thardin>
remind me, is there some way to have the muxing logic not wait forever for packets for every stream?
<thardin>
if say there is a subtitle stream which only puts out packets now and then, that will cause everything to block when streaming
<Lynne>
there's a switch to minimize latency, and another function to completely avoid interleaving
<mkver>
jamrial: It seems to me you haven't answered Alexander Strasser's question.
<jamrial>
mkver: oh, missed it
cone-245 has quit [Quit: transmission timeout]
cone-499 has joined #ffmpeg-devel
<cone-499>
ffmpeg James Almer master:d7180a3f92e5: avcodec/vvc/dec: print thread debug logs only if DEBUG is defined
<cone-499>
ffmpeg James Almer master:292c1df7c159: avformat/mov: merge stts and ctts arrays into one
<jamrial>
thardin: build_index and fix_index should be more readable now
<JEEB>
thardin: there is a patch set for making non-continuous streams have a separate interlaeve delta
<JEEB>
authored by rcombs, IIRC. there were some review comments and if you also need something like that you may want to take it over? (since IIRC rcombs no longer has interest towards those changes)
abdu has quit [Ping timeout: 240 seconds]
abdu has joined #ffmpeg-devel
<thardin>
seems in this case the issue is actually that the pipeline I'm working on has multiple ffmpeg's with -re
<thardin>
jamrial: woop
<thardin>
hopefully I should have time again soon to get back to work on mov.c
<thardin>
index table fragments in FFFormatContext would likely work best with an interpolation search. binary search would also work of course
System_Error has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 265 seconds]
___nick___ has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 252 seconds]
__nick__ has joined #ffmpeg-devel
TD--Linux is now known as TD-Linux
^Neo has quit [Ping timeout: 244 seconds]
<thardin>
looking a bit at the literature, seems it's possible to implement a search that is O(log log N) on average and O(log N) at worst
<thardin>
that could be useful in many places in the codebase
<cone-056>
ffmpeg James Almer master:42e72d5c8b57: avutil/frame: add AV_FRAME_SIDE_DATA_FLAG_NEW_REF
<cone-056>
ffmpeg James Almer master:f635f19537bd: avcodec/aom_film_grain: use av_frame_side_data_add() where useful
<cone-056>
ffmpeg James Almer master:5cd49e1bfd04: avcodec/hevc/hevcdec: use av_frame_side_data_add() where useful
meego has quit [Quit: Leaving...]
ForeverLeader has joined #ffmpeg-devel
<fflogger>
[newticket] robteny45: Ticket #11410 ([ffmpeg] Can't convert hevc flv to mp4. Video codec (c) is not implemented error.) created https://trac.ffmpeg.org/ticket/11410
philipl has quit [Quit: leaving]
<fflogger>
[editedticket] oromit: Ticket #11410 ([ffmpeg] Can't convert hevc flv to mp4. Video codec (c) is not implemented error.) updated https://trac.ffmpeg.org/ticket/11410#comment:1
<fflogger>
[editedticket] oromit: Ticket #11410 ([ffmpeg] Can't convert hevc flv to mp4. Video codec (c) is not implemented error.) updated https://trac.ffmpeg.org/ticket/11410#comment:2
philipl has joined #ffmpeg-devel
<rcombs>
JEEB: I'm happy to help with basically anything as long as it doesn't involve sending emails to a mailing list
<ForeverLeader>
ban the mailing list
System_Error has quit [Remote host closed the connection]
<BtbN>
wtf is that flv sample. Has facebook re-invented enhanced flv/rtmp in an incompatible way with literally everyone else?
<another|>
facebook?
System_Error has joined #ffmpeg-devel
<another|>
you mean ByteDance?
<BtbN>
oh, yes. The tiktok guys
System_Error has quit [Remote host closed the connection]
<Compn>
hevc flv
System_Error has joined #ffmpeg-devel
<Compn>
we could have had it allllllllllllll
<Compn>
blame btbn :P
<BtbN>
Well, we have it now
<BtbN>
it's pretty easy to add support for that legacy hevc-in-flv thing. Question is, do we want to?
<Compn>
yes
<BtbN>
It seems to be relatively well established.
<BtbN>
But there is no spec
<Compn>
never stopped us before
<BtbN>
It actually did stop us adding stuff to flv for years
<BtbN>
people had sent patches for more formats since ages
<ForeverLeader>
Leader is forever, forever, forever, foreeeeeeeveeeeeeeeeerrrr
<Compn>
i think tiktok is big enough we can support that file though
<BtbN>
It'd get more fun if the user wanted us to MUX such a file, for ingest to TikTok...
<Compn>
i like ability to save and playback videos from social media
<ForeverLeader>
antisocial media
<BtbN>
Yeah, I'm also inclined to just add support
<Compn>
ForeverLeader, irc included
<BtbN>
I'm getting a weird parser error on that sample still, with support added. But I think that's just cause the file got truncated.
<Compn>
i think youtube-dl can be used to grab such files
<Compn>
lets see
<BtbN>
It remuxes fine up until that point
<BtbN>
and plays. And is weird.
<Compn>
ydl says h264 and h265 but all mp4
<BtbN>
So where does that file come from then?
<Compn>
at least yt-cdp or whatever fork
<Compn>
it might be from a livestream
<BtbN>
They serve that via flv?
<BtbN>
Guess to their app they can serve whatever they want, huh...
<nevcairiel>
people have been hacking other codecs into flv ever since flv existed
<Compn>
yea winamptv had a bunch
<ForeverLeader>
bring back flash
<Compn>
or was that nsv...
<BtbN>
yeah, the only reason I care to add this is that it's apparently somewhat broadly used, given it's tiktok
ForeverLeader has quit [Quit: Client closed]
<cone-056>
ffmpeg Timo Rothenpieler master:b76053d8bf32: avformat/flvdec: add support for legacy HEVC files
<fflogger>
[editedticket] oromit: Ticket #11410 ([ffmpeg] Can't convert hevc flv to mp4. Video codec (c) is not implemented error.) updated https://trac.ffmpeg.org/ticket/11410#comment:3
<jamrial>
why is tiktok using flv?
<jamrial>
BtbN: reading these files is fine. creating them is a big no
<BtbN>
creating them would also be really annoying now, given the flv muxer will create a spec compliant file instead
<BtbN>
jamrial: same reason all the others use it I guess. rtmp
<BtbN>
And since their primary way of consuming the streams is their app, and not a website, I guess they figured they might as well just deliver the raw flv stream
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Compn>
i like flv over segmented mp4 anyway
<Compn>
mp4 was never meant to be streamed
* Compn
throws a moov at jamrial
<Compn>
all those incomplete mp4 files that are impossible to play. lost like tears in rain
abdu has quit [Ping timeout: 240 seconds]
abdu has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 265 seconds]
ccawley2011_ has quit [Read error: Connection reset by peer]
<jamrial>
Compn: by incomplete you mean the fragments containing moof?