MPEG-2 Transport Stream Support

Archive of historical development discussions
Discussions / Development has moved to GitHub
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

MPEG-2 Transport Stream Support

Post by awk »

I'm looking at adding support for MPEG-2 Transport Streams to Handbrake. My initial 'take' on this is that much of the underlying stuff is all there but what's missing is mechanisms to allow the handling of MPEG-2 streams outside of the DVD Format (no .ifo files, no titles etc etc).

I'm an experienced developer (with a lot of media experience) - but I'm new to the Handbrake/MediaFork code base so it's very early days - I'm just starting, so consider this a placeholder more than anything else.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

:D
This will truly be a boon to HandBrake, awk.
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

A short update on progress so far...

I have the 'preview picture' functionality working with a sample MPEG-2 Program Stream (which I had previously converted from a transport stream). In order to get this far I had to 'tweak' some parts of scan.c (don't try and call the DVDReader functions) and reader.c (new hb_stream_read function), but thats about it - the current demux code works fine (for this stream at least). Although it's designed for 2KByte chunks it (has to - even for DVDs) handles MPEG data that spans that chunk size - so it seems good so far.

What is broken right now is audio handling - I have some chores to do here at home but I'll tackle that later tonight. I suspect my current 'hackish' attempts to force AC-3 are screwing things up and I need to actually decode the data out of the stream to set the right things.

So far so good....
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Progress

Post by awk »

So....

http://www.awkward.org/handbrake/mpeg2-ps-diffs.txt.gz

Has a set of diffs that can be applied to the current SVN head to enable MPEG-2 Program stream support. I've tried this with a few different program streams and it seems to be OK - but bug reports welcome of course !

You should be able to browse to any valid MPEG-2 Program stream file with a .mpg suffix and open it. Frame size, previews and audio track selection should all work. What you'll see in the UI is a single title with a single chapter.

Next up is .VOB format support and finally real transport stream support.[/b]
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

You are a prince among men.

Bow down before awk, people. This is huge.

Just tested the patch...applies clean with no errors, compiles clean with no errors, and successfully opens, previews, and rips.

Not sure what else you really need for .vob support--all I did was rename a .vob to .mpg and it worked swimmingly!

...anxiously awaiting .ts support... (can anyone say "HandBrakeHD" ?)
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

VOB files just needed to be renamed ?! That's a surprise ! But I'm glad it works that well. I had thought that VOB files were Program Streams with some additional headers (or perhaps private data sections). I hadn't done that much work on the subject - my plan was to leverage a (possibly private) function in libdvdread which (my memory is hazy) is something like DVDOpenVOBPath().

I'll do some testing when I get home later tonight with some .VOB files I have and see if I can see any problems - if it looks good I'll adjust the patch to handle .VOB files the same way as .MPG That's a pretty trivial change.

Transport Streams aren't too bad at all - I have code to 'liberate' the program streams from a transport stream, but right now it's a file -> file conversion which seems horribly wasteful. A much better approach would be to add reading/parsing code directly 'inline' with the the current reader functions. Not too much work hopefully.

As for HD (program streams) it might just work now - if you have some lying around give it a shot ! I'll grab one later in the week at home and give it a try.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

History in the making -- High Def in HandBrake is a reality

Post by jbrjake »

OK, this is incredibly bad ass.

I found a great open source tool called replex. It converts MPEG-TS to MPEG-PS.

Ran a 1920x1088 soft-telecined .ts sample through it. Opens in HB like a charm.

And HB encoded it, at full-resolution, without a single complaint!

(As an aside, if you want to see ugly, check out what 1080p looks like when you only give ffmpeg 1000kbps to play with.)

This is the start of a new era for HandBrake, awk. Thank you so much for this.
nightstrm
Veteran User
Posts: 1887
Joined: Fri Mar 23, 2007 5:43 am

Post by nightstrm »

This is an awesome development! Thanks for the work so far!
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

Thanks for all the kind words and encouragement !

I had thought (from the description on freshmeat) that replex only did PS -> TS and not the other way around - it's cool that it goes both ways.

It's not a lot of work to add the Transport Stream demultiplex code - I already have it written, I just need to work out how to fit it into the handbrake framework- shouldn't take too long (a few more days) then handbrake can open Transport Stream files directly.

One aspect of Transport Streams is that they can contain multiple program streams - I intend to make that visible through multiple 'titles' but that might take a little bit longer than a few days 8-) An initial implementation will probably just demux transport streams with a single program stream. If the source device providing the stream already does PID filtering and PAT/PMT rewriting that'll be fine for many people.
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

I've updated the patch referred above so that it correctly handles lengthy files (like VOBs 8-). It also now opens .VOB/.vob suffix files - no need to rename them.

There is however an apparent bug with the duration calculation code - it seems for many VOBs (other than perhaps little chapter extractions) the duration will be incorrect (often zero) which will not let you rip anything.

I'm working on the duration problem 8-)
cbud
Bright Spark User
Posts: 181
Joined: Thu Feb 22, 2007 2:24 am

Post by cbud »

awk wrote:I've updated the patch referred above so that it correctly handles lengthy files (like VOBs 8-). It also now opens .VOB/.vob suffix files - no need to rename them.

There is however an apparent bug with the duration calculation code - it seems for many VOBs (other than perhaps little chapter extractions) the duration will be incorrect (often zero) which will not let you rip anything.

I'm working on the duration problem 8-)
This might be due to timecode breaks. For MPEG Streamclip to encode certain VOBs it has to correct these breaks.
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

cbud wrote: This might be due to timecode breaks. For MPEG Streamclip to encode certain VOBs it has to correct these breaks.
My previous 'trick' for working out the duration of stream quickly was to compare the first and last Presentation Time Stamp for the first Video Stream. This seems pretty reliable for broadcast delivered program streams (though it's still not foolproof).

For DVD VOBs there are clearly timecode 'discontinuities' in the program stream - a little debugging last night showed this to be the case. I need to revisit my 'quick and dirty' find the duration approach. Unfortunately the only thing I can come up with right now is to scan the file which will take some time with feature length movies.
cbud
Bright Spark User
Posts: 181
Joined: Thu Feb 22, 2007 2:24 am

Post by cbud »

awk wrote:
cbud wrote: This might be due to timecode breaks. For MPEG Streamclip to encode certain VOBs it has to correct these breaks.
My previous 'trick' for working out the duration of stream quickly was to compare the first and last Presentation Time Stamp for the first Video Stream. This seems pretty reliable for broadcast delivered program streams (though it's still not foolproof).

For DVD VOBs there are clearly timecode 'discontinuities' in the program stream - a little debugging last night showed this to be the case. I need to revisit my 'quick and dirty' find the duration approach. Unfortunately the only thing I can come up with right now is to scan the file which will take some time with feature length movies.
MPEG StreamClip has to scan the entire VOB set. It takes less then a minute for a 6 GB set.
nightstrm
Veteran User
Posts: 1887
Joined: Fri Mar 23, 2007 5:43 am

Post by nightstrm »

That is what I did last night when testing in the IRC channel, but when I tried to load the "fixed" VOB, handbrake reported a duration of 00:00:00 and wouldnt encode, which I think is related to the second issue mentioned earlier.
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

nightstrm wrote:That is what I did last night when testing in the IRC channel, but when I tried to load the "fixed" VOB, handbrake reported a duration of 00:00:00 and wouldnt encode, which I think is related to the second issue mentioned earlier.
Yep - you're problem is still my buggy duration code, even though MPEG Streamclip may try and fix up discontinuities I think the resultant VOB is still too 'complicated' in terms of the presentation time stamps for my cheap approach to handle.

It seems more and more like scanning the file is the only way - the trick is to make it quick enough.
maurj
Regular User
Posts: 148
Joined: Thu Jan 11, 2007 5:31 pm

Post by maurj »

awk - this is a *brilliant* feature. I've been trying other tools to convert EyeTV mpeg-2 streams to mp4, but if I can use Handbrake... wow :) I'm a Handbrake developer (audio's my thing) and jbrjake is right - this is a whole new era for Handbrake :) Great stuff!

- maurj
nightstrm
Veteran User
Posts: 1887
Joined: Fri Mar 23, 2007 5:43 am

Post by nightstrm »

I agree, let me know if you need any testing help!
hawkman
Veteran User
Posts: 609
Joined: Sat Feb 17, 2007 9:46 pm

Post by hawkman »

maurj wrote:awk - this is a *brilliant* feature. I've been trying other tools to convert EyeTV mpeg-2 streams to mp4, but if I can use Handbrake... wow :)
Ditto. Now, about that better deinterlacing that was mentioned... ;)
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

I've updated the patch (and there's a little more explanatory text) at :

http://awkward.org/category/handbrake/

At this point VOB files should process - but there's a coded maximum length of 4 hours (if the VOB is less than this the true duration will be transcoded)

For now I'm moving on to Transport Streams.
kogyaru
Posts: 25
Joined: Sat Apr 14, 2007 1:29 am

Post by kogyaru »

Hiya awk,

I've just applied your patch to the 503 rev, and it applied fine with one hunk failing (deca52.c). jbrjake mentioned he fixed that.

The patch correctly reads in VOB files, either named .vob or .mpg, but it doesn't seem to work with SVCD .mpg files. I'm interested in that as I've got a considerable archive of SVCDs.

Here's the `mpgtx -i` output of the target SVCD file:

Code: Select all

  Mpeg 2 Program Stream File [Video/Audio]
  Muxrate : 3.16 Mbps
  Estimated Duration: 15:20.15s
  Checking all time stamps (This may take a while.) ...
  Time line seems to be ok.
  Aspect ratio 4/3 (TV)
  Interlaced, chroma format: 4:2:0
  Size [480 x 480]     29.97 fps    2.52 Mbps
  Audio : Mpeg 1 layer 2
  192 kbps  44100 Hz
  Stereo,  No emphasis
Here's what I see when trying to read it in with HB using the following invocation:

Code: Select all

hb -v -i test-svcd.mpg -o test.mp4 -d -b 1500 -B 160

Code: Select all

[21:26:58] hb_init: checking cpu count
[21:26:58] hb_init: starting libhb thread
[21:26:58] thread -1211147344 started ("libhb")
HandBrake 0.8.0b1 (20070211) - http://handbrake.m0k.org/
4 CPUs detected
Opening test-svcd.mpg...
[21:26:58] hb_scan: path=test-svcd.mpg, title_i
[21:26:58] thread -1219540048 started ("scan")
[21:26:58] scan: trying to open with libdvdread
[21:26:58] dvd: DVDOpen failed (test-svcd.mpg)
[21:26:58] scan: trying to open as MPEG-2 Program Stream
[21:26:58] scan: id=80bd, lang=English (AC3), 3cc=eng
[21:26:58] scan: decoding previews for title 0
[21:26:58] scan: preview 1
[21:26:58] hb_demux_ps: not a PS packet (d4db38c9)
[21:26:58] hb_demux_ps: not a PS packet (fb0ddd5d)
[21:26:58] hb_demux_ps: not a PS packet (f98268a1)

...snip ~10,000 lines...

[21:26:58] hb_demux_ps: not a PS packet (3e4921de)
[21:26:58] scan: could not get a decoded picture
[21:26:58] thread -1219540048 exited ("scan")
[21:26:58] thread -1219540048 joined ("scan")
[21:26:58] libhb: scan thread found 0 valid title(s)
No title found.
[21:26:58] thread -1211147344 exited ("libhb")
[21:26:58] thread -1211147344 joined ("libhb")
HandBrake has exited.
Any clue?
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Post by awk »

Well.... it looks like the SVCD format isn't quite as standards compliant as the code expects (in fact it might be quite different I'm not familiar with it at this point).

If you have a short example (a few 10s of megabytes) I can take a look at it once I've completed the Transport Stream stuff.

I just gave the wikipedia page on SVCD a read and it's possible that even if the stream/file issues are resolved it may still not transcode due to the framesizes - a codec expert would have a better clue if one is reading.
kogyaru
Posts: 25
Joined: Sat Apr 14, 2007 1:29 am

Post by kogyaru »

Try this one:

(url removed)

It's 31.5 MB and has the following characteristics:

Code: Select all

  Mpeg 2 Program Stream File [Video/Audio]
  Muxrate : 2.71 Mbps
  Estimated Duration: 01:34.20s
  Checking all time stamps (This may take a while.) ...
  Time line seems to be ok.
  Aspect ratio 4/3 (TV)
  Interlaced, chroma format: 4:2:0
  Video Format: NTSC
  Size [480 x 480]     29.97 fps    2.52 Mbps
  Audio : Mpeg 1 layer 2
  224 kbps  44100 Hz
  Stereo,  No emphasis
I'm able to demux the SVCD in ffmpegX, transcode the MP2 audio stream to AC3, and mux it into a DVD structure which HB can then handle. But it would be nice to skip those three steps!

I'll leave the SVCD link up for a week.
Last edited by kogyaru on Sat Apr 28, 2007 4:03 pm, edited 1 time in total.
awk
Regular User
Posts: 109
Joined: Sat Mar 31, 2007 11:55 pm

Transport Streams Update

Post by awk »

It's been a while (other things interjecting in my priorities 8-), however I've made some progress on the Transport Stream front.

I've 'welded' my transport stream parsing code into handbrake and have it working to at least generate previews (I'm doing a test transcode now0. However it needs some 'clean up' before I can prepare a real patch - it'll probably be a couple more days.
nightstrm
Veteran User
Posts: 1887
Joined: Fri Mar 23, 2007 5:43 am

Re: Transport Streams Update

Post by nightstrm »

awk wrote:It's been a while (other things interjecting in my priorities 8-), however I've made some progress on the Transport Stream front.

I've 'welded' my transport stream parsing code into handbrake and have it working to at least generate previews (I'm doing a test transcode now0. However it needs some 'clean up' before I can prepare a real patch - it'll probably be a couple more days.
I can't wait to be able to run my .ts files through Handbrake and get a AppleTV-compatible file with DPL2 audio. Can't wait to test it out!
maurj
Regular User
Posts: 148
Joined: Thu Jan 11, 2007 5:31 pm

Post by maurj »

Hi awk,

Just wanted to say: as a HandBrake developer, this is the feature I'm most interested in for the next version :) I've got a bunch of mpeg2 transport streams from my EyeTV, and if I play them as-is on my Apple TV then they come over all interlaced and icky. I need to transcode them to mp4, with deinterlacing, and I really want to use HandBrake for the job. So good luck with your integration, and I look forward to using it!

- maurj
Post Reply