So, a teaser first:
With GNU Radio, you can transmit various DVB standards. Here's Alexandru Csete demoing his DVB-S2 transmission:
As you can see from the FFT Plot generated by the flow graph in the upper picture, some 7MHz of bandwidth would be sufficient for this transmission mode – the HackRF should, like the device Alexandru used, be able to deal with the 10MHz that this flowgraph ran at.
The input is really just an MPEG transport stream file that's compatible with the DVB-S2 specs. You can find a lot of these at W6RZ Ron Economos' website, who's the main author behind gr-dtv. File source doesn't sound that great – but really, MPEG transport streams like this are meant to be streamed, and you can just replace that file in the file source with a named pipe and pipe the output of your MPEG encoder to it, or maybe just the MPEG transport screen you grabbed off the air from another broadcast. Also, because GNU Radio is so flexible, you could just replace the file source e.g. with a UDP source, and let another computer stream MPEG to that, in case your computer isn't up to SDR reception of video, reencoding and SDR modulation. That's is a handful of things even for fast PC workstations!
I'm going to go ahead and shamelessly plug GNU Radio here: If you haven't heard about it, it is a Software Defined Radio framework. It's based on the idea of signal processing flow graphs, in which (as you can see in the upper screenshot) you connect blocks that contain functionality to a bigger, useful application. Such blocks can be simple things like "multiply signal with a constant value", or more complex things like a DVB-S2 modulator, or they can also be hardware interfaces (the osmocom Sink in the screenshot talks to your SDR device). You're also not limited to existing blocks: writing blocks that do things that aren't possible by combining existing blocks is easy, and there's a whole ecosystem of people writing modules for GNU Radio.
Without further ado: GNU Radio's website and the Guided Tutorials, which I strongly recommend.
Generating an FM receiver takes minutes from scratch if you went through them, which shouldn't take too long, either.
I'm fully aware that SSTV with let's say 48kHz of sampling rate isn't really comparable to DVB-S2 with Megahertzes of bandwidth, but to answer your original question:
Could DVB-T be used with reduced parameters, thus smaller bandwidth?
You can configure gr-dtv's DVB-T (contained in the standard GNU Radio source code) for smaller bandwidth than what is used in above example, no problem. The lowest standardized (and hence, decodable by anyone) bandwidth is 5 MHz.
DVB-T is an OFDM-based transmission standard, and has a lot of channel coding. That makes a lot of sense, because it's designed to carry high-datarate bitstreams, and thus, by Shannon's Channel Capacity, needs a large bandwidth for a limited SNR. High bandwidth means that the channel response isn't "flat", ie. attenuation and rotation aren't the same for all frequency within that bandwidth. You need an equalizer to counter that at the receiver – equalizers are hard to do right, and even harder to implement fast, and so standards like DVB, IEEE802.11a/g/n/p (WiFi), LTE… take the channel and divide it into small subchannels with a DFT (the frequencies in the DFT don't cross-talk, hence the "O" in OFDM, Orthogonal Frequency Division Multiplex). That way, you get a lot channels, but each of those is flat, so equalization is really just one independent correction factor per subcarrier.
If you reduce the bandwidth of OFDM a lot, you lose that advantage, and also get into SNR problems (signals within a small bandwidth necessarily have less energy than signals of the same spectral density in a larger bandwidth), so I'm not sure that scaling DVB-T below let's say 2MHz would work.
