Page 17 of 70 FirstFirst ... 715161718192767 ... LastLast
Results 241 to 255 of 1041

Thread: MUX'ing, VSplit, and MPG2 files.

  1. #241
    Join Date
    Jun 2002
    Location
    here, there, everywhere
    Posts
    190
    looking at mplex and....

    vbr only does a few things in the multiplex code (that I can see).

    first, theres a method call RunInSectors. the comment follows:

    /*
    * Compute the number of run-in sectors needed to fill up the buffers to
    * suit the type of stream being muxed.
    *
    * For stills we have to ensure an entire buffer is loaded as we only
    * ever process one frame at a time.
    *
    */


    in which there's a if statement for computing sector_delay:

    else if( vbr )
    sectors_delay += 3*(*str)->BufferSize() / ( 4 * sector_size );
    else
    sectors_delay += 5 *(*str)->BufferSize() / ( 6 * sector_size );


    not sure what the meaning of the math is, but hopefully it'll make sense to someone.

    then later in the code they create sys_headers. not sure whats going on here. I need to look at it more.

    then in the OutputMultiplex method, theres a big if statement again about vbrs.
    comments are:
    //
    // If we got here no stream could be muxed out.
    // We therefore generate padding packets if necessary
    // usually this is because reciever buffers are likely to be
    // full.
    //


    code is about 10 extra lines. seems to be about judging how to do the output padding for vbr.
    check out line 986 of multplex.cc


    seems worthwhile for someone w/ mpg knowledge to look into this a little more. there's plenty of comments in this code.

    -lloyd-

  2. #242
    Join Date
    Jan 2002
    Posts
    4,809
    The frustration with source code like that is that what is being produced is wrong. Why is it wrong? Who knows. Where is it wrong? Again who knows...

    I use PowerDVD, as I mentioned, to play these things. Is it the source of some of the problems? Again who knows... What I need is setup that we can all agree works so I can start lifting information from it. But no one really seems to have one. I know I don't. I have had so many codecs come and go on this machine that MediaPlayer is dodgy at best these days.

    --jdiner

  3. #243
    Join Date
    Feb 2002
    Posts
    54
    You could always try zoomplayer and build your own graphs to control exactly which codecs get used - if you think that's really an issue.

    I've done it in the past to troubleshoot crazy dshow type things.

  4. #244
    Join Date
    Feb 2002
    Posts
    54
    jdiner:

    Just a shot in the dark, but do you have the tmpgenc vfapi plugin setting that takes over playback of mpeg2 related things turned on?

    It could possibly explain why tmpgenc output plays back the 'best' for you.

    I'd rate this one as a one in a million shot, but I figured I'd mention it.

  5. #245
    Join Date
    Jul 2001
    Posts
    657
    Originally posted by jdiner
    ...
    I use PowerDVD, as I mentioned, to play these things. Is it the source of some of the problems? Again who knows... What I need is setup that we can all agree works so I can start lifting information from it. But no one really seems to have one. I know I don't. ...
    --jdiner
    I think I do...

    From my dtivo running 2.5.1,
    I use Tytool to extract.
    I use vsplit13c to process.
    I use Tmpgenc to simple mux.

    I never use any offset value to "re-sync". I just mux 'em as vsplit spits 'em out.

    Other than when I try to do frame accurate edits(gop edits with Tmpgenc's merge and cut are fine), I never have a sync problem at all with any file from my dtivo. I haven't since the arrival of vsplit-x.

    I use windvd 3 and 4 and hollywood station to view, as well as an apex 1100w.

    No sync probs at all.

    Other than the occasional bad rip(due to reasons stated in earlier posts), I am working at almost 100%.

    Am I just the lucky one? Did I simply luck into "The Setup That Works"???!??!?!

    or am i just hosed and missed the point entirely?

  6. #246
    Join Date
    May 2002
    Posts
    134
    You're not the only one - I know several people who follow that process (the only thing I do differently is that I use TivoApp to extract...other than that I'm identical to you) and have no problems whatsoever. I believe that Jdiner has the vsplit down-pat, and is now working on a Muxing component that will allow us to eliminate that last step as well.

    If we could get the muxing figured out through TyTool/Vsplit/Whatever and just find a frame-accurate way of SIMPLY removing commercials I'd be ready to start burning my MacGyver's to DVD and fulfill my promise to Jdiner (I promised that when we got Muxing and a way for me to simply edit out the commercials and therefore create DVD's with shows on them, I'd burn the entire MacGyver series for Jdiner onto DVD). I'm a man of my word, so as soon as we get to that point I'm ready to rock. I just don't relish spending weeks of my time muxing and editing several hundred gigs of .TY files!

    Originally posted by Fugg
    I think I do...

    From my dtivo running 2.5.1,
    I use Tytool to extract.
    I use vsplit13c to process.
    I use Tmpgenc to simple mux.

    I never use any offset value to "re-sync". I just mux 'em as vsplit spits 'em out.

    .....

    Am I just the lucky one? Did I simply luck into "The Setup That Works"???!??!?!

    or am i just hosed and missed the point entirely?

  7. #247
    Join Date
    Jan 2002
    Posts
    4,809
    Ok. Here is what I have discovered and here is what is going on.

    Mux'ing is most definately possible. But VBR streams are as near as I can tell seriously under-documented. I have thought about buying the latest and greatest docs from the ISO group but at $145 for just the one file I want to try and make sure that it will cover what I am looking for first.

    As near as I can tell almost everyone does VBR mux'ing wrong. And here is why...

    Let's start first with a description of mux'ing and how mpeg-2 works as a system, i.e. Program Stream. There are 0 or more Video Elementary Streams and 0 or more Audio Elementary streams. Each of these streams has a series of PTS/DTS values associated with it. It should be decoded at a certain time and should "played", i.e. presented, at a certain time. For audio there is only a presentation timestamp. For video there is both for an I or P frame and only a PTS timestamp for a B frame. The reason for this in video is the "this frame is based off of these other frames" method of compression. Just trust me that this is what is going on and that it is both needed and works.

    I figured out a long time ago how to create these PTS and DTS values for both audio and video. To be quite honest it was simple once I stepped back and started thinking about it.

    For audio you get a PTS every 24ms or 32ms or... Basically I just lift these values from the TyStream. You should at some point have noticed that at the top of the output from VSplit/TyTool is "stream" information. One of the fields is what this timestamp offset is. So I just use it and all is well. Infact I got a bit "better" for Dolby Digital and I calculate each frame off of each audio packet, since they change size and therefore duration.

    For video you calculate them off of 29.97 FPS for NTSC and 25 FPS for PAL. Again this is simple arithmatic and is ease to generate. A wide variety of tests both by myself and others on the forum have shown that this part works.

    Now we get to the last past. And this is where things are still... wonky. Mostly because I can find no clear definition of how to do it correctly to match the MPEG spec...

    Each of these streams works on a different base clock. You have all seen this. Think about it... When you VSplit the TyStream file you get seperate audio and video files. Then VSplit dumps out at the end a print out of "how far off" these 2 are from each other. Sometimes it is 0ms, sometimes it is 1-4 and sometimes it is 16-17ms off. Each clock, or timestamp starting point, is completely valid because they are completely seperate from each other. If you have 2 audio streams it would be perfectly legal to have one and -16ms from the video and one at 16ms...

    So... at long last the key is HOW??? does mpeg-2 really synchronize them. Rather than lining them all up to one of the Elementary Streams (ES) it lines them up to a non-stream releated clock, the System_Clock_Reference (SCR). This SCR value is really a measure of how many bytes have gone through the system based off of some simple calculations. Simple at least for a CBR system. As my sister would say... "Let me break it down for you Fred..."

    The SCR is based off of an expected data rate.

    Code:
      mux_rate = (video data rate +audio data rate)(1+packet header +pack header * packs/packet)/data
    
    				20 + 12/3
      mux_rate = (150 000 + 24 000)(1 + -------------- )
    				  2 028 
    
      mux_rate = 176 059 bytes/sec
    This mux_rate value is quite literally how many bytes should go by during a second of playback. 150,000 bytes of video data, 24,000 bytes of audio data, and a 20 byte pack header with a PES packet header, and so on. Giving a grand total of 176,059 bytes per second.

    This value used with the number of bytes that have "gone past" are used to generate the SCR value put in each PACK header. For CBR data this is correct. I built a counting tool and each pack is off by no more than about a 1000 bytes in either direction. So the timestamps line up nicely.

    Now using that same counting tool, I ran a bunch of VBR streams through it. Average data rates... Anywhere from 90,000 bytes/sec to 700,000 bytes/sec...

    I hope you begin to see the problem. Things just don't line up. After having observed this the one comment I have seen that applies to all of this is... "Using VBR things are no longer linear". I believe this came from the bbmpeg source itself.

    contiuned....

  8. #248
    Join Date
    Jan 2002
    Posts
    4,809
    Continued here...

    Now if they are not linear how and when do you determine that the SCR value need to be changed or set and then set to what? I don't know at present.

    One thing I can tell you is that if it is wrong it causes jerky playback. And the reason why is obvious. If the central clock counts from 1 to 2 ... to 5 seconds but the PTS value for the next video frame is at 4 seconds, it is skipped, in favour of catching up with the next frame. And vice versa... If you are at 6 seconds for the PTS value and the SCR is at 5 it is "held" until you catch up. Slight milisecond fluctuations are common during playback and not a problem. But in timing things I have occasionally seen them be off by over a second. Very noticable...

    So all we need to be done with mux'ing is to figure out how to generate a proper SCR value from the VBR data.

    So your mission should you choose to accept it, is look for docs newer than mine (ISO 13818-1 for me is from Nov. 1994 and has nothing about VBR in it), or a book that describes it... Or (fill in the blank here...) that will give me some clue.

    Source is not a bad thing. But the problem is that it needs to be working source. My own testing has shown that mplex. bbmpeg, etc... simply aren't doing it right. Some codecs play them back but in looking into it and reading up on groups.google.com many PC codecs ignore the SCR and just sync audio to the video. This is easier. Much much easier but again from what I have read most likely won't work on a standalone player that is really doing it right.

    --jdiner

  9. #249
    Join Date
    Jan 2002
    Posts
    4,809
    I supose I should have pointed out the rest of the SCR formula. It is basically:

    Code:
    scr_increment = #byte_gone_past * mux_rate * clock_freq / 50
    Thus if 2048 bytes have gone by you get a fraction of a second increment. If the full 170k or 300k or 700k or whatever has gone by then you see a full second increment in the SCR.

    When in CBR mode this is simple and straight forward. But in VBR... it is not. I have tried a few brute for methods and have thought about a few more ways.... Basically pool up a full second of video, however much it is, and then write out packs that use the right mux_rate values for that block.

    But as near as I can tell this value can and should be calculatable. i.e. some formula is used to spit things out. But who knows... I am open to any and all suggestions.

    Hopefully this description helps people in some fashion. I have what I think is a solid handle on mux'ing and how and why it is done. But I am definately missing this one last piece... However if you are certain I am wrong about something then please let me know, and I will refine things as needed.

    --jdiner

  10. #250
    Join Date
    Jun 2002
    Location
    Was Frozen North now Sunny South
    Posts
    351
    Well, I for one think you should concentrate on the "known quantity" first, i.e. CBR SA Tivo streams, to get a solid base to work from, and to prove that muxing can work. But then maybe I'm prejudiced... (how to erase my sig on-the-fly?)
    Philips Standalone v3.01 w/2-80G drives and Tivonet.

  11. #251
    Join Date
    Dec 2001
    Location
    Seattle, WA
    Posts
    174
    Well Jdiner, I'm confused. By your explination CBR should be easy and all working. This is not the case for any SA CBR streams I have. Am I missing something?

  12. #252
    Join Date
    Jun 2002
    Posts
    34
    I deal with MPEG-2 transport streams on a daily basis, and while I don't get my hands deep into them, I can say for a fact that:

    - With transport streams, there is a program clock reference (PCR) field that is analogous to the SCR field.

    - The system I deal with generates its own 27 MHz clock through a DCXO hooked up to a PLL. The clock drives about a billion things, including system time clocks (STCs) in the demux and decoder.

    - Since the 27 MHz timebase from the onboard crystal is almost definitely not in sync with the 27 MHz timebase of the stream, we have a task that compares the difference between received PCR and the demux STC and adjusts both the demux STC and the DCXO to "lock" the STC to the incoming PCR.

    - When the demux STC is written to, the decoder STC is also written to, and since both operate off the same clock, they are generally the same.

    - The demux doesn't do anything with its STC besides update it. It demuxes transport stream data as it receives it. The decoder, on the other hand, is charged with synchronizing the PTSes in the PES packets to its STC. This is how the decoder enables audio/video synchronization. (The decoder also decodes elementary streams directly, but I'm not sure how it maintains synchronization there, except by calculating presentation timestamps on the fly from the frame rate specified in the headers.)

    So my gut feeling is this: the PTS values should increase at a constant or near-constant rate. Based on that, it should be possible to calculate an appropriate SCR and bitrate such that the decoder buffers completely contain the frame at or just before it is to be decoded. What I'm saying is that I think SCR is tied to the PTS. In CBR streams you get away with just increasing SCR on its own because the data rate is constant, but in VBR streams you can't and so you have to find some other temporal reference to use as a base.

    Unfortunately, the MPEG-2 transport streams I work with are ALSO CBR in general, so I can't just rip data direct from the demux queues and print it out in large quantities.

  13. #253
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by laserfan
    Well, I for one think you should concentrate on the "known quantity" first, i.e. CBR SA Tivo streams, to get a solid base to work from, and to prove that muxing can work. But then maybe I'm prejudiced... (how to erase my sig on-the-fly?)
    well. Now see the problem is this. I have both tivo's and what I want for me right now is the DTivo stuff... I am using VirtualDub to make AVI's from the SA Tivo stuff. Hummm. We'll see.

    --jdiner

  14. #254
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by FreydNot
    Well Jdiner, I'm confused. By your explination CBR should be easy and all working. This is not the case for any SA CBR streams I have. Am I missing something?
    Yeah. You are missing my mux'ing engine. <-- Ok I honestly could not resist... I can't speak for the other programs out there. And to be honest I should back pedal a bit and warn that mine is not necessarily perfect yet either. But in a couple of initial tests things start sync'ed and stay there through four 5-minute clips. Which is more than I was getting from anything else. And I have had one full 1 hour clip make it start to finish. But that has been it for my testing todate.

    Also I am not referring to the older stuff I released a few months ago. What I am talking about is now about 24 hours old... More tests to come and then a release here for people to look at and try themselves. But sadly it is a bit of a pain. If something is wrong figuring out how or why is a challenge.

    --jdiner

  15. #255
    Join Date
    Dec 2001
    Location
    Montreal, Canada
    Posts
    288
    i say we all chip in 5$ so you can buy that newer manual
    from the ISO group.

    I mean this is so frustrating for some of us that we don't
    care what it costs anymore.

    I was using Honestech MPEG Editor v4.0 to edit out the
    commercials from The Real World : Las Vegas season
    premiere when i saw that it created perfectly synced
    MPEGS out of the TMPGEnc muxed MPEG. Problem was
    that i could only produce 5 Minute clips in the demo
    version. So i bought the full version and turns out that
    it did a great job for the 1st 45 minutes of the show
    but the last 15, it couldn't keep the sync at all.

    VERY frustrating... I was all ready to come brag on the
    board that i found the perfect editor but it is a great
    editor only if everything is kosher.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •