Fórum figyelő

Ismét a szinkronhang megszűnik

Nagyon bocsánatot kérek, ezt a témát többször felvetették a fórumon, de nincs szilárd megértés.
Sajnálom a közelmúltbeli disszinkronizációt a rögzített 1:30 filmben, bár mielőtt ezt szokták írni. Az AVI M-JPEG-ben írt, a "interlace" és a "main stream" "Nincs" (a súgóban javasolt), a "Record through PCI" és a "Audio binding", a "High priority for recording" jelölőnégyzetek be vannak jelölve. A pufferelés kényszerítése a memóriában volt a maximális. Amikor a processzor írása nem "túlterhelt", nem volt abbahagyás. Szoftver és illesztőprogramok - ez utóbbi. A jel kábel, azaz. nem nagyon rossz.
És már nyugodt voltam.

Lehetséges (és szükséges-e) az írási módban a buszon keresztül a "Main stream" - Audio beállítására?

Aztán a fórumon tanácsot kapott, hogy megragadja a buszon, és átnézi a csipkét, de a Támogatás nem kapott megerősítést.
Segít a szinkronizálásból?

Ha globálisabban van, a felvétel elve és a szinkronizálás okai nem egyértelműek.

Például, ha a buszon történő rögzítés a tuner "hardver képességek", akkor miért íródott a segítség, hogy csak az "disszinkronizálás valószínűsége csökken"? Aztán, amennyire megértettem, a "Sound Bind" jelölés csak akkor működik, ha a forrásjel elveszett? Talán így van, és érdemes bevonni? És hogyan, egyébként, hogy meghatározza, mikor működik? Bármilyen mellékhatással?
Továbbá nem világos, hogy miért nem ajánlott a "váltakozó" puffer a nagy áramlásokhoz? Miért van szükséged pufferelésre, ha nem nagy tételekre? És milyen problémák merülhetnek fel ebben az esetben?

Általában ellenőrizzük a jeleket, és mi történik, nem tudom elképzelni, hogy egy vak kiscicát megpróbál.
Ochchen szeretne normális magyarázatot kapni a támogatásról az AVI rögzítési problémákért és az optimális beállításokért.

ZY
Függetlenül attól, hogy a rövid távú processzorterhelés disszinkron, akkor a 100% -ot érinti, ha a kiemelt fontosságot a memóriában történő íráshoz és puffereléshez használják (leesett képkockák hiányában).

Vannak hasonló problémák az ASF konténerben?

Re: Újra a hang deszinkronizálásáról

Például, ha a buszon történő rögzítés a tuner "hardver képességek", akkor miért íródott a segítség, hogy csak az "disszinkronizálás valószínűsége csökken"?


Amennyire megértem, az okok a következők:
1) a képsebesség kissé eltérhet a másodpercenként 25 képkockából, azaz például 25.002 (valamilyen okból mindig ezt teszem). Az AVI fejlécben a BTV program pontosan 25-et tesz fel. Amikor játszol, megkapod a desyncot
2) ha a keret leesik, (ha a terhelés nagy, a szinkronizálás sikertelen, vagy ott, a csillagok nem így vannak), az avi fájlban lévő képeket kihagyják, és a megfelelő hangot rögzítik. Ismét a desync.

Aztán, amennyire megértettem, a "Sound Bind" jelölés csak akkor működik, ha a forrásjel elveszett?


Ahogy ezt megértem, a hatás ismét egy képsebességgel fordul elő, amely nem egyenlő a 25. Ie-vel. rendszeresen a chip / szoftver kivágja az "extra" -t vagy hozzáadja a hiányzó hangot. Valójában ez egy kicsit megtakarít a deszinkronoktól, de gyakran hangos spetsseffekty-t jelent - a "kötés" idején, amikor valaki kicsit dobba dob, vagy inkább egy tambourine-ba. (emlékeztet minden adminisztrátor és programozó kedvenceire a "tambourine-tánc" kifejezéssel).

Talán így van, és érdemes bevonni?


Régen bekapcsoltam, amíg észrevettem, hogy ez tamburinhez vezet.

Továbbá nem világos, hogy miért nem ajánlott a "váltakozó" puffer a nagy áramlásokhoz? Miért van szükséged pufferelésre, ha nem nagy tételekre? És milyen problémák merülhetnek fel ebben az esetben?


Csatlakozom a kérdéshez

Ochchen szeretne normális magyarázatot kapni a támogatásról az AVI rögzítési problémákért és az optimális beállításokért.


Ismerem ezt a technikai támogatást. Azt fogják mondani - mi nem hibáztatjuk, az AVI hibás, megragad az mpeg2-ben, asf, vmv. Bár igazuk lehet.

Vannak hasonló problémák az ASF konténerben?


Úgy tűnik, nincs. Úgy tűnik, minden csodálatos. A probléma csak a felvétel feldolgozásának kellemetlensége, bár valószínűleg győztes.


Az út során szeretnék egy kérdést feltenni a témáról a Sapport / admin számára.
Amikor az Avi-ba rögzítem, mindig kapok (a naplóból): 0 fallouts, az átlagos frame rate 24.998. Az AVI fejlécben 25 képkocka van => 100% -a a desync. A virtuális tölgyben ellenőrizem a "videofelvétel sebességének módosítását, így az audio- és a videóhosszúság megegyezik". A tölgyfa képessége 25.002. Ugyanakkor nincs desynchronizmus. Arra kérem, hogy elmagyarázza ennek az egésznek az okait, és hogyan kell kezelni.

Re: Újra a hang deszinkronizálásáról

Ismerem ezt a technikai támogatást. Azt fogják mondani - mi nem hibáztatjuk, az AVI hibás, megragad az mpeg2-ben, asf, vmv. Bár igazuk lehet.

Kedves admin, köszönöm a választ.
Az a tény, hogy a Beholder minden jó felhasználója nem követeli meg a fejlesztők számára, hogy felelősek legyenek a "felügyeleten kívüli területekért", legyen az akár chipset vagy konténer munkája. Szeretném kapni a legátfogóbb válaszokat a "hatalmad" sajátosságairól. Ráadásul, ki a legjobban tudja, és tanácsot ad a termék (hardver + szoftver) használata során felmerülő problémák elkerülésére vagy megoldására. Például rögzíthet egy AVI tárolóban. Igen, más helyeken alaposan megvizsgálhatom az összes kapcsolódó problémát (és most csinálom), még az iuvcr oldalon is, legalábbis az api-hoz. De amikor valódi cselekvésekre kerül sor (az elfogás végrehajtása), az iuvcr-vel (például) már nem tud segíteni, ha valamilyen konkrét munkamódszerrel (például az disszinkronizálás problémáinak megoldása) jönnek működésbe, csak te segíthetsz.
Vagyis (véleményem szerint) részletesebb bemutatásra van szükség (a meglévő segítséghez képest).

Ismétlem, hogy itt szeretnék megbeszélni a problémákat azzal, hogy az AVI TV jelet leveszem, és a PCI buszon keresztül, csepp nélkül, kellemesen hangzik.

Itt egy ilyen különleges helyzetre gondolok, hogy tisztázhatnám a következőket:

1. Fogja meg a hangot - a buszon keresztül, a rögzítés során a csipkén keresztül hallgatva. Ez valahogy hatással lesz a sabzhra? Vagy táncos tánc?

2. Megértettem helyesen, hogy a szinkronizálás nemcsak vas és jel miatt, hanem a tároló működtetése miatt is?

3. Mely rögzítési paraméterek, például a konténer (itt - "Mode" és "Main stream") és a "common" (itt - "kötés") optimálisak lesznek a VDube további hangolási frekvenciáihoz (amint fent említettük)?

3a. Azonnal - részletesebb magyarázatot szeretnék kapni a "Snap" -ról. Paraméter, amit plusz és mínusz (a segédben leírtakon kívül). Tudatosabban szeretném használni (ha létezik).

3b. A buszon való írás közben nem ajánlatos a fő audió adatfolyamot beilleszteni. MIÉRT?

Segítség:
"Az" Audio "üzemmód használata esetén a képsebesség átlagos értékének kis eltérése egy irányban vagy egy másik irányban"

törekvés:
admin:
"a [konténer] felhalmozza a belső statisztikáit, és az így kapott képarány (általában nem kerek, például 24.996) a bejegyzés vége után tárolja az AVI fájl fejlécében"
Hamis.
Ez csak a fő stream-hanggal működik. Ha nincs, akkor a törtet statisztikában nyomtatja ki, és csak a fejlécben rögzíti az egészet, amelyet "megosztunk" (velünk) a Dubba. Amit AlexCrush írt. A végső frekvencia egyik esetben sem esik egybe az eredeti frekvenciával.

3c. A megbomlott pufferolt (igen még titokzatos teljes).
Nos, teljesen nem elégedett a "segítő" leírással. Írja be az XP-t egy ilyen hasznos paraméter, de nem kell tartalmaznia, különben probléma. MI? Milyen patakokkal? A stream nem több mint 5 MB / s (MJPEG, Q = 19,768x576).

Megnéztem a rögzített fájlokat. Mindenütt a felvételt AVI, MJPEG codec (19), audio - PCM (mono, 32 kHz, 16 bit, h / w PCI) végzi. AVI mux interleaving. Pufferelt (csak XP).

Fájl c AVI mux master stream: Nincs.

13: 50: 21.562 A felvételi feladat sikert indított.
15: 10: 01.468 Felvételi feladat leállítása.
Összesen rögzített keretek. 119450
Összesen leadott keretek. 0
Átlagos képsebesség. 24.998 fps

File c AVI mux master stream: Hang.

21: 28: 35.890 A felvételi feladat sikert indított.
22: 56: 35.390 A felvétel leállása.
Összesen rögzített keretek. 131968
Összesen leadott keretek. 0
Átlagos képsebesség. 24.998 fps


Vannak fájlok a MainStream = None nélkül desync nélkül. Bár nincsenek fájlok a MainStream = Audio disszinkcióval.
Ie mint a MainStream = Az audio egy probléma mentése. De valahogy nem meggyőző.
Kérdések a támogatáshoz:
0) Miért mindig a napló 24.998? Hogyan számít ez, és általában a valósághoz kapcsolódik?
1. 3) Az r.aleks kérdései

1. Fogja meg a hangot - a buszon keresztül, a rögzítés során a csipkén keresztül hallgatva. Ez valahogy hatással lesz a sabzhra? Vagy táncos tánc?


Nem, nem fog. A felvétel bármilyen módon jobb, mint a PCI, mert a hangkártya (az illesztőprogram és a különböző mintavételi frekvenciák) csak súlyosbíthatja a szinkronizáción kívül.

2. Megértettem helyesen, hogy a szinkronizálás nemcsak vas és jel miatt, hanem a tároló működtetése miatt is?

3. Mely rögzítési paraméterek, például a konténer (itt - "Mode" és "Main stream") és a "common" (itt - "kötés") optimálisak lesznek a VDube további hangolási frekvenciáihoz (amint fent említettük)?


Ami a tartályt illeti, ez bizonyos mértékig önmagában is egy dolog. A belső algoritmusok részletei nem állnak rendelkezésre. Ezért érdemes táncolni egy tamburinnal, talán egyes paraméterek kombinációja gyengítheti vagy súlyosbíthatja az disszinkronizációt. Egyáltalán nem mondhatjuk.

3a. Azonnal - részletesebb magyarázatot szeretnék kapni a "Snap" -ról. Paraméter, amit plusz és mínusz (a segédben leírtakon kívül). Tudatosabban szeretném használni (ha létezik).

3b. A buszon való írás közben nem ajánlatos a fő audió adatfolyamot beilleszteni. MIÉRT?


Nem, nem az. Semmi nem adódik az áramláshoz. Ezenkívül az AVI-áramot maga a multiplexer képezi, és ennek a képződésnek a folyamata már nem különösebben elérhető számunkra.

Meg tudja mondani nekem, miért derül ki, hogy a naplófájlban a frame rate 24.998, és a fájl fejlécében - RARE 25.

Kedves admin, nagyon köszönöm a választ.
A kábellel érthető.
A kötésről (igen, ez a hang a képsebességnek, van egy másik, és nincs). Ahogy ezt megértem, a valódi frame rate soha nem 25, így még jó jel esetén is rendszeresen működik? Vagyis annak fő célja egy összetett forrás megragadása, amikor szükséges a "perestroika" zaj felmerülése?
És milyen időkben működik? Észrevettem ezt körülbelül egyszer.

Az utolsó bekezdéshez egy különleges köszönet.
A teljes puffer meghajtó munkáját illetően az, hogy az ablak videó feldolgozásában?
És mi az oka a hangminták érkezésének felfüggesztésében? Valami borzalmas történnie kell.
És mi van a pufferrel?

Mondja meg, hogy az ASF konténer (különösen) tényleg megoldja a problémát?

Általában rengeteg kérdés merült fel, de először megpróbálom felvenni a tudásomat. De akkor újra kell aggódnia.

Kapcsolódó cikkek