Transkodieren mit Nvidia Kepler Graka unter Linux mit ffmpeg... Es geht

MartenR · March 28, 2016 at 11:08 AM

Quote

Das einzige was noch besser wäre wär ein richtiges Ausgabeplugin das on the Fly transkodiert und mit dem man auch via HTTP Request umschalten kann ohne das er den Transkodier Prozess neu starten muss.

Vielleicht liest ja hier einer von den Ausgabe Plugin Profis mit und baut das mal eben kurz Ich beteilige mich dann auch mit einer hübschen Mediengalerie für den Browser.

Naja, interessant ist das schon (wobei das schon viel Zeit brauchen wird), aber ich würde das eher nicht als Ausgabeplugin machen, sondern eher so eine Art Plugin, dass die Aufnahmen und die aktuellen Sender, als segmentierte TS oder MP4 transcodiert. (Also so eine Art vompserver plugin, nur http basiert und mit Transcoding und Segmentierung mit Clients entweder nativ oder Javascript).
Das Problem sind hier eher die vielen Standards Samsung TV wollen noch die alten HAS oder HLS Standards, moderne Browser und Android TV (z.B. Sony) kann man über die MediaSourceExtensions von HTML5 bedienen oder nativ über MediaCodecs, aber das sind dann entweder MP4 oder TS Container. (Bei Segmentierung kann man leider ffmpeg nicht zum muxen nehmen, da es das nicht unterstützt). Zusätzlich gibt es noch ein großes Codec Wirrwar was die einzelnen Devices unterstützen.....

Aber viel brennender Interessiert mich, habt ihr mal geschaut ob das parallel zu einem über VDPAU laufenden SoftHDDevice in vernüftiger Performance läuft???

Marten

jsffm · March 28, 2016 at 11:18 AM

Quote from MartenR

Aber viel brennender Interessiert mich, habt ihr mal geschaut ob das parallel zu einem über VDPAU laufenden SoftHDDevice in vernüftiger Performance läuft???

Ich hab da keinen Unterschied festgestellt.

hannemann · March 28, 2016 at 11:37 AM

Quote from MartenR

Naja, interessant ist das schon (wobei das schon viel Zeit brauchen wird), aber ich würde das eher nicht als Ausgabeplugin machen, sondern eher so eine Art Plugin, dass die Aufnahmen und die aktuellen Sender, als segmentierte TS oder MP4 transcodiert. (Also so eine Art vompserver plugin, nur http basiert und mit Transcoding und Segmentierung mit Clients entweder nativ oder Javascript).
Das Problem sind hier eher die vielen Standards Samsung TV wollen noch die alten HAS oder HLS Standards, moderne Browser und Android TV (z.B. Sony) kann man über die MediaSourceExtensions von HTML5 bedienen oder nativ über MediaCodecs, aber das sind dann entweder MP4 oder TS Container. (Bei Segmentierung kann man leider ffmpeg nicht zum muxen nehmen, da es das nicht unterstützt). Zusätzlich gibt es noch ein großes Codec Wirrwar was die einzelnen Devices unterstützen.....

Ich hab da ja so eine Webapp Programmiert, mit der man über Streamdev auch TV oder Aufnahmen ansehen kann. Was mich dabei stört, ist das ich IOS nicht bedienen kann, da hier die angesprochene Segmentierung verlangt wird und die langsamen Umschaltzeiten. Das Codec Wirrwarr ist gar nicht so schlimm. Eigentlich benötigt man nur x264 und Webm. Damit bedient man schon mal alles außer IOS (IE mit Webm Plugin von Google, Edge hab ich (noch) nicht). Chrome nimmt übrigens auch MKV

Ich wünsche mir so ein Plugin, damit VDR eine eigene Lösung für Mobiles Fernsehen anbieten kann. Das funktioniert mit meiner App sehr gut (ich nutze sie täglich z.B. zum Nachrichten schauen beim Zähneputzen), ist aber wie gesagt verbesserungswürdig. Jetzt mit NVENC kann man schon mal schwachbrüstigere Server dafür nutzen. TV Geräte interessieren mich hier weniger. Da kann man auch einen RPI oder ähnliches als Client anschließen oder meine App mit Chromecast nutzen (ist eher nur zum Aufnahmen schauen gut TV geht auch, man kann ja aber nicht umschalten).

Vielleicht kann man ja auch Streamdev beibringen bei Nutzung von Externremux auf Befehl umzuschalten. Aktuell muss ich immer den Stream anhalten und einen neuen starten, was auch schon Probleme macht und ca. 30 Sekunden dauert.

kmoss · March 28, 2016 at 1:25 PM

Quote from hannemann

Du hast doch eine Karte die das unterstützt. Mach doch bitte mal einen Test

Habe in den "11W-PC"-Bauvorschlag der c't die MSI aus 7/16 eingebaut. FFMPEG nach schon genannter Anleitung von NVIDIA gebaut.

"11W-PC" mit NVIDIA GM206

Code

>inxi -v2
System:	Host: u14041d-11W Kernel: 3.13.0-83-generic x86_64 (64 bit) Console: tty 0 Distro: Ubuntu 14.04 trusty
Machine:   Mobo: MSI model: Z170-A PRO (MS-7971) version: 1.0 Bios: American Megatrends version: 1.70 date: 12/16/2015
CPU:   	Quad core Intel Core i5-6500 CPU (-MCP-) clocked at 800.00 MHz
Graphics:  Card: NVIDIA GM206 [GeForce GTX 950]
       	X.org: 1.15.1 drivers: nvidia (unloaded: fbdev,vesa,nouveau) tty size: 144x36 Advanced Data: N/A out of X
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Drives:	HDD Total Size: 60.0GB (21.8% used) 1: model: ADATA_SSD_S511_6
Info:  	Processes: 184 Uptime: 15 min Memory: 815.6/32143.3MB Runlevel: 2 Client: Shell (bash) inxi: 1.9.17

Die Ergebnisse:

Code

>time ffmpeg -i ~/Downloads/test_hd.ts -map 0:v -map 0:a:0 -c:v nvenc_h264 -b:v 4500K -maxrate 5000K -bufsize:v 9000K -bf 2 -g 150 -i_qfactor 1.1 -b_qfactor 1.25 -qmin 1 -qmax 50 -c:a copy -f matroska test_hd_nvenc_x264.mk
...
frame= 4055 fps=156 q=-0.0 Lsize=   98560kB time=00:02:43.20 bitrate=4947.3kbits/s
video:90867kB audio:7615kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.079809%


real	0m26.412s
user	0m45.220s
sys 	0m0.787s


>time ffmpeg -i ~/Downloads/test_hd.ts -map 0:v -map 0:a:0 -c:v nvenc_hevc -b:v 4500K -maxrate 5000K -bufsize:v 9000K -bf 2 -g 150 -i_qfactor 1.1 -b_qfactor 1.25 -qmin 1 -qmax 50 -c:a copy -f matroska test_hd_nvenc_hevc.mkv
...
[nvenc_hevc @ 0x2fa6240] InitializeEncoder failed: 0x8
Output #0, matroska, to 'test_hd_nvenc_hevc.mkv':
	Stream #0:0: Video: hevc, none, q=2-31, 128 kb/s, SAR 1:1 DAR 0:0, 25 fps
	Metadata:
  	encoder     	: Lavc57.15.100 nvenc_hevc
	Stream #0:1(deu): Audio: ac3, 48000 Hz, 5.1(side), 384 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (nvenc_hevc))
  Stream #0:1 -> #0:1 (copy)
Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height




>time ffmpeg -i ~/Downloads/test_hd.ts -c:v nvenc_hevc -b:v 4500K -c:a copy -f matroska test_hd_nvenc_hevc.mkv
...
frame= 4055 fps=140 q=-0.0 Lsize=   93830kB time=00:02:43.24 bitrate=4708.7kbits/s
video:86137kB audio:7615kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.083240%


real	0m29.389s
user	0m46.040s
sys 	0m0.815s

Display More

Allerdings gibt es Unterschiede, da nicht alle Optionen von nvenc(_h264) bei nvenc_hevc angenommen werden (?). Der Vergleich der Optionen sagt mir nichts

Vergleich der Optionen

Code

>ffmpeg -h encoder=nvenc
ffmpeg version N-76538-gb83c849 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
  configuration: --enable-nonfree --enable-nvenc --enable-nvresize --extra-cflags=-I../cudautils --extra-ldflags=-L../cudautils --enable-gpl --enable-libx264
  libavutil  	55.  5.100 / 55.  5.100
  libavcodec 	57. 15.100 / 57. 15.100
  libavformat	57. 14.100 / 57. 14.100
  libavdevice	57.  0.100 / 57.  0.100
  libavfilter 	6. 15.100 /  6. 15.100
  libswscale  	4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc	54.  0.100 / 54.  0.100
Encoder nvenc [NVIDIA NVENC h264 encoder]:
	General capabilities: delay
	Threading capabilities: none
	Supported pixel formats: yuv420p nv12
nvenc AVOptions:
  -preset        	<string> 	E..V.... Set the encoding preset (one of slow = hq 2pass, medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default) (default "hq")
  -profile       	<string> 	E..V.... Set the encoding profile (high, main, baseline)
  -level         	<string> 	E..V.... Set the encoding level restriction (auto, 1.0, 1.0b, 1.1, 1.2, ..., 4.2, 5.0, 5.1)
  -tier          	<string> 	E..V.... Set the encoding tier (main or high)
  -cbr           	<boolean>	E..V.... Use cbr encoding mode (default false)
  -2pass         	<boolean>	E..V.... Use 2pass encoding mode (default auto)
  -gpu           	<int>    	E..V.... Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from 0 to INT_MAX) (default 0)
  -delay         	<int>    	E..V.... Delays frame output by the given amount of frames. (from 0 to INT_MAX) (default INT_MAX)
  -enableaq      	<boolean>	E..V.... set to 1 to enable AQ  (default false)


>ffmpeg -h encoder=nvenc_hevc
ffmpeg version N-76538-gb83c849 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
  configuration: --enable-nonfree --enable-nvenc --enable-nvresize --extra-cflags=-I../cudautils --extra-ldflags=-L../cudautils --enable-gpl --enable-libx264
...
Encoder nvenc_hevc [NVIDIA NVENC hevc encoder]:
	General capabilities: delay
	Threading capabilities: none
	Supported pixel formats: yuv420p nv12
nvenc_hevc AVOptions:
  -preset        	<string> 	E..V.... Set the encoding preset (one of slow = hq 2pass, medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default) (default "hq")
  -profile       	<string> 	E..V.... Set the encoding profile (high, main, baseline)
  -level         	<string> 	E..V.... Set the encoding level restriction (auto, 1.0, 1.0b, 1.1, 1.2, ..., 4.2, 5.0, 5.1)
  -tier          	<string> 	E..V.... Set the encoding tier (main or high)
  -cbr           	<boolean>	E..V.... Use cbr encoding mode (default false)
  -2pass         	<boolean>	E..V.... Use 2pass encoding mode (default auto)
  -gpu           	<int>    	E..V.... Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from 0 to INT_MAX) (default 0)
  -delay         	<int>    	E..V.... Delays frame output by the given amount of frames. (from 0 to INT_MAX) (default INT_MAX)
  -enableaq      	<boolean>	E..V.... set to 1 to enable AQ  (default false)

Display More

hannemann · March 28, 2016 at 1:30 PM

Cool... Danke.
Geht ja recht fix. Ich hätte erwartet, das es wesentlich länger dauert als nvenc_h264.
Und wie ist die Qualität und Dateigröße im Verglich zu der h264 Datei?

kmoss · March 28, 2016 at 1:59 PM

Quote from hannemann

Und wie ist die Qualität und Dateigröße im Verglich zu der h264 Datei?

Die Größe habe ich im Logauszug mit angegeben, z.B.

Code

video:86137kB

Die hevc-Datei ist etwas kleiner, wobei die Optionen allerdings nur ähnlich sind. Daher sollte man die gleichen Optionen nehmen, wenn man die Qualität (subjektiv) vergleicht, zumal interlaced-Material meiner Meinung nach für hevc auch nicht so gut ist.
Vllt. sollte man eher 1080p-Material für die Performancevergleiche (NASA oder NFL Highlights fallen mir ein) nehmen und dann bestimmte Bilder nach Kriterien (wie Bewegung, Farbtreue, Schärfe von Logos/Einblendungen usw.) herausnehmen.

jsffm · March 28, 2016 at 3:20 PM

720p ginge auch, sollte halt nicht interlaced sein.

MartenR · March 28, 2016 at 3:58 PM

Quote

Ich hab da keinen Unterschied festgestellt.

Und softhddevice hat über vdpau h264 dargestellt. Lief beim transcodieren die dekodierung von h264 auch über vdpau?

Quote

Ich hab da ja so eine Webapp Programmiert, mit der man über Streamdev auch TV oder Aufnahmen ansehen kann. Was mich dabei stört, ist das ich IOS nicht bedienen kann, da hier die angesprochene Segmentierung verlangt wird und die langsamen Umschaltzeiten. Das Codec Wirrwarr ist gar nicht so schlimm. Eigentlich benötigt man nur x264 und Webm. Damit bedient man schon mal alles außer IOS (IE mit Webm Plugin von Google, Edge hab ich (noch) nicht). Chrome nimmt übrigens auch MKV

Ich wünsche mir so ein Plugin, damit VDR eine eigene Lösung für Mobiles Fernsehen anbieten kann. Das funktioniert mit meiner App sehr gut (ich nutze sie täglich z.B. zum Nachrichten schauen beim Zähneputzen), ist aber wie gesagt verbesserungswürdig. Jetzt mit NVENC kann man schon mal schwachbrüstigere Server dafür nutzen. TV Geräte interessieren mich hier weniger. Da kann man auch einen RPI oder ähnliches als Client anschließen oder meine App mit Chromecast nutzen (ist eher nur zum Aufnahmen schauen gut TV geht auch, man kann ja aber nicht umschalten).

Vielleicht kann man ja auch Streamdev beibringen bei Nutzung von Externremux auf Befehl umzuschalten. Aktuell muss ich immer den Stream anhalten und einen neuen starten, was auch schon Probleme macht und ca. 30 Sekunden dauert.

Naja, wir haben hier jetzt überall smarttvs, und ich habe mir viele Apps von Streamingdiensten angeschaut.
Die verwenden alle HTML5 als Basis für die UI und je nach Device wird das video Tag über HTML5 MediaSourceExtensions (https://www.w3.org/TR/media-source/) gefüttert oder die Dekodierung wird nativ über z.B. Android durchgeführt.
Ich schau mir schon seit einigen Wochen Ideen an um vomp durch etwas zu ersetzen, was für die meisten Plattformen über HTML5 läuft und daher die entsprechenden segmentierten Files braucht. (Also sowohl AndroidTV, SmartTV Android für mobiles TV, und Versorgung über Webbrowser am PC).
Mein aktueller Stand ist das die meisten Browser nur Mp4 Container über MediaSourceExtensions verarbeiten können und meist nicht TS (das nur über die älteren HLS und HAS Standards und dann Mp3 mit h264 und AAC oder mp3 der kleinste gemeinsame Nenner ist.
Aber mir ist noch nicht klar wie der Weg genau aussehen wird. Das Schreiben eines Plugins das so etwas macht ist weniger das Problem, ich habe genug an muxer, demuxern und ffmpeg für die raspberry pi und windows ports für vomp gearbeitet (inklusive experimentellen Streamings mit Transcoding für bluray, das aber von der SchreibPerformance der temporär Dateien auf bluray Seite schrecklich war.
Vielmehr eine Architektur zu finden die möglichst viele Geräte ansprechen kann, also welche Container und Codecs bedient werden müssen. Außerdem habe ich nicht so richtig Lust auf die javascript Seite und ich brauche noch eine lib die sich um die http routen kümmert.
Also ich schwanke noch ob ich damit anfangen soll....

Marten

chriszero · March 28, 2016 at 4:08 PM

Da werdet Ihr keine Leistungseinbußen spüren. NVENC nutzt spezielle dedizierte ASICs auf dem Grafikchip, der kann nichts anderes als h264 bzw HEVC zu codieren. Einzig der RAM wird wohl geshared.

chriszero · March 28, 2016 at 4:14 PM

Quote from MartenR

Bei Segmentierung kann man leider ffmpeg nicht zum muxen nehmen, da es das nicht unterstützt

Das halte ich für ein Gerücht.
ffmpeg kann doch Fertige HLS TS Streams ausgeben? Das macht der Plexmediaserver sowie Emby doch mit ffmpeg am laufendem Band...

kmoss · March 28, 2016 at 4:25 PM

Quote from jsffm

720p ginge auch, sollte halt nicht interlaced sein.

Hmm, Baraka war mal bei AreaDVD eine Referenz. Unter https://www.youtube.com/watch?v=ZSfFHxyYJJA gibt es einen "Baraka Original Theatrical Trailer - HD Matchframe Re-Edit" in 720p. Länge 02:46 bei 43,6 MB.

Quote from chriszero

ffmpeg kann doch Fertige HLS TS Streams ausgeben? Das macht der Plexmediaserver sowie Emby doch mit ffmpeg am laufendem Band...

Mir ist auch so, dass es geht. Meiner Meinung nach war
http://www.heise.de/ct/ausgabe/201…en-2312251.html
auf Basis ffmpeg.

MartenR · March 28, 2016 at 4:39 PM

Quote

Das halte ich für ein Gerücht.
ffmpeg kann doch Fertige HLS TS Streams ausgeben? Das macht der Plexmediaserver sowie Emby doch mit ffmpeg am laufendem Band...

Ich meine aber etwas anderes, nicht das ein fixer HLS TS Stream ausgegeben wird, sondern das durch Kontrolle des Clienten die Bitrate dynamisch geändert werden kann, die das Plugin zum encoden nutzt.
Ob da der muxer noch eingesetzt werden kann glaube ich weniger, da er ja eine feste HLS Datei ausgibt, außerdem ist HLS auch schon Schnee von gestern, die neue Standards nutzen alle MediaSourceExtensions und das ist ein anderer Container, leider kein TS mehr (auch wenn es Teil der Spezifikation ist). Grundsätzlich meine auch nur das der muxer wahrscheinlich im Plugin implementiert werden muss (ich vermute plex und emby machen das ähnlich aber die scheinen nicht open source zu sein(jedenfalls habe ich keinen source gefunden) , da kann ich nicht reinschauen, was die machen).

Marten

chriszero · March 28, 2016 at 5:43 PM

Mal am Rande. Alternativ gibt es ja noch Intel Quick Sync.
-vcodec h264_qsv

http://emby.media/community/inde…-30#entry314835

hannemann · March 28, 2016 at 6:17 PM

Coole Sache! Die Qualität soll ja viel besser sein. Ist aber ganz schön was zu tun um das zu testen

hannemann · March 28, 2016 at 6:31 PM

Quote from MartenR

Vielmehr eine Architektur zu finden die möglichst viele Geräte ansprechen kann, also welche Container und Codecs bedient werden müssen. Außerdem habe ich nicht so richtig Lust auf die javascript Seite und ich brauche noch eine lib die sich um die http routen kümmert.
Also ich schwanke noch ob ich damit anfangen soll....

Also wenn das mit den Segmentierten Dateien irgendwie hinzubekommen ist... den JavaScript Part übernehme ich gerne. Mein Player kann ja schon die Hälfte. Aktuell arbeite ich mit den Streams von Streamdev aber das kann man auch umbauen.
Für den HTTP Teil könnte man cxxtools nehmen.

chriszero · March 28, 2016 at 6:46 PM

Quote from hannemann

Für den HTTP Teil könnte man cxxtools nehmen.

oder libpoco

kmoss · March 28, 2016 at 7:21 PM

Quote from chriszero

Da werdet Ihr keine Leistungseinbußen spüren. NVENC nutzt spezielle dedizierte ASICs auf dem Grafikchip, der kann nichts anderes als h264 bzw HEVC zu codieren. Einzig der RAM wird wohl geshared.

"nativ" auf dem Server mit NVIDIA GM204 [GeForce GTX 970] mit dem Baraka-Trailer bei 4500K -> ca. 80MB vs 43,6 MB beim Original (ohne HW-Skalierung nach 1080p).

h264

Code

>time ffmpeg -i ~/Downloads/Baraka_Trailer_720p.mp4  -map 0:v -map 0:a:0 -c:v nvenc_h264 -b:v 4500K -c:a copy -f matroska Baraka_nvenc_h264_720p.mkv
frame= 4162 fps=513 q=-0.0 Lsize=   78578kB time=00:02:46.48 bitrate=3866.4kbits/s	
video:74571kB audio:3902kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.133635%
...
real	0m8.476s
user	0m25.102s
sys	0m0.882s


>nvidia-smi dmon -i 0
# gpu   pwr  temp	sm   mem   enc   dec  mclk  pclk
# Idx 	W 	C 	% 	% 	% 	%   MHz   MHz
	0	20	36 	1	15 	0 	0   324   135
	0	22	36 	7	18 	0 	0   324   135
	0	22	36	10	18 	0 	0   324   135
	0	20	36 	0	14 	0 	0   324   135
	0	20	36 	0	15 	0 	0   324   135
	0	30	36 	2 	3 	0 	0  3004  1050
	0	49	38 	9 	6	22 	0  3004  1050
	0	50	38 	8 	6	42 	0  3004  1113
	0	61	40	10 	7	51 	0  3004  1252
	0	61	40 	7 	5	59 	0  3004  1252
	0	61	41 	7 	5	61 	0  3004  1252
	0	61	41 	8 	6	63 	0  3004  1252
	0	61	41 	6 	5	65 	0  3004  1252
	0	62	42	15 	9	69 	0  3004  1252
	0	60	42 	0 	1	51 	0  3505  1252
	0	60	42 	0 	1	35 	0  3505  1252
	0	60	42 	0 	1	24 	0  3505  1252
	0	60	42 	0 	1	17 	0  3505  1252
	0	60	43 	0 	1	12 	0  3505  1252
	0	60	43 	0 	1 	8 	0  3505  1252
	0	60	43 	0 	1 	5 	0  3505  1252
	0	60	43 	0 	1 	3 	0  3505  1252
	0	60	43 	0 	1 	2 	0  3505  1252
	0	60	44 	0 	1 	1 	0  3505  1252
	0	60	44 	0 	1 	1 	0  3505  1252
	0	61	44 	0 	1 	0 	0  3505  1252
	0	61	44 	0 	1 	0 	0  3505  1252
	0	61	44 	1 	2 	0 	0  3505  1252
	0	62	45 	0 	1 	0 	0  3505  1252
	0	61	45 	0 	1 	0 	0  3505  1252

Display More

hevc

Code

time ffmpeg -i ~/Downloads/Baraka_Trailer_720p.mp4  -map 0:v -map 0:a:0 -c:v nvenc_hevc -b:v 4500K -c:a copy -f matroska Baraka_nvenc_hevc_720p.mkv


frame= 4162 fps=268 q=-0.0 Lsize=   79962kB time=00:02:46.48 bitrate=3934.5kbits/s	
video:75967kB audio:3902kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.116342%


real	0m15.788s
user	0m25.902s
sys	0m0.799s


>nvidia-smi dmon -i 0
# gpu   pwr  temp	sm   mem   enc   dec  mclk  pclk
# Idx 	W 	C 	% 	% 	% 	%   MHz   MHz
	0	20	37 	0	14 	0 	0   324   135
	0	20	37 	0	14 	0 	0   324   135
	0	22	37 	9	20 	0 	0   324   135
	0	48	38 	6 	5 	6 	0  3004  1050
	0	49	38 	4 	4	35 	0  3004  1050
	0	61	40 	5 	5	54 	0  3004  1252
	0	61	41 	4 	4	68 	0  3004  1252
	0	60	41 	4 	4	79 	0  3004  1252
	0	60	41 	4 	4	85 	0  3004  1252
	0	61	42 	4 	4	89 	0  3004  1252
	0	61	42 	5 	5	93 	0  3004  1252
	0	61	42 	4 	4	95 	0  3004  1252
	0	61	43 	4 	4	96 	0  3004  1252
	0	61	43 	4 	5	97 	0  3004  1252
	0	61	43 	4 	4	98 	0  3004  1252
	0	61	43 	4 	5	98 	0  3004  1252
	0	61	43 	5 	5	99 	0  3004  1252
	0	61	44 	6 	5	99 	0  3004  1252
	0	61	44 	7 	6	99 	0  3004  1252
	0	60	44 	0 	1	71 	0  3505  1252
	0	61	44 	0 	1	49 	0  3505  1252
	0	61	44 	0 	1	34 	0  3505  1252
	0	61	44 	0 	1	24 	0  3505  1252
	0	61	45 	0 	1	16 	0  3505  1252
	0	51	44 	0 	1	11 	0  3505  1088
	0	50	44 	0 	1 	8 	0  3505  1088
	0	50	44 	0 	1 	5 	0  3505  1088
	0	46	44 	0 	1 	3 	0  3004   847
	0	46	43 	0 	1 	2 	0  3004   847
	0	26	43 	0 	5 	1 	0   810   721
	0	21	42 	0 	6 	1 	0   810   721
	0	21	42 	0 	5 	0 	0   810   721
	0	20	41 	0	14 	0 	0   324   202
	0	20	41 	0	14 	0 	0   324   202
	0	23	41	20	28 	0 	0   324   202

Display More

MartenR · March 28, 2016 at 8:04 PM

Quote

Also wenn das mit den Segmentierten Dateien irgendwie hinzubekommen ist... den JavaScript Part übernehme ich gerne. Mein Player kann ja schon die Hälfte. Aktuell arbeite ich mit den Streams von Streamdev aber das kann man auch umbauen.
Für den HTTP Teil könnte man cxxtools nehmen.

Ich habe mir gerade libavformat genauer angeschaut, scheint sich insbesondere 2015 viel getan zu haben (was vermutlich bedeutet das jessie nicht die richtigen libs hat).
Scheint vieles da zu sein, alle wichtigen Container usw. auch als segmentierte Version.

Die Frage ist, wie soll die API aussehen, die aktuellen Bitraten, Codecs und Container sowie Audiospur alle in die URL encoden für die Files?
Dann noch eine JSON API die Informationen über die Aufnahme wie Länge und Audiospuren mitteilt (muss ja nicht alles transkodiert werden).
Und das Ganze immer im Zusammenspiel mit dem Restfulapi plugin bauen.

Frage ist cxxtools noch sinnvoll, die Webseite kann ich nicht aufrufen..., libpoco kann ich mir wenigstens anschauen...

Ich schau mir das mal nächstes Wochenende noch genauer an... und dann entscheide ich ob ich einen Prototyp baue...., sieht aber einfacher aus als ich dachte..

Marten

hannemann · March 28, 2016 at 9:20 PM

MartenR

Wie man die Parameter übergibt kann man ja relativ einfach anpassen. Ich habe jedenfalls gerade festgestellt, das Apache als Proxy zicken macht wenn man kodierte slashes im URL übergeben will (404). Vielleicht sind GET Parameter doch besser geeignet.

Restfulapi kann bereits alles liefern was benötigt wird. Wenn man das als Quelle für die benötigten Infos hernimmt braucht man sich darum gar nicht zu kümmern und falls was fehlt bauen wir es ein.

Meinst du Live TV lässt sich auch so umsetzen? Das zu segmentieren stell ich mir irgendwie schwierig vor.

chriszero · March 28, 2016 at 9:29 PM

Das segmentieren macht komplett ffmpeg bzw libav. Die Segmente werden dann über einen Webserver ausgeliefert (Apache, ngix, libpoco)
Segmentiert wäre dann wohl Hls (m3u8) oder MPEG dash. Moderne Browser oder auch Geräte (Chromecast, Smarttv) spielen auch MKV als stream ab.
Mit libpoco sind das nicht mehr als ein paar Zeilen Code, Beispiel siehe plex Plugin.

Chris

Participate now!