Bitraten på DR HD efter MKV remux
Udskrevet fra: recordere.dk - Danmarks AV Forum
Kategori: Modtagelse og distribution
Forumnavn: Det digitale sendenet
Forumbeskrivelse: DTT nettet incl. Boxer (DVB-T)
Web-adresse: https://forum.recordere.dk/forum_posts.asp?TID=74161
Udskrevet den: 07-Februar-2025 kl. 12:56
Emne: Bitraten på DR HD efter MKV remux
Skrevet af: JesperLund
Emne: Bitraten på DR HD efter MKV remux
Skrevet den: 17-Januar-2010 kl. 19:34
|
Når jeg optager noget fra DR HD, som jeg gerne vil gemme, bruger jeg Matroska formatet, i hvert fald så længe DR HD ikke sendes med DVB undertekster på YouSee DVB-C som er min primære kilde. TS containeren har cirka 5% overhead i forhold til MKV, men jeg har bemærket at MKV filstørrelsen er væsentligt mindre end TS filstørrelsen, svarende til at stream bitraten (video+audio) er meget lavere. Formålet med dette indlæg er at rapportere denne observation og finde en forklaring (jeg har en teori, men er ikke sikker). Jeg vil ikke skrive en lang instruktion i hvordan man laver Matroska udgaver af DR HD, men ganske kort har jeg brugt følgende fremgangsmåde: 1. Optagelse på Dreambox DM600C 2. Brug TS-Doctor til at beskære optagelsen samt fjerne overflødige PID'er (teletext) 3. Demux video + audio med TsMuxer (TsRemux kan også bruges, men TsMuxer håndterer audio delay automatisk) 4. MKV muxing med mkvmerge. (Den opmærksomme læser vil bemærke at DM600C ikke er en MPEG4 box, og det er fuldstændigt rigtigt. Men den kan sagtens optage DR HD, og efterfølgende bruger jeg min Popcorn Hour A-100 til at se optagelsen, enten den rå TS eller en remuxet MKV udgave, typisk det sidste). Jeg har også lavet denne øvelse et par gange på DVB-T udgaven af DR HD, mere om det i slutningen af indlægget (optagelsen er lavet med et PC DVB kort på Linux). Nedenstående tabel har 17 DR HD optagelser, som efterfølgende er remuxet til MKV format. Jeg har angivet dato for optagelsen samt den samlede stream bitrate i TS og MKV filen, begge i Mbps. Bitraten er fra MediaInfo. Alle DVB-C optagelser er lavet før der kom AC3 lyd hos YouSee, så bitraten dækker over video og et 384 Kbps MPEG-1 Layer II audio track (samt container overhead, hvor der spildes ca 4% på de små 188-byte pakker i TS containeren) TS MKV Breach 4/11 11.7 8.6 End Game 28/11 11.5 8.2 First Blood 18/12 11.5 9.9 Godsend 3/11 11.6 7.6 Heat 30/12 11.5 5.8 Runaway Train 31/12 11.5 10.2 The Constant Gardener 25/11 11.5 8.4 The Getaway 4/12 11.5 10.7 Zorro 11/12 11.5 6.7 The Presido 30/12 11.5 10.5 Undercover (10th & Wolf) 8/12 11.5 7.6 War of the World 13/11 11.5 10.8 Wallander 1/3 - 22/12 11.5 5.6 Wallander 2/3 - 29/12 11.5 5.8 Wallander 3/3 - 5/1 11.5 5.3 Infernal Skanderborg 31/12 11.4 11.0 Livvagterne 11+12 - 10/1 11.5 8.4 Bitraten for YouSee TS filen svarer til hvad vi har observeret tidligere. Næsten CBR med 11.5 Mbps. Ingen overraskelsen her. HDTV er cool, jubiiii.  Derimod er det underligt at bitraten falder så meget når jeg laver remux til MKV format. Den teoretiske forskel på grund af TS containerens overhead skulle svare til ca 11.0 Mbps i MKV stream bitrate, men det er kun Infernal koncerten som opnår dette. De andre ligger langt lavere, specielt Wallander mini-serien og filmen Heat den 30/12 (jeg synes ikke at Heat så specielt "HDTV-agtig" ud, og bitraten bekræfter sådan set dette). Jeg har som nævnt også prøvet at lave MKV remux af DVB-T optagelser af DR HD, og nedenfor rapporterer jeg bitraten for "Heat". Det skal dog understreges at mine DVB-T modtageforhold ikke er optimale, og at jeg har nogle uopklarede lip-sync problemer i MKV udgaven men ikke TS udgaven. Bitraten er for video + to audio streams (2.0 og 5.1 HE-AAC) Heat DVB-T 30/12: TS = 9.54 Mbps, MKV = 3.31 Mbps (det kan næsten ikke passe??) Jeg har også Casino Royale på DVB-T men her var der endnu større problemer med modtagelsen (ja, indendørs antenne i København sucks!), og jeg har slettet MKV filen igen. Den kan dog genskabes, hvis det skal være. Det gode spørgsmål er nu: hvad er årsagen til dette voldsomme fald i bitrate? Lad mig starte med at udelukke at det skyldes re-encodning. Mkvmerge operation tager kun et par minutter, og det er helt udelukket at dette program re-encoder til en lavere bitrate. Demuxing operationen tager ligeledes kun et par minutter, og filstørrelsen falder ikke ved demuxing til elementary streams. Det er først med MKV muxing at dette sker. Der er heller ikke tale om at der mangler noget i MKV filerne. Jeg har set de fleste DR HD udsendelser efter MKV remux, ikke med den oprindelige TS. Min umiddelbare teori er at der er ekstremt mange "stuffing bytes" (tomme bytes) i TS filen, og at mkvmerge fjerner dem fra H264 elementary stream inden der muxes. Jeg er i gang med at inspicere TS pakker, men jeg er ikke kommet så langt endnu med dette. Opdatering følger, når jeg får tid... Anyways... i mellemtiden kan det være at der kommer andre forklaringer på banen? Gerne fra de teknikere som er begyndt at skrive på forumet.  Det kunne også være interessant at få målt bitraten på TS kontra MKV-remux niveau på andre kilder end YouSee DVB-C, for eksempel DVB-T (med bedre modtageforhold end mine), Stofa DVB-C og DVB-S fra Canal Digital og Viasat. Det kan kun gøres af folk med PC modtagere eller ikke-officielle DVB PVR boxe, som Dreambox, hvor man kan få "lov" til at hive optagelserne ud til videre analyse. Jeg har ikke andre HD kanaler end DR HD, så jeg kan ikke sige om bitraten på dem også er lavere efter MKV remux. Da det er H264 encoderen som indsætter stuffing bytes (og YouSee encoder selv så vidt jeg ved), kunne det bestemt være interessant at teste dette. Men eftersom jeg ikke gider betale for andet end grundpakken hos YouSee, kan jeg desværre ikke gøre dette selv. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Svar:
Skrevet af: HeartWare
Skrevet den: 17-Januar-2010 kl. 21:20
|
Jeg kan bekræfte disse observationer. Jeg har ikke udregnet bitrater, men min optagelse af Star Trek: Insurrection i går resulterede i en .ts fil efter gennemløb i TS Doctor for at klippe til på 7,87 Gb, men efter remux til .mkv fylder den kun 4,03 Gb. Varigheden på begge filer er 1 time og 34 minutter, så kan en anden regne bitraten ud . ------------- Keld R. Hansen Pioneer DVL-909, DV-545 Sony KDL40EX723 3D TV DreamBox 8000, YouSee Cable PopCorn Hour A-500 Panasonic DMR-BCT820 + DMR-BCT940 Yamaha RX-V771 Receiver |
Skrevet af: JesperLund
Skrevet den: 18-Januar-2010 kl. 18:25
|
http://forum.doom9.org/showthread.php?p=1362330#post1362330 - Dette doom9 indlæg rapporterer en tilsvarende observation fra nogle tyske HDTV broadcasts. Der henvises til indlæg (på tysk), hvor MKV remux har filstørrelser ned til 50% af den oprindelige TS. De tyske indlæg, som doom9 indlægget henviser til, forklarer det med NALU padding, hvis formål skulle være at få en forud fastsat bitrate i situationer hvor billedet ikke indeholder tilstrækkelig information til encoderen (så der paddes med null bytes indtil den ønskede bitrate opnås). Et andet formål kan være at padde en VBR stream til CBR. Jeg synes bare ikke at det giver mening i DVB-C (hos YouSee) eller DVB-T (digi TV) sammenhæng, da udgangspunktet for H264 encodningen skulle være et 1.5 Gbps SDI HDTV signal. Der burde ikke være noget problem ved at fyre 12 Mbps af på en 720p@50fps stream. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: JesperLund
Skrevet den: 18-Januar-2010 kl. 18:34
Dette er en vild spekulation fra min side, men jeg kom til at tænke på følgende... Alt hvad jeg har optaget, med undtagelse af Infernal koncercen. er 25 fps materiale som er frame-doubled til 50 fps (Infernal er skudt med 50fps). At encode 25fps der er frame-doubled til 50fps bør ikke kræve ret meget mere bitrate end den rene 25fps stream, men måske sker allokeringen af bitrate til encoderen ud fra at det er ægte 50 fps materiale, og så går der noget "galt" efterfølgende? Lad os håbe at der kan blive kastet mere lys over sagen i de forhåbentligt kommende indlæg i denne tråd. Lige nu får vi ikke den bitrate på DR HD som vi tror at vi får!! ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
JesperLund skrev:Skrevet af: Hansemand
Skrevet den: 18-Januar-2010 kl. 22:22
|
Jeg kan også bekræfte disse forskelle. Et Eks. af mange. Legenden om Zorro som ts=8014,5 og som Mkv=3114,5 incl. omkodet HE-AAC 5.1 lyd til 5.1 448 Kbps. ac3 lydspor. ------------- Mvh Hansemand |
Skrevet af: xcardman
Skrevet den: 18-Januar-2010 kl. 22:26
hvilket program bruger du til remux. har endnu ikke fundet et som kan tage HE-AAC lyd. |
Skrevet af: JesperLund
Skrevet den: 18-Januar-2010 kl. 22:28
Du må meget gerne lave et par eksempler mere til dokumentation. Problemet synes at være en del værre på DVB-T end YouSee DVB-C. Med Zorro mister du over halvdelen af bitraten!! ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Hansemand
Skrevet den: 18-Januar-2010 kl. 22:55
Det er en lang og besværlig vej. Kort fortalt: Klip/fix i TsDoctor/Igennem Vlc uden konvert/import lyd i Avs audio editor, gemme i 24000 khz pcm/import wav i Audacity og gem som export multiple i 48000 khz. Så har du 6 mono Wav filer til feks. besweet. Mux i TsMuxer. Jeg kan ikke gi' flere eksempler på diff, bitrate idet jeg har slettet ts filerne efter jeg lavede mkv filerne. Highlander er 7662,7, Tiger på spring, drage i skjul 2799,9 i Mkv. ------------- Mvh Hansemand |
Skrevet af: JesperLund
Skrevet den: 20-Januar-2010 kl. 18:24
|
TS Doctor 1.0.17 viser nu andelen af "filler data" i H264 streams. Jeg checkede et par TS filer, og andelen svarer cirka til den reduktion som opnås ved MKV remux. For min DVB-T optagelse af Heat den 30/12 var 62% filler data!! Er der nogen som har DVB-T optagelser af DR HD fra starten af november? Som bekendt blev bitraten forøget fra slutningen af november, men hvis det primært er sket ved at forøge mængden af "filler data" har det ingen betydning for billedkvaliteten. Jeg kan se at jeg har Breach fra den 4/11 (DVB-T) liggende på en af mine harddiske, og den stream vil jeg analysere næste gang jeg er på Windows (TS Doctor kører desværre ikke under Linux). TS Doctor 1.0.17 giver mulighed for at fjerne filler data fra TS filen (eksperimentel feature, ikke fuldt testet endnu). Dette kunne måske være et alternativ til MKV remux, specielt for DVB-T streams hvor der er en del problemer med at remuxe HE-AAC lyden til MKV (Hansemand's procedure er ikke ligefrem simpel). Jeg vil prøve den nye feature i TS Doctor på min Heat DVB-T optagelse snarest for at se om det har nogle uheldige sideeffekter. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Hansemand
Skrevet den: 20-Januar-2010 kl. 19:51
Jeg har lige kørt Charlies Angels igennem TsDoctor 1.0.17 og den blev ca. 1,3 gb mindre i forhold til samme klip i VideoRedo. Jeg har ikke tid til at gå filmen igennem sådan lige nu. Det ser ud til at DR tager rø... på moder Danmark
------------- Mvh Hansemand |
Skrevet af: JesperLund
Skrevet den: 20-Januar-2010 kl. 20:25
Hvad står der i logfilen om andelen af H264 filler data (sidst i logfilen, jf. eksemplet nedenfor) --------- NAL Unit Type Statistic --------- Slices : 481096 I-Slices : 15445 P-Slices : 14632 B-Slices : 451019 SP-Slices : 0 SI-Slices : 0 Data Partition A : 0 Data Partition B : 0 Data Partition A : 0 IDR Picture : 1 SEI : 962196 Sequence Parameter Set : 15446 Picture Parameter Set : 46340 AUD : 481098 End of Sequence : 0 End of Stream : 0 Filler : 405898 Slices : 0 Seq. Param. Set Ext. : 0 H264 filler data: 62.4% [Netto] Cutted pakets at the beginning: 0 Cutted pakets at the end: 0 Discarded pakets (not needed): 12212 ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Hansemand
Skrevet den: 20-Januar-2010 kl. 22:11
|
--------- NAL Unit Type Statistic --------- Slices : 267111 I-Slices : 8758 P-Slices : 8033 B-Slices : 250320 SP-Slices : 0 SI-Slices : 0 Data Partition A : 0 Data Partition B : 0 Data Partition A : 0 IDR Picture : 0 SEI : 534222 Sequence Parameter Set : 8758 Picture Parameter Set : 26274 AUD : 267111 End of Sequence : 0 End of Stream : 0 Filler : 89315 Slices : 0 Seq. Param. Set Ext. : 0 H264 filler data: 20,0% [Netto] Cutted pakets at the beginning: 1516090 Cutted pakets at the end: 1520394 Discarded pakets (Filler data): 7087460 = 20,1% [Brutto] Discarded pakets (to synch audio/video): 949 Discarded pakets (not needed): 23495 ERRORS : 0 WARNINGS : 4 Speed: 5,9 MBytes/sec Duration: 00:17:44 ------------- Mvh Hansemand |
Skrevet af: dkscan
Skrevet den: 20-Januar-2010 kl. 22:33
|
Blot for sammenligningens skyld, så prøvede jeg med Charlies Angels optaget fra YouSee: --------- NAL Unit Type Statistic --------- Slices : 272693 I-Slices : 12103 P-Slices : 56071 B-Slices : 204519 SP-Slices : 0 SI-Slices : 0 Data Partition A : 0 Data Partition B : 0 Data Partition A : 0 IDR Picture : 0 SEI : 272693 Sequence Parameter Set : 12103 Picture Parameter Set : 12103 AUD : 272693 End of Sequence : 0 End of Stream : 0 Filler : 31852 Slices : 0 Seq. Param. Set Ext. : 0 H264 filler data: 7,2% [Netto] Cutted pakets at the beginning: 0 Cutted pakets at the end: 0 Discarded pakets (Filler data): 3015918 = 7,2% [Brutto] Discarded pakets (not needed): 8330 ERRORS : 0 WARNINGS : 0 Speed: 23,2 MBytes/sec Duration: 00:05:21 ------------- Per H. Nielsen http://www.dkscan.dk - Dansk Scanner Information |
Skrevet af: Hansemand
Skrevet den: 21-Januar-2010 kl. 11:13
Hvad har HE-AAC lyden at gøre med MKV? Det eneste problem(og som jeg ønskede løst) var hvordan man får 5.1 lyd på sin Forstærker/reciever og min fremgangsmåde er den eneste jeg kan komme frem til for nuværende. Lettere fremgangsmåde søges selvfølgelig. At konvertere stereo lyden er jo ikke noget problem. F.eks et par klik med musen i VideoRedo og vupti så har du konverteret HE-ACC lyden til mp2. ------------- Mvh Hansemand |
Skrevet af: JesperLund
Skrevet den: 21-Januar-2010 kl. 11:24
Jeg tænkte på lip-sync problemer når HE-AAC lyden muxes ind i en MKV container. Det problem har jeg, men det er meget muligt at jeg er den eneste.. Jeg tænkte ikke på behovet for at sende digital lyd til receiver, og så er det klart at remuxing i TS Doctor for at fjerne filler data ikke vil hjælpe noget. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Hansemand
Skrevet den: 21-Januar-2010 kl. 11:37
Ok, så forstår vi hinanden. Jeg optog "Den sidste pelsjæger" i går aftes og lavede HE-AAC lyden om til mp2 og der var ingen lip-sync problemer i den nye ts fil. Jeg mener heller ikke det sker i en mkv container hvis ellers ts filen spiller ok. Jeg har da efterhånden lavet et "par" mkv filer med godt resultat.------------- Mvh Hansemand |
Skrevet af: JesperLund
Skrevet den: 22-Januar-2010 kl. 01:24
|
Jeg har analyseret lidt videre på H264 filler data og bitraten i to DVB-T streams: Breach optaget lige i starten af november og Heat fra den 30/12. Breach havde 0.1% H264 filler data. Figuren nedenfor viser en graf over bitraten. ABR er på ingen måde imponerende, men optagelsen er som bekendt lavet lige efter 1/11, hvor vi klagede over den lave bitrate på DR HD på DVB-T.  Næste eksempel er Heat, hvor jeg har 62% filler data. Helt ekstremt. Jeg har lavet bitrate grafen dels for den oprindelige TS incl H264 filler data, dels for en trimmet TS hvor jeg har brugt den nye eksperimentelle feature i TS Doctor 1.0.17 til at fjerne H264 filler data. ABR for de to streams er hhv. 9.5 Mbps og 3.5 Mbps (MediaInfo), dvs. når H264 filler data fjernes, er ABR for Heat faktisk på samme niveau som Breach. Her kommer bitrate graferne. Først bitraten incl H264 filler data... (der er en forskel mellem ABR fra MediaInfo og Bitrate Viewer, og jeg er ikke helt klar over om det der muxing overhead eller fordi Bitrate Viewer kun rapporterer bitraten for video streamen; anyways, det er ikke væsentligt for denne sammenligning)  ... og dernæst bitraten for TS filen hvor H264 filler data er fjernet (fuldstændig samme optagelse: Heat sendt den 30/12).  Jeg synes at det er påfaldende at den første graf incl H264 filler data stort set er CBR, dvs. H264 filler data bruges reelt til at lave en CBR stream ud af en VBR encodning. Det giver bare ingen mening (synes jeg) at den statistiske multiplexer og H264 encoderen opfører sig på denne måde og faktisk spilder næsten 2/3 af bitraten?? Jeg har desværre ikke andre DVB-T optagelser fra starten af november (som var brugbare da det kom til stykket). Det kunne ellers være interessant at undersøge om Breach er en enlig svale uden H264 filler data? Hos YouSee DVB-C har der været H264 filler data hele tiden (ca 20% da Breach blev sendt på YouSee i starten af november). ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: JesperLund
Skrevet den: 22-Januar-2010 kl. 02:47
|
Vi kan lige tage samme øvelse med Heat fra YouSee den 30/12. Først bitraten for den rå TS fil, dernæst bitraten for en TS fil hvor H264 filler data er fjernet (dog lavet uden om TS Doctor, nemlig ved at remuxe MKV tilbage til TS) Udgangspunktet er næsten CBR (screendump ser lidt anderledes ud da disse to kørsler er lavet med Bitrate Viewer under Wine på Linux)  ... og når vi fjerner H264 filler data ser det sådan ud  Også her ser det ud til at H264 filler data bruges til at procedure en næsten-CBR stream ud fra en VBR encodning. Husk at dette er YouSee DVB-C mens forrige indlæg er DVB-T, dvs. to forskellige encodere. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: JesperLund
Skrevet den: 23-Januar-2010 kl. 23:02
|
Her er bitrate graferne for Casino Royale på DVB-T (min DVB-C optagelse mislykkedes somehow), først med og dernæst uden H264 filler data. Igen ser det ud som om at H264 filler data bruges til at gøre en VBR encodning til en næsten-CBR video PID i transport streamen. Casino Royale DVB-T med filler data (den modtagne transport stream)  Casino Royale hvor H264 filler data er fjernet (med TS Doctor 1.0.17)  ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: HeartWare
Skrevet den: 31-Januar-2010 kl. 19:29
|
Så har jeg behandlet gårsdagens Star Trek film - fra en 10 Gb .ts fil til en 4.5 Gb .mkv fil...
Dvs. mindre end halvdelen af den tilgængelige båndbredde blev rent faktisk brugt til video-data !!! ------------- Keld R. Hansen Pioneer DVL-909, DV-545 Sony KDL40EX723 3D TV DreamBox 8000, YouSee Cable PopCorn Hour A-500 Panasonic DMR-BCT820 + DMR-BCT940 Yamaha RX-V771 Receiver |
Skrevet af: JesperLund
Skrevet den: 31-Januar-2010 kl. 19:32
Ser dine bitrate grafer ud som ovenstående? (man kan forresten godt gøre Bitrate Viewer direkte på MKV filen, det er ikke nødvendigt at remuxe tilbage til TS). ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: HeartWare
Skrevet den: 31-Januar-2010 kl. 22:32
|
Jeg ved ikke, hvordan du producerer de bitrate grafer, så jeg kan ikke frembringe dem...
Jeg har også lige behandlet "Close Encounters of the Third Kind", og den gik fra ca. 11 Gb til ca. 10 Gb, hvilket sagtens kan være den normale mindre størrelse af .MKV i forhold til .ts filer... ------------- Keld R. Hansen Pioneer DVL-909, DV-545 Sony KDL40EX723 3D TV DreamBox 8000, YouSee Cable PopCorn Hour A-500 Panasonic DMR-BCT820 + DMR-BCT940 Yamaha RX-V771 Receiver |
Skrevet af: JesperLund
Skrevet den: 31-Januar-2010 kl. 22:38
Jeg bruger http://www.videohelp.com/tools/Bitrate_Viewer_2 - Bitrate Viewer . 11 Gb -> 10 Gb er nok lidt mere end TS overhead, men ikke ret meget. Du kan i øvrigt se andelen af H264 filler data i logfilen fra TS Doctor. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: ehelmer
Skrevet den: 09-Februar-2010 kl. 14:26
|
Jeg synes denne diskussion bør fortsætte. Der er alt for mange åbne og ubesvarede spørgsmål. DR HD blev i begyndelsen sendt med en bithatighed på ca 4000-5000 kbps i en variabel bitrate og med en begrænset mængde filler data. Jeg har som eksempel 'Forbrydelsen' fra 22.11.09. hvor der var 18% filler data,. Det gav en reel bithastighed på 4300 kbps. I dag sender DR alle HD udsendelser med en konstant bithastighed på 9000 kbps. Mængden af filler data er nu enormt stor. Den reelle information er kun på de samme 4000-5000 kbps som tidligere. Vi seere får altså ikke et bedre signal, nogle bliver måske blot narret til at tro det. Det har været nævnt at real time kodning af en MPEG4 fil er så krævende at det er nødvendigt med filler data. Det er sikkert rigtigt, men det forklarer ikke hvorfor mængden af disse tomme data nu er steget enormt. Det forklarer heller ikke at alle udsendelser sendes med samme bithastighed, selv pauseudsendelserne med stationære billeder sendes med denne høje bithastighed og en 80% filler data. Hvad er så formålet med denne ændring? Er den lavet for at lukke munden på kværulanter, der klagede over for lille bithastighed? I samme muxer som DR HD sendes DR K og DR Update. De sendes med VBR og uden nævneværdige filler data. Det er svært at se at en MPEG4 kodning af 1280*720 pixel skal være så meget anderledes eller vanskeligere end 704*576. Antallet af pixel er dog kun godt og vel det dobbelte. Hvis vi tænkte os at DR sendte sine HD udsendelser i MPEG2 kodning med 9000 kbps, så ville det ikke være nødvendigt med filler data af betydning. Kvaliteten ville sikkert være mindst ligeså god, som den vi nu får med MPEG4 og en reel bithastighed på 4000-5000 kbps. Er det således ikke en misforståelse at bruge MPEG4 på TV udsendelser, som skal kodes i real time? Er MPEG4 i høj kvalitet i virkeligheden kun egnet til at lave f.eks. BluRay film, hvor der er tid og kraft nok til en effektiv kodning. DR HD sender lyden i det lidt besværlige HE-AAC format. Det må vel være for at spare en ca. 100 kbps på lydkanalen. Den besparelse virker latterlig, når der samtidig bliver brugt ca. 4000 kbps på tomme data i videokanalen. Erik Helmer Nielsen |
Skrevet af: JesperLund
Skrevet den: 09-Februar-2010 kl. 15:55
Lad mig benytte lejligheden til at gentage en tidligere opfordring. Vi mangler 1) Målinger fra DR HD på Stofa og satellit (Canal Digital), hvor der er rapporteret 15 Mbps. Hvad er den reelle bitrate efter filler data? 2) Folk med kenskab til teknikken (statistisk multiplexing, realtime H264 encodning), som har lyst til at give et give et bud på hvad der foregår? #2 kan være lidt tricky, men #1 burde recordere.dk læserne kunne bidrage med. Det kræver blot en PC DVB-modtager (eller STB PVR hvor man kan flytte optagelserne). Det virker som om at der blev pillet ved encodningen på mux2 i slutningen af november, så DR HD fik højere bitrate, men det er tilsyneladende gået til filler data, og det giver ingen mening. Så får vi bare en ringere DR K, Update og Ramasjang (tænk på børnene!), uden at få bedre DR HD. Men det er ikke kun et DVB-T problem. YouSee encoderen har også en stor andel filler data. Jeg mangler at analysere hele mux'et på 442 MHz for at se om det udnyttes fuldt ud, eller om de bruger den officielle PID til filler data (ikke udnyttet og ikke-allokeret kapacitet). Derudover ville det som sagt være nyttigt med analyser af DR HD fra andre kilder (især Stofa og Canal Digital som siger de har 15 Mbps). Jeg har desværre ikke andre HD kanaler hos YouSee (kun grundpakke), men andre kan måske analysere andelen af filler data på de øvrige HD kanaler? Det kunne også være interessant at vide hvorfor andelen af filler data varierer fra udsendelse til udsendelse. Jeg har YouSee optagelser med næsten ingenting og andre optagelser med over 50%. HeartWare har lige nævnt Star Trek med masser af filler data og Nærkontakt af Tredje Grad med næsten ingen. De bedste til at besvare det spørgsmål er selvfølgelig folk med kendskab til de encodere som bruges... ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Mb120
Skrevet den: 09-Februar-2010 kl. 19:32
|
Har lige målt på DR-HD fra canal digital (via satellite) 1280 x 720 : cirka 15500 kbit/s Målt med en DB800 |
Skrevet af: JesperLund
Skrevet den: 09-Februar-2010 kl. 20:42
Har du mulighed for at beregne andelen af H264 filler data, og dermed den reelle video bitrate? Du skal optage et eller andet, for eksempel aftenens film, og overføre TS filen til en PC med Windows, hvor du kører den igennem TS Doctor (downloades http://www.cypheros.de/dvb_e.html - her ). Nederst i logfilen fra TS Doctor er der en linje med "H264 filler data", ligesom eksemplet nedenfor (fremhævet med boldface). --------- NAL Unit Type Statistic --------- Slices : 172458 I-Slices : 7541 P-Slices : 35574 B-Slices : 129343 SP-Slices : 0 SI-Slices : 0 Data Partition A : 0 Data Partition B : 0 Data Partition A : 0 IDR Picture : 0 SEI : 172458 Sequence Parameter Set : 7541 Picture Parameter Set : 7541 AUD : 172458 End of Sequence : 0 End of Stream : 0 Filler : 39272 Slices : 0 Seq. Param. Set Ext. : 0 H264 filler data: 13.2% [Netto] ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Mb120
Skrevet den: 10-Februar-2010 kl. 07:31
| Dette gør jeg iaften |
Skrevet af: B-CLG
Skrevet den: 10-Februar-2010 kl. 09:30
Lige mht. dette punkt, så oplevede brugere af Sonys DVB-T tuner, PlayTV, at DR HD hakkede fra begyndelsen, men blev vist pænt i perioden omkring 30 november til 2. december 2009, hvorefter det begyndte at hakke igen. (På DR K og DR Ramasjang, forsvandt hakkene omkring 7. november, og de er heldigvis ikke kommet igen) Så ja, der pilles! /B |
Skrevet af: ehelmer
Skrevet den: 10-Februar-2010 kl. 14:00
Se også om dette DR HD signal er med konstant bitrate ligesom DR's eget (brug Bitrate viewer). Det er også interessant at vide hvilke andre signaler der bliver sendt i samme Mux (Transponder), samt hvordan de bliver behandlet. Så får vi et fingerpeg om Canal Digital bruger samme udstyr som DR, og om det er indstillet på samme måde. Erik Helmer Nielsen |
Skrevet af: SandSand
Skrevet den: 10-Februar-2010 kl. 16:43
| Jeg har ikke så meget forstand på teknikken. Men hvis jeg har forstået problematikken nogenlunde rigtigt så virker det jo helt gak gak det der foregår. |
Skrevet af: ehelmer
Skrevet den: 10-Februar-2010 kl. 17:18
|
Den tyske ASTRA satellit sender på frekvensen 11362H tre kanaler i HD. Det drejer sig om ARTE, ERSTE og ZDF. De regulære udsendelser starter først 12 Febr., men de sender allerede nu smagsprøver eller reklamespots for deres nye HD kanaler. Jeg har nu fået hentet nogle prøver hjem fra de tre kanaler og analyseret dem på min PC. Det viser sig at de alle tre sendes med ca. 12000 kbps i nærmest konstant bitrate. De er ligesom DR HD fyldt med filler data, dog i stærkt varierende omfang fra 10% op til 60%, i gennemsnit vel 40-50%. Mængden af fyld er sikkert afhængig af billedindholdet, men jeg synes dog ikke helt det kan forklare den store variation. Det ser altså ud til, at det er normalt at TV udsendelser i HD sendes på den måde, åbenbart på grund af problemerne med MPEG4 kodningen. Det må så medføre den konklusion, at det ikke er muligt at udnytte mere end ca. halvdelen af Mux'ens kapacitet når der sendes HD. Vi kan så reflektere over om der er reel baggrund for de ofte berømmede fordele ved at bruge MPEG4 codec'en til netop HD udsendelser. Erik Helmer Nielsen |
Skrevet af: Mb120
Skrevet den: 10-Februar-2010 kl. 20:20
|
Fra DR HD : 1900 -> 1930 H264 filler data: 7,2% [Netto] Kan evt nappe en test på BBC HD eller Discovery HD for en sammenligning hvis det har interresse ? |
Skrevet af: JesperLund
Skrevet den: 10-Februar-2010 kl. 20:24
Gerne, og du må også meget gerne prøve DR HD senere, for eksempel filmen United 93 (der bestemt er værd at se). Men tillykke med den absolut bedste bitrate på DR HD, specielt efter korrektion for filler data. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Mb120
Skrevet den: 11-Februar-2010 kl. 19:45
|
Test fra Discovery HD : --------- NAL Unit Type Statistic --------- Slices : 88643 I-Slices : 3402 P-Slices : 26145 B-Slices : 59096 SP-Slices : 0 SI-Slices : 0 Data Partition A : 0 Data Partition B : 0 Data Partition A : 0 IDR Picture : 0 SEI : 180688 Sequence Parameter Set : 3402 Picture Parameter Set : 3402 AUD : 88643 End of Sequence : 0 End of Stream : 0 Filler : 96758 Slices : 0 Seq. Param. Set Ext. : 0 H264 filler data: 3,7% [Netto] Cutted pakets at the beginning: 0 Cutted pakets at the end: 0 Discarded pakets (not needed): 35169 ERRORS : 0 WARNINGS : 3403 Speed: 17,1 MBytes/sec Jeg kan ikke få TS Doctor til at læse den 12GB fil jeg optog med United 93... ? den kan ikke finde nogen stream... |
Skrevet af: Mb120
Skrevet den: 11-Februar-2010 kl. 20:01
|
Man skulle "bare" forsøge at åbne den nogle gange :-) --------- NAL Unit Type Statistic --------- Slices : 312135 I-Slices : 11935 P-Slices : 66098 B-Slices : 234102 SP-Slices : 0 SI-Slices : 0 Data Partition A : 0 Data Partition B : 0 Data Partition A : 0 IDR Picture : 0 SEI : 636205 Sequence Parameter Set : 11935 Picture Parameter Set : 11935 AUD : 312135 End of Sequence : 0 End of Stream : 0 Filler : 368015 Slices : 0 Seq. Param. Set Ext. : 0 H264 filler data: 10,2% [Netto] Cutted pakets at the beginning: 0 Cutted pakets at the end: 0 Discarded pakets (not needed): 1372469 ERRORS : 0 WARNINGS : 11935 Speed: 15,3 MBytes/sec |
Skrevet af: ehelmer
Skrevet den: 11-Februar-2010 kl. 23:55
TS Doctor viste samme antal filler data, 10%. Bitrate viewer siger at bithastigheden faldt fra konstant 9300 kbps til i gennemsnit 7500 kbps (~19%). De to angivelser passer dårligt sammen. De lærde er åbenbart uenige. Det ret beskedne tal for filler data forekommer rimeligt, da det er en action film med mange bevægelser og hurtige sceneskift. En mere rolig film ville give et højere antal filler data. Erik Helmer Nielsen |
Skrevet af: ehelmer
Skrevet den: 12-Februar-2010 kl. 11:31
Rettelse
Ved at køre TS Doctor en gang mere på den oprindelige fil, så siger den nu 19%. Det stemmer altså fint med Bitrate viewer. Erik Helmer Nielsen |
Skrevet af: eudlek
Skrevet den: 12-Februar-2010 kl. 11:59
|
Her kommer så et par målinger fra Stofa. Vores Planet - 31. januar:
ABR: 14990 kbps
H264 filler data: 2,7% [Netto]
Oceaner Af Liv - 20. januar:
ABR: 14989 kbps
H264 filler data: 1,0% [Netto]
Star Trek II - 9. februar (optog de sidste sidste 30 min):
ABR: 14989 kbps
H264 filler data: 12,7% [Netto]
United 93 - 10. februar:
ABR: 14990 kbps
H264 filler data: 3,6% [Netto]
|
Skrevet af: Bobben
Skrevet den: 11-Juni-2010 kl. 17:13
|
Jeg mistenker at andelen filler data er stor når innholdet er enkelt å mpeg komprimmere. Nå som det sender kamper fra fotball VM på DR HD så kunne det vært interessant om noen sjekker andelen filler data. Jeg vil tro den er liten siden fotball er ekstremt mye mer komplekst å komprimmere enn feks. film. |
Skrevet af: JesperLund
Skrevet den: 11-Juni-2010 kl. 21:54
Under 1% filler data for eftermiddagskampen (Sydafrika - Brasilien var det vist?). ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: JesperLund
Skrevet den: 23-Juni-2010 kl. 17:40
|
Jeg har checket bitraten på en VM kamp mere (hos YouSee), og her var der også under 1% filler data. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: root
Skrevet den: 23-Juni-2010 kl. 20:21
|
Så med andre ord har denne tråd været stor ståhej for ingenting. Hvis billedet er simpelt kan det sendes med lav (reel) bitrate, og det er ingen grund til at føle sig snydt eller tro at MPEG-4 AVC/H.264 er en dårlig idé (SandSand, ehelmer). |
Skrevet af: JesperLund
Skrevet den: 23-Juni-2010 kl. 20:33
Det kan du ikke konkludere. Vi mangler stadig en forklaring på hvorfor der nogle gange er 30-50 procent filler data i en stream. Det ser jeg stadigvæk i andre optagelser. Jeg kan ikke forstå hvorfor man bruger bitrate på at udsende ingenting. DR HD sender masser af HDTV med 6-7 Mbps ABR, og det kan gøres bedre! ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: Bobben
Skrevet den: 23-Juni-2010 kl. 21:09
Det er sannsynligvis satt en "fixed target quality" i MPEG4 koderen slik at kvaliteten ikke varierer. Film og serier er ekstremt mye enklere å komprimmere i forhold til fotball. Fotball er kanskje det som krever mest bitrate av alt. DR HD sender også i 720p. Det man skal være klar over da er at film,dokumentar & serier osv. da vil bli sendt med 25p doblet til 50p vha. å sende samme frame to ganger. Dette kan nok spille inn på andelen filler data. MPEG koderen behøver ikke så sende to identiske frames hvis den er intelligent nok. Den kan da sende 50% av frames og evt. sende filler data for å opprettholde CBR. Er DR HD på YouSee og i DVB-T CBR eller VBR ? |
Skrevet af: JesperLund
Skrevet den: 23-Juni-2010 kl. 21:23
|
DR-HD på YouSee DVB-C er reelt CBR med ca 11 Mbps. Men andelen af filler data varierer, så korrigeret for det er H264 streamen VBR. Jeg har relativt dårlige DVB-T modtageforhold med indendørs antenne, så jeg vil ikke udtale mig skråsikkert om det. Men også her spildes en den bitrate på filler data, jf. også ehelmer's målinger tidligere i tråden. ------------- Linux FTW, afspiller nu Blu-ray film på Ubuntu 12.04 med VLC direkte fra optisk disc. |
Skrevet af: ehelmer
Skrevet den: 24-Juni-2010 kl. 13:15
" DR HD blev i begyndelsen sendt med en bithatighed på ca 4000-5000 kbps i en variabel bitrate og med en begrænset mængde filler data. Jeg har som eksempel 'Forbrydelsen' fra 22.11.09. hvor der var 18% filler data,. Det gav en reel bithastighed på 4300 kbps. I dag sender DR alle HD udsendelser med en konstant bithastighed på 9000 kbps. Mængden af filler data er nu enormt stor. Den reelle information er kun på de samme 4000-5000 kbps som tidligere. Vi seere får altså ikke et bedre signal, nogle bliver måske blot narret til at tro det." Nogen tid derefter blev DR HD's udsendelser igen ændret. Nu sendes de med en variabel bitrate og uden filler data af betydning. En test af VM mellem Ghana og Tyskland i aftes gav iflg. BitRateViewer en middel bithastighed på ca. 9600 kbps med max. på ca. 20000 kbps eller mere. Ingen målelige filler data. Det ser ud som om DR har fået udstyret skiftet til noget bedre, eller har det bare været et problem at få det justere det rigtigt? Erik Helmer Nielsen |