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
<ePirat>
llyyr, not that uncommon for ffmpeg sadly
<ePirat>
ML is a great place for patches to get lost
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 260 seconds]
<beastd>
llyyr, ePirat: True it's sad, but the mailing list isn't the problem usually. It's most of the time the lack of developers with interest in that particular area and specific use case.
<llyyr>
That is a ML issue as well, email based workflow discourages new developers from submitting patches or reviewing patches they might be interested in
<beastd>
llyyr: FWIW I had a look at that ticket and patch earlier today. Seeing that I don't know enough about ogg and chaining and that use case. So I think I'm rather out of it. Sorry.
<Marth64>
I can try to look at it as a validator but I have no samples
<Marth64>
I am not sure if thats a normal/allowed thing to do changing the stream metadata on the fly in read_packet
<Marth64>
I will see if other demuxers do it
<Marth64>
but it feels unnatural to me
vipyne has joined #ffmpeg-devel
<llyyr>
everything except the flac decoder supports it fwiw
vipyne has quit [Ping timeout: 246 seconds]
<Marth64>
and Icecast server effectively joins segments over a streaming ogg container?
ccawley2011 has quit [Read error: Connection reset by peer]
<llyyr>
I think it can not do that, but in configured to be "lossless" it does do that
<Marth64>
ah
<ePirat>
Marth64, chaining ogg is valid (in most cases)
<ePirat>
I might be able to look at it if no one beats me to it
<ePirat>
beastd, llyyr, ML also makes it easy that patches get lost/forgotten
vipyne has joined #ffmpeg-devel
<ePirat>
we have patchwork, yes, but its a mess
vipyne has quit [Ping timeout: 248 seconds]
vipyne has joined #ffmpeg-devel
vipyne_ has joined #ffmpeg-devel
<Marth64>
ePirat: I can rebase and do a few validation then send new copy if that helps (just stepping out for few hours)
<Marth64>
since its old patch. might apply fine though
<llyyr>
applies fine, I've already tested it on master
<ePirat>
llyyr, is there an easy way to test the meta updates work as expected, like with ffplay or so?
sgm has quit [Remote host closed the connection]
sgm has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 252 seconds]
vipyne_ has quit [Ping timeout: 276 seconds]
<llyyr>
ePirat: should work? I was testing with mpv but no reason why ffplay wouldn't print out the metadata change I'd think
<llyyr>
only problem is that I don't have any other stream to test with, and this stream appears to play random stuff so you might not get to the next track for hours
<ePirat>
I can definitely make test streams / files
<llyyr>
ah, well mpv definitely prints out the metadata change as long as the ffmpeg patch is applied but I don't know if ffplay needs special handling for it
<llyyr>
nope, ffplay doesn't print out the new metadata for any format
<ePirat>
I might look into adding that…
vipyne has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
paulk has quit [Ping timeout: 252 seconds]
vipyne has quit [Ping timeout: 276 seconds]
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 260 seconds]
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 248 seconds]
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
kasper93 has quit [Remote host closed the connection]