rom1v

14 ms·

121.
by rom1v 7y ago
> when a video is paused, it will stop the computer from going to sleep This seems to be fixed: - https://trac.videolan.org/vlc/ticket/3724 - https://trac.videolan.org/vlc/ticket/19463
122.
by rom1v 7y ago
> Is there some API to be able to script VLC? https://wiki.videolan.org/Documentation:Building_Lua_Playlis... (I recently changed its implementation to use the new playlist/player [1], but the API was kept unchanged
123.
by rom1v 7y ago
And actually Thomas already implemented it in VLC 4: https://code.videolan.org/videolan/vlc/blob/f93fef718c3c61e2... \o/ (we discussed about it, I didn't remember he already did it)
124.
by rom1v 7y ago
> What if I have two items on the playlist that both fails, is it going to remember the number of consecutive errors ? Yes, it will, the counter is reset only on successful playback.
125.
by rom1v 7y ago
I just proposed a patch to fix the problem on VLC 3: https://mailman.videolan.org/pipermail/vlc-devel/2019-May/12... (proposed != merged)
126.
by rom1v 7y ago
IMO, an infinite queue does not really apply to VLC. If all songs are correctly tagged (which cannot be assumed in VLC), what Spotify does is interesting: https://labs.spotify.com/2014/02/28/how-to-shuffle-son
127.
by rom1v 7y ago
> VLC continues to be riddled with crashes in the menus, because of a bug in how they use A List, that is almost 10 years old. Could you be more specific, please? Which menu, in which circumstances?
128.
by rom1v 7y ago
Ah ok, thank you for the details! In that case, indeed there is some overlap (when removing an item, the randomizer only swaps 2 items in the "non-ordered" part).
129.
by rom1v 7y ago
Personally, I'd love to :) One annoying point is that the core API, used by the modules, can change at any time (the modules are updated along with the API). If there are Rust bindings for the core API [1], every API change must be ref
130.
by rom1v 7y ago
Shuffling a vector at once is "trivial": https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#T... I am not sure to understand what to look in the first link, nor the connection with the second link.
131.
by rom1v 7y ago
I'm glad that supporting "previous" in random mode will not be useless, then :)
132.
by rom1v 7y ago
> I mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing I agree, that's a waste of time I would have preferred to avoid. The lack of a such basic structures is something I really dislike in C
133.
by rom1v 7y ago
Definitely, we are aware of this stupid behavior, it will be fixed (at the latest) in 4.0.
134.
by rom1v 7y ago
Did you get it from https://www.videolan.org/ ?
135.
by rom1v 7y ago
TBH, I think this is acceptable for a playlist random order, even if it's not perfectly evenly distributed.
136.
by rom1v 7y ago
Interesting, I didn't know about the tetris randomizers! https://simon.lc/the-history-of-tetris-randomizers
137.
by rom1v 7y ago
> I never had any issues with the playlist. The playlist is not a especially relevant part in the whole thing. The playlist rewrite I detail in this blogpost is an internal technical refactor, so you're absolutely right, it's n
138.
A new core playlist for VLC 4(blog.rom1v.com)
214 points by rom1v 7y ago|159 comments
139.
by rom1v 7y ago
> Rust has C-like pointers, so if you're OK with them, you can just use them as if you were writing a C program. This would not be practicable. Raw pointers in Rust are (probably on purpose) far less convenient to use (no operator +
140.
by rom1v 7y ago
> The negative spin would be: how to spend a lot of effort to solve a problem you would never have if you didn't use rust. I can't totally disagree, I sometimes had this feeling during the implementation. Contrary to other lang
141.
by rom1v 7y ago
> the mentioned lack of a huge speedup is due to both hyperthreading Correct :) I just updated the article after similar comments on reddit: https://blog.rom1v.com/2019/04/implementing-tile-encoding-in...
142.
by rom1v 8y ago
Thanks to the initial work submitted by igorinov via a pull request ( https://github.com/Genymobile/scrcpy/pull/292 ), scrcpy now provides an option to record the device screen to a video file: scrcpy --r
143.
Show HN: Record your Android screen with "scrcpy --record file.mp4"(github.com)
1 points by rom1v 8y ago|1 comments
144.
by rom1v 8y ago
Thanks to the initial work submitted by igorinov via a pull request ( https://github.com/Genymobile/scrcpy/pull/292 ), scrcpy now provides an option to record the device screen to a video file: scrcpy --r
145.
Show HN: Record your Android screen with “scrcpy --record file.mp4”(github.com)
2 points by rom1v 8y ago|1 comments
146.
by rom1v 8y ago
Hi, I just looked over your github repos, the number of "high quality" projects is impressive. Great job!
147.
by rom1v 8y ago
You're right, I read diagonally :) However, the optimization argument for signed overflow seems weird to me, because I can't see any reason why this argument would not apply to unsigned overflow as well. If we keep undefined behav
148.
by rom1v 8y ago
size_t is unsigned, overflow is defined.
149.
by rom1v 9y ago
We recently published an open source application to display and control Android devices: https://news.ycombinator.com/item?id=16544977 But the audio was not forwarded. I investigated, and implemented something experimental,
150.
Show HN: Forward audio from Android device to computer(github.com)
1 points by rom1v 9y ago|1 comments

More ›