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
Everything has quit [Quit: leaving]
iive has quit [Quit: They came for me...]
Traneptora has joined #ffmpeg-devel
cone-891 has quit [Quit: transmission timeout]
thilo has quit [Ping timeout: 246 seconds]
arch1t3cht9 has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
arch1t3cht has quit [Ping timeout: 260 seconds]
arch1t3cht9 is now known as arch1t3cht
compnnn has joined #ffmpeg-devel
compnn has quit [Read error: Connection reset by peer]
paulk has quit [Ping timeout: 248 seconds]
^Neo has quit [Ping timeout: 245 seconds]
System_Error has joined #ffmpeg-devel
jamrial has quit []
Cheetahze has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 252 seconds]
wyatt8740 has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 255 seconds]
mkver has quit [Ping timeout: 264 seconds]
Cheetahze has quit [Quit: Connection closed for inactivity]
<Lynne>
anyone has had time to test ffv1_vulkan?
<Lynne>
particularly on windows
<Lynne>
I'll stop talking bad stuff (though I've never mentioned it because its just insignificant) about intel's vulkan drivers on windows if they run my code properly (anv on linux fails)
System_Error has quit [Ping timeout: 260 seconds]
haihao has quit [Ping timeout: 276 seconds]
haihao has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
BradleyS has quit [Quit: quit]
BradleyS has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
haihao has quit [Ping timeout: 246 seconds]
haihao has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<Traneptora>
Lynne: dyou have a branch or is it in git master?
<Traneptora>
also I have nvidia, not intel gpu, does that matter for you?
<JEEB>
it's in master, that's why FATE was bork yesterday (due to one of the refactors before the encoder commit)
Workl has joined #ffmpeg-devel
<Lynne>
(the encoder shouldn't support version 1 files since no one ever used it ever but w/e)
<thardin>
just got a sample with 7.1 pcm_f32le audio. probably the first time I've seen float audio in production
<Traneptora>
desktop here, not weird setup
<JEEB>
thardin: it does occur :)
<JEEB>
although indeed rarer since the pipes don't usually pass it
Krowl has joined #ffmpeg-devel
<thardin>
I can imagine. it's also a speedhq file. and for some reason the system struggles to play it at the full 50 Hz
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 272 seconds]
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 255 seconds]
<thardin>
hm.. why would mid-range values -crf in libx264 make decoding slower? -crf 10 is fine as is -crf 40 but 20-30 seem to cause issues. there are differences in extradata
ccawley2011_ has joined #ffmpeg-devel
<thardin>
oh this is even more interesting: decoding is actually faster with those settings
haihao has quit [Ping timeout: 244 seconds]
haihao has joined #ffmpeg-devel
<JEEB>
at the point where CABAC etc are your primary costs, the less bits (higher CRF) you utilize, the faster things go
<thardin>
yeah I imagine it's something like that. anyway it's probably something else
<thardin>
err that the root cause of the problem I'm looking at is something
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 255 seconds]
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 248 seconds]
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 260 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 260 seconds]
ccawley2011 has quit [Ping timeout: 260 seconds]
jamrial has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
mateo` has quit [Ping timeout: 272 seconds]
Krowl has joined #ffmpeg-devel
mateo` has joined #ffmpeg-devel
Gramner has quit [Remote host closed the connection]
Gramner has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 265 seconds]
rvalue has joined #ffmpeg-devel
<fflogger>
[editedticket] Balling: Ticket #11307 ([avcodec] [truehd_core] Application provided invalid, non monotonically increasing dts to muxer in stream 0) updated https://trac.ffmpeg.org/ticket/11307#comment:4
cubicibo has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 260 seconds]
cubicibo has quit [Quit: Ping timeout (120 seconds)]
ccawley2011_ has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 245 seconds]
Daemon404 has left #ffmpeg-devel [#ffmpeg-devel]
Marth64 has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 272 seconds]
^Neo_ has joined #ffmpeg-devel
Marth64 has quit [Read error: Connection reset by peer]
Marth64 has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 252 seconds]
cone-815 has joined #ffmpeg-devel
<cone-815>
ffmpeg James Almer master:9d8f7bf4b836: tests/checkasm/diracdsp: fix alignment for src and ombc_weight buffers
Krowl has quit [Read error: Connection reset by peer]
<kasper93>
I have trouble with matroska muxer. It fails in hvcc_write() because numNalus[VPS_INDEX] == 0. Is this expected?
<JEEB>
what would that write since hvcc_write is called afterwards? also array_completeness = 1 requires that parameter sets are there
wyatt8740 has quit [Ping timeout: 252 seconds]
<JEEB>
oh
<JEEB>
so it writes the config version etc before calling hvcc_write
<JEEB>
ah no, that's get_bits
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 244 seconds]
ccawley2011 has joined #ffmpeg-devel
<JEEB>
yea, so the checks in hvcc_write should be limited to array_completeness = 1
<JEEB>
the > We need at least one of each: VPS, SPS and PPS.
ccawley2011_ has quit [Ping timeout: 252 seconds]
<JEEB>
the one case I am unsure of is array_completeness = 0 && one of them missing
<JEEB>
since otherwise it doesn't even include a single set of params
<JEEB>
since at least with initial glance hvcc_write seems to handle numOfArrays = 0
wyatt8740 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ngaullier has quit [Read error: Connection reset by peer]
<Marth64>
Is there any interest or thoughts in IETF language element support for Matroska (stream level language with country code / locale)? I currently apply it with mkvpropedit but would be nice to be able and apply with ffmpeg.
<Marth64>
I haven't thought through implementation at all yet just curious on others feelings of it
<Marth64>
the ebml element is TagLanguageIETF
<Traneptora>
Marth64: does -metadata:s lang=eng not work?
<ePirat>
"Can have multiple values with different language and country code designations"
<Marth64>
that is good to hear (kasper93 + ePirat). so it is not entirely a waste of time to look at
<Marth64>
I personally like the added detail of the locale
ccawley2011 has joined #ffmpeg-devel
<ePirat>
I think at least Quicktime will display the metadata preferably in the user locale
<Marth64>
for example es-419 (Latin America Spanish) should be distinguished from es-ES. or endangered/diaspora language like syr benefit from the regional wualifier
<Marth64>
interesting. I'll play with quicktime on that later
ccawley2011__ has joined #ffmpeg-devel
<kasper93>
it is important for track language selection of en_CA or pt_BR. When you can find files with 40 tracks muxed it is common to have both of the languages
<Marth64>
s/wualifier/qualifier
<Marth64>
correct. agreed
<ePirat>
Marth64, if necessary I might be able to produce a sample for that
<Marth64>
thank you ePirat: I will ping if I can't find one.
ccawley2011_ has quit [Ping timeout: 276 seconds]
<Marth64>
I am hoping both formats are not actually strict on checking the country/regional part of the code
<Marth64>
I don't want a regions list
<ePirat>
its probably still a good idea to have a regions list
<ePirat>
to at least warn users if they mess it up…
ccawley2011 has quit [Ping timeout: 255 seconds]
<Marth64>
true
Sean_McG has quit [Ping timeout: 252 seconds]
Sean_McG has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
<ePirat>
"com.apple.quicktime.location.body" Good to know Quicktime is ready to represent locations that aren't on earth if we move on to a different planet
<JEEB>
I think 3GPP also had a celestial body
<JEEB>
if you look at its metadata stuff
<ePirat>
I assume so, as it says "for compatibility with the 3GPP format" in that table
<JEEB>
:D
<kasper93>
makes sense, how else would you tag videos from the Moon?
<courmisch>
how else would you not be sued by the Extraterrestrial Rover Protection League?
ngaullier has quit [Ping timeout: 255 seconds]
* Sean_McG
snickers
Krowl has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 252 seconds]
<jamrial>
JEEB: what does array_completeness = 1 entail? at least one of each PS?
<JEEB>
that all parameter sets are in the hvcc. which of course means that you need to have at least one set of them there.
<JEEB>
defined by 14496-15
<JEEB>
(technically I think you can then have another set of extradata in mp4, where you could then put the changed edition - and I think this would still be valid. the main point being that no parameter sets should be in the samples (packets in mp4-speak) themselves
<jamrial>
i don't know if we're filtering NALUs from packets, that said
<JEEB>
I think you should be able to just have it call hvcc_write since the NALU parsing gets skipped, and then that function seems to handle numOfArrays = 0 since it for each entry of the static array checks numNalus[i] which would be zero.
<JEEB>
validation of the parsed stuff from the record seems to happen there
<JEEB>
(although I also see it randomly fixing invalid values there, too)
<jamrial>
mmh, ok
<JEEB>
I do agree that hvcc_write could then be made more early-exit
<JEEB>
as well as clearly checks and then either copying or writing a new one
<JEEB>
currently it would rewrite it as what we know of existing specs
<JEEB>
in other words, in my opinion the module probably should move towards what you describe - verify parsed values and then pass the configuration record on as-is
<JEEB>
but the first fixup should be to properly handle array_completeness modes from the requesting side
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 276 seconds]
<Traneptora>
JEEB: not that I didn't read your sentence, it's that I was trying to reproduce before you submitted yours
<JEEB>
ah, right :)
<JEEB>
also do note the smiley, so don't worry about it
<JEEB>
but yea, it's a classic case of "we can set all options really early in the process. right? right?!"
<JEEB>
anyways, thanks for taking a look at it. glad I wasn't the only one
<IndecisiveTurtle>
Lynne: Update, I've been dabbling at this rebase these days when I have time after uni. Was broken when I adapted it unsurprisingly, but did find some things. First thing, vc2 encoder is also affected by alignment seems and breaks when using u64buf. In my case I had made it work by using align = 1, which I discovered is incorrect sadly reading the spec but seems gpus dont care.
<fflogger>
[editedticket] dank074: Ticket #9346 ([undetermined] failed with error info "partial file" when input a mp4 file via unix socket) updated https://trac.ffmpeg.org/ticket/9346#comment:2
IndecisiveTurtle has quit [Remote host closed the connection]