View Full Version : Scenarist 4.1 avc/vc1 assets
Sergey A. Sablin
6th February 2007, 14:15
If you make that you must rewrite HRD parameters in the stream. IMO the best way is pehaps to make complete flags rewrite tools:
-> input is basic H264 raw stream
- tool write Sequence End Code flag
- tool write SEI flag
- tool write HRD flag
- tool write pulldown flag
etc etc etc
-> output is compliant HDDVD/BD stream
wrong. encoder was used given buffer model with given timing - it will be a luck to change these parameters and still keep buffer model correct. No one could give a guarantee for this without buffer analyzing and adjusting HRD parameters for new timing.
Clown shoes
6th February 2007, 14:50
The reason I was discussing it here Sergey, is the fact that I know members here have had success in producing HDDVD compliant files. I don't consider it likely to be a technical problem with the software, more likely a user problem caused by myself. Therefore I feel I will probably troubleshoot this problem quicker If I mention it on Doom 9.
Sergey A. Sablin
6th February 2007, 15:02
The reason I was discussing it here Sergey, is the fact that I know members here have had success in producing HDDVD compliant files. I don't consider it likely to be a technical problem with the software, more likely a user problem caused by myself. Therefore I feel I will probably troubleshoot this problem quicker If I mention it on Doom 9.
ok. I've just suggested.
Clown shoes
6th February 2007, 15:16
Sorry Sergey, I didn't mean to be rude. I am just used to solving my video related problems on my favourite video related forum :)
I have just gone to the mainconcept website and sent an email to technical support. Hopefully between the two places I will get an answer to my problems. At least before my boss tears me a new one!
@Sagittaire Can you confirm which version of the encoder you have been using? Also as i see you too have been using QT trailers, have you managed any at high constant bitrates, Specifically in the 20,000 kbps range?
Thanks again guys.
Clown shoes
7th February 2007, 12:39
Ok, update:
I have tested the same source material with some variable encodes. I can push the max bitrate all the way to 29 mbps without problems, but the average cannot pass the same limits I was restricted to in the constant bitrate encodes. The curious thing is, the limitation varies between sources. It seems to be between 6000 and 10000 kbps (at least on everything I have checked)
I am going to test out the Elecard demo today and see if the same restrictions apply.
Can anyone else confirm this bitrate limitation issue?
Sagittaire
7th February 2007, 15:35
Ok, update:
I have tested the same source material with some variable encodes. I can push the max bitrate all the way to 29 mbps without problems, but the average cannot pass the same limits I was restricted to in the constant bitrate encodes. The curious thing is, the limitation varies between sources. It seems to be between 6000 and 10000 kbps (at least on everything I have checked)
I am going to test out the Elecard demo today and see if the same restrictions apply.
Can anyone else confirm this bitrate limitation issue?
Try with differents values for the buffer ...
1 150 000 bytes
1 843 000 bytes
3 750 000 bytes
Clown shoes
7th February 2007, 17:02
We have success with Mainconcept (Thanks to Sagittaire)
150,000 bytes is too low and causes the encoder to crash, but 750,000 and 843,000 both work a charm. Even going up to 29mbps.
I am well chuffed. :)
Sagittaire, can you tell me how you worked out the correct VBV values? The default is set to 11,718656 which is so drastically different it's not funny. As I will be purchasing this encoder for commerial purposes, I want to make sure I don't get caught out like this again.
Sagittaire
8th February 2007, 19:14
Sagittaire, can you tell me how you worked out the correct VBV values? The default is set to 11,718656 which is so drastically different it's not funny. As I will be purchasing this encoder for commerial purposes, I want to make sure I don't get caught out like this again.
1 150 000 bytes is the official value for HDDVD with MPEG2 MP@HL
1 843 000 bytes is the official value for HDDVD with VC1 AP@L3
3 750 000 bytes is the official value for HDDVD with H264 HP@4.1
I don't know the particular value for sonic authoring but 1150000 must work in all case. Higher buffer values imply potentially higher values for local peak bitrate and more constant quality in complexe part. It's particulary true if your average bitrate is close to your max bitrate.
If average bitrate = max bitrate and if buffer = 0 then Rate Control will be strict CBR
If average bitrate = max bitrate and if buffer = infinite then Rate Control will be strict VBR
Clown shoes
8th February 2007, 20:30
Well that's interesting. Scenarist seems to be extremely fussy with what I give it.
At a constant bitrate of 29mbps (The highest limit available to AVC within the HD-DVD spec)
A Mainconcept buffer of;
1,000.000 bytes causes Scenarist to throw a muxing error
750,000 is perfectly ok though
300,000 or lower causes the encoder to crash.
Therefore Mainconcept's default buffer of 11,718.656 really is well off the mark.
Thanks for your help Sagittaire. The only thing still puzzling me is the issue of Pulldown though. It's clearly working for you in version 2.0. Has anyone got it working in version 2.1 or is it broken. I still get the error: C045:H.264 Validation Error: Invalid target frame_rate/pulldown combination. Must be 29.97, 30, 59.94, or 60. every time I try to set pulldown on a 23.976 source
Sagittaire
8th February 2007, 21:31
Make average bitrate encoding really close to the max bitrate is a hell for the rate control:
- really difficult to respect vbv -> can produce no compliant files
- easy to sature the buffer -> can produce bad Iframe quality
IMO it's always better in multipass mode to use average bitrate < 2/3 * max bitrate
lazyn00b
9th February 2007, 01:26
The only thing still puzzling me is the issue of Pulldown though. It's clearly working for you in version 2.0. Has anyone got it working in version 2.1 or is it broken. I still get the error: C045:H.264 Validation Error: Invalid target frame_rate/pulldown combination. Must be 29.97, 30, 59.94, or 60. every time I try to set pulldown on a 23.976 source
I still always have exactly the same problem with 2.1.
Sergey, since you work for MainConcept, surely you can shed some light on this, can't you? Are we doing something wrong, or is there a bug in the program?
Sergey A. Sablin
9th February 2007, 11:17
I still always have exactly the same problem with 2.1.
Sergey, since you work for MainConcept, surely you can shed some light on this, can't you? Are we doing something wrong, or is there a bug in the program?
unfortunately it is impossible right now to add pulldown through this application.
The only way is like this: source shall signal 29.97 fps and you then may specify 3:2 pulldown. I think one could try to signal 29.97 frame rate for 23.976 source via avi synth.
Clown shoes
9th February 2007, 11:18
What a relief. Confirmation that I'm not going mad :)
I've tried the 2.0 demo and that seems to work ok. The thing is, I think the pulldown is working automatically in 2.1 if you just enter an output framerate of 29.97, the resulting file is the correct length and seems to play back smoothly on my XBOX360 HD-DVD drive. My hesitation is the fact I'm not so use to working with pulldown due to the fact I come from PAL land.
Can you shed some light on this for us Sergey? I did send an email to Mainconcept technical support as you requested on tuesday, however there has been no response!
EDIT; Sorry Sergey, you were posting at the same time as me.
Are we to assume 2.1 is broken then?? Pulldown worked fine in 2.0.
Sergey A. Sablin
9th February 2007, 11:46
What a relief. Confirmation that I'm not going mad :)
I've tried the 2.0 demo and that seems to work ok. The thing is, I think the pulldown is working automatically in 2.1 if you just enter an output framerate of 29.97, the resulting file is the correct length and seems to play back smoothly on my XBOX360 HD-DVD drive. My hesitation is the fact I'm not so use to working with pulldown due to the fact I come from PAL land.
Can you shed some light on this for us Sergey? I did send an email to Mainconcept technical support as you requested on tuesday, however there has been no response!
EDIT; Sorry Sergey, you were posting at the same time as me.
Are we to assume 2.1 is broken then?? Pulldown worked fine in 2.0.
seems like it was a luck that 2.0 worked with pulldown fine. cause there was no such functionality. we will check this and probably update application soon (this depends on current priorities as usual, so be patient please).
Clown shoes
9th February 2007, 12:19
Ok Sergey, well if I understand you correctly, a simple script like this;
QTInput("G:\HDTests\300-tlr2_h1080p.mov")
changefps(29.97)
followed by 3:2 pulldown should suffice.
I will test now and post the results when I get a chance (probably not untill this evening)
Sergey A. Sablin
9th February 2007, 12:30
Ok Sergey, well if I understand you correctly, a simple script like this;
QTInput("G:\HDTests\300-tlr2_h1080p.mov")
changefps(29.97)
followed by 3:2 pulldown should suffice.
I will test now and post the results when I get a chance (probably not untill this evening)
just assumefps(29.97), as source has to just indicate 29.97, but do not change anything inside.
Clown shoes
9th February 2007, 12:37
Are you sure?? The way I understood it, assumefps only speeds up the footage. Apply pulldown will then set a flag to remove certain frames on playback. Would that not really mess with the output? I envision something that is then too fast and stuttering. However if we use changefps it will duplicate certain frames. Applying the pulldown flags will tell the playback unit to remove the dupes.
Or have I got that all the wrong way round? :D
Sergey A. Sablin
9th February 2007, 12:59
Are you sure?? The way I understood it, assumefps only speeds up the footage. Apply pulldown will then set a flag to remove certain frames on playback. Would that not really mess with the output? I envision something that is then too fast and stuttering. However if we use changefps it will duplicate certain frames. Applying the pulldown flags will tell the playback unit to remove the dupes.
Or have I got that all the wrong way round? :D
assumefps just indicates specified frame rate - that is what is needed for workaround atm (works fine here).
pulldown flags indicate how to show frames - either as two fields or as three fields.
if you want to see your encodings on progressive display you dont need these flags - just encode as 23.976 and you'll see progressive playback on your PC display. If you are targeting TV or other interlaced device, then using pulldown flags you're telling to decoder to duplicate some fields to see kinda interlaced 29.97.
seems you have to read a bit about 3:2 pulldown.
Clown shoes
9th February 2007, 13:17
Ha ha, yes like I said I had it all confused :D
I am used to working with nice easy PAL framerates, but seeing as many HDDVD players are still only able to playback at NTSC framerates, I foresee having to work with it for a while. I do understand the principle of pulldown, but I have clearly got myself confused using a combination of filters and flags in this situation.
Thanks for setting me straight Sergey.
I just have one last question if you can bear it. I just want to make sure I have got all of this straight.
My source footage is 23.976fps progressive, but Scenarist will only accept 25fps or 29.97fps. Therefore, do I still use your suggested method of assumefps followed by pulldown, even though it is clearly not interlaced material. Or am I still on the wrong track.
Thanks again
Sergey A. Sablin
9th February 2007, 13:31
I just have one last question if you can bear it. I just want to make sure I have got all of this straight.
My source footage is 23.976fps progressive, but Scenarist will only accept 25fps or 29.97fps. Therefore, do I still use your suggested method of assumefps followed by pulldown, even though it is clearly not interlaced material. Or am I still on the wrong track.
Thanks again
yes, here you are right - this is the way to make scenarist happy (u2 eventually :))
lazyn00b
10th February 2007, 01:50
@Clown shoes:
All you need to do is change fps with avisynth like you said to 29.97 and and use MainConcept to encode at 29.97, but do NOT set the 3:2 pulldown setting. You definitely do NOT want to apply pulldown on top of a video that has already been adjusted to 29.97 fps, because then you will end up with a video that plays back too many frames!
I should warn you, however, that even though Scenarist will accept a 29.97 fps progressive stream, the authored .EVO may not play back smoothly in your HD DVD player. I've had problems with these progressive streams in PowerDVD 7.2 Ultra. Better to try a few test clips for yourself and see what happens.
Clown shoes
10th February 2007, 02:00
That's what I'm doing now.
I tried encoding the way Sergey suggested with assumefps and 3:2 pulldown and guess what? Just like I said, it played too fast and stuttered. I should have trusted my initial instincts!
EDIT;
Actually I've just been thinking about it and I don't think that is the best way either. If the source is 23.976fps and I use changefps it will add duplicate frames which will cause stuttering. If I use assumefps that will speed it up. No good also. Finally if I use convertfps it will blend frames. I don't want to make any changes to the frames I have, so none of these solutions are any good.
dvdboy
10th February 2007, 02:08
Hang on, my brain is starting to hurt here...
If you've got a feature film with a framerate of 23.976fps how do you encode this through mainconcept so that it is HD DVD compatible and will drop into Scenarist?
- AssumeFPS specifies a framerate, so I can understand how this works if you have a 25fps film source and you want to 'recover' the original framerate, but how does 'speeding up' a film help.
- Sergey, are you saying that the Pulldown 3:2 / 2:3 options under misc within MainConcept 2.x do not work???
My understanding was that you feed MainConcept a 23.976fps source file, tell MainConcept to produce a 29.97fps progressive file which has 3:2 pulldown set under misc, so that the video plays back 29.97, but if the display supports it, then the player can IVTC the footage back to 23.976.
But to do this the footage needs to be interlaced, not progressive. Isn't that how 3:2 pulldown works?
Why don't you then feed a 23.976fps file, and then produce a 29.97 interlaced file with perfect 3:2 cadence generated at encoding time.
Isn't that how CCE works?
Clown shoes
10th February 2007, 04:12
OK apologies!! :o
It appears the reason my disc played back strangely had nothing to do with the video, but instead the DD+ audio I was using. I tried the same clip but this time without the audio and it played back fine.
Interestingly though, I also encoded the same clip without changefps and 3:2 pulldown and just selected 29.97fps as the output and that appears to play fine as well. Can anyone confirm this?
lazyn00b
10th February 2007, 04:43
Interestingly though, I also encoded the same clip without changefps and 3:2 pulldown and just selected 29.97fps as the output and that appears to play fine as well. Can anyone confirm this?
Try checking the playback time - is it the same as the original video? Does the audio and video stay in sync through out the whole movie?
BTW, which player are you using?
EDIT: Also, I'm pretty sure that if you leave the source as 23.976, and simply allow the MainConcept encoder to change the FPS to 29.97, it is just doing the same thing as using the avisynth changefps function. You can verify this by stepping through the encoded video frame by frame: you will see that the doubled frames differ ever so slightly from each other, meaning that they were doubled prior to encoding.
Sergey A. Sablin
10th February 2007, 07:14
Try checking the playback time - is it the same as the original video? Does the audio and video stay in sync through out the whole movie?
BTW, which player are you using?
EDIT: Also, I'm pretty sure that if you leave the source as 23.976, and simply allow the MainConcept encoder to change the FPS to 29.97, it is just doing the same thing as using the avisynth changefps function. You can verify this by stepping through the encoded video frame by frame: you will see that the doubled frames differ ever so slightly from each other, meaning that they were doubled prior to encoding.
you are right, it is exactly as you said. Changing frame rate on property pages will change source clip frame rate.
I'll try to investigate video+audio encoding a bit later...
Clown shoes
10th February 2007, 16:05
I can confirm that Sergey's workaround using assumefps and 3:2 pulldown does give a smooth output (don't really understand how though :D )
dvdboy
10th February 2007, 17:08
Ok.
So if I have a 25fps film, which therefore has PAL speed-up, I can use an AVISynth script to generate a 23.976fps AVI. I feed this to mainconcept and tell it to produce a 29.97fps encode, and under Misc, I select 3:2 pulldown.
Is this correct??
BTW, my reason for making the AVI rather than feeding Mainconcept the AVS file is that I'm getting strange framelength errors otherwise (16 hour films as opposed to 90 minutes!!)
The Audio I am slowing down via BeLight.
Many Thanks
Clown shoes
10th February 2007, 17:20
Almost. It won't work unless you use an avisynth script with assumefps(29.97) in it. Mainconcept will show you the wrong running time, but the pulldown seems to fix it. I don't really understand the logic, but it works. Just out of interest DVDBoy, what's your source material?
dvdboy
10th February 2007, 19:06
Hi Clown Shoes,
I'm not sure if I can say here - PAL H264 Broadcasts off the internet...
So my source material has to be flagged as 29.97?
PAL H264 File > AssumeFps (29.97) > MainConcept 29.97 with 3:2
With the audio slowed down to 23.976 via belight.
Would that sound about right?
Clown shoes
10th February 2007, 19:48
Hey DVDBoy, I think what you meant to say was H264 broadcasts off of the TV ;)
Yes your script needs to have assumefps(29.97) at the end of it. I know this seems odd, as it means the video will play back too fast, but it seems to be the current fix for a bug in Mainconcept. It will not allow you to apply 3:2 pulldown to most non 29.97fps material. I say most because it does appear to work with some, but I guess it's just trial and error.
But in a nutshell, yes what you are doing looks the same as my method and it seems to be working great. :D
dvdboy
10th February 2007, 19:57
Thanks Clown Shoes, I'll report back how I get on.
I'm currently seeing how well Scenarist behaves with video which I encode in chunks but sync to one audio track.
Until MainConcept add a 3rd Pass / Segment based re-encode option.
What do you say Sergey? :D
Clown shoes
10th February 2007, 20:10
I'm currently seeing how well Scenarist behaves with video which I encode in chunks but sync to one audio track.
It can be done in Scenarist but it is a bit of a pain. Say if you have three parts, you can use the multi file import option, but you must take care to ensure the first two parts do not have sequence end codes, other wise your video will probably stop mysteriously when it reaches the join. That would be the only way to apply one audio track to a peice of video cut into several chunks (that I know of at least)
Is there a reason you have to encode the chunks seperately? Would it not be easier to join them in AVISynth?
dvdboy
10th February 2007, 21:21
I've got the source material as one long piece (90mins give or take). As I said, Mainconcept seems to be playing silly buggers with the duration, although this is probably down to using AVISynth and parsing in an H264 file. Because it is listing the duration wrong, MC seems to crash when it reaches the end of the encode. 'Fine' on a single pass, but useless on a 2 pass.
Because of this I'm currently bouncing the video back out to an AVI to feed MainConcept. Not ideal, but works and produces big files.
So, part of the reason for wanting to feed Scenarist chunks was to get around converting the whole film to an AVi first (I've guess-timated about 400GB). The other reason was so that I could allocate different bitrates to different peices, or re-encode a segment if I didn't like the results.
As it is, it is looking a complete ball-ache to try and sync, so my next plan is to generate the AVI. Just need to archive some old projects off first...
Clown shoes
10th February 2007, 21:40
Just out of interest, is it a raw .h264 or is it in a container like .mkv? and what was your avisynth script that was having problems?
dvdboy
10th February 2007, 23:55
My process so far has been as follows, and I'm always open to suggestions:
- .ts file run through xport to produce an .mpv (containing the H264 elementary stream) and .mpa (which is actually ac3).
- DirectShowSource (".mpv)
- AssumeFps (23.976)
- CropBottom (8)
- ConvertYUV ()
Opening the AVS file up, both virtualdub and mainconcept report the wrong length. I can play the file's back in PowerDVD 7.1 or MediaPlayerClassic and it's all there, but the duration is totally messed up.
Hence my thinking if I bounce this out to a 'physical' AVI, I'll use more disc space (temporarily), but I don't then get an issue with misreading the running time.
Sagittaire
11th February 2007, 00:41
In fact encoding is purely progressive internaly at 23.976 fps. Pulldown add just telecine flag in the stream for the playback because output in NTSC standard must be at 60 Hz.
Sergey A. Sablin
12th February 2007, 07:44
So my source material has to be flagged as 29.97?
your source has to be real 23.976 and flagged via avisynth as 29.97 if you want to produce 29.97 fps. Don't change frame rate in MainConcept H.264 encoder - just use 3:2 pulldown in this case.
Or source has to be real 24 and flagged as 30 to produce 30 fps. Again don't change frame rate in MainConcept H.264 encoder - use 3:2 pulldown flag.
Clown shoes
12th February 2007, 14:25
Sergey, this method does not appear to be working properly. I imported a raw .vc1 via avisynth (directshowsource) and used assumefps(29.97) I then applied 3:2 pulldown. The original source is 2.02.18.25, Mainconcept displays approx; 1.37.00.00 and the resulting output file has a running time of 2.01.56.12 The file appears to play back smoothly but the 22 second difference is alarming! Any idea what the cause for this might be?
What will happen to my 23.976 output file if I select 29.97 as my desired framerate and apply the 3:2 pulldown flag. Will I get duplicated frames?
Sergey A. Sablin
12th February 2007, 16:24
Sergey, this method does not appear to be working properly. I imported a raw .vc1 via avisynth (directshowsource) and used assumefps(29.97) I then applied 3:2 pulldown. The original source is 2.02.18.25, Mainconcept displays approx; 1.37.00.00 and the resulting output file has a running time of 2.01.56.12 The file appears to play back smoothly but the 22 second difference is alarming! Any idea what the cause for this might be?
What will happen to my 23.976 output file if I select 29.97 as my desired framerate and apply the 3:2 pulldown flag. Will I get duplicated frames?
if you'll set target frame rate in H.264 encoder application different from source, then you'll have either duplicated frames (if target > source) or dropped frames (if target < source) without regard to pulldown flag (which doesn't affect video content at all - just playback)
Clown shoes
12th February 2007, 16:43
@Sergey
Do you have any idea why my output file might end up 20 seconds shorter than the source file for a 2 hour feature encode, using your workaround with assumefps(29.97)?
The majority of the work I will be doing is going to be 23.976 sources for a local art gallery who are going HD. Therefore I really need to know this is going to work with what I throw at it. Is there any news as to when a version of the encoder will be released with the pulldown bug fixed?
Sorry to direct all this at you Sergey, but I never heard anything back from your tech department after emailing them last wednesday.
mpucoder
13th February 2007, 06:08
The original source is 2.02.18.25 if this is in hh.mm.ss.ff format it is an invalid time for 23.976fps
Mainconcept displays approx; 1.37.00.00 that is to be expected, the framerate change will shorten the runtime to 80%, the original was approximately 122 minutes, so 97 minutes is correct.
Do you know if the times are in drop-frame or non-drop format? if 2.01.56.12 is the correct non-drop value that equals 219492 displayed frames, converting to drop-frame would add 218 - not enough to account for the difference, but I question the original run time value.
btw - this is not new to HD, pulldown issues are the same as SD. In SD the most common way to do this is encode at 23.976 then apply pulldown which not only adds the flags but changes the framerate in the headers.
MarcioAB
23rd June 2007, 04:30
Hello,
Is there any reason why Scenarist does not accept a project for 23.976 or 24 fps ?
(most) HD content should playback on LCD displays that do not suffer with 50 or 60Hz, so any frame rate should be ok.
(most) DVD Mpeg2 movies are 24 fps and playback at 24 fps.
Thank you.
dvdboy
24th June 2007, 13:28
Hello,
Is there any reason why Scenarist does not accept a project for 23.976 or 24 fps ?
(most) HD content should playback on LCD displays that do not suffer with 50 or 60Hz, so any frame rate should be ok.
(most) DVD Mpeg2 movies are 24 fps and playback at 24 fps.
Thank you.
Hi MarcioAB,
Neither HD DVD or DVD accept 'pure' 24fps / 23.976fps video - they have to be wrapped into a 29.97fps container using 3:2 pulldown.
Only blu-ray accepts 'pure' 24fps video.
MarcioAB
24th June 2007, 20:39
Hi dvdboy,
Ok, but why when I play the majority of my DVDs movies directly on the PC, using Media Player Classic, I see on the statistics panel of MPC a number very close to 24 for the frame-rate ?
Thank you.
EDIT (after some pulldown readings)
TV1: interlaced CRT-based ( 15750 scan-lines capable ) (very old)
TV2: progressive CRT-based ( 31500 scan-lines capable ) (old)
TV3: progressive LCD-based ( 60 Hz )
DVD Player1: interlaced (old)
DVD Player2: progressive
The (old) DVD when filled with film content has always (or most of the time) 24 fps.
There is only a "pulldown" flag in the DVD content to instruct old interlaced DVD players to adapt the video to be able to play that 24 fps content in old interlaced CRT-based displays.
Progressive DVD players (as well as PC players) when connected on progressive displays (CRT or LCD) just ignore the "pulldown" flag, and play at 24 fps.
I understand things like NTSC or PAL were invented for that very old interlaced technology.
Today in the progressive and digital world, there is no need for NTSC or PAL ... I can have a video in 27fps, 233 fps or anything I want and it should be OK. Modern DVD players should be able to pass it, as any PC player can do it.
Is that correct, or I totally misunderstood my readings and the point ?
So, why a modern product like Scenarist4 is not open for other framerates ?
Are the current specs for future DVD limited to that ? Why ?
Thank you.
dvdboy
25th June 2007, 16:53
Don't ask me man, I only work here!
I guess the easiest answer is that it's all to do with specs and standards and legacy format support.
But let's look at this on the flip side - currently most if not all HD DVD & Blu-Ray players do not support PAL-based resolutions, so no 25fps, 50fps etc.
You've got to remember that these are all based on aquisition formats, whether that means film (24fps), or video (29.97, 59.94, 25, 50fps).
Here's the framerates that Sonic Cinevision supports:
* 59.94
* 50
* 29.97
* 25
* 24
* 23.98
* 3:2 pull-down insertion
Which is more than DVD supported. If you are just working in an internet / computer based system, of course you've got more choice, but DVD and HD is inherently an offshoot of Broadcast, and therefore follows their specs and standards.
HTH
MarcioAB
25th June 2007, 22:43
Don't ask me man, I only work here!and that is great !!
HD is inherently an offshoot of Broadcast, and therefore follows their specs and standards.That is an interesting point. Difficult (for me) to get that it is not an offshoot of high speed optical media.
So I need to look somewhere else beyond Scenarist ...
Thank you
Marcio
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.