Dotaz: Titulky do Matrosky

[Vtipnéř]

Všechny zdravím.

Zkoušel jsem do kontejneru Matroska vložit pomocí ffmpeg titulky v kódování CP1250. Titulky se vložily, ale čeština byla v háji. Přitom když titulky načítám z externího soubory, je to bez problémů. Když jsem použil UTF-8, tak to taky fungovalo, takže bych tipnul, že ffmpeg fonty nějak překódoval.

Na internetu jsem našel volbu pro ffmepg -sub_charenc, kterou by se mělo nastavit kódování, ale moje verze ffmpeg ji nezná. (Mám Debian stable.)

Díval jsem se do dokumentace avconv, ale tam jsem tuhle volbu taky nenašel. Věděl by někdo, co by pomohlo?

Jirka

---

---

Odpovědi

[MadCatX]

Tipnul bych si, že při přidání titulků přes ffmpeg se nastaví jejich kódování na UTF-8 a přehrávač pak předpokládá, že v něm ty titulky jsou. Pro správu MKV souborů používám "mkvmerge" ze sady nástrojů "mkvtoolnix". Má to CLI i GUI rozhraní. CLI jsem nezkoušel, v GUI lze obsah MKV kontejneru jednoduše naklikat; kódování i jazyk titulků se tam dá nastavit.

[Kazatel]

Potvrzuji chování. Když stáhnu titulky a přibalím do kontejneru, je čeština v háji. Proto před mkvmerge dělám iconv -f CP1250 -t UTF8 -o out.txt input.txt

Pak přibalím input a je to OK. Jestli má mkvmerge přepínač na kódování, tím líp. Zatím sem to nestudoval.

[MadCatX]

V GUI mkvmerge (mmg) je na kartě "Format Specific Options" nabídka "Charset", kde lze kódování titulků nastavit. Nemám to teď na čem vyzkoušel, ale vzpomínám si, že to fungovalo. Možná bude záležet na přehrávači, zda příslušné pole přečte a zařídí se podle něj.

[Kazatel]

Problém je v tom, že já to dělám z cli rozhranní :)) Tam klikadlo nemám a ani nechci... :) (typicky si stáhnu titulky v archivu na headless serveru a potřebuju je kovertovat + přibalit do kontejneru)

[Kazatel]

I když mohl bych ozkoušet sub-charset podle webu by to mohlo být to, co hledám a ušetřil bych si tím jeden krok...

[kulich]

Taky používám mkvmerge GUI a bez problémů.

[Vtipnéř]

Díky za tipy, vyzkouším.

Jirka

[kulich]

jinak když mám problém s kodováním použiji enca -c titukly.sub překonvertuje do znakove sady na pc

[Vtipnéř]

Překonvertovat titulky do libovolné znakové sady není problém. Ale v XBMC na RaspberryPi mám nastaveno kování CP1250, protože v něm je převážná většina titulků.

[Vtipnéř]

v xbmc by melo byt enca, to uhadne kodovani a zobrazi to spravne

v mplayeru to taky mam

jinak v mkv by vzdy mely byt titule utf8 a prehravac uz si to sam nejak prekonvertuje

[Vtipnéř]

jinak v mkv by vzdy mely byt titule utf8 a prehravac uz si to sam nejak prekonvertuje

Aha, myslím, že tohle je ta zásadní informace. V XBMC mám nastaveno, že titulky jsou v CP1250, ale podle toho, co píšete, se to týká jen titulků v externím souboru. Tím by byl problém vyřešen. Ještě to otestuju.

Jirka

[Vtipnéř]

Testování dopadlo úspěšně, i např. mplayer zobrazuje titulky správně, když má nastaveno, že titulky jsou v CP1250, a v mkv jsou uloženy v UTF8.

Jirka

[trubicoid]

ano, presne tak to ma byt, kodovani vybiras jen pro externi titule napr. v srt, v mkv vzdy utf8

a kdyz jeste pouzijes enca, tak se kodovani v srt samo uhadne

[pavlix]

a kdyz jeste pouzijes enca, tak se kodovani v srt samo uhadne

Jak moc spolehlivé to vlastně je? Kdysi jsem si na to psal vlastní tool jen tak cvičně a pro čtení se to chytalo docela dobře. Cokoli co lze číst jako utf-8 bylo většinou skutečně utf-8 nebo jeho podmnožina. Trochu horší byla osmibitová kódování, kde nebylo moc možné určit kódování bez odhadování jazyka, i když pro čtení taky celkem v pohodě. Trochu horší je odhadovat skutečné kódování, pokud by člověk chctěl zapisovat a zachovat ho, tam je to často nemožné a jinak dost obtížné.

[trubicoid]

ja titule moc nepouzivam, ale kdyz, tak to vzdy samo uhadlo kodovani; no mozna se najde nejakej specialni pripad, kdy to nefunguje

enca vyzaduje, abys rekl, co to je za jazyk (-L ), to si ulozis do nastaveni

enca --list languages

belarussian: CP1251 IBM866 ISO-8859-5 KOI8-UNI maccyr IBM855 KOI8-U

bulgarian: CP1251 ISO-8859-5 IBM855 maccyr ECMA-113

czech: ISO-8859-2 CP1250 IBM852 KEYBCS2 macce KOI-8_CS_2 CORK

estonian: ISO-8859-4 CP1257 IBM775 ISO-8859-13 macce baltic

croatian: CP1250 ISO-8859-2 IBM852 macce CORK

hungarian: ISO-8859-2 CP1250 IBM852 macce CORK

lithuanian: CP1257 ISO-8859-4 IBM775 ISO-8859-13 macce baltic

latvian: CP1257 ISO-8859-4 IBM775 ISO-8859-13 macce baltic

polish: ISO-8859-2 CP1250 IBM852 macce ISO-8859-13 ISO-8859-16 baltic CORK

russian: KOI8-R CP1251 ISO-8859-5 IBM866 maccyr

slovak: CP1250 ISO-8859-2 IBM852 KEYBCS2 macce KOI-8_CS_2 CORK

slovene: ISO-8859-2 CP1250 IBM852 macce CORK

ukrainian: CP1251 IBM855 ISO-8859-5 CP1125 KOI8-U maccyr

chinese: GBK BIG5 HZ

none:

[pavlix]

enca vyzaduje, abys rekl, co to je za jazyk

Tak to je dost na hovno a stálo by za vylepšení. Moje ročníkovka na střední na pár řádků už nevím v jakém jazyce zvládala detekovat kódování společně s jazykem za pomoci podobné tabulky, kdy záleželo na pořadí kódování pro daný jazyk a při podmnožině několika známých kódování se použilo to, které bylo na seznamu pro daný jazyk dříve.

[trubicoid]

Enca is an Extremely Naive Charset Analyser

tak muzes to vylepsit :)

http://cihar.com/software/enca

https://github.com/nijel/enca

[pavlix]

Budu o tom uvažovat, akorát toho mám na TODO list trochu víc a z oblastí, co mě více zajímají, případně jsou to věci, které jdou obhájit jako součást mojí práce, u tohoto bych si nebyl úplně jistý.

[j]

UTF-8 poznas snadno, soubor by mel mit na zacatku hlavicku. Zbytek je prevazne o tom, ze se hledaji konkretni znaky, v idealnim pripade se dela neco jako frekvencni analyza(= vemes nejakej dostatecne velkej vzorek pro danej jazyk, znej si zjistis jak casto se vyskytuje ten kterej znak a pak zjistujes neznamej text), kde je uspesnost prakticky 100%. Dokonce se da vpohode takhle rozlustit i kodovani zcela neznamy (treba prehazeni znaku podle nejaky kodovaci tabulky).

[pavlix]

UTF-8 poznas snadno

S tím bych ještě souhlasil, stačí se pokusit daný bajtový řetězec jako utf-8 interpretovat a v případě úspěchu ho za utf-8 prohlásit.

soubor by mel mit na zacatku hlavicku.

Ovšem toto se nebojím prohlásit za čirou idiocii. Kódování utf-8 žádnou (povinnou) hlavičku nemá, navíc hovořit o detekci kódování v kontextu toho, že jinak čistě textový soubor opatřím hlavičkou s informací o kódování, to jaksi nedává smysl. Já osobně jsem se do kódování utf-8 bez jakýchkoli hlaviček zamiloval kvůli jeho výtečným znalostem především v kontextu ASCII světa, mezi něž patří, že nad utf-8 řetězci a soubory fungují prakticky všechny operace stejně jako nad ascii souborem. Snad jedinou výjimkou jsou operace vyžadující práci s počtem znaků. Ovšem pro utf-8 opatřené nesmyslnou značkou pořadí bajtů v kódové jednotce, kterou je jediný bajt, už touto vlastností neoplývá a osobně ho tak považuju za podobný odpad jako utf-16.

TL;DR verze: Nikoliv, u textových souborů v osmibitových kódováních včetně utf-8 se minimálně na unixových systémech nevyžaduje hlavička označující kódování. A můj osobní názor je, že systémy, které jen a pouze u tohoto konkrétního osmibitového kódování vyžadují speciální hlavičky v textových souborech, jsou idiotsky navržené.

Zbytek je prevazne o tom, ze se hledaji konkretni znaky, v idealnim pripade se dela neco jako frekvencni analyza(= vemes nejakej dostatecne velkej vzorek pro danej jazyk, znej si zjistis jak casto se vyskytuje ten kterej znak a pak zjistujes neznamej text)

Analýza frekvence jednotlivých znaků je sice super věc na hraní, ale u detekce jazyka/kódování krátkých textů (v řádu jednotlivých vět) se mi vůbec neosvědčila, což by u detekce jazyka/kódování obecných souborů mohl být docela problém, ale pravda je, že na titulky by to stačit mohlo.

[Josef Kufner]

Druhý případ je řazení podle abecedy. Tam také řadící program musí rozumět použitému kódování.

A UTF-8 BOM (ta hlavička) byl naprosto debilní nápad, který rozbíjí snad úplně vše. Ta hlavička má v UTF-8 tři byty a je zcela na nic, neboť Byte-Order-Mark u kódování, kde pořadí bytů (little/big endian) je pevně dáno (slova jsou jednobytová), ani nemá smysl.

[pavlix]

Druhý případ je řazení podle abecedy. Tam také řadící program musí rozumět použitému kódování.

Pravda, akorát že nějaké řazení vznikne i z toho utf-8 a na cokoli lepšího by stejně člověk potřeboval aplikovat národní pravidla a občas i jejich úpravu pro specifické využití.

[Josef Kufner]

Nějaké řazení je i náhodné Ale jinak jo, pokud zrovna člověk nemá písmenka s diakritikou na začátcích slov, tak je to v pohodě.

[pavlix]

Tak toto řazení ani není náhodné. Jednak je kompatibilní s výchozím řazením ASCII, jednak řadí dvoubajtové znaky podle unicode code pointu, akorát že je jako celek řadí za ty jednobajtové. Takže ani člověku (většinou programátorovi) nedělá problémy si to řazení velmi rychle osvojit. Ideální pro případ, že skutečně držíš data v UTF, nemáš k dispozici informace o národním řazení a víš, že by ti takovéto univerzální mezinárodní řazení unicode nic kromě zatížení procesoru nepřineslo. Ale je fakt, že to už vedeme takové teoretické plky.