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
wyatt8740 has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
wyatt8750 has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 264 seconds]
thilo_ has quit [Ping timeout: 264 seconds]
thilo_ has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
mkver has quit [Ping timeout: 264 seconds]
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht0 is now known as arch1t3cht
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
jamrial has quit []
vipyne has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 276 seconds]
zsoltiv_ has quit [Ping timeout: 252 seconds]
HarshK23 has quit [Quit: Connection closed for inactivity]
<ramiro>
the output of uncompressed data _may_ change between zlib versions 1.2.11 and 1.2.12
<jamrial>
well, that's a problem
<ramiro>
I can't think of anything to fix fate off the top of my head...
<jamrial>
have the failing fate machines update their zlib version?
ngaullier has joined #ffmpeg-devel
<ramiro>
or we write our own ff_deflate_uncompressed() which bypasses zlib
<ramiro>
if only måns had finished his native zlib replacement...
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 246 seconds]
cone-495 has joined #ffmpeg-devel
<cone-495>
ffmpeg Michael Niedermayer master:2542e9296c76: avcodec/ffv1: RCT is only possible with RGB
<cone-495>
ffmpeg Michael Niedermayer master:d0927ed0a802: libavcodec/ffv1enc: Add option to select the quantization table
<cone-495>
ffmpeg Michael Niedermayer master:81a360a5ed9e: avcodec/ffv1: add a named constant for the quant table size
<wbs>
not sure if "update fate machines" is a feasible requirement in general; say that a user is building ffmpeg on their machine, and they want to run fate once to see that their local compile is ok - now it will show spurious errors like that for anybody that don't have the right version - the machines that periodicallly run fate and post it to the website isn't the only thing that matters here
<ePirat>
is there a way to not compress at all for tests like that? but I guess then you end up missing something in the test…
<wbs>
that's exactly what they did change here
<wbs>
before, when compressing, zlib used to produce stable output across versions, while zlib-ng produced different output
<ePirat>
right, I meat without going through zlib at all
<nevcairiel>
ban zlib-ng already :D
<ePirat>
*meant
<michaelni>
<ramiro> or we write our own ff_deflate_uncompressed() which bypasses zlib <--- this
<wbs>
anyway, if we don't have a solution soon, I'll probably set up my fate instances with --disable-zlib to get rid of the noise
<michaelni>
solution == revert
<wbs>
that's true, we should probably use reverts much more liberally than we generally do here. (in llvm, whenever there's an issue with almost any commit, you revert so that everybody can get back to a more working tree rather than a less working one, while figuring out what to do about it)
<michaelni>
+1
<ePirat>
though reverting this would just change to a similar issue to happen for people that use zlib-ng, no?
<wbs>
that is true
<michaelni>
revert the creation of zlib-ng
<wbs>
but when trading bug for bug, you need to consider inertia and familiarity
<ePirat>
not saying reverting this would be bad, just that it still needs a proper solution
<wbs>
this issue, with zlib-ng not giving you the expected output, has always existed in ffmpeg, right? while the issue where zlib version X breaks fate while zlib version X+1 is ok, is a new situation which hasn't been around. so while reverting trades one bug for another, it gives a more familiar bug landscape at least
<michaelni>
yes, i still am in favor of reverting this comit until theres a better solution
<ePirat>
probably the best way forward for now
<jamrial>
this is why testing external libraries is a pain
<wbs>
yep
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 252 seconds]
<ramiro>
+1 for reverting and going back to an expected failure for zlib-ng
<ramiro>
chatgpt says it shouldn't be too hard to implement ff_deflate_uncompressed()...
<wbs>
lol
<wbs>
can chatgpt give us a suitably licensed one with our names on top as well? :P
<ramiro>
the code might end up with six fingers...
kasper93 has quit [Remote host closed the connection]
<cone-495>
ffmpeg James Almer master:e206e72b83a0: Revert "tests/fate: disable compression for zlib-based codecs"
feiw1 has quit [Ping timeout: 255 seconds]
kasper93 has joined #ffmpeg-devel
<wbs>
jamrial: thanks!
feiw1 has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
<Marth64>
i might need to make a bsf or split pgs decoder to parser/decoder for bd subs
<Marth64>
we need a way to get forced subs on their own stream
<Marth64>
vs. part of full sub stream
<Marth64>
not immediate need but would be very nice
<Marth64>
decoder can do it but what if i want to streamcopy
<ePirat>
Marth64, I am curious, how does it work currently?
System_Error has quit [Remote host closed the connection]
<Marth64>
ePirat: Two types of muxers out in the wild. Type 1 muxer creates PGS stream with full subtitles and has frame level marking on which subs are forced if the track is off.
compnnn has joined #ffmpeg-devel
<Marth64>
Type 2 muxer makes forced PGS in their own stream and thus no work needed :)
<Marth64>
"if the track is off" from the perspective of a real BD player UI
<ePirat>
Marth64, how does Type 1 work if I have multiple languages? Can I simply not have multi-language forced subs on the same disc?
compnn has quit [Ping timeout: 245 seconds]
paulk has quit [Ping timeout: 245 seconds]
System_Error has joined #ffmpeg-devel
<Marth64>
ePirat, you will simply have one "combination" track per language. so for example there can be a type 1 EN and type 1 FR track, each with their own frames marked forced or not alongside the entire text for the program
<Marth64>
(sorry if bad explanation hope it makes sense.)
<Marth64>
this should then demux to: EN, EN (forced), FR, FR (forced) in an ideal world
<ePirat>
Marth64, how does the player (as in actual DVD players) know which one to choose if they are not exposed separately?
<ePirat>
like how does it know I want german not english for example?
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
<nevcairiel>
the menu logic tells it
<ePirat>
ooh so the initial menu where I select the language that the subsequent menus will have influences that as well?
<Marth64>
it is both the menu logic OR the player region code (if you do not go through the menu)
<Marth64>
yep
<nevcairiel>
there is really no unified behavior of the menus anyway, especially if they are java
<ePirat>
they are only java for BD, right?
<Marth64>
only java for BD
<nevcairiel>
they'll just send control commands to the player which stream to use and if forced should be filtered
<Marth64>
DVD menus are a hoax
<Marth64>
they are just subtitle stream activation on top of mpeg2 video
<Marth64>
nevcairiel: on some discs they assume player region as default and make the selection stream optional
<Marth64>
selection screen**
vipyne has joined #ffmpeg-devel
<Marth64>
but yes lines up with my research also
<ePirat>
Marth64, how is active selection indicator handled, just different streams for each selected state?
<nevcairiel>
both DVD and BD have some registers that store state in various ways
<Marth64>
correct
<Marth64>
the state determines what stream the vm selects
<Marth64>
and can be controlled by the in-disc menu or player's own menu
<Marth64>
in my demuxer case i am presenting all available options to user, but want to also show user when they have a stream with forced frames in it and give them option to get it as an independent stream
<Marth64>
as is a practical use case
<nevcairiel>
in my experience its impossible to know this information without scanning the entire disc
<nevcairiel>
(which stream has forced subs, that is)
<Marth64>
which is why i was thinking make a bsf and if user wants to extract them while still doing streamcopy, user can decide
<Marth64>
easiest solution i think
<Marth64>
or do processing after initial demux
<nevcairiel>
a bsf to filter out only forced subs would certainly be useful, although it has a few intricate entanglements to do it clean
vipyne has quit [Ping timeout: 252 seconds]
<Marth64>
do tell if you get a chance, as i probably will write one
<Marth64>
unless i find a different solution
<Marth64>
i was thinking firstly pgs need a header parser instead of only decoder
<nevcairiel>
i would have to lookup the details, but what I do remember is that its not as simple as deleting some frames, but need to keep track of state and sometimes need to rewrite some parts, especially if normal and forced are on the screen at the same time
<Marth64>
ouch...ok
<Marth64>
i do not think it is showstopper for bd demuxer not to have this but its too useful to not attempt
<Marth64>
it can always come later postprocessed off the original track
<nevcairiel>
its really an unrelated feature, we could demux plain m2ts files from blu-ray before that contained such tracks
<Marth64>
other demuxers have it as a feature, agreed its not related but certainly after using it hard to go back
<Marth64>
kind of like backup camera in a car
<Marth64>
but not really lol
<Marth64>
i think of user friendliness and see extracting of forced subs as a tedious task that should be automated