> >>>Uhm, extract_mpeg2 it's already pretty a barely-readable hack, so I'm not >>>enthusiast to going on hacking it even more. >>>Neverthless, your proposal looks reasonnable, so I'll apply it during >>>weekend. >> >>The hack consisyts of adding a few extras to a switch statement. > > That's not the problem. The problem is that none of us know _why_ it >only goes up to 0xE9. Maybe the person who wrote it simply hadn't read the >spec; on the other hand, maybe there are some streams out there that use >0xEA..0xEF for non-video things, and the code was deliberately limited to >0xE9 to avoid Bad Things happening with such streams. What Francesco's >saying (and which I agree with) is that he's reluctant to change it without >knowing why it was written that way in the first place. >
I can tell you why it only goes up to 0xe9. Because hardly anyone, and certainly nobody who uses transcode on Linux which is a tiny minority to start with, has encountered a video stream with a stream id greater than 0xe9!! That would seem quite obvious wouldn't it? Anyhow, if you like you can just sit back and wait until some possibly deceased person comes along and tells you why it was written that way. Or you can be a tiny bit more proactive, and first figure out what the specs say, make the conforming changes, then get a whole bunch of test files (which obviously already exist in abundance because you test your software very thoroughly after every change dont you) and run tests and see what breaks. If nothing breaks then you have made the right decision and progress can resume. If something breaks then the problem is probably that the thing that broke doesn't conform to the specs anyhow and should be ignored. Make your choice. I have made mine. But it sounds very much to me that I am preaching to somebody who doesn't have much of a clue about software development - viz Bad Things! No wonder the transcode stuff is so crappy.
