Graduated from college and day one in my first real job, I was handed a hardcopy of the MPEG-2 transport stream spec and told to read it and come back with questions.
I wasn't given the spec, but I was told to see if I could solve the problem that all our 16:9 adverts were stored as 1:1.
As it was broadcast, and we had a billion different versions of the same add (localisation) it was something that needed automating, as sending it through the blasted tape machines and back to get it into 16:9 was a faff, and the digital solution cost many thousands of pounds.
So I turned to my toolset, which at the time was googling to find the full spec and spending the next few days workout out how to flip the aspect ratio bit of the mpeg2 to flip it to 16:9/4:3 depending on the metadata. I did this using perl and binary regex. It worked great, better than the commercial tools. but still not 100% correct, because it turns out a good number of mpeg2 encoders kick out non-compliant data.
This was before the days of ffmpeg's `mpeg2_metadata=display_aspect_ratio=16/9`
>I was handed a hardcopy of the MPEG-2 transport stream spec and told to read it and come back with questions.
OK, but what did you have to do on the job with the spec after reading it? Did you also have to do a codec implementation in SW or what? Don't leave us hanging.
>That's how you onboard.
Yeah, 15-30 years ago, when professional experienced SW devs weren't dime a dozen. Valve would also hire people off the street who never wrote any SW to code on the original Half-Life. But those days are long gone now, after 10+ years of "just learn to code bro" and ZIRP creating an oversupply of coders who now need to know a dozen programing languages, frameworks and buzzwords just to get a AI written rejection. Those were the days, writing SW felt like a craft, a science and a hobby at the same time.
But alas, certain jobs in EE/embedded SW still work like this. You get to read and learn a lot of source code, requirements, specs, design documents and standards, before actually building things, plus a proper (graybeard) mentor to onboard you. At least those remaining jobs that haven't yet been offshored(defense, aerospace).
I've been struggling with getting carplay to show it's alternate screen on my car's cluster display. Everything is fine for the first three seconds or so, then because apple doesn't use a nice annex-b stream (android auto's cluster display works fine), but avcc, shoving it into mpeg-ts requires some work.
Apple's encoder stops sending frames if nothing is happening on the screen, and at least my instrument cluster's h264 decoder loses sync after 3 seconds of no frames being delivered.
I've tried different kinds of filler, null ts packets, P-frames with no changes, etc. The decoder just doesn't want to resume playback when the frames start flowing again.
The real argument about Transport Stream isn't its age but unnecessary overhead. If backwards compatibility is more important than overhead, fine. But acknowledge that there is a tradeoff.
That's how you onboard.
As it was broadcast, and we had a billion different versions of the same add (localisation) it was something that needed automating, as sending it through the blasted tape machines and back to get it into 16:9 was a faff, and the digital solution cost many thousands of pounds.
So I turned to my toolset, which at the time was googling to find the full spec and spending the next few days workout out how to flip the aspect ratio bit of the mpeg2 to flip it to 16:9/4:3 depending on the metadata. I did this using perl and binary regex. It worked great, better than the commercial tools. but still not 100% correct, because it turns out a good number of mpeg2 encoders kick out non-compliant data.
This was before the days of ffmpeg's `mpeg2_metadata=display_aspect_ratio=16/9`
OK, but what did you have to do on the job with the spec after reading it? Did you also have to do a codec implementation in SW or what? Don't leave us hanging.
>That's how you onboard.
Yeah, 15-30 years ago, when professional experienced SW devs weren't dime a dozen. Valve would also hire people off the street who never wrote any SW to code on the original Half-Life. But those days are long gone now, after 10+ years of "just learn to code bro" and ZIRP creating an oversupply of coders who now need to know a dozen programing languages, frameworks and buzzwords just to get a AI written rejection. Those were the days, writing SW felt like a craft, a science and a hobby at the same time.
But alas, certain jobs in EE/embedded SW still work like this. You get to read and learn a lot of source code, requirements, specs, design documents and standards, before actually building things, plus a proper (graybeard) mentor to onboard you. At least those remaining jobs that haven't yet been offshored(defense, aerospace).
I've been struggling with getting carplay to show it's alternate screen on my car's cluster display. Everything is fine for the first three seconds or so, then because apple doesn't use a nice annex-b stream (android auto's cluster display works fine), but avcc, shoving it into mpeg-ts requires some work.
Apple's encoder stops sending frames if nothing is happening on the screen, and at least my instrument cluster's h264 decoder loses sync after 3 seconds of no frames being delivered.
I've tried different kinds of filler, null ts packets, P-frames with no changes, etc. The decoder just doesn't want to resume playback when the frames start flowing again.
Any ideas?