mpv
mpv copied to clipboard
libmpv ignores `--o` property for encoding
mpv Information
[ 0.007][v][cplayer] mpv v0.40.0-133-g47bc7b2a0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
[ 0.007][v][cplayer] built on Jun 11 2025 00:07:46
[ 0.007][v][cplayer] libplacebo version: v7.351.0 (v7.351.0-dirty)
[ 0.007][v][cplayer] FFmpeg version: N-119877-gf019dd69f
[ 0.007][v][cplayer] FFmpeg library versions:
[ 0.007][v][cplayer] libavcodec 62.3.101
[ 0.007][v][cplayer] libavdevice 62.0.100
[ 0.007][v][cplayer] libavfilter 11.0.100
[ 0.007][v][cplayer] libavformat 62.1.100
[ 0.007][v][cplayer] libavutil 60.3.100
[ 0.007][v][cplayer] libswresample 6.0.100
[ 0.007][v][cplayer] libswscale 9.0.100
Important Information
- Platform version: Windows
- Source of mpv: github releases
Reproduction Steps
- Initialize libmpv in your favorite language
- set the properties
o,vo,ao,ovc,oac,of, - add video filter
realtime - start playing video file with
loadfilecommand
Values used as per the output log:
[ 0.007][v][cplayer] Set property: log-file="D:\\log.txt" -> 1
[ 0.007][v][cplayer] Set property: o="rtmp://127.0.0.1:1935/live/abc123" -> 1
[ 0.007][v][cplayer] Set property: vo="null" -> 1
[ 0.007][v][cplayer] Set property: ao="null" -> 1
[ 0.007][v][cplayer] Set property: ovc="libx264" -> 1
[ 0.007][v][cplayer] Set property: oac="aac" -> 1
[ 0.007][v][cplayer] Set property: of="flv" -> 1
[ 0.014][d][cplayer] Run command: vf, flags=64, args=[operation="add", value="realtime"]
[ 0.015][d][cplayer] Run command: loadfile, flags=64, args=[url="D:\\test.mp4", flags="replace", index="-1", options=""]
The video does "play" as I get the event for the file ending after the same duration as the video should take. But no output stream or file is produced.
Doing the same thing with mpv over the commandline works!
mpv -o=rtmp://192.168.0.16:1935/live/abc123 --of=flv --ovc=libx264 --oac=aac -vo=null -ao=null --vf-add=realtime "D:\test.mp4"
Expected Behavior
I expect the o property for the encoder output to work, or at the very least to get an error if this is not supported.
Actual Behavior
The o property gets silently ignored.
Log File
Sample Files
No response
I carefully read all instruction and confirm that I did the following:
- [x] I tested with the latest mpv version to validate that the issue is not already fixed.
- [x] I provided all required information including system and mpv version.
- [x] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of
--log-file=output.txt. - [x] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
- [x] I attached the full, untruncated log file.
- [x] I attached the backtrace in the case of a crash.
ImPlay and mpv.net are libmpv players that forward the argument properly, look into their code for ideas.
ImPlay and mpv.net are libmpv players that forward the argument properly, look into their code for ideas.
mpv.net not compatible with libmpv-2, so that's long dead.
From what I understand of the mpv C code is that the --o flag NEEDS to be set on initialization, so I need to call mpv_initialize_opts and pass it along there. I've not yet been able to verify this as I'll have to update my C# bindings to support this method of initialization.
However it's still odd that I didnt get any errors on setting the o property at "runtime"
EDIT:
I just realized mpv_initialize_opts isn't actually exported, so this still won't work.
Please attach the code you are using. This might depend on the order of mpv_initialize or your usage of mpv_set_option_string / mpv_set_property.
Please attach the code you are using. This might depend on the order of
mpv_initializeor your usage ofmpv_set_option_string/mpv_set_property.
Sorry for the delay.
You are right, if I set the property before mpv_initialize then it works fine.
However the issue remains that setting it AFTER mpv_initialize does not give an error, which will be confusing as finding any documentation about this isn't exactly easy.
We can document it but that's enough IMO.
Would it be an option to ensure properties marked M_OPT_PRE_PARSE return an error when set at "runtime" ?
I don't think so. There are options with M_OPT_PRE_PARSE but that do support runtime updates.
We can always have additional flag to mark options like that. But I would say it's low-priority.