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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
MisterMinister has quit [Ping timeout: 248 seconds]
MisterMinister has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
mkver has quit [Quit: Leaving]
mkver has joined #ffmpeg-devel
jamrial has quit []
cone-492 has joined #ffmpeg-devel
<cone-492>
ffmpeg Andreas Rheinhardt master:1b6f37ac138a: avcodec/sbcenc: Mark sbc_encode_init() as av_cold
<cone-492>
ffmpeg Andreas Rheinhardt master:d7820a2b6f80: avcodec/sbcenc: Don't use deprecated AVCodec.supported_samplerates
<cone-492>
ffmpeg Andreas Rheinhardt master:e934fd96c1d2: avcodec/snow: Remove outdated assert
Anthony_ZO has joined #ffmpeg-devel
Anthony_ZO has quit [Remote host closed the connection]
Anthony_ZO has joined #ffmpeg-devel
mkver has quit [Ping timeout: 244 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
Traneptora has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 252 seconds]
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
Anthony_ZO has quit [Remote host closed the connection]
Anthony_ZO has joined #ffmpeg-devel
Anthony_ZO has quit [Quit: Anthony_ZO]
Anthony_ZO has joined #ffmpeg-devel
Anthony_ZO has quit [Client Quit]
Anthony_ZO has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
Anthony_ZO has quit [Remote host closed the connection]
Anthony_ZO has joined #ffmpeg-devel
cone-721 has joined #ffmpeg-devel
<cone-721>
ffmpeg Frank Plowman master:20a6eb1ca343: lavc/vvc: Stricter bound on pps_exp_slice_height_in_ctus_minus1
Anthony_ZO has quit [Quit: Anthony_ZO]
mkver has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
SohamK has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 244 seconds]
ccawley2011_ has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 244 seconds]
ccawley2011 has quit [Ping timeout: 276 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
<fflogger>
[newticket] idest: Ticket #11499 ([ffprobe] ffprobe: "Unsupported codec with id 0" for attachement streams) created https://trac.ffmpeg.org/ticket/11499
minimal has joined #ffmpeg-devel
SohamK91 has joined #ffmpeg-devel
SohamK91 has quit [Client Quit]
<BBB>
haasn: for sws design, it would be useful (I think you were working on that already) if you could include some speed comparisons vs. current swscale as well as zscale for popular conversions that people do often, rather than just "sometimes it's 6x as fast" (but not telling us for what conversion)
<BBB>
e.g. "yuv420p10le to yuv420p" or "yuyv to yuv422p" or "yuv420p to rgb24" or "rgb24 to gbrp" or whatever you think is a a reasonable and objective way to compare designs
<BBB>
(this can also be colorspace conversion that people might currently do with zscale or the colorspace filter or maybe (poor souls) with swscale
<BBB>
I guess my point is that the design sounds really nice but some people like numbers as a practical way to validate the design's efficiency
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
<haasn>
Sure, I’ll make a summary of important formats
<haasn>
Well some of the numbers are a bit preliminary because there is no asm yet
<haasn>
For example rgb24 -> rgba is much faster with the current mmx simd code than the one generated by the compiler
<toots5446>
Lynne: I'm waiting for this series to get in to start working on the follow-up we discussed, i.e. to get the ogg header packets out of the demuxer.
shrewd has quit [Quit: shrewd]
shrewd has joined #ffmpeg-devel
shrewd has joined #ffmpeg-devel
Mirarora has joined #ffmpeg-devel
<michaelni>
BtbN, soft works said patchwork seems not updating
MyNetAz has quit [Remote host closed the connection]
<Lynne>
toots5446: why do you have txt files for the fate samples?
<BtbN>
michaelni: yeah, but no obvious reason
<Lynne>
don't they automatically get generated when doing make fate GEN=1?
MyNetAz has joined #ffmpeg-devel
<BtbN>
oh, found an error
<BtbN>
"temporary failure. Command output: Could not create directory '/nonexistent/.ssh'._ "
<toots5446>
ha sorry. Do you need another format? This is the output of the test program to see decoded metadata/PTS/DTS
<Lynne>
toots5446: yes, I saw that, just wondering why you have reference files there when they get generated
<toots5446>
What do you mean?
<Lynne>
make fate GEN=1 regenerates all refs
<toots5446>
I did not know that
<toots5446>
Then you probably don't need the text files I imagine.
<toots5446>
Lynne: yeah make fate GEN=1 is not supported by the patch series atm. I see how this can be done. Do you need to have it in the series to get it included or can that be a follow-up?
<Lynne>
is it a lot of work?
<Lynne>
if not, just send me a patch and I'll apply it alongside the rest of the patchset (or merge it into one)
<toots5446>
I don' think so, looks like a new make target. My concern is more that I included the files to make sure we catch any breaking change. If we generate them, I think the test looses some of its value.
<toots5446>
Lynne: yeah looks like the GEN targets are called as part of the fate test run to generate data to run the tests. In this case, it does not make sense to me to generate those files there. What I want, typically, is that if the metadata stops being decoded, that the test would start breaking. If we generate it during the tests we wouldn't see that happening. That's how I understand the current
<toots5446>
code but maybe I'm missing something.
<Lynne>
I don't get it, this happen automatically with all fate tests, no need for special handling
<JEEB>
files that are actual references against which things get tested should be included, but the temporary results that get generated during the tests (which are then compared against the references) should not be
<JEEB>
I would expect that Lynne interprets those files as the latter, and toots5446 is interpreting them as the former?
<Lynne>
yeah, pretty much
<toots5446>
Yeah agreed. To me the txt files are reference and the test makes sure that we don't break the reference output in the future.
<Lynne>
we may have to break them in the future, if some refactor comes along and redoes timestamp handling and so on
<toots5446>
Yeah that's the intent I think but in this case it becomes intentional. Typically, for the follow-up, removing ogg headers from the demuxer I would expect them to break, which would be great to see what's changing and to document any potential breaking change.
<JEEB>
test results changing due to improvements in modules is a usual thing that happens. but yea, I haven't looked at the diff so I'm just talking generics at this point
<Lynne>
toots5446: the idea is to not have to manually redo references when they get broken
<Lynne>
*intentionally
<Lynne>
we're criminally lazy and having to do menial work like this would make us just give up
<toots5446>
I understand. In this case, I'm not sure what we could test then. If you feel strongly this way you could just strip the test commits from the series, they're independent. That's fine with me but I do think that they are useful to be more robust long-term.
<haasn>
BBB: I posted a fairly substantial breakdown of the new performance figures on the ML
<haasn>
Let me know if that satisfies your curiosity :)
<haasn>
Maybe I can generate graphs and write a blog post
<toots5446>
Lynne: Looking back, I could include a make target that re-generates the reference file manually. This would create a workflow where the reference file can be re-generated after a breaking change by calling this target explicitly and then updating the stored fate files.
<toots5446>
How does that sound? If so I'm happy to include that with the next round of work which is expected to break those files.
<Lynne>
I still don't get the problem
<Lynne>
the files should *already* be generated automatically when you run GEN=1
<Lynne>
*why* are they not?
jamrial has joined #ffmpeg-devel
<toots5446>
What do you think the test should do?
<Lynne>
same thing as all fate tests? run an ffmpeg command line, the command line output gets scanned by the framework and compared to the ref
<toots5446>
What should the ref be?
<Lynne>
whatever the command line spits out
<toots5446>
I think that it would help to clarify what you think the output should be. The test, as I view it, output a text file as dump of ffmpeg metadata decoding and the ref is the text file so to me the txt file is the output.
<toots5446>
But maybe I'm misunderstanding your perspective.
<toots5446>
I'm open to other alternative just would like to understand what should be generated and what should be tested.
<Lynne>
can you use the output of ffprobe? I'm pretty sure we have tests which use ffprobe's output
<JEEB>
yea, we do
<toots5446>
I can look into it for sure. Last I checked ffprobe was not able to inspect the AVStream metadata but I'll double check.
<toots5446>
So we call ffprobe, dump the result and compare to another text file? Would that work for you?
<JEEB>
see `ffprobe -of json -show_{format,streams} -i INPUT` for example
<JEEB>
if it's on the general avfmt level it's on the format one, and stream-specific stuff is in the latter
<JEEB>
then there's separately packets and frames as well, and you can also limit it to specific streams with `-select_streams`. there should be quite a few examples in the FATE makefiles for ffprobe usage
<toots5446>
JEEB: the problem is that the metadata for the stream change in the middle of the stream. Can ffprobe output the AVStream metadata on each packet?
<toots5446>
In the custom test binary, I have to print the AVStream on each packet to be able to capture the metadata change:
<toots5446>
This output is the current behavor BTW.
<toots5446>
I'm very happy to do this with ffprobe is this is possible or to change ffprobe to make it possible.
<JEEB>
toots5446: so the API client doesn't get any other hint regarding the metadata update as it reads the input?
<toots5446>
It does: st->event_flags |= AVSTREAM_EVENT_FLAG_METADATA_UPDATED
<toots5446>
Again this is all current code, my patchset is just generalizing this mechanism to other ogg encapsulations and adding tests for it.
<JEEB>
yea, I understand. just wanted to recall what the current mechanism for that is
<toots5446>
Sure thing!
<toots5446>
The patchset is adding frame-level metadata update, however, plugging into what seems like left over from previous unfinished work.
<JEEB>
and yea, then current ffprobe only dumps format and streams once, so the API usage test is probably the way to go
<toots5446>
ok thanks!
<JEEB>
but you should probably only dump the stuff when that event is received
<JEEB>
not at each packet
<toots5446>
Yeah that makes sense
<toots5446>
would be even more robust
<toots5446>
Should ffprobe be updated instead to support dumping metadata on this event? Would that be a better route?
<JEEB>
I expect events get reset somehow... OK, so avformat.h says it's the user that must clear the flags
<toots5446>
I'm thinking ffprobe could implement the expected user-end of this, inspect the flag, print the metadata on change (with an opt-in option) and clear the flag.
<toots5446>
This way this could be tested further when other formats adopt it.
<JEEB>
toots5446: adding support for such updates somehow would be nice, but I'm not sure where to put it. show_{packets,frames} are the ones that keep reading the input, but how do you then expose it in the structure of the JSON/XML/etc
<toots5446>
Good question.
<toots5446>
I'm also happy to take this as a follow-up from that patch series then
<toots5446>
So to summarize:
<toots5446>
- There's confusion about what should be tested but it seems that a text output dumping metadata should be generated and compared to a reference.
<toots5446>
- Ideally, ffprobe could generate the text output but it is not currently able to output metadata update on the AVStreams after the initial probe.
<toots5446>
- The ad-hoc test binary can do that but could be enhanced to only print change when the specific event flags are turned on.
<toots5446>
- ffprobe could also be extended to do the same though it's unclear how/where to output the data.
Rodi has quit [Quit: Client closed]
Rodi has joined #ffmpeg-devel
<toots5446>
Happy to tackle any of that. Ideally the current patch set could be applied now and I'd set up to do a follow-up on what has consensus. And also start working on Lynne's concern, i.e. removing ogg header packets from the demuxer output.
<toots5446>
Ha and also fixing PTS/DTS for those streams (see output dump above..)
<Lynne>
I'm fine with applying the patch now, though where would the test files go?
<Lynne>
we cannot delete files from our fate repo ever, so the text files would need to be in our main repo
Rodi29 has joined #ffmpeg-devel
Rodi has quit [Quit: Client closed]
<toots5446>
Quick glance seems to show that tests/ref/fate would be appropriate for it.
Rodi29 is now known as rodidort
<toots5446>
And, yeah, having breaking changes in the git diff would be great too.
rodidort has quit [Changing host]
rodidort has joined #ffmpeg-devel
rodidort has quit [Quit: Client closed]
rodi_ has joined #ffmpeg-devel
rodidort has joined #ffmpeg-devel
rodi_ has quit [Client Quit]
rodidort has quit [Quit: Client closed]
<toots5446>
I have to go let me know if you would me to submit an updated patchset. Otherwise should be pretty easy to adapt.