Hacker Newsnew | past | comments | ask | show | jobs | submit | AkBKukU's commentslogin

> Killing some processes to free up memory

This section is disregarding a key lore element, the inhabitants of the grid are programs. Killing a process in this context more likely has an interpretation of an attempt to stop an individual such as the villain Clu. I would say an alternative explanation is is more story based, with Kevin Flynn trying to stop Clu from the outside world but being unable to and instead taking the last resort of entering the grid when he knows it would be dangerous.


That's a good idea, but remember that, up until CLU's outright betrayal, Kevin had no reason to be concerned, and after it, he had no way back into meat space to run those commands.

Also -- unrelated, but a nitpick of the article -- Kevin was using the laser to come and go from the grid for a while before he got stuck there. The laser would have been pretty well-tested by the time he made/edited the last will and testament, so the article's explanation that it was his first use of the tech doesn't make sense. (He could have just spontaneously decided to update it though, which isn't too far fetched)


> can't afford to pay one for whatever business I have

At small scales what "art" does your business need? If you can't afford to hire an artist (which is completely fine, I couldn't for my business!) do you really need the art or are you trying to make your "brand" look more polished than it actually is? Leverage your small scale while you can because there isn't as much of an expectation for polish.

And no, a band poster doesn't have to be a labor of love. But it also doesn't have to be some big showy art either. If I saw a small band with a clearly AI generated poster it would make me question the sources for their music as well.


I've been editing on linux with resolve since the launch of the BMPCC4K in 2018, were you trying to import MP4 footage? BMD can't be bothered to pay for the AAC audio codec for linux users even if they buy studio. So if you pay for studio you can read the h264 video stream but not the AAC audio. I end up converting everything to MOVs with pcm_le16 audio as a workaround.

The ALSA issues are beyond aggravating at this point. You do not want to actually run ALSA directly, you need it to connect to pulseaudio on 24.04. But I still have never been able to record audio within resolve. I've had mixed luck on newer wayland+pipewire setups with having to install the bridge packages to connect the different backends. Linux audio is cursed on its own so I don't fully blame BMD.

I exclusively run Kubuntu and have been using makeresolvedeb[1] for installing resolve and it has been pretty good.

[1] https://www.danieltufvesson.com/makeresolvedeb


> Some games are designed around content and "extraction". Many are not.

While I think the parent post leaves a lot of open ended questions, I think they are spot on about the tightness of design in games.

In many open world RPGs, or something like GTA, you cannot open every door in a city. In street fighter you can't take a break to talk to your opponent. In art games like Journey you cannot deviate from the path.

Games are a limited form of entertainment due to technical and resource restrictions, and they always will be. Even something as open ended and basic as minecraft has to have limits to the design, you wouldn't want the player to be able to collect every blade of grass off of a block just because you could add that. You have to find the balance between engaging elements and world building.

Having a LLM backed farmer in an RPG that could go into detail on how their crops didn't grow as well last season because it didn't rain as much seems good on paper for world building. But it is just going to devalue the human curated content around it as the player has to find what does and does not advance their goals in the limited time they have to play. And if you have some reward for talking to random NPCs players will just spam the next button until it's over to optimize their fun. All games have to hold back from adding more so that the important parts stand out.


> Yes - some things go out of fashion for a while, but trends almost always cycle back.

Exactly, this is even supported by Nintendo's own services offering emulation of their older systems. There is clearly demand for the ability to older games.

Capitulation to an "inevitable" fate of download only games is just taking the easy way out by not sticking to your own core values. I have personally pre-ordered a Switch 2, but I will not being purchasing any online only cartridges or download only software.

We haven't had the watershed moment that brings it into focus for gamers at large yet, The Crew was close. But Nintendo has kept the download servers going for all of their systems which has provided a false sense of security. Once those start being shut down maybe we'll see some actual response. Though with the introduction of Gamecube emulation on the Switch 2, they are only a small step away from emulating the Wii and giving people another scapegoat for their lazy acceptance of lack of ownership.


This was decided in court[1] over two decades as acceptable fair-use and that thumbnail images do not constitute a copyright violation.

[1] https://scholar.google.com/scholar_case?case=137674209419772...


I have a project that uses a proprietary SDK for decoding raw video. I output the decoded data as pure RGBA in a way FFMpeg can read through a pipe to re-encode the video to a standard codec. FFMpeg can't include the Non-Free SDK in their source, and it would be wildly impracticable to store the pure RGBA in a file. So pipes are the only way to do it, there are valid reasons to use high throughput pipes.


What percentage of CPU time is used by the pipe in this scenario? If pipes were 10x faster, would you really notice any difference in wall-clock-time or overall-cpu-usage, while this decoding SDK is generating the raw data and ffmpeg is processing it? Are these video processing steps anywhere near memory copy speeds?


So pipes are the only way to do it

Lets not get carried away. You can use ffmpeg as a library and encode buffers in a few dozen lines of C++.


The parent comment mentioned license incompatibility, which I guess would still apply if they used ffmpeg as a library.


If the license is incompatible, it would still be incompatible regardless of whether you use library API calls or pipes.


And you go from having a well defined modular interface that’s flexible at runtime to a binary dependency.


You have the dependency either way, but if you use the library you can have one big executable with no external dependencies and it can actually be fast.

If there wasn't a problem to solve they wouldn't have said anything. If you want something different you have to do something different.


The context of this discussion is that it would be better if pipes were faster. Then you would have more options.


I replied to them saying "So pipes are the only way to do it".


ffmpeg's library is notorious for being a complete and utter mess


It worked extremely well when I did something almost exactly like this. I gave it buffers of pixels in memory and it spit out compressed video.


What about domain sockets?

It's clumsier, to be sure, but if performance is your goal, the socket should be faster.


It looks like FFmpeg does support reading from sockets natively[1], I didn't know that. That might be a better solution in this case, I'll have to look into some C code for writing my output to a socket to try that some time.

[1] https://ffmpeg.org/ffmpeg-protocols.html#unix


Why should sockets be faster?


Sockets remap pages without moving any data while pipes have to copy the data between fds.


Why not just store the output of the proprietary codec in an AVFrame that you'd pass to libavcodec in your own code?


At some point, I had a similar issue (though not related to licensing), and it turned out it was faster to do a high-bitrate H.264-encode of the stream before sending it over the FFmpeg socket than sending the raw RGBA data, even over localhost… (There was some minimal quality loss, of course, but it was completely irrelevant in the big picture.)


> There was some minimal quality loss, of course, but it was completely irrelevant in the big picture

But then the solutions are not comparable anymore, are they? Would a lossless codec instead have improved speed?


No, because I had hardware H.264 encoder support. :-) (The decoding in FFmpeg on the other side was still software. But it was seemingly much cheaper to do a H.264 software decode.)


H.264 has lossless mode.


Look into the Domesday Duplicator project for Laserdiscs as an example of how what ssl-3 is talking about can be done using a high sample rate input. That exact process is possible and with enough storage and processing power can be used to get the most "low level" access to the data. It is not for the faint of heart though, and can take around 1TB of storage and hours of CPU time to process full movies in this way, I know because I've done it.

I believe I've seen there is work being done to attempt this on CDs but it would have still been in the exploratory phases and not yet ready to start archiving with. It might seem like overkill to do this to something meant to be digitally addressed but I've experienced enough quirks with discs and drives when ripping that I would 100% be willing to switch over to a known complete capture system to not have to worry about it anymore. Post process decoding also allows for re-decoding data later if better methods are found.


Even BIN/CUE is not enough. It cannot store subchannel data like CD+G and is only able to hold a single session which breaks bluebook CDs with audio and data.

We do not currently have a widely supported CD standard for storing data from a CD that can properly hold all data. Aaru [0] is close, but still has to output back to other formats like BIN/CUE to use the contents of the disc.

[0] https://www.aaru.app/#/


I'm curious if you have a specific example of an album with the crowd noise between tracks like that? I collect and rip hundreds of CDs and am always on the look out for edge case discs to further hone my tools.

On your pregap + 99 indexes remark, the "pregap" is the space between index 00 and 01 which continues on up to index 99. Players seek to index 01 as the start point of the track. There is no separate pregap designation. I've paid special attention to this because it is a difficult problem to solve as many discs have space between tracks stored in index 00-01 but rarely is there anything audible in there after the first track. The only example I have of this is a specialty music sample disc, Rarefaction's A Poke In The Ear With A Sharp Stick, that has over 500 samples on the disc accessed by track + index positions.

As a sidebar based on the later comments in the thread, I've made it a habit to rip and store every audio CD as BIN/CUE+TOC using cdrdao. This allows me to go back and re-process discs I may have missed something on. But that is imprecise even because it usually breaks bluebook discs with multiple sessions to store data due to absolute LBA addressing. Also the ways different CD/DVD drives handle reading data between index 00-01 on track 1 is maddening. Some will read it, some will error, and the worst is those that output fake blank data.


>I'm curious if you have a specific example of an album with the crowd noise between tracks like that? I collect and rip hundreds of CDs and am always on the look out for edge case discs to further hone my tools.

E.g. the Japanese version of Flying Lotus' album "Until The Quiet Comes" has a pregap of 5 seconds before the 19th track, to separate it from the rest of the album, as it's a Japanese-exclusive bonus track.


Is it crowd noise or just a gap? I'm also interested to see one of these skipable crowd noise CDs.


Not sure why I didn't think to mention this before: One tool you might consider is redumper, it's designed in particular to handle multisession CDs, and it attempts to over-read into the disc lead-in and lead-out to catch data outside of the range covered in the TOC (particularly common in older CDs). It only outputs a final split bin+cue, but everything read, including scrambled data, toc, and subchannel/subcode, is saved for future processing. The bin+cue can be used with ISO Buster (and probably other tools) to access Enhanced CD filesystems. Feel free to reach out if you need some tips, this is what I use for my collection.

https://github.com/superg/redumper/

Caveat: It is mostly intended for use with the low-level features of Plextor drives, so CD support on other drives is relatively limited; in particular it doesn't have any overlapping read paranoia-style features. The recommendation is to dump twice to confirm; it's running straight through without seeking so that's usually still quite fast.


Seven minute pregap on disc 1 track 4 of https://vgmdb.net/album/5549 , it's a whole long discussion between songs, with some audience cheering. VGMdb follows the "append pregap to previous track" convention, that's why track 3 looks so long. There's similar but shorter gaps with banter on tracks 2 and 7.

Cuesheet looks like:

    TRACK 04 AUDIO
      INDEX 00 00:00:00
      INDEX 01 07:34:43
Edit: Probably covered by your sfx disc, but this one has 17 indexes on track 1: https://vgmdb.net/album/3091

That messed with a tool that only anticipated one index in track 1 for detecting hidden pregap audio, cuesheet is like:

    TRACK 01 AUDIO
      INDEX 00 00:00:00
      INDEX 01 00:00:37
      INDEX 02 00:11:40
      INDEX 03 00:37:33
      ...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: