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.0.2 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 255 seconds]
arch1t3cht0 is now known as arch1t3cht
Warcop has quit [Remote host closed the connection]
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 244 seconds]
darkstardevx has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
mkver has quit [Ping timeout: 252 seconds]
MrZeus has quit [Ping timeout: 255 seconds]
jamrial has quit []
Guest55 has joined #ffmpeg-devel
<Guest55>
Is anyone there?
HarshK23 has joined #ffmpeg-devel
<Guest55>
I recently used ffmpeg 4.0 on a Linux system and encountered a problem:
<Guest55>
When converting a video file such as mp4 format (about 2G) to m3u8 format, it would get stuck after executing the command and would not execute further. To be exact, the command was executed through Rutime.exec() in java.
<Guest55>
This is the command: /usr/bin/ffmpeg -i /xxxx/input.mp4 -codec: copy -start_number 0 -hls_time 10 -hls_list_size 0 -f hls -y /xxxx/output.m3u8
<Guest55>
If I terminate the Java program, the command will continue to execute and the m3u8 file will be converted. The conversion can also be completed by executing it directly in the Linux shell. It can also be completed smoothly in the Windows system.
<Guest55>
Has anyone encountered such a problem when calling ffmpeg in java?
darkdrgn2k has joined #ffmpeg-devel
<Guest55>
'=D
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 255 seconds]
<Guest55>
There is no problem with videos of several hundred MB
<darkdrgn2k>
how would i find the filename being written inside the int avio_close(AVIOContext *s) fucntion (avio.c)
<darkdrgn2k>
so i found URLContext, but its a .tmp file, is there a better place to add code that triggers when then files are written.
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
Guest55 has quit [Quit: Client closed]
mkver has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]
xvaclav0 has joined #ffmpeg-devel
xvaclav has quit [Ping timeout: 255 seconds]
xvaclav0 is now known as xvaclav
Krowl has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
derpydoo has quit [Ping timeout: 252 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
darkstarx has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
darkstardevx has quit [Ping timeout: 260 seconds]
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
darkstardev13 has joined #ffmpeg-devel
darkstarx has quit [Ping timeout: 246 seconds]
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
derpydoo has quit [Ping timeout: 252 seconds]
darkstardev13 has quit [Quit: Leaving]
Traneptora has quit [Quit: Quit]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<ramiro>
the instruction scheduling can be improved for in-order cores.
<ramiro>
and I need to test more corner cases (such as overflow and checking if that right shift on the qmat[i] has any noticeable impact)
<ramiro>
Lynne: ^^
<ramiro>
wbs: ^^
MrZeus has joined #ffmpeg-devel
<wbs>
does one have to duplicate that huge C wrapper to do an optimized asm implementation of the core function?
<ramiro>
wbs: I did try cleaning up and splitting the function (for example the block permute could be easily split), but no matter what I tried I always ended up with slowdowns :/
Kei_N has joined #ffmpeg-devel
<ramiro>
the slowdowns were small (mostly 0.5%, not more than 1%), but I remember having patches rejected by michael because of even smaller slowdowns...
<ramiro>
( sure, that was around 15 years ago, but still :P )
<wbs>
well if we have the setup where we have a C wrapper, calling an external assembly function, making that external assembly function a new DSP interface should not be any slower (other than the difference between indirect vs direct call)
<wbs>
yes, it might slow down the all-C case by a marginal amount, but that should be outweighed by the possibility of easily getting more asm optimized versions of it
<JEEB>
(25
<JEEB>
whoops
Krowl has quit [Read error: Connection reset by peer]
<courmisch>
sounds like the same problem as my h263 dequantize
<courmisch>
unsurprisingly
<courmisch>
which has been stuck in TC for most of two months now
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has quit [Remote host closed the connection]
IndecisiveTurtle has joined #ffmpeg-devel
<Lynne>
ramiro: ld1 {v0.8h}, [x1], #16 followed by stp xzr, xzr, [x1, #-16]
<Lynne>
you should skip incrementing and then decrementing x1
<Lynne>
unlike x86 those ops aren't free
<ramiro>
Lynne: should I do ld1, stp, and then a separate add instruction?
<Lynne>
I would move stp after the second ld1, as that's likely how an out-of-order CPU would execute them
<Lynne>
most arm chips can do 2 loads + 1 store at the same time
<Lynne>
not sure about what happens if the load and store are to the same address, but even if the store misses the 1-clock dispatch, it'll just be in the second group of 2loads+1store
<ramiro>
Lynne: I wonder how far should I try to space the loads and the uses...
<Lynne>
2+1+2 is fine
<Lynne>
other than that, LGTM
cone-237 has joined #ffmpeg-devel
<cone-237>
ffmpeg Anton Khirnov master:efe38286d102: lavu/opt: document underlying C types for enum AVOptionType
<cone-237>
ffmpeg Anton Khirnov master:4a5bb84515ba: lavu/opt: forward av_opt_get_video_rate() to av_opt_get_q()
<cone-237>
ffmpeg Anton Khirnov master:d89930f8666c: lavu/opt: add API for retrieving array-type option values
<Lynne>
ramiro: oh, you should also move ff_inv_zigzag_direct16 into mpegvideoenc_neon.S
<ramiro>
Lynne: good idea
<Lynne>
ramiro: also, you still have plenty of registers left, you should duplicate the code and unroll by a factor of 1
<Lynne>
doing this would allow you to compress the zigzag table to 8-bits instead of 16-bits
<Lynne>
which would reduce the number of loads by 1 in the main loop
<Lynne>
you'd need 2 more instructions to expand it back to 16-bits, but that's better than loading
<ramiro>
Lynne: should I do "ld1 {v0.8h, v1.8h}, [x1], #32" or split the loads?
<Lynne>
no need to split, you should double them up like that, I believe Apple's CPUs like it
<Lynne>
besides, you'd have more increments in loads, which is never good
System_Error has quit [Ping timeout: 260 seconds]
Krowl has quit [Read error: Connection reset by peer]
<ramiro>
Lynne: unrolling by a factor of 1 made it quite a bit faster, especially for the in-order cores
<Lynne>
told ya
jarthur has joined #ffmpeg-devel
<wbs>
yes, unless the algorithm itself has enough parallel tracks (or requires too many registers), you almost always want to unroll by 2. but more than that is usually counterproductive
<Lynne>
I think clocking down and turning cores off is a better tradeoff than having a heterogenous architecture with a smart scheduler
<Lynne>
generally with the latter higher-level cache isn't shared between processors
___nick___ has quit [Ping timeout: 255 seconds]
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
Warcop has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<darkdrgn2k>
how do i pass a command line argument, then read it inside a context?
HarshK23 has quit [Quit: Connection closed for inactivity]
yigithanyigit has joined #ffmpeg-devel
<BBB>
darkdrgn2k: register an AVClass, add it as an AVOption to that class as a private option, make sure AVClass is first member of your struct
<Daemon404>
git log -> search for any commit which adds an option
<darkdrgn2k>
thats really good idea....
<darkdrgn2k>
i tried adding it to const OptionDef options[]
<darkdrgn2k>
and ffmpeg accepts the flag but not sure how to access it
yigithanyigit has quit [Ping timeout: 265 seconds]
<BBB>
OptionDef options[] is for application-level arguments. I assume you're trying to add a demuxer or decoder option here?
<BBB>
or muxer/encoder
<BBB>
so it really depends on what you're trying to do
<darkdrgn2k>
Thats fair, its an option that will affect possibly many differnt output formats. its for a post-processing step
<darkdrgn2k>
so it seems for bool you declare a static variable, but how do you read deeper in side ffmpeg
Traneptora has quit [Ping timeout: 260 seconds]
dionisis has quit [Quit: WeeChat 3.8]
<darkdrgn2k>
like right now im trying to read it inside dash_flush in dashenc
<darkdrgn2k>
(static int dash_flush(AVFormatContext *s, int final, int stream))
<BBB>
elenril: for mv-hevc (wow!), does the AVFrame just contain one frame? is it possible/meaningful to export all views (or multiple, like a mask) for conformance testing and/or application-level selection if the view at runtime without re-decoding?
<BBB>
"does the AVFrame just contain one frame" -> I meant "does the AVFrame just contain one view"
<darkdrgn2k>
so does AVFormatContext provide a way to OptionDef options[] vaules?
<BBB>
darkdrgn2k: yes
<BBB>
is it just for dash? or is it possibly for all muxers?
<darkdrgn2k>
for now just dash, eventually it will be for many others
<BBB>
if it's for many, see libavformat/options_table.h and add it to AVFormatContext in libavformat/avformat.h
<BBB>
if it's for dash-only, then add it to libavformat/dashenc.c (?) as a private option, see static const AVOption options[] at the bottom of that file
<darkdrgn2k>
actually im not sure if dash_flush is the right place to trigger this logic either. i was thinking avio_Close() but couldnt figure out how to get the filename of the mpd file
<BBB>
to use it on the commandline, ffmpeg -i inputfile -f dash -youroptionname youroptionvalue outputfile
<BBB>
and that value will automatically be set in the variable in the struct (dash specific or AVFormatContext) named in the OFFSETOF()
<darkdrgn2k>
so i added {"test1", "test1", OFFSET(enable_test1)), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, INT_MIN, INT_MAX, D|E, .unit = "enable_test1"}, to static const AVOption avformat_options[]
<ramiro>
I was kind of expecting a better improvement...
<ramiro>
Lynne: ^^
<ramiro>
wbs: ^^
<Lynne>
that's because you're thinking with x86 context in mind, 2.4x speedup is equivalent to 16x speedup with sse2 on x86
<ramiro>
I was kind of surprised that rgb24toyv12 actually subsamples by just dropping 3/4 pixels for chroma. I was expecting it would convert all and average the values...
System_Error has joined #ffmpeg-devel
<Lynne>
I don't see anything that can be improved with the code
<ramiro>
Lynne: thanks... I'll clean it up tomorrow and try to have a fresh look at it.
ccawley2011 has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
microchip_ has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
System_Error is now known as SystemError
yigithanyigit has quit [Ping timeout: 276 seconds]