Skip to content

Port several python scripts to Perl#2

Closed
Jessidhia wants to merge 2 commits intompv-player:masterfrom
Jessidhia:kovensky/perl_port
Closed

Port several python scripts to Perl#2
Jessidhia wants to merge 2 commits intompv-player:masterfrom
Jessidhia:kovensky/perl_port

Conversation

@Jessidhia
Copy link
Copy Markdown
Member

@Jessidhia Jessidhia commented Nov 7, 2012

file2string.pl and vdpau_functions.pl are direct ports.
matroska.py was reimplemented as the Parse::Matroska module in CPAN,
and matroska.pl was made a client of Parse::Matroska.
A copy of Parse::Matroska is included in TOOLS/lib, and matroska.pl
looks there first when trying to load the module.

osxbundle.py was not ported since I have no means to verify it.
Python is always available on OSX though, so there is no harm in
removing the check for it on configure.

Kovensky added 2 commits November 7, 2012 19:25
Port several python scripts to Perl
d9dbfa4 
file2string.pl and vdpau_functions.pl are direct ports.
matroska.py was reimplemented as the Parse::Matroska module in CPAN,
and matroska.pl was made a client of Parse::Matroska.
A copy of Parse::Matroska is included in TOOLS/lib, and matroska.pl
looks there first when trying to load the module.

osxbundle.py was not ported since I have no means to verify it.
Python is always available on OSX though, so there is no harm in
removing the check for it on configure.
Update Parse::Matroska to version 0.003
7f318a6 
Fixes header generation.
@ghost
Copy link
Copy Markdown

ghost commented Nov 8, 2012

Merged as fae7307.

@ghost ghost closed this Nov 8, 2012
ghost pushed a commit that referenced this pull request Nov 20, 2012
options: support chapters for --start and --end
f5e2ee5 
The --start and --end switch now accept a chapter number. The chapter
number is prefixed with '#', e.g. "--start=#2" jumps to chapter 2.

The chapter support might be able to replace --chapter completely, but
for now I am not sure how well this works out with e.g. DVDs and BDs,
and a separate --chapter option is useful interface-wise.

(This was supposed to be added in 51503a, but apparently the fixup
commit adding it was lost in a rebase. This might also be the reason
for the mess-up fixed in 394285.)
@qyot27 qyot27 mentioned this pull request Apr 29, 2013
Closed
@ChrisK2 ChrisK2 mentioned this pull request Aug 16, 2013
Closed
@aktau aktau mentioned this pull request Sep 23, 2013
Closed
@xnoreq xnoreq mentioned this pull request Jan 4, 2014
Closed
@haasn haasn mentioned this pull request Apr 1, 2014
Closed
@p-pioneer-q p-pioneer-q mentioned this pull request Apr 7, 2014
Closed
@ghost ghost mentioned this pull request Apr 19, 2014
Closed
@alejandro-perez alejandro-perez mentioned this pull request Apr 21, 2014
Closed
@tholin tholin mentioned this pull request Jun 20, 2014
Closed
@jannewmarch jannewmarch mentioned this pull request Jul 9, 2014
Closed
@skalinichev skalinichev mentioned this pull request Jul 13, 2014
Closed
@qjqqyy qjqqyy mentioned this pull request Aug 13, 2014
Closed
@koct9i koct9i mentioned this pull request Sep 8, 2014
Closed
@Divetoxx Divetoxx mentioned this pull request Sep 23, 2014
Closed
@b4 b4 mentioned this pull request Nov 2, 2014
Closed
@fjordson fjordson mentioned this pull request Dec 23, 2014
Closed
@kinleyd kinleyd mentioned this pull request Dec 24, 2014
Closed
@unic0rn unic0rn mentioned this pull request Feb 4, 2015
Closed
@kokoko3k kokoko3k mentioned this pull request Mar 4, 2015
Closed
haasn referenced this pull request in haasn/mp Apr 10, 2015
@haasn
Merge pull request #2 from onodera-punpun/patch-1
b3d1f5a 
README.md: Add link to CRUX port
@paulguy paulguy mentioned this pull request May 5, 2015
Closed
@sgerwk sgerwk mentioned this pull request Jan 24, 2018
Closed
@maru-sama maru-sama mentioned this pull request Feb 3, 2018
Merged
@roderick1980 roderick1980 mentioned this pull request Sep 21, 2018
Open
@kokoko3k kokoko3k mentioned this pull request Nov 23, 2018
Closed
@AlessioKuro AlessioKuro mentioned this pull request Oct 7, 2019
Closed
@unculcated unculcated mentioned this pull request Oct 13, 2019
Closed
@syphyr syphyr mentioned this pull request May 22, 2020
Closed
@tonycpsu tonycpsu mentioned this pull request Aug 10, 2020
Closed
@mrkapqa mrkapqa mentioned this pull request Nov 12, 2020
Closed
@kelppo kelppo mentioned this pull request Jun 2, 2021
Closed
@afarley afarley mentioned this pull request Sep 17, 2021
Closed
@ghost ghost mentioned this pull request Feb 28, 2022
Merged
12 tasks
@lavilao lavilao mentioned this pull request May 27, 2022
Closed
@1156175523 1156175523 mentioned this pull request Oct 11, 2022
Closed
xfangfang pushed a commit to xfangfang/mpv that referenced this pull request Jun 17, 2023
@Cpasjuste
Merge pull request mpv-player#2 from WinterMute/ffmpeg-fix
8f9add1 
fix linking with devkitPro ffmpeg package
xfangfang pushed a commit to xfangfang/mpv that referenced this pull request Jun 23, 2023
@averne
Temp commit mpv-player#2
fbeccfb
@kungfubeaner kungfubeaner mentioned this pull request Nov 24, 2023
Closed
@avih avih mentioned this pull request Nov 28, 2023
Open
@Essoje Essoje mentioned this pull request Dec 12, 2023
Merged
@CounterPillow CounterPillow mentioned this pull request Mar 16, 2024
Closed
@shachter shachter mentioned this pull request Oct 15, 2024
Closed
6 tasks
@kasper93 kasper93 mentioned this pull request Apr 2, 2025
Merged
kasper93 added a commit that referenced this pull request Apr 2, 2025
@kasper93
player/scripting: fix race condition when destroying clients
0757185 
Clients run in detached threads and are waited to signal when they are
finished with self mpv_destroy() call. Problem is that after detached
thread calls this function, mpv consider this client to be done and can
do whatever. One example is when mpv exits and wait for scripts to
finish we got race condition, because mpv (main thread) can exit first
and the detached thread calls ta_free() which crashes, because we may
have already destroyed things that the thread depends on.

I've seen this crash on FreeBSD CI job (libmpv-lifetime test), where the
libmpv.so has been unloaded while the thread was still doing ta_free()

```
==5081==ERROR: AddressSanitizer: SEGV on unknoun address 0x000001111806 (pc 0x000001111806 bp 0x7fffdedf4e40 sp 0x7fffdedf4e08 T40)
==5081==The signal is caused by a READ memory access.
    #0 0x1111806  (<unknown module>)
    #1 0x803cd6900 in ta_free /home/runner/work/mpv/mpv/build/../ta/ta.c:243:5
    #2 0x803a2fc87 in run_script /home/runner/work/mpv/mpv/build/../player/scripting.c:93:5
    #3 0x803a2ffe0 in script_thread /home/runner/work/mpv/mpv/build/../player/scripting.c:99:5
    #4 0x2c451a in asan_thread_start(void*) /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:239:28
    #5 0x80034fb04  (/lib/libthr.so.3+0x10b04)
```

Note the 0x1111806 jump which is completelly bogus.

Fix this by doing mpv_destroy() as a last step in detached threads.
@globalshrug globalshrug mentioned this pull request Jun 11, 2025
Closed
6 tasks
@ghost ghost mentioned this pull request Aug 6, 2025
Open
6 tasks
rom311979 referenced this pull request Aug 20, 2025
@guidocella @kasper93
input.conf: bind MBTN_MID to align-to-cursor
e98d3b6
trim21 referenced this pull request in trim21/mpv Dec 25, 2025
@kasper93 @trim21
player/scripting: fix race condition when destroying clients
11c33d2 
Clients run in detached threads and are waited to signal when they are
finished with self mpv_destroy() call. Problem is that after detached
thread calls this function, mpv consider this client to be done and can
do whatever. One example is when mpv exits and wait for scripts to
finish we got race condition, because mpv (main thread) can exit first
and the detached thread calls ta_free() which crashes, because we may
have already destroyed things that the thread depends on.

I've seen this crash on FreeBSD CI job (libmpv-lifetime test), where the
libmpv.so has been unloaded while the thread was still doing ta_free()

```
==5081==ERROR: AddressSanitizer: SEGV on unknoun address 0x000001111806 (pc 0x000001111806 bp 0x7fffdedf4e40 sp 0x7fffdedf4e08 T40)
==5081==The signal is caused by a READ memory access.
    #0 0x1111806  (<unknown module>)
    #1 0x803cd6900 in ta_free /home/runner/work/mpv/mpv/build/../ta/ta.c:243:5
    #2 0x803a2fc87 in run_script /home/runner/work/mpv/mpv/build/../player/scripting.c:93:5
    #3 0x803a2ffe0 in script_thread /home/runner/work/mpv/mpv/build/../player/scripting.c:99:5
    mpv-player#4 0x2c451a in asan_thread_start(void*) /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:239:28
    mpv-player#5 0x80034fb04  (/lib/libthr.so.3+0x10b04)
```

Note the 0x1111806 jump which is completelly bogus.

Fix this by doing mpv_destroy() as a last step in detached threads.
N-R-K referenced this pull request in N-R-K/mpv Mar 10, 2026
@N-R-K
filters/f_decoder_wrapper: fix use-after-free
e40ae4f 
to trigger it, run any video with mutliple audio tracks and
click on the audio track icon in default osc.

this used to be guarded by locks but was changed in
a569c3c with no explaination as to why.
reverting back to old way fixes the UAF, so do that.

ASan stacktrace (notably, the allocation happens in one thread
and the free on another):

==29382==ERROR: AddressSanitizer: heap-use-after-free on address 0x7ba2add5cc70 at pc 0x7f22b71f0ddf bp 0x7ffe01061990 sp 0x7ffe01061150
READ of size 5 at 0x7ba2add5cc70 thread T0
    #0 0x7f22b71f0dde  (/usr/lib/gcc/x86_64-pc-linux-gnu/15/libasan.so.8+0x88dde)
    #1 0x000000b6b875 in ta_strdup ../ta/ta_utils.c:114
    #2 0x000000b6ca63 in ta_xstrdup ../ta/ta_utils.c:285
    #3 0x00000072b39e in str_get ../options/m_option.c:1289
    mpv-player#4 0x00000075240b in m_option_get_node ../options/m_option.h:604
    mpv-player#5 0x0000007571d5 in m_property_read_sub ../options/m_property.c:486
    mpv-player#6 0x0000007b4a76 in get_track_entry ../player/command.c:2132
    mpv-player#7 0x000000758ca4 in m_property_read_list ../options/m_property.c:577
    mpv-player#8 0x0000007b6001 in mp_property_list_tracks ../player/command.c:2239
    mpv-player#9 0x000000752ef7 in do_action ../options/m_property.c:94
    mpv-player#10 0x000000753b75 in m_property_do ../options/m_property.c:175
    mpv-player#11 0x0000007d965b in mp_property_do ../player/command.c:4734
    mpv-player#12 0x0000007868d2 in getproperty_fn ../player/client.c:1422
    mpv-player#13 0x00000078c8ea in send_client_property_changes ../player/client.c:1699
    mpv-player#14 0x00000078e364 in mp_client_send_property_changes ../player/client.c:1770
    mpv-player#15 0x0000008610e1 in mp_wait_events ../player/playloop.c:56
    mpv-player#16 0x000000875e39 in run_playloop ../player/playloop.c:1313
    mpv-player#17 0x000000842b74 in play_current_file ../player/loadfile.c:1952
    mpv-player#18 0x000000846816 in mp_play_files ../player/loadfile.c:2144
    mpv-player#19 0x00000084cbde in mpv_main ../player/main.c:457
    mpv-player#20 0x000000d0bb9a in main ../osdep/main-fn-unix.c:5
    mpv-player#21 0x7f22b2a76038  (/lib64/libc.so.6+0x26038)
    mpv-player#22 0x7f22b2a760f4 in __libc_start_main (/lib64/libc.so.6+0x260f4)
    mpv-player#23 0x000000418160 in _start (/home/nrk/src/core/mpv/build-debug/mpv+0x418160)

0x7ba2add5cc70 is located 80 bytes inside of 85-byte region [0x7ba2add5cc20,0x7ba2add5cc75)
freed by thread T2 here:
    #0 0x7f22b72aeaeb  (/usr/lib/gcc/x86_64-pc-linux-gnu/15/libasan.so.8+0x146aeb)
    #1 0x000000b68bca in ta_free ../ta/ta.c:246
    #2 0x000000b689ff in ta_free_children ../ta/ta.c:231
    #3 0x000000b68ba1 in ta_free ../ta/ta.c:243
    mpv-player#4 0x000000b689ff in ta_free_children ../ta/ta.c:231
    mpv-player#5 0x000000b68ba1 in ta_free ../ta/ta.c:243
    mpv-player#6 0x000000765060 in ao_chain_uninit ../player/audio.c:275
    mpv-player#7 0x000000765410 in uninit_audio_chain ../player/audio.c:290
    mpv-player#8 0x000000827f7c in mp_switch_track_n ../player/loadfile.c:733
    mpv-player#9 0x0000007ae477 in mp_property_switch_track ../player/command.c:1982
    mpv-player#10 0x000000752ef7 in do_action ../options/m_property.c:94
    mpv-player#11 0x000000753680 in m_property_do ../options/m_property.c:142
    mpv-player#12 0x0000007d965b in mp_property_do ../player/command.c:4734
    mpv-player#13 0x0000007cf713 in mp_property_alias ../player/command.c:3788
    mpv-player#14 0x000000752ef7 in do_action ../options/m_property.c:94
    mpv-player#15 0x000000753680 in m_property_do ../options/m_property.c:142
    mpv-player#16 0x0000007d965b in mp_property_do ../player/command.c:4734
    mpv-player#17 0x0000007e42f9 in change_property_cmd ../player/command.c:5367
    mpv-player#18 0x0000007ed67e in cmd_add_cycle ../player/command.c:5870
    mpv-player#19 0x0000007e9617 in run_command ../player/command.c:5643
    mpv-player#20 0x000000782aa7 in run_client_command ../player/client.c:1134
    mpv-player#21 0x000000783284 in mpv_command_string ../player/client.c:1169
    mpv-player#22 0x000000bac63c in script_command ../player/lua.c:610
    mpv-player#23 0x7f22b370945a  (/usr/lib64/libluajit-5.1.so.2+0x645a)

previously allocated by thread T0 here:
    #0 0x7f22b72afc9b in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/15/libasan.so.8+0x147c9b)
    #1 0x000000b67ee4 in ta_alloc_size ../ta/ta.c:139
    #2 0x000000b68241 in ta_realloc_size ../ta/ta.c:187
    #3 0x000000b6b5dd in strndup_append_at ../ta/ta_utils.c:93
    mpv-player#4 0x000000b6b96b in ta_strndup ../ta/ta_utils.c:127
    mpv-player#5 0x000000b6b892 in ta_strdup ../ta/ta_utils.c:114
    mpv-player#6 0x000000b6ca63 in ta_xstrdup ../ta/ta_utils.c:285
    mpv-player#7 0x000000625be3 in reinit_decoder ../filters/f_decoder_wrapper.c:458
    mpv-player#8 0x000000626bf5 in mp_decoder_wrapper_reinit ../filters/f_decoder_wrapper.c:491
    mpv-player#9 0x0000007698bc in init_audio_decoder ../player/audio.c:533
    mpv-player#10 0x00000076a9dc in reinit_audio_chain_src ../player/audio.c:592
    mpv-player#11 0x000000769c49 in reinit_audio_chain ../player/audio.c:556
    mpv-player#12 0x0000008411e8 in play_current_file ../player/loadfile.c:1871
    mpv-player#13 0x000000846816 in mp_play_files ../player/loadfile.c:2144
    mpv-player#14 0x00000084cbde in mpv_main ../player/main.c:457
    mpv-player#15 0x000000d0bb9a in main ../osdep/main-fn-unix.c:5
    mpv-player#16 0x7f22b2a76038  (/lib64/libc.so.6+0x26038)

Thread T2 created by T0 here:
    #0 0x7f22b72a5efd in pthread_create (/usr/lib/gcc/x86_64-pc-linux-gnu/15/libasan.so.8+0x13defd)
    #1 0x000000881a9a in mp_load_script ../player/scripting.c:192
    #2 0x000000882827 in load_builtin_script ../player/scripting.c:252
    #3 0x000000882bd7 in mp_load_builtin_scripts ../player/scripting.c:264
    mpv-player#4 0x00000080bfaf in mp_option_run_callback ../player/command.c:7989
    mpv-player#5 0x000000861b4b in handle_option_callbacks ../player/playloop.c:130
    mpv-player#6 0x00000084bd41 in mp_initialize ../player/main.c:389
    mpv-player#7 0x00000084cbc9 in mpv_main ../player/main.c:455
    mpv-player#8 0x000000d0bb9a in main ../osdep/main-fn-unix.c:5
    mpv-player#9 0x7f22b2a76038  (/lib64/libc.so.6+0x26038)
@drejjmit drejjmit mentioned this pull request Mar 14, 2026
Open
6 tasks
@dengzhongyuan365-dev dengzhongyuan365-dev mentioned this pull request Apr 9, 2026
Open
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@Jessidhia