Nastaveni x264 (MeGUI, Staxrip) a prokladani DV ?

[LadaOva]

Mam testovaci SD video (DV Canopus HQ codec). Pri kodovani do h264 (9mbps) a zachovani prokladani dostavam z Mainconceptu a Procoderu prokladany vysledek, ktery je kvalitne zobrazen v WMP, na PS3 a i v VLC(s nastavenim automatickeho odstraneni prokladani).
Pri pokusu prevest stejne video pomoci x264 dostavam vysledek, ktery pri vyse zminenem prehravani ma vsude hrube rozostreni prokladani - jako kdyby pri prehravani vubec nedochazelo k odstraneni prokladani.

Ma se nekde v Avisynthu nebo v tech GUI neco nastavit?

[vivid.sk]

Predpokladam, ze video sa javi ako progresivne. Musis nastavit vystup ako prekladany (over si to vo vystupnom videu cez MediaInfo).

[LadaOva]

v Mediainfo to pise pro vystupni soubor:
************************************************** ************
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 27s 400ms
Bit rate : 8 889 Kbps
Maximum bit rate : 11.4 Mbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Original display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.857
************************************************** ****

Kde se ma nastavit, ze chci prokladany vystup ??

[vivid.sk]

priamo v GUI v ktorom to robis, pripadne skontroluj command line pre x264, prekladanie sa nastavuje tymto parametrom

[ai]

V tom MeGui musi nastavit i SAR nejen bff ( bottom field first pro DV video).

Tedy v Megui se v config pro video zaskrtne "show advanced settings", Frame Type tab - nastavi se "interlace mode" jako BFF (--bff v command line) a pak pro Misc tab - "Force SAR" se zvoli pro PAL 4:3, SAR 16:15 (--sar 16:15) nebo 64:45 pro PAL 16:9. To jsou korektni hodnoty. Ty hodnoty pro Blu-ray by byly jine podle ITU (12:11, nebo 16:11, posle videohelp fora, BR pocita z 704 ne 720)

Ja osobne prokladani likviduju s QTGMC a hned prevedu take na ctvercovy pixel. Kupodivu to ma pak mensi objem vysledne video nez ten interlace (stejne nastavene CRF), ovsem trva to mnohem dele ten prevod.

[LadaOva]

ai: na ten bff uz jsem prisel (je to tam dost skryte a mlcky jsem predpokladal, ze kdyz se nenastavi zadny parametr, tak to necha stejne jako je vstup)

- SAR dela co?

- pri odstraneni prokladani se ale ztrati cast informace (50i); mi prijde nejlepsi vysledek doposud nechat prokladani a na PC se divat v WMP.

(Jinak ten x264 je zatracene rychly oproti Mainconceptu a hlavne Procoderu.)

[ai]

SAR x PAR - DAR .. to je rovnice pro aspect ratio, storage aspect ratio, pixel aspect ratio, display aspect ratio, bohuze DV avi neni ctvercovy pixel, tedy musis s timto pracovat

pro DV avi 4:3 tedy:
16/15 x 720/576 = 4/3

pouzivam bob deinterlacer QTGMC, ten deinterlacuje na 50p/60p tedy interpoluje chybejici pole, vysledek je suprovy, nesmis pouzit deinterlacer na 25p, to je jasne, to znici video

[LadaOva]

"Force SAR" se zvoli pro PAL 4:3, SAR 16:15 (--sar 16:15)

tak to tam nemam. Je tam v nabidce tech dvoucifernych jenom: 12/11, 16/11, 32/27, 40/33, 64/45


tak jsem tam dal to tvoje a Avisynth tam hlasi, ze pro COnvertto.. muze byt pouze RGB.
ConvertToYV12(interlaced=true,matrix="pc.709")
QTGMC( Preset="Slow" )
SelectEven()

Kdyz tam necham jen ten QTGMC tak to udela celkem pekne video.

Jak tam davas ten ctvercovy pixel?

[ai]

Je tam v nabidce tech dvoucifernych jenom: 12/11, 16/11, 32/27, 40/33, 64/45

no jo, ja taky ne, ja delam jen z NTSC, ta hodnota tam skutecne neni, ono to neni az zas tak matematicka chyba, kdyz tam das SAR podle ITU-R normy jak ma byt 12:11, DAR vyjde nejak 1,36 misto 1,333, tedy zkresleni minimalni ...

SelectEven() v tom skriptu vyse vyhodi kazdy druhy snimek, to prave nechceme, to je dobre maximalne na web, a i tam by se to melo odbouravat, specialne u SD videa

DV video je uz YUV tedy prikaz convertYV12() je zbytecny a Avisynth prave hlasi chybu, protoze ten prikaz je aplikovatelny jen na RGB video, treba z Vegasova Debugmode frame serveru, mozna, ze mas skript prave odtamtud nejak. Pokud nacitas DV avi do Avisynthu primo skript by mohl byt nejak takto:

AviSource("D:\Dv.avi") #nacte se DV avi z hardisku
Assumebff() #rekne se Avisynthu, ze video je bottom field first
QTGMC( Preset="Medium" ) #vyrobi se 50p
LanczosResize(768,576) # nebo Spline36Resize(720,540) #proste pomer stran nastavit na ctvercovy pixel 4:3

tento skript je ctvercovy pixel, tedy aspect ratio je 1.0, 50p video, ready na vsechny tablety, telefony, PC a vselijaka zarizeni , prokladani a aspect ratio je pryc

[ai]

no, me napadlo to dopsat rucne do toho Custom command line v megui (pod Misc tabem), --sar 16:15, a to prebije jakekoliv nastaveni tim Force SAR, jde to hned videt jak se to aktualizuje dole, ten delsi command line se vsemi nastavenimi , takze jde nastavit jakykoliv SAR

[LadaOva]

Custom command line v megui (pod Misc tabem), --sar 16:15, a to prebije jakekoliv nastaveni tim Force SAR, jde to hned videt jak se to aktualizuje dole, ten delsi command line se vsemi nastavenimi , takze jde nastavit jakykoliv SAR

jo to uz jsem taky tak udelal vecer.

Chci se zeptat:
1) Ctvercovy pixel z DV (resp Video8 grabovane do DV) - na co to ma vyhodu. I obecne vyhoda ctvercoveho pixelu? (chabu dobre, ze to je vhodne pro soucasne zobrazovadla - PC, fullHD TV a nevhodne pro CRT TV)

2) kdyz v Avisynthu udelas ten prevod na ctvercovy pixel tim rozsirenim, pak uz v MeGUI se nenastavuje pro x264 ten SAR? Fce Crop to usekne zacenu ztraty casti obrazu?

diky

[ai]

1) prehravace musi respectovat aspect ratio, at uz softwarove nebo hardwarove a provest rescale spravneho pomeru vysky k sirce, tedy zjisti, nebo-li precte SAR,vynasobi to s rozmerem videa a dostane se DAR - Display aspect ratio. Muzes se na to spolehnout, nebo to odbourat, protoze to video enkodujes tak jako tak. Pokud si myslis, ze vsechny prehravace to budou respektovat tak to enkoduj s nastavenym SAR a video se nemusi nastavit na jiny rozmer (resize). Ja se rozhodl na to nespolehat, jeste ke vsemu u NTSC ten nepomer stran je vetsi nez u PAL. Tam kdyz se "vynecha" ten SAR (u PAL) a video se precte jednoduse 4:3 tak ve vysledku tam neni az tak velka "chyba" , nepomer strat nez u NTSC videa.

2)ne , zadny SAR se nenastavi , provede se resize, zmena rozliseni a video je prehravano po enkodovani jako 4:3, coz je i rozmerove po te zmene rozliseni . 768/576 = 4/3 (nebo 720/540 atd...)

[LadaOva]

Assumebff() --- je nutne uvadet v tom scriptu?? Nepostaci, kdyz je to nastaveno v tom meGUI?

[ai]

Nech to tam v tom skriptu, to je kvuli pro QTGMC, ja ted momentalne nevim na co je QTGMC defaultne nastaveny, jestli pro BFF nebo TFF.

Nastaveni v enkoderu Megui je o necem jinym, tam to musis zatrhnout taky, timto volis typ enkodovaneho videa. V tom avisynth skriptu to je jenom info kvuli QTGMC, aby vedel co to je za typ toho nacitaneho videa.

Pokud tedy nacitas video bez QTGMC s umyslem enkodovat prokladane staci jen tento skript na jeden radek:
AviSource("D:\DV.avi")

resize prokladaneho videa nedelej, to spatne dopadne, ten resize na ctvercovy pixel je jen v tom pripade s QTGMC.