Hacking YouTube with a MP4(realkeyboardwarrior.github.io) |
Hacking YouTube with a MP4(realkeyboardwarrior.github.io) |
Also, it's not uncommon to get odd frame rates in the containers. Even on things as "innocent" as listing the frame rate as 29.97 vs 30000/1001 will affect timing (depending on usage). The variations on 23.976 is fun too: 24000/10001. 2997/125.
The muxer is an important step. When using software decoders, things can be a lot more flexible. Back when shiny round discs were popular, there were verifiers that ensured your muxed data was correct. When your decoders are in hardware, there is a very strict set of parameters the input is expected. Any deviation means the hardware cannot play the video. Early days of "cheaper" DVD software had issues with the muxing.
Niche knowledge really can creep up on you over the years as you gradually encounter problems and work to solve them a few hours at a time.
Nowadays it's mostly moot since MP3 is obsolete.
What should we be using instead for lossy audio?
https://www.youtube.com/watch?v=5Grsvyt5xps
The video is 22 minutes but it's reported at nearly 3 hours in length.
Just become its file size is small, does not mean it can't be 15 hours long (one of the author is takeaway is "[t]he size of a video file is not an proper indicator for how long it is": but even without this hack, you can't do that either, since video can have whatever bitrates.)
> Herbie Hancock on Miles: Don't play the butter notes!
i'm interested in learning more about the mp4 format. where can I read more? is there a canonical read that everyone but me knows about?
OP seems like he has some kind of file explorer UI for it - also interested in that
The MP4 format is fundamentally pretty easy, at least the box structure. But there have been so many standards that overlap that the MP4 format is also really messy. Aaand you need to pay to get access to the specs of the format..
> To the best of my knowledge, the impact was rather low because their transcoders are setten up in such a way that they will eventually give up on file if it takes too many resources.
In the end I just encoded them the 'correct' way, but it was eye opening to the wildness going on in video files. I just assumed I would be able to set a duration, a frame rate, and things would "work".
ffmpeg -i INPUT -map 0:v -map 0:a -enc_time_base -1 -c copy -f null -
So rather than loading the bogus videos in a sandboxed Chromium instance, you want to load them in an unsandboxed VLC instance? I smell eventual RCE.
They were hacking around with MP4 muxers and YouTube. This is definitely the hacker spirit. The word doesn't need to be re-appropriated by Hollywood caricatures.
For your average person a hacker is a person in Guy Fawks mask with a black hoodie that steals your facebook password.
For people in the industry a "hack" is a code that works but might be a placeholder/potentially dangerous code. The author would want to write a better version of it but perhaps is not able to due to time or design constraints
I don't think anyone other than HN using "hacker" in the way it mean to be, perhaps it is time to catch up with the time
I would guess YouTube will do some sort of fix or sanity check.
For example, I wrote an iTunes-in-the-browser web app; I needed to know durations of songs to display them. MP3 doesn't include these in metadata IIRC, so I needed to pre-process them with ffmpeg just to have duration data. I wasn't doing anything with that other than displaying it. But it would have been nice to just have that info in the metadata.
This jogged my memory from (part of) the first thing I ever built in a general purpose programming language, all of probably 20 years ago! I was doing exactly this: using ffmpeg to get duration metadata from MP3s.
My memory was fuzzy so I looked it up, which (surprisingly!) confirmed what I remembered. MP3s may include metadata (ID3) which may include duration (or start/end times).
I knew my input source (it was me, my music, my MP3 conversions), so I was able to rely on the metadata directly. IIRC I even processed it on demand in my first naive version, which was “slow” but not nearly as slow as stuff I’d complain about today.
I can set up a broken service, that outputs a gajillion lines of same errors to syslog, creating terrabytes of logs, zip all that into few megabytes, and that'd be a valid zip, that'd fill up most modern laptops and servers.
A surveillance camera video, with a very high frame rate when motion is detected and a very low frame rate when not (high framerate -> timelapse), can be a perfectly valid video, taking a few gigabytes in this format, and a few terrabytes when converted to fixed 60fps.
- VLC has decades of battle hardening and entirely discards all the aforementioned nonsense. In a perfect world, both Discord and VLC would be sandboxed themselves, but I accept that this world is far from perfect. Discord could at least sanitize anything that strays from a filename when passed to VLC.
- Discord is already vulnerable to crashes from multimedia. This has been a long running problem that has not been resolved by sandboxing in Electron. The folks at Discord will not be able to resolve this with code changes in Electron AFAIK. If you can crash it, there is potential for an RCE. What that RCE can effectively accomplish will entirely depend on sandboxing boundaries external to the application, not sandboxing within the application.
In reference to sandboxing, I could make a document that explains how to enable the OS wide sandboxing features of Windows 10 [1] VirtualSecureMode / DeviceGuard / CredentialGuard and Linux SELinux / AppArmor. I don't have one for MacOS. I should add, don't enable the Windows 10 security features if you depend on any virtualization outside of Hyper-V. Enabling those will break all hypervisors that don't rhyme with Hyper-V.
I should add that my solution for Discord is to not preview videos or play them in the client. I click on the links and VLC plays them but that is not the default behavior of the application.
[1] - https://techcommunity.microsoft.com/t5/iis-support-blog/wind...
Idea was that you could "grep" by specific text in the subtitles and automatically create a clip of every occurrence of the text (by looking at the subtitle timing and padding that in both directions).
The biggest source of my frustration was that I was unable to get the clipping to work exactly as I wanted, where the start or end of the clip would seemingly drift back and forth. That was until I realized it boiled down to how the different seek modes in ffmpeg handled keyframes.
I still haven't gotten the clipping to work exactly as I want but I figured doing two passes might be the way to go: first pass would do a fuzzy match and ensure there is enough extra on both ends of the desired clip and the second pass could re-encode the fuzzy-matched clip to shuffle the keyframes around, allowing more accurate clipping.
I did something similar many moons ago to auto create summary videos based on changing sentiment in the subtitles for the BBC. Worked... interestingly.
If you want to nail scene changes, one thing you can do is look for sudden changes to the histogram frame by frame. It'll change pretty smoothly as people move, cameras move etc but there's a discontinuity when there's a cut. One issue though then is that there are a lot of camera cuts! Surprising how many there are that you don't really notice.
"The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped, which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB. So, if you extract all files, you will most likely run out of space :-)"
Why recursively extract zip files? Well maybe a security tool is truing to inspect or process zip file contents
If your drive is 500GB, there is no practical difference between a 10TB log file a 10PB zip file or an infinite zip bomb... once the disk is full, the unzipping stops.
Vorbis is also notable as a better format than MP3, although that too is made obsolete by Opus.
https://sound.stackexchange.com/questions/26167/opus-vs-mp3-...