Elecard
May 20, 2013, 10:23:28 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Use padding option  (Read 5534 times)
firebird
Newbie
*
Posts: 2


View Profile
« on: December 27, 2006, 02:49:14 pm »

I am a newbie using XMuxer Pro. I would like to know how the "Use padding" option works during the MUX Process. I created two streams out of a 1 minute MPEG-2 Elementary stream ( and an AC3 track) - one with padding enabled and another without padding.

I would expect the use padding option to stuff packets with PID 0x1FFFF for the duration of the MPEG-2 Elementary stream. However, it appears that I get an extemely long Transport stream (something like a couple of hours worth! ) and after the 1 minute duration of the Elementary stream, the rest of the TS is stuffed with packets with PID 0x1FFFF.

Do I miss something or am I doing anything wrong?

I have not edited anything else from what the default selections for Transport stream Multiplexing are...

Thanks in advance
Logged
Kostya
Newbie
*
Posts: 148


View Profile WWW
« Reply #1 on: December 27, 2006, 09:42:30 pm »

Hi firebird,

Please, upload on our ftp (ftp.elecard.com, user name: uploader, password: ybrjveybrf,tkmyjcnm) source files which you try to multiplexing and describe in more details sequence of your actions. I will try to help you.

Best Regards,
Konstantin.
Logged

est Regards,
Konstantin
www.elecard.com
firebird
Newbie
*
Posts: 2


View Profile
« Reply #2 on: December 28, 2006, 05:57:15 pm »

Konstantin,
Thanks for your prompt reply.

I figured out that the huge files were caused by the tool picking up the bit rate from the bit-rate indicated in the MPEG sequence header for the value in bit_rate_value field, which in the case of this stream, seems to be some absurd value like 104 MB per second. The elementary video stream itself is a Standard Definition 720x480i stream, but the sequence header appears to be corrupted.
Now, what I wonder is this :  
if the padding option is ON and the bit_rate_value in the header is some absurd value, then the MUXer should take a sensible option ( like in this case it should take the parameters for an MP@ML stream). But, it does not seem to be the case here. Wonder if this is an improvement option for the tool??

Anyway, I have uploaded a ZIP file containing 3 files, so that if you get a chance to look at this and let me know if my hunch is correct!

1. slice.ts : which is the original stream without any padding
2. slice-packed.ts : Padding option is ON and bit rate is set to 19200000 (close to an ATSC channel bandwidth)
3. slice-packed-default.ts : Padding option is ON but bit-rate is left at 0 (i.e default)


Many Thanks
Firebird
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!