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
zenmov has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
Marth64 has joined #ffmpeg-devel
Everything has quit [Ping timeout: 255 seconds]
<cone-701>
ffmpeg IndecisiveTurtle master:f794ed48c09c: vulkan/common: Fix off-by-one error in flush_put_bits
<cone-701>
ffmpeg IndecisiveTurtle master:e3ac63b213de: vulkan/common: Use u32vec2 buffer type instead of u64
<Marth64>
ok. sent up bdmv demuxer. too tired to finish docs now
<Marth64>
TLDR -f bdmv -i /my/bdmv.iso --> open with and use libbluray's filtering features for seeking or -f bdmv -mpls_mode direct -i /my/bdmv.iso --> concat segments with ffmpeg and calculate timestamp
<Marth64>
there is room for improvement (more features, reading metadata for individual segments, etc) but it can happen in phases
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
secondcreek has quit [Quit: secondcreek]
<Marth64>
i will move on now to fix bugs in ccaption_dec
<nevcairiel>
does that mean in filtered mode the timestamps will actually have disconinuities, or does the filtering override them? maybe thesame timestamp offset logic can be used there?
<nevcairiel>
discontinuities* .. too early to type
<Marth64>
it might. it usually doesn't, libbluray does a good job generally. but on some structures i've seen it have discontinuities
<Marth64>
so as a secondary mode i added direct reading and concatenating of the mpeg-ts segments from ffmpeg (no libbluray filtering involved)
<Marth64>
this solves the issue for those structures
<nevcairiel>
when i checked what libbluray did ages ago, all I could see was cutting the m2ts as indicated by the playlists, not actually re-writing them, but that may have changed in the meantime
<nevcairiel>
yeah that just seems to drop packets that are unwanted, not actually rewrite anything to ensure timestamps are continous or something like that
<nevcairiel>
but libbluray of course knows this data so getting it out and applying it would be fairly easy, when i find time i might look at that and see how it behaves on some discs
<Marth64>
it does not have a way to get the index of the currently playing clip, so as i am passing through the filtered stream i can't fix the timestamps
<Marth64>
at least a publically exposed way
<Marth64>
(without the clip index i can't check the in/out times)
<Marth64>
however, if using -mpls_mode direct this is being done after reading the segments directly in the order they are supposed to be
<Marth64>
i just did not implement seeking with that
cone-120 has quit [Quit: transmission timeout]
<Compn>
Marth64, which libbluray
<Compn>
oh nm i see you link above
zenmov has joined #ffmpeg-devel
<Marth64>
of the 10 samples i have been using 1 has had bad packets in filtered mode, so not too bad
<nevcairiel>
Marth64: yes and no, it doesnt have an API to tell you the clip index, but you can listen to its event mechanism to be told when the clip changed and to what index, so you need to keep a state
<Marth64>
it gives play item (which is not a clip0 and a discontinuity event (which only appears to trigger on menus)
<Marth64>
s/0/)
<frankplow>
jamrial: vvc_frames_with_ltr.vvc is a really good stream — it tests a lot of stuff none of the current VVC tests exercise. We could probably drop some of the other tests if we add it.
<Marth64>
unless I missed something I could not find a way (I do also like having the option of bypassing the libbluray filter complete)
<nevcairiel>
pretty sure playitem corresponds to clip (disclaimer: i have actually implemented full menu support based on libbluray, just not as part of ffmpeg)
<nevcairiel>
having the option to bypass the filter is fine, just trying to think about enhancing the experience :)
<frankplow>
It looks like an Argon stream and similarly has a really exhaustive use of coding tools. Nobody’s written an Argon stream model for VVC AFAIA, so I’ve been wondering how it was made. Perhaps encoding the decoded YUV from an AV1/HEVC Argon stream is still somewhat effective for other codecs?
<Marth64>
nevcairiel: you are right about play_item=clip and I had missed that. I will do it. thanks!
<Marth64>
for some reason I remember steering away from it thinking they were different but on re-reading I guess they are the same
<frankplow>
jamrial: And yeah, I have a patchset which fixes a handful of issues I fixed related to it. I should send it to the ML later this week or at the weekend.
<Marth64>
nevcairiel: pls let me know anything else you find
<nevcairiel>
i'll give it a try soon and see how it works
<nevcairiel>
was just a thing i noticed based on your comments about timestamps
<nevcairiel>
because for playback .. discontinuities are really annoying to handle right :P
<Marth64>
hence marked experimental
<Marth64>
there is room to grow
<Marth64>
but its already better than the blurary protocol handler i think
<kasper93>
could we upload dovi samples to fate and possibly test and even add them to oss-fuzz corpus?
<kasper93>
there seems to be issues with RPU recently discovered
<JEEB>
I think we had at least one RPU sample
<kasper93>
This doesn't answer question.
<kasper93>
(+the)
<elenril>
kasper93: I've been discussiing this with jamrial recently
<elenril>
should happen soonish
<kasper93>
cool, thank you
<JEEB>
kasper93: I mean in FATE I'm pretty sure I saw RPU parsing results
<JEEB>
so that's not what you were talking about? testing RPU parsing? but yes, if we need to widen the range of stuff we test we need samples having that
<JEEB>
(`tests/ref/fate/hevc-dv-rpu` is the one we have, just grep'd)
<JEEB>
but yea if the question was not about FATE but oss-fuzz config then yes, I started with the thing you first mentioned (samples in FATE)
<Raz->
Compn, thanks :)
Krowl has quit [Read error: Connection reset by peer]
<thardin>
elenril: the spotify guy showed up at the hackerspace yesterday and we talked a bit about the avio stuff. we realized if properly done it could also be useful for whenever one needs to transform the input data for whatever reason, in addition to providing windows of it
<JEEB>
kasper93: if it was not clear my response with saying we have at least one sample is that we already have uploaded something to FATE and that if we require more samples for testing different features of that stuff already having something like that means that there should be no blocker for uploading more to FATE suite...
<JEEB>
so I did answer your question > could we upload dovi samples to fate
<JEEB>
I could not respond regarding oss-fuzz because I have not poked that part of the project
<JEEB>
but I clearly did (indirectly) answer to the first part of your question
<JEEB>
as if we already have a sample uploaded it means that clearly uploading such samples to fate is not blocked or not permitted or whatever :V
<JEEB>
I'm sorry, but I got triggered by your "This doesn't answer the question"
<JEEB>
since I was attempting to be helpful and respond. perkele
<JEEB>
meanwhile: thank you cloud instances for not being consistent
<JEEB>
need to redo the beginning of my bisect
rvalue has quit [Ping timeout: 272 seconds]
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 245 seconds]
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 252 seconds]
mkver has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle>
Lynne: Submitted some patches a few hours ago, they dont break fvv1 for me
^Neo_ has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 248 seconds]
<fflogger>
[newticket] ddesouza: Ticket #11324 ([avformat] Corrupted HEVC bitstream generated by extracting it from MP4 file) created https://trac.ffmpeg.org/ticket/11324
Krowl has quit [Read error: Connection reset by peer]
MisterMinister has joined #ffmpeg-devel
<Lynne>
IndecisiveTurtle: err, you mean the ones I pushed 12 hours ago?
Krowl has joined #ffmpeg-devel
Sean_McG has joined #ffmpeg-devel
cone-172 has joined #ffmpeg-devel
<cone-172>
ffmpeg gnattu via ffmpeg-devel master:248832dd5b79: avcodec/bsf/dovi_rpu: remove EL when stripping dovi metadata
<cone-172>
ffmpeg Nicolas Gaullier master:44d32c8a2304: avcodec/ac3dec: fix build when eac3 decoder is disabled
<elenril>
asdfgh
<elenril>
can we kill those stupid "via ffmpeg-devel"?
<JEEB>
ML has to rewrite one of the tags, but I think it could still change the patch so the authorship would be correct
<JEEB>
alas, I guess the ML doesn't have that built-in
<elenril>
well, it could stop adding those entirely useless footers that break DKIM
<JEEB>
or that, yes
<JEEB>
just sending emails as-is
<IndecisiveTurtle>
Lynne: Oh didnt receive any notification they got merged on my email, all good then
<IndecisiveTurtle>
Will rebase my vc2 again and send the patch one more time
<Lynne>
great
<Lynne>
I've been holding back making an announcement of soft hwaccel codecs to wait for vc2enc
<elenril>
soft harware
<elenril>
hard software
<JEEB>
seeing compute vulkan is pretty neat
<JEEB>
opencl is also a thing, but a lot of that stuff is stuck in ancient versions of it (like the x264 PoC)
<cone-172>
ffmpeg Manuel Lauss master:1e2a72ae1da9: libavcodec/sanm: add codec47 interpolation table support
<cone-172>
ffmpeg Manuel Lauss master:85fec8d90f37: libavcodec/sanm: fix XPAL handling
<cone-172>
ffmpeg Manuel Lauss master:dc98e7989d81: libavcodec/sanm: clear codec47 diff buffers with specific color
<cone-172>
ffmpeg Manuel Lauss master:a786dd4889ec: libavcodec/sanm: codec47: apply top offset also to diff buffers
<JEEB>
hmm, seems like the av_format_inject_global_side_data deprecation is not documented in APIchanges?
Krowl has quit [Read error: Connection reset by peer]
secondcreek has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
ocrete has quit [Quit: Ping timeout (120 seconds)]
mkver has joined #ffmpeg-devel
ocrete has joined #ffmpeg-devel
names_are_hard has joined #ffmpeg-devel
natto has quit [Quit: a.]
<Marth64>
good day
natto has joined #ffmpeg-devel
Arsen has quit [Remote host closed the connection]
names__are__hard has quit [Read error: Connection reset by peer]
aaabbb has quit [Ping timeout: 252 seconds]
Arsen has joined #ffmpeg-devel
aaabbb has joined #ffmpeg-devel
zenmov has quit [Remote host closed the connection]
<Marth64>
can tools/dvd2concat be retired
<nevcairiel>
add a deprecation warning to it, check back in two years? =P
<Marth64>
lol
<Marth64>
i am flirting with the idea
<Marth64>
its probably the best way really without outright deleting it
<nevcairiel>
i mean thats how you do it generally
<JEEB>
sounds like a good idea since the demuxer is good now
<Marth64>
or maybe turning it into a bash script that calls demuxer
<nevcairiel>
add a message informing them what to use instead, ideally
<Marth64>
but whats point
<nevcairiel>
delete it after a while
<Marth64>
yeah
<Marth64>
i am done(tm) with dvd demuxer
<Marth64>
some day i will add printing of titles etc and maybe stills
<elenril>
but what about the menus
<Marth64>
full playback it can be done if we can rewire streams after averror_input_changed
<Marth64>
If we have that and skip mouse support its pretty easy
<Marth64>
calling application can send remote control commands over a socket or whatever and its done
<Marth64>
doesnt hls and dash do this already when swithcig playlists
<Marth64>
segments in the playlist rather
<Marth64>
(for now) you can extract menus but you can't interact with them which is boring
<Marth64>
so yeah we just need a graceful way for client to handle streams changing
<Marth64>
avtransport 2025???
<elenril>
do we really need to?
<elenril>
can't we just add new ones?
<Marth64>
then do we mark previous ones ended and its a never ending stream generating machine as you navigate the disc?
<Marth64>
if so then yeah
<Marth64>
how to tell player, "switch to this?"
<Marth64>
i can do a proof of concept with ffplay if thats possible
<elenril>
there is no API for this, you'd have to create it
<elenril>
just seems to me that creating new streams would be simpler wrt internal structure
<Marth64>
thats cool as long as we can terminate the old ones and signal a switch
<Marth64>
i'm getting more hang of the API now (and C, which is not my native language)
<Marth64>
janitor work helps me do that
esu has left #ffmpeg-devel [#ffmpeg-devel]
<elenril>
there's no API for terminating streams either, but you could add one
<Marth64>
i will look at it
<Marth64>
today was supposed to be eia608 day!
<kasper93>
Marth64: I noticed that dvd demuxer is missing last chapter. Have you seen issue like that?
<Marth64>
kasper93: Yes, already fixed, patch is up on ML and I plan to push in 1-2 days
<kasper93>
Oh, nice. Didn't check ML lately. Sorry to bother you :)
<Marth64>
never a bother. please tell me bugs anytime
<Marth64>
the bug does not appear if remuxing with -preindex 1 but it makes for an annoying playback experience
<kasper93>
yeah, I was testing in mpv
<Marth64>
seeking should be much better with latest set
<Marth64>
already merged set
<kasper93>
audio tracks seems to be in different order
<kasper93>
not sure which one is correct though
<Marth64>
they should be presented in IFO order
<Marth64>
are you comparing 7.0 vs master? or mpv demuxer vs ffmpeg
<kasper93>
mpv vs master
<Marth64>
yes that makes sense. since I report all the possible tracks for the title from dvdread. dvdnav's looping will only present what the disc wants you to know about for your player region/current part of navigation/etc
<Marth64>
i have not tested with mpv in some time but ffplay is driving me crazy a bit so i will switch back
<elenril>
is there much point in using this in mpv?
<Marth64>
yes, its a good alternative to built in demuxer especially with some more complicated discs
<Marth64>
and i linearize timestamps
<Marth64>
it was quite smooth last i tried. these days ffplay is just letting me get my work done faster
<elenril>
huh, interesting
<elenril>
I thought dvd playback in mpv was a solved problem
<Marth64>
i have also thought of possibly contributing full menu support to mpv but (1) i am not too familiar with its inner workings and (2) wish it could be in ffmpeg for anything to use
<Marth64>
its not unsolved, i thought it was not as smooth though. of course i am biased
<Marth64>
try it! it works ok
<JEEB>
wasn't the DVD module removed from mpv?
<JEEB>
just the libbluray one was kept
<JEEB>
OK, I am incorrect
<JEEB>
dvdnav is still there :D
<kasper93>
lots of things are there, but not exposed to users
<Marth64>
i could try and fix mpv's demuxer up a bit but it pains me to have more dvd demuxers out there
<Marth64>
from a testing perspective
<llyyr>
mpv can just use ffmpeg if it works well enough
ngaullie has quit [Quit: Leaving]
<Marth64>
it should be rock solid now except for the last chapter bug which is fixed and pending push
<Marth64>
the other annoyance is i do not tell you what titles are available so number has to be set manually
<Marth64>
if user really wants they can get "advanced" things from the disc with this demuxer like specific menus or hidden titles/pgcs
<kasper93>
Once mpv bumps minimal ffmpeg version to next ffmpeg release, we can think about replacements, but it's too soon. You can use it without problems, already
<kasper93>
mpv doesn't expose title selection anymore too
<kasper93>
so you can manually set number, but that would be all
<kasper93>
once upon a time there was dvd-title property
<Marth64>
if theres anything needed to help (toward the "one dvd demuxer to rule them all" goal), i can accommodate let me know
<kasper93>
now there is only edition-list, which is used for mkv and could be wired to dvd too, similar thing. Or just revert removal of dvd-title
<Marth64>
i can try to add the menu support in mpv but will probably have a ton of questions and unfortunately unmotivated since my original intent was to demux discs down to good set of mkvs
<kasper93>
Marth64: right now, we need current dvd demuxer in release version of ffmpeg so it is possible to switch to it by default
<Marth64>
sounds good
<Marth64>
if/as that happens please let me know any bugs your users report
<kasper93>
given how minimal is current dvd support in mpv, I think we will be able to do the switch, without issues
<kasper93>
also BDMV support might be interesting for mpv too
<Marth64>
i sent ffmpeg demuxer patch overnight. nevcairiel has pointed me to an improvement so i will be focused on that the next few days
<Marth64>
it is very new and needs some love and care but i am confident its on the right track
<kasper93>
cool, will keep an eye on that
<Marth64>
dvd took me 1 year. this one was a 2 month thing
<Marth64>
dvd is cryptic and overly flexible
<JEEB>
kasper93: yea re: switching DVD to avformat
<Marth64>
bd is "here you go, mpeg-ts streams, have a good day"
<Marth64>
with a sprinkle of annoyances of course but not like dvd where i wanted to break my keyboard
realies has joined #ffmpeg-devel
<Marth64>
anyways.. back to eia608... have a good thanksgiving if celebrated in your culture
<kasper93>
oh, bdmv is also annying with seamless branching
<kasper93>
though, indeed more sane overall
<JEEB>
and at least you can get the spec as it's floating around
<JEEB>
DVD spec was book only
<Marth64>
i think mostly it took me a long time to learn ffmpeg internals too and managing a subdemuxer
<Marth64>
in the end its not hard but the learning journey was
<Marth64>
GENPTS is also evil
<Marth64>
luckily bd does not need that
<Marth64>
thanks all here for the help/advice along the way
<Marth64>
we still need something that truly does menus. people need a way to know what segment/titles to pick and for some discs navigating the menu is the only effective way since its a state machine
<Marth64>
of course, VLC works great for this at the time
<Marth64>
</caffeine-ramble>
<Marth64>
i also want closed captions to look good. right now its mess
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<elenril>
clearly a new subtitle api is needed for that
<JEEB>
Marth64: UINT32_MAX into a signed 32bit field for unknown duration. yee-haaa
<JEEB>
*haaw
<Marth64>
i will work my way there over the next year. we need subtitle filtering
<Marth64>
JEEB: that would be a fun experiment
<Marth64>
infinite streams
<Marth64>
:D
<Marth64>
the author of previous subtitle authoring patch replied they planned to continue the work in April
<Marth64>
i have seen nothing so its fair game to pick it up imo
<JEEB>
totally
<Marth64>
imagine -filter:s trim_whitespace at long last
<JEEB>
I would like someone to actually verify if the guy's claims that he totally needed those duplicate fields copied from AVSubtitle
<JEEB>
because he didn't explain the necessity of them too well
<Marth64>
i have to go back and unpack it all. its on my 2025 bucket list
<JEEB>
( ^_^)b
cone-172 has quit [Quit: transmission timeout]
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 276 seconds]
Krowl has quit [Read error: Connection reset by peer]
Marth64 has quit [Quit: Leaving]
<jamrial>
<@elenril> clearly a new subtitle api is needed for that <- vietnam flashbacks
<KillerWasp>
hello. I have a C program that get a mp4 and send to twitch, i already have all the code for get the frame, resize the video, and send the frame to switch. The problem is that i'm like 2 days with the damn pts/dts sincronization, i never can fix it, i don't know what pts/dts send to avcodec_send_frame and how to handle the pts/dts receive from avcodec_receive_packet, and where/how handle with av_usleep.
<JEEB>
that's API usage, which would be on the general usage channel.
<KillerWasp>
the avcodec_send_frame+avcodec_receive_packet is where i process the frame to packet for send to switch, but i always get wrong pts/dts, and in av_interleaved_write_frame i get whining.