[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


mpv librempeg yt-dlp
>>
>>106946415
I use all of this but I haven't become a tranny and still fuck women. What am I doing wrong?
>>
>>106946425
I use yt-dlp and ffmpeg without configs or any other tinkering and I'm an adult virgin anxious OCD wreck incel.
>>
>>106946425
>>106946466
paul won
>>
https://github.com/libass/libass/pulls?q=is%3Apr+is%3Aopen+label%3Aperformance+sort%3Aupdated-desc
they're all dead, sis
>>
File: redditcombs.jpg (178 KB, 640x640)
178 KB
178 KB JPG
SWE at Discord folx
>>
>>106927382
doom9
>>
what build do i use on windows?
>>
yt-dlp is unbelievably slow on some arm boards
takes 30 seconds just for yt-dlp -F, 10 times slower than on a modern desktop
>>
dead thread
>>
>>106947836
I wouldn't recommend that unless you want to buy a time-bombed set-top box to run madVR with.
>>106948759
Yeah, starting up the python runtime is really really really slow. Thanks for noticing.
>>
>>106948759
hmm who could be behind this post.
>>
>>106946415
why yt-dlp force me have ipv6 at buildtime? why are they pushing their ideology on me?
>>
>Fixing MPEG-TS in MP4 container
Is there a command to check if this is done afterwards or a way to ask for an indicator? It seems to be happening fast enough that it doesn't matter but not having a definitive "Done" feels weird.
>>
>>106951067
starting up takes 10 seconds, fetching api takes 10 seconds, and another 10 seconds just to extract links
my own youtube client takes less than a second on the same hardware
>>106951856
me
>>
>>106951881
>why are the tests testing wahhhh
RTFM
>>
>>106946425
>What am I doing wrong?
Start posting anime girls.
>>
>>106952210
yt-dlp doesn't take that long (not on a a real OS anyway). and you and your malware are not special. literally anything based on rustypipe does this already. e.g.
https://github.com/siriusmart/youtube-tui

# code below
% ./target/release/test-rustypipe evA33uW8jq8
done in 0.78057575s
Mp4 | Avc1 | 49564 | 144p | url_len=1142
Mp4 | Avc1 | 168133 | 360p | url_len=1141
Mp4 | Avc1 | 541926 | 720p | url_len=1135
Mp4 | Avc1 | 2986969 | 1080p | url_len=1144
M4a | Mp4a | 49815 | url_len=1143
M4a | Mp4a | 130281 | url_len=1135
Webm | Opus | 125347 | url_len=1144


use rustypipe::{client::RustyPipe, model::traits::YtStream};

use std::time::Instant;

async fn main_(id: &str) {
let rp = RustyPipe::new();
let inst = Instant::now();
let player = rp.query().player(id).await.unwrap();
eprintln!("done in {}s", inst.elapsed().as_secs_f64());
player.video_only_streams.iter().for_each(|vs| {
println!("{:?} | {:?} | {} | {} | url_len={}", vs.format, vs.codec, vs.bitrate, vs.quality, vs.url().len());
});
player.audio_streams.iter().for_each(|as_| {
println!("{:?} | {:?} | {} | url_len={}", as_.format, as_.codec, as_.bitrate, as_.url().len());
});
}

fn main() {
let id = std::env::args().nth(1).unwrap();
let rt = tokio::runtime::Runtime::new().unwrap();
rt.block_on(main_(&id));
}


stick to threads where only retards lurk.
>>
sisters, what are your thoughts on the latest mpv drama
https://github.com/mpv-player/mpv/pull/16915
>>
>>106953148
irrespective of technical details or the drama volume, it's good that there is a focus on something that belongs to mpv's "one job". that's infinitely better than adding random out-of-scope bloat a solo wintard may or may not have asked for.
>>
>>106953000
> yt-dlp doesn't take that long (not on a a real OS anyway)
it really takes that long if you have that kind of weak hardware (and the os is linux)
the alternatives also can't display cute mascots and don't have a mpv plugin version
> rust
compiling on that hardware would be too slow and likely oom
>>
>>106953452
>my malware has a use-case for some unspecified "weak hardware"
>i also don't provide sources so you don't have to compile it, because according to me it would oom
lmao
>>
File: 1750959304769002.jpg (39 KB, 792x410)
39 KB
39 KB JPG
>>106953148
qrd
>>
>>106953533
not malware
i compiled my youtube client on a phone chip from 10 years ago using less than 1gb ram
rust would never
>>
>>106954011
your malware is written in rust.
feel free to prove otherwise.
>>
>>106953533
Anon, don't you trust the virustotal results? And just look at the very convincing screenshots. No way that's malware.
>>
File: 1724030105777.png (773 KB, 1179x802)
773 KB
773 KB PNG
>>106954090
its written in c
>>
>>106954210
Wow! Thank you for the very convincing screenshot concrete proof proving totally not malware!
>>
>>106953148
Literally no drama in that thread.
>>
>>106954210
you failed to provide your proof. we will assume your malware is written in rust and can't be compiled on toasters (your own claimed requirement) until you provide actual proof that it isn't, in the form of source code we can try to build on toasters.
>>
>>106954011
>rust would never
you are not special.
your malware is not special.
and cargo/rustc supports the jobserver protocol and scales parallelism/resource usage accordingly.
building with very limited cpu and 512MiB ram works without much swapping if any. building with <=256MiB still works but requires swapping and thus can be extremely slow. and this was tested on a 64bit environment, so there is overhead from the larger addresses.
so users who want access to the source, and want to build it on a "phone chip from 10 years ago", can very much do so. they however can't do either with your not special malware.
you lost the "my malware extracts fast" argument.
your current argument requires you to share the source of your malware and you won't.
you should have heeded my advice and found another thread to lure victims in.
>>
>>106954613
>>106954852
compilers leave version strings in binary
my binaries have gcc markers and no rustc markers
meanwhile you don't have any malware proof despite being available for anyone to inspect for years
> building with very limited cpu and 512MiB ram works without much swapping if any.
post build time for release build
my extractor builds in less than a second with optimization and lto
> you lost the "my malware extracts fast" argument.
0.78s is still slower than mine
>>
>>106955188
all your claims were, are, and will always be unverifiable without functional source code that can be built.
>compilers leave version strings in binary
binaries can be trivially patched. unverifiable claim.
>post build time for release build
it takes an hour, maybe slightly longer. single threaded. limited CPU. 512MiB memory. all defaults. code from the previous comment with this dependencies section:
rustypipe = "0.11.4"
tokio = { version = "1.48.0", features = ["rt-multi-thread"] }

this is a verifiable claim.
>my extractor builds in less than a second with optimization and lto
your extractor builds in 10 hours and requires 32GiB of ram. feel free to provide a counter proof that can be verified.
no matter how much you repeat this, it's a 100% useless claim, which is a % only slightly higher than the disingenuousness of the "compile time on 10 year old phone" argument.
>my malware is maybe XXms faster
good progress from "yt-dlp takes 30s on windows". at least someone could verify this if they are willing to install your malware and it has a usable CLI interface.
>>
>>106953452
>he added child pornography to the ui
>>
how the fuck do I add the cookie bullshit, to mpv or yt-dlp?
>>
>>106955450
>binaries can be trivially patched
not in a way that can't be found out
>good progress from "yt-dlp takes 30s on windows"
you said "yt-dlp doesn't take that long (not on a a real OS anyway)" while anyone with a rpi 3 running linux can verify my claim and prove you wrong
>>my extractor builds in less than a second with optimization and lto
>it's a 100% useless claim
works for me and i don't need to prove it to you
meanwhile you proved yourself that rust compile is very slow
>>106955527
the mascot can be any image
i've seen some anons use photos of adult women or nonhuman creatures as the mascot
>>
>>106955873
>i don't need to prove it to you
fair. i have an extractor that compiles in 0.1s and extracts video info in 0.2s.
>>
>>106955873
>not in a way that can't be found out
lmao
with the code (screencap) and knowledge on display, that malware of yours probably has 20 accidental exploits on top the malware-ness.
>>
>>106956232
link?
>>
i filtered trannies and anyone replying to them so i can't see half the posts itt, i just see that it keeps getting bumped
>>
>>106956403
i don't need to prove it to you
>>
File: images.jpg (8 KB, 299x168)
8 KB
8 KB JPG
>>106954210
looks comfy
>>
>>106952226
it works without it, I have to modify that proxy tests file whatever the fuck it is, take out the ipv6 nonsense, compiles and works just fine. so they pushing their ideology on me. I wish they got politics out of tech
>>
>>106958834
buy an ad. Selling RIFE for $20, ok.
>>
https://www.inmatrix.com/files/zoomplayer_whatsnew.shtml
>>
>>106953148
there is no "drama" if i don't read it.

>>106956423
DropWindowsSupportNow is just another retard who has to get the last word in to own some thread derailing faggot
>>
catmull_rom in linear light i think
>>
>>106946415
read that as mpreg



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.