- Jul 19, 2020
-
-
Yaron Shahrabani authored
-
Yaron Shahrabani authored
-
- Jul 18, 2020
-
-
Pierre Ynard authored
-
Pierre Ynard authored
Apparently the tag appended to the video title isn't always spelled exactly the same.
-
Rémi Denis-Courmont authored
This is just instance-independent data. The player provides the instance.
-
- Jul 17, 2020
-
-
Steve Lhomme authored
Only a few fields are shared with vout_wrapper.c and interlacing.c via vout_thread_private_t in vout_private.h. users of vout_internal.h API's do not have access to any of the internal fields. vout_thread_t is a VLC object that no other object should derive from, so only the vlc_object_t should be seen publicly.
-
Steve Lhomme authored
The internal call definitions using vout_thread_private_t are moved to vout_private.h as well. The object and storage structure are now separated for these calls.
-
Steve Lhomme authored
-
Steve Lhomme authored
-
Steve Lhomme authored
-
Steve Lhomme authored
This way only video_output.c needs to know about the original format.
-
Steve Lhomme authored
So that only video_output.c needs to know about its internal control.
-
Steve Lhomme authored
-
Steve Lhomme authored
-
Steve Lhomme authored
It's a VLC_API defined in vlc_vout.h
-
- Jul 16, 2020
-
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
refs #24949 Was wired as SUBT for ease, but that only works as long as cue parameters are not used.
-
François Cartegnie authored
-
François Cartegnie authored
-
Alexandre Janniaux authored
Remove hardocded --jobs and use the value from the build script by default, which is machdep.cpu.core_count + 1.
-
- Jul 15, 2020
-
-
Steve Lhomme authored
-
Steve Lhomme authored
-
Steve Lhomme authored
We don't add useless rules. vorbisenc is built with libvorbis, so we just build that when needed.
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
and removes unused flag from cfea200c
-
François Cartegnie authored
-
Steve Lhomme authored
They don't actually need some special treatment. They extract properly in the expected folder given their tarball name.
-
Steve Lhomme authored
It doesn't have any depedency with x264 nor anything shared.
-
Steve Lhomme authored
It doesn't build but at least we get the sources to build properly.
-
Steve Lhomme authored
The official tarballs (with a proper extraction folder name) are in .tar.gz The tarballs we used so far are git snapshots.
-
Steve Lhomme authored
-
Steve Lhomme authored
This is cleaner than using a loop of vlc_tick_sleep(VOUT_OUTMEM_SLEEP); We don't potentially wait 19.9999ms before giving a surface to the decoder.
-
Steve Lhomme authored
If there's no surface available the decoder should wait for one to be available, not get an error and not try to decode anymore. When pictures (and thus surfaces) were coming from the display a picture_pool_Wait() was used, so in the normal case we should do something similar. The infinite looping shouldn't be an issue as on Flush or Close the decoder will release all the past pictures/surfaces. So there will be new surfaces available for past calls. We could improve the code by using a conditional variable or semaphore to unlock the pending requests rather than using vlc_tick_sleep().
-
Steve Lhomme authored
avcodec_flush_buffers() is already not "protected" on close or drain. The comment mentions some deadlock but when it was introduced there was a semaphore around the call (3532e72e). There's no such thread protection anymore. libavcodec must handle its threads flushing internally (see ff_thread_flush() in pthread_frame.c) With canceled pictures/surfaces, before the flush is received it may still try to get a picture after the previous call returned NULL and so on. Without canceled pictures/surfaces, the threads waiting for a picture/surface will keep waiting but their "context" is reset. Either they will receive a picture from the pending call for a previous frame but the flush should discard it. Either the picture will be used for a fresh picture to decode and we don't need to care at all.
-
- Jul 14, 2020
-
-
Alexandre Janniaux authored
Non-regression test for 12fa8556: lib: media_player: keep player libvlc instance
-
Alexandre Janniaux authored
The media_player instance retains and releases the libvlc instance it's created from. When using a different libvlc instance for media_player and media, it was using the libvlc instance from the media_t object, leading to the release of the wrong libvlc instance, and thus potential use-after-free of one instance and leaks of the other. It has been spotted since VLCKit creates a shared libvlc instance and then can create a new libvlc instance in case the VLCMediaPlayer is created with different options, which means that the VLCMediaPlayer and the VLCMedia will be bound to different libvlc instances, triggering the issue described in first paragraph and crashing. /!\ This commit changes libvlc behaviour in the following case: - There's at least two libvlc instance, one being the parent of a media and the other being the parent of a media_player. - The media is set on the media_player. - A new media is played by the underlying vlc_player_t, in which case the new libvlc_media_t instance is now created with the player libvlc instance instead of the media libvlc instance. - The user call libvlc_media_player_get_media() on the player. - The user call preparse functions on the media. Since this very case was leading to crash anyway, and is quite intricate, it's probably not a very important change though. Refs videolan/VLCKit#189, videolan/VLCKit#116
-
Alexandre Janniaux authored
Avoid leaks in freetype when not testing it.
-