Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > (HD) DVD, Blu-ray & (S)VCD > (HD) DVD & Blu-ray authoring

Reply
 
Thread Tools Search this Thread Display Modes
Old 29th October 2008, 10:08   #2201  |  Link
GZZ
Registered User
 
Join Date: Jan 2002
Posts: 581
I havent notice that yet. But I have another 'issue' so to speak. I dont know if its a issue and its properly not related to tsMuxer. But after inserted chapters and playing the movie, I sometimes see the last 1-5 frames from the previous scene, if I then shift forward the chapters by 100-200 ms, then they are acurrate. Dont know if it has something to do with -b-pyramid option in x264 encoder or what it is. But its a small bug, I can live with it.
GZZ is offline   Reply With Quote
Old 29th October 2008, 12:27   #2202  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,973
Quote:
Originally Posted by Ryu77 View Post
jdobbs, I just wanted to mention something in regards to your application. I am not sure if I should be concerned or not...

After correcting the clip info file with your application, I am noticing that during seeking at regular intervals the picture seems to display a band across the bottom portion of the screen from a previous scene. This seems to be where tsMuxeR created files used to stick for a fraction of a second. I guess my concern is... Yes, your application has definitely made seeking smoother... But... Has it introduced something else that could present problems?

Has anybody else noticed this after using the clpi fix?

Note: For reference, I am using ArcSoft TotalMedia Theatre.
I don't see how there could be any connection whatsoever to the updates by fixclpi. The file that is changed is simple pointers to locations. It doesn't have any effect at all on the video at all. It doesn't really even change the pointer location -- it only corrects data that was missing in the MSB (most significant bits) of the pointers.

I'd look somewhere else for the cause...
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 29th October 2008 at 12:33.
jdobbs is offline   Reply With Quote
Old 29th October 2008, 12:37   #2203  |  Link
Diablo69_HUN
Registered User
 
Join Date: Apr 2008
Posts: 12
Quote:
Originally Posted by jdobbs View Post
I don't see how there could be any connection whatsoever to the updates by fixclpi. The file that is changed is simple pointers to locations. It doesn't have any effect at all on the video at all. It doesn't really even change the pointer location -- it only corrects data that was missing in the MSB (most significant bits) of the pointers.

I'd look somewhere else for the cause...
I just burnt Matrix and checked it on PS3, and everything was O.K. Thank you Jdobbs for this very usefull application!
Diablo69_HUN is offline   Reply With Quote
Old 29th October 2008, 12:58   #2204  |  Link
Ryu77
Registered User
 
Ryu77's Avatar
 
Join Date: Mar 2008
Location: Australia
Posts: 246
Quote:
Originally Posted by jdobbs View Post
I don't see how there could be any connection whatsoever to the updates by fixclpi. The file that is changed is simple pointers to locations. It doesn't have any effect at all on the video at all. It doesn't really even change the pointer location -- it only corrects data that was missing in the MSB (most significant bits) of the pointers.

I'd look somewhere else for the cause...
Yes, I was thinking it's probably just the Media Player. It's not even much concern. It's only a slight flash and the video is flashing past at 20x speed anyway so it's likely quite normal. I just thought I'd mention it just in case it was useful in any way.

I already burnt a disc with a corrected clpi and I plan to take it into work (I help manage an Audio Visual Retail Store) and test it on every Blu-ray Player we have.

Previous discs burnt after multiplexing with tsMuxeR did stick a little when seeking and on some players completely froze (mainly the Sony BD players did this). I will report back later. :-)
Ryu77 is offline   Reply With Quote
Old 29th October 2008, 13:40   #2205  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,890
@jeffnoone
Please put your eac3to log files to know the problem.

Thanks to odin24 I know:
"The TrueHD track on DM & TR Live at Radio City is 96/24"

then your:
"used DOS commandline, and -i 24 -c 6 -s 48000"
is wrong. If your TrueHD track is the 4 (with the logs I can know this) you need:

eac3to <your_source> 4: stdout.pcm | Pcm2Tsmu - tsmu.pcm -s 96000

-i 24 -c 6 -s 48000 are defaults and only need the parameter when are distinct.
If you want half size and 48 KHz you can use:

eac3to <your_source> 4: stdout.pcm -resampleTo48000 | Pcm2Tsmu - tsmu.pcm
__________________
BeHappy, AviSynth audio transcoder.
tebasuna51 is offline   Reply With Quote
Old 29th October 2008, 16:11   #2206  |  Link
laserfan
Aging Video Hobbyist
 
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
Quote:
Originally Posted by GZZ View Post
...after inserted chapters and playing the movie, I sometimes see the last 1-5 frames from the previous scene, if I then shift forward the chapters by 100-200 ms, then they are acurrate. Dont know if it has something to do with -b-pyramid option in x264 encoder or what it is. But its a small bug, I can live with it.
I have noticed the same problem, though it's not always that the chapter point is too early i.e. you get the prior scene. Sometimes it's too late i.e. comes a few frames after the ideal/original point.

It seems as if using the original program's chapter points (e.g. 01:23:35.638) with the Re-encoded movie just misses the mark i.e. the original doesn't line-up properly with a keyframe in the new encoding.

I wonder if one needs to manually look at the re-encoded .264 recording, prior to muxing w/tsMuxeR, to find the best new I-frame to specify for the chapter point?
laserfan is offline   Reply With Quote
Old 29th October 2008, 18:00   #2207  |  Link
winoni71
Registered User
 
Join Date: Feb 2008
Posts: 14
Is there a simple way to demux a Wmv file with Vc-1 video stream?
winoni71 is offline   Reply With Quote
Old 29th October 2008, 19:27   #2208  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,973
Quote:
Originally Posted by laserfan View Post
I have noticed the same problem, though it's not always that the chapter point is too early i.e. you get the prior scene. Sometimes it's too late i.e. comes a few frames after the ideal/original point.

It seems as if using the original program's chapter points (e.g. 01:23:35.638) with the Re-encoded movie just misses the mark i.e. the original doesn't line-up properly with a keyframe in the new encoding.

I wonder if one needs to manually look at the re-encoded .264 recording, prior to muxing w/tsMuxeR, to find the best new I-frame to specify for the chapter point?
Some slight inaccuracy might be expected, especially when there isn't a stark difference at the scene change that would trigger X264's scene change detection to put a keyframe at the exact chapter point. The chapters you put into TSMUXER only relate to muxing and building of the MPLS file... the encode with selection of keyframes has already been done at that point. On the other hand, it may be possible for the playback software to be frame accurate even without a keyframe with AVC on BD-- I'm not positive about that. You'd think it would be really obvious in those encodes where a large grouping is used.

Interesting from the referenced post that is seems to always be off by the same amount, though...

One way you could make them exact, I guess, would be to encode all the chapters individually and then combine them afterward.

I'm not aware of another way to force a keyframe in x264 -- does anybody else know of one?
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 29th October 2008 at 19:37.
jdobbs is offline   Reply With Quote
Old 29th October 2008, 20:37   #2209  |  Link
rica
Registered User
 
Join Date: Mar 2008
Posts: 2,021
Quote:
Originally Posted by winoni71 View Post
Is there a simple way to demux a Wmv file with Vc-1 video stream?
Yes: ASF2VC1

http://www.ftyps.com/unrelated/asf2vc1/
rica is offline   Reply With Quote
Old 29th October 2008, 21:03   #2210  |  Link
Cela
Registered User
 
Join Date: May 2004
Posts: 185
Quote:
Originally Posted by jdobbs View Post
Actually it's close to beta test now.
Great!

Still time for a Feature Request asking for a TSRebuilder
to rebuild captured DVB-S2 TS supporting kind of the following procedure?

a) trim both ends (ok with tsMuxeR)
b) cut out unwanted interior parts (possible but complicated with tsMuxeR, involving append with risk of audio sync problems)
c) define chapters in the resulting stream (ok with tsMuxeR; finding of suitable chapter locations probably could be done using some other sw like NeroVision)
d) supply a simple, table-of-contents-like main and chapters menu (currently not possible with tsMuxeR)
c) create an AVCHD structure (like supplied by tsMuxeR, but including chapter menus)

More details here

Does anybody know of an affordable sw out there which does this WITHOUT excessive re-encoding?
Cela is offline   Reply With Quote
Old 29th October 2008, 21:06   #2211  |  Link
m1482
Registered User
 
Join Date: Apr 2003
Location: Totolalandia
Posts: 96
roman76r:

Would it be possible to add to TsMuxer "3:2 pulldown" option?
At this moment the only tool available that have this option (h264info) doesn't work with all type of h264 files...

Thanks...
m1482 is offline   Reply With Quote
Old 29th October 2008, 21:22   #2212  |  Link
GZZ
Registered User
 
Join Date: Jan 2002
Posts: 581
Quote:
Originally Posted by jdobbs View Post
I'm not aware of another way to force a keyframe in x264 -- does anybody else know of one?
I was thinking the same, X264 should have a parameter, so you could include at chapter list and it then could insert an keyframe on those exact location, then I think chapters will be correct. I think CCE does that for Mpeg2, so cant see why it couldnt be built into x264. But I might be wrong.
GZZ is offline   Reply With Quote
Old 29th October 2008, 21:27   #2213  |  Link
peterjcat
Registered User
 
Join Date: Sep 2008
Posts: 37
Quote:
Originally Posted by m1482 View Post
roman76r:

Would it be possible to add to TsMuxer "3:2 pulldown" option?
At this moment the only tool available that have this option (h264info) doesn't work with all type of h264 files...

Thanks...
eac3to will properly strip 3:2 pulldown from H.264 files and so far it's worked for all of mine... is that what you mean?
peterjcat is offline   Reply With Quote
Old 29th October 2008, 21:28   #2214  |  Link
laserfan
Aging Video Hobbyist
 
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
Quote:
Originally Posted by jdobbs View Post
Some slight inaccuracy might be expected, especially when there isn't a stark difference at the scene change that would trigger X264's scene change detection to put a keyframe at the exact chapter point. ...I'm not aware of another way to force a keyframe in x264 -- does anybody else know of one?
I just learned a number of things about this:

1. Apparently most x264 cl's allow use of B-frames as "reference points" and so I observed that many scene changes in my 264 were at B-frames, not I-frames.

2. To find this I had to use Avidemux, as serving VirtualDub 1.8.6 with DGAVCindex .dga file displays each/every frame as a K(keyframe)!!??

3. Although I'd changed my .meta file for tsMuxeR to reflect the exact scene change point, clearly it was instead finding I-frames on playback. Sorta ugly.

4. When I saw with Avidemux the correct x:xx:xx.xxx codes for the I-frames, and edited the .meta file accordingly, all the chapters now seek to exactly the place I'd selected (which was in every case an I-frame).

I would like to know how to not use B-frames as "reference" if I'm interpreting this correctly. Would rather always assert an I-frame if possible at scene changes. All of my scene changes were stark/different/obvious indeed.

BTW I used --keyint 24 and --min-keyint 2 and it seems each/every GOP was 24 long, not sure this is right (should have been some GOPs <24???).

Thanks jdobbs for fixclpi.exe--tried that also and it seemed to make a difference.

Last edited by laserfan; 30th October 2008 at 02:14.
laserfan is offline   Reply With Quote
Old 29th October 2008, 21:56   #2215  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by laserfan View Post
...

I would like to know how to not use B-frames as "reference" if I'm interpreting this correctly. Would rather always assert an I-frame if possible at scene changes. All of my scene changes were stark/different/obvious indeed.

BTW I used --keyint 24 and --minkeyint 2 and it seems each/every GOP was 24 long, not sure this is right (should have been some GOPs <24???).

Thanks jdobbs for fixclpi.exe--tried that also and it seemed to make a difference.
You need an I frame on a chapter point. If you put it somewhere on P or B frame than it's very likely that player will jump to the nearest I frame instead of specified place. It does work like this for DVD and also for Blu-ray.

They can be shorter GOPs, but there may not be- depends on the encoder.

Last edited by kolak; 29th October 2008 at 21:59.
kolak is offline   Reply With Quote
Old 29th October 2008, 22:24   #2216  |  Link
rebkell
Registered User
 
Join Date: Oct 2006
Posts: 303
Quote:
Originally Posted by laserfan View Post
I just learned a number of things about this:

1. Apparently most x264 cl's allow use of B-frames as "reference points" and so I observed that many scene changes in my 264 were at B-frames, not I-frames.

2. To find this I had to use Avidemux, as serving VirtualDub 1.8.6 with DGAVCindex .dga file displays each/every frame as a K(eyframe)!!??

3. Although I'd changed my .meta file for tsMuxeR to reflect the exact scene change point, clearly it was instead finding I-frames on playback. Sort ugly.

4. When I saw with Avidemux the correct x:xx:xx.xxx codes for the I-frames, and edited the .meta file accordingly, all the chapters now seek to exactly the place I'd selected (which was in every case an I-frame).

I would like to know how to not use B-frames as "reference" if I'm interpreting this correctly. Would rather always assert an I-frame if possible at scene changes. All of my scene changes were stark/different/obvious indeed.

BTW I used --keyint 24 and --minkeyint 2 and it seems each/every GOP was 24 long, not sure this is right (should have been some GOPs <24???).

Thanks jdobbs for fixclpi.exe--tried that also and it seemed to make a difference.
You can raise the value of scenecut, but I use --min-keyint 1 on all my captures that I reencode and it definitely does nail almost every break, of course I'm going to a lot of black scenes and such during commercials, so my odds probably increase. I think min-keyint has a dash in the parameter, did you use minkeyint? that might be why every gop is exactly 24.
rebkell is offline   Reply With Quote
Old 29th October 2008, 23:03   #2217  |  Link
Ryu77
Registered User
 
Ryu77's Avatar
 
Join Date: Mar 2008
Location: Australia
Posts: 246
Quote:
Originally Posted by rebkell View Post
You can raise the value of scenecut, but I use --min-keyint 1 on all my captures that I reencode and it definitely does nail almost every break, of course I'm going to a lot of black scenes and such during commercials, so my odds probably increase. I think min-keyint has a dash in the parameter, did you use minkeyint? that might be why every gop is exactly 24.
Yes you are correct, "min-keyint" is meant to have a dash.
Ryu77 is offline   Reply With Quote
Old 30th October 2008, 00:34   #2218  |  Link
laserfan
Aging Video Hobbyist
 
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
Quote:
Originally Posted by Ryu77 View Post
Yes you are correct, "min-keyint" is meant to have a dash.
Just a typo in my post. I did indeed use --min-keyint 2.
laserfan is offline   Reply With Quote
Old 30th October 2008, 00:37   #2219  |  Link
odin24
Registered User
 
odin24's Avatar
 
Join Date: Mar 2008
Location: The Great North (the better half of North America)
Posts: 301
@jdobbs and GZZ,

Thanks for the clpifix app and GUI, they both work fantastic. My only trial with the app was on a direct port with no recoding, rip --> BD-RE (h264 & DTSHD-MA). Hopefully I'll have the same results from the same source recoded for DVD9 and DTS core, I'll know soon. Playback was on the PS3.

Thanks again.

EDIT: The recoded DVD9 works just as well with the fixed clpi file on the PS3.

Last edited by odin24; 30th October 2008 at 01:32. Reason: More info. and more results
odin24 is offline   Reply With Quote
Old 31st October 2008, 02:42   #2220  |  Link
jamos
Hey Now!
 
Join Date: Feb 2006
Posts: 812
Quote:
Originally Posted by jdobbs View Post
Attached is a small command line program that will correct the CLPI. Just run it with a single parameter that represents the path to the CLPI file that was created by TSMUXER in blu-ray mode. If it finds the error (it will normally be there except on very small muxes) it will rewrite the CLPI with the tables corrected.

I want to be sure that no one misunderstands me on this... TSMUXER is a great program and I use it all the time. It's the only one I know of that does what it does as well as it does. This little app is just a way to correct a small glitch -- which I have to assume will be corrected by the TSMUXER authors in due time.
Thanks Bud!
jamos is offline   Reply With Quote
Reply

Tags
tsmuxer

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.