Page 20 of 70 FirstFirst ... 10181920212230 ... LastLast
Results 286 to 300 of 1041

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

  1. #286
    Join Date
    Jun 2002
    Location
    Silicon Valley, CA
    Posts
    199
    Originally posted by jdiner
    For those that have not made a respository of 5min clips. Please take a few minutes to do so. For those that intend to test the new mux'ing code. It is going to be crucial that you test on the same clips in the same way every time. That is why I really do want people to use TyFileSplit and make new smaller TyStream files.

    Just to confirm, we need a set of clips that have NOT YET BEEN PROCESSED.
    It's no use having .m2v and .m2a files that have already been vsplit - right?
    SVR 2000 running 3.0 with 1x160Gb and Lifetime Sub
    SAT-T60 running 3.1 with 1x250Gb and Turbonet over 802.11

  2. #287
    Join Date
    Jan 2002
    Location
    Charlotte, NC
    Posts
    327

    Question anybody read this web page before?

    just wondering if anyone had read/reviewed this person's web pages. they're largely geared to his ATI video capture and burning SVCD, but i found it interesting where he mentioned the packet size and buffering necessary for good SVCD playback.

    http://www.pcphotovideo.com/svcd.htm

  3. #288
    Join Date
    Jan 2002
    Posts
    4,809

    Re: anybody read this web page before?

    Originally posted by keith721
    just wondering if anyone had read/reviewed this person's web pages. they're largely geared to his ATI video capture and burning SVCD, but i found it interesting where he mentioned the packet size and buffering necessary for good SVCD playback.

    http://www.pcphotovideo.com/svcd.htm
    The 2324 is the standard sector size for CDs either vcd or svcd. For a standard program stream playback it is 2048. It is valuable to note that by and large this is a simple difference. In an MPEG-2 program stream there are layers of information. At the lowest layer are the elementary streams. The audio and video components. They are seperate from each other and have no timing information. At the layer above that is where timing info takes place.

    The upper layer is make up of PACKs and PES Packets. The lower level ES is split up into PES Packets. Literally it is just "put this many bytes in here with a header" type of splitting... And then 1 or more PES packets is placed in a PACK structure.

    The PACK is where you find the SCR I mentioned before. It is the "base" clock for the stream while being played. The PES has PTS, and sometimes DTS, values for whatever type of ES is in it.

    The PES packets are interlaced with each other. You get 1 video, 1 audio, and then usually since it is much larger a bunch of video packets and then 1 more audio and so on...

    So while 2324 is often what is needed for VCD/SVCD it is quite literally an arbitrary distinction. By default Tmpgenc uses the standard 2048 and the output burns just fine onto VCD/SVCD. Now I am not saying that a tool that wants a sectore of 2324 is going to accept a 2048, just that there are tools that do...

    --jdiner

  4. #289
    Join Date
    Jan 2002
    Posts
    4,809
    Ah ha... I have found out why most players take a second to lock on to the multiplexed streams from a Tivo.

    The Frame pattern in an mpeg-2 is supposed to be IPBBPBBPBB

    But as we are technically starting in the middle of a stream when we multiplex, having looked for the first valid sequence header in the data, we get IBBPBBPBB. Come to think of it I remember having a discussion about this here on the forum some months ago.

    Having converted things over so that we get the problem IPBBPBB ordering things seem much better at startup.

    --jdiner

  5. #290
    Join Date
    Oct 2001
    Posts
    250
    Deja Vu!

    Originally posted by jdiner here
    Ah ha! I knew it was something like this... The frame order is non-standard on the Tivo TyStream files. (For both the DTivo and the SATivo...) According to the MPEG-2 spec the stream should be sent and save in the format IPBBPBBPBB... This is due to the fact that B frames can be bi-directionally predictive.

    However it is being saved in the format IBBPBBPBBP... Which is the correct play order but not the correct transmission order.

    So I spend the evening picking apart streams from most of the mux'ers out there.

    Those that produce something that is usable seem to be doing some frame re-ordering. At least the very first GOP and sometimes more.

    Those that produce stuff that just explodes right off the bat for me do not do any re-ordering at all.

    I think that to be more correct I am going to have to redo what I have done. Actually start over sadly and do frame re-ordering through-out. However before I do I intend to get a few people to check out what I have and see if it works for them. It what we have works then we can go with it. If not it is time to get down to brass-tacks and force it to be as good as possible.

    Further it appears that most of the mux'ing engines out there expect it to be in IPBBPBB... order. And don't check to see if it is. So we have B-Frames getting the DTS/PTS combination and I and P frames that are not. This is what is causing the skipping, hopping and jerking in playing things mux'ed with certain programs.

    I can't even guess at this point what impact these two things combined would have on the current editing software. It is far enough out of the norm that I would expect the results to be serious unpredictable. (Although I would not have expected some of the problems that people have been reporting...)

    --jdiner


  6. #291
    Join Date
    Dec 2001
    Location
    Montreal, Canada
    Posts
    288
    Once again, something to weird is going on.

    Ok i'm talking about unedited streams here
    with all commercials intact.

    If i take a show and mux it with TMPGEnc
    as a MPEG-2 Program Stream, it doesn't
    play on my Apex AD-1200. Well it plays
    but all i see is garbage and skipping audio.
    That's ok cause if i mux MPEG-2 SVCD, it
    plays fine.

    Now what bothers me is this :

    If i mux MPEG-2 SVCD and i create a menu,
    the audio is out of sync right from the get go!

    Is this some sort of bug from my player or
    Nero? What's going on here?

  7. #292
    Join Date
    Jan 2002
    Posts
    4,809
    Oh man. Sorry for the delays.

    I hoped to have this out before this. I wanted people to look at the new mux'er this weekend. I still do actually, so please stay tuned. I am just in the middle of re-writing part of it yet again in an attempt to make it even better. I found a gap in my logic based on what seemed to be a reasonable assumption.

    --jdiner

  8. #293
    Join Date
    Jun 2002
    Location
    here, there, everywhere
    Posts
    190
    Pr.Sinister: The menu causes problems w/ that player. I've read a few posts about it on vcdhelp.com.

    I've noticed the problem w/ Program streams vs. VBR SVCD mpgs too. I really think it's something wacked w/ the apex-1200.

    My Panasonic dones't have these problems.

    -lloyd-

  9. #294
    Join Date
    Dec 2001
    Location
    Seattle, WA
    Posts
    174
    Originally posted by jdiner
    Oh man. Sorry for the delays.
    No problem. I'm standing by with 10 5 min clips and a nice batch file to automate the testbed.

    Does anyone know how to run TMPGEnc muxing or bbMpeg muxing from the command line?

  10. #295
    Join Date
    May 2002
    Posts
    56
    TMPG, I have no idea how to automate it from the commandline. bbMPEG can be done but you might not like the answer since it will require something more complex than a batch file (well, if you have a bunch of unix tools on your box, you could prolly work something out...) but what you have to do with bbMPEG is produce a default.ini file with your settings. If you want some specifics, email me at drodriguez(at)ma.rr.com and I'll try to help you. I wrote a simple program to launch bbMPEG and mux my mpv/mpa files and compensate for the async reported in the txt file that tytool5 produces.

    OtakuCODE

  11. #296
    Join Date
    Jan 2002
    Posts
    4,809
    Oh man. I should have just written this thing in C++. It would make some of this so much easier. Just a heads up. I am still working on the latest fix but it took longer than I had planned. I shouldn't have stopped to mow the lawn this afternoon... But that is one chore that can only be put off for so long...

    --jdiner

  12. #297
    Join Date
    Feb 2002
    Posts
    363
    Thanks for the update. I hope you are getting close. Your work is appreciated!

  13. #298
    Join Date
    Feb 2002
    Posts
    116

    Editing

    Here's a thread on the AVS Forum about software that'll cut MPEG-2 files on I-frame boundaries. It's geared toward editing HDTV recordings but maybe it'd be of use for editing TiVo shows as well.

    http://www.avsforum.com/avs-vb/showt...hreadid=175352

  14. #299
    Join Date
    Jan 2002
    Posts
    4,809
    Alright. Well after working late on it and spending some more time this morning. The problem was with my size-reduction code. I was I guess trying to be a bit to clever on the first pass at things and reduce the output size as much as possible. I going to have to roll back to the code that uses padding more liberally, and combined with the latest fixes to other code it should be ready to test.

    --jdiner

  15. #300
    Join Date
    May 2002
    Posts
    56
    Trust me when I say I am not posting this to try to rush you. I am a coder myself and understand that good code does not come under pressure. But I was just wondering, concering your last post jdiner, how big of a setback is this? You say you have to revert back to some older code and re-apply fixes. This could be a titanic job or a quite quick one, which side does it fall on?

    Just wondering if I should keep refreshing the last page of this thread every hour or not

    OtakuCODE

Posting Permissions

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