Wie aufwendig ist das programmieren eines MPEG-4 AVC (H.264) En- und Decoders?



  • Mit wievielen Arbeitsstunden müßte man etwa rechnen?



  • PS:

    Der Codec sollte dabei in normalem C oder C++ programmiert werden.
    Assembleroptimierungen & Co sind nicht dabei.



  • Der Aufwand dafür, dass man etwas derartiges wirklich zum Laufen bringt... massiv. Der Aufwand dafür, dass es dann auch brauchbar ist... schwer zu sagen. Schau dir vielleicht mal XVID an. Da bekommst du einen Eindruck, wie komplex solche En- und Decoder sein können.



  • VXID ist aber kein MPEG-4 AVC Codec, inwiefern soll der für die gestellte Aufgabe repräsentativ sein?



  • Codec Progger schrieb:

    VXID ist aber kein MPEG-4 AVC Codec, inwiefern soll der für die gestellte Aufgabe repräsentativ sein?

    troll?



  • detector schrieb:

    Codec Progger schrieb:

    VXID ist aber kein MPEG-4 AVC Codec, inwiefern soll der für die gestellte Aufgabe repräsentativ sein?

    troll?

    XVID ist kein MPEG-4 AVC Codec, lies halt mal die Doku oder genaue Definition was MPEG-4 AVC genau ist!



  • Dann soll sich der Codec Progger mal x264 und den h.264-Decoder von FFmpeg anschauen. Was letzteren betrifft:

    $ cat ffmpeg/libavcodec/h264*.[hc] | wc -l
    12246
    


  • namespace invader schrieb:

    Dann soll sich der Codec Progger mal x264 und den h.264-Decoder von FFmpeg anschauen. Was letzteren betrifft:

    $ cat ffmpeg/libavcodec/h264*.[hc] | wc -l
    12246
    

    Schon besser, wenigstens mal ein vergleichbarer MPEG-4 AVC Encoder.



  • die sache an sich ist nicht uebermaessig aufwendig, aber die kompatibilitaet macht schon einige probleme. selbst wenn man sich an die spezifikation haelt, gibt es oft luecken oder es gibt einfach nen wichtigen player oder encoder der etwas falsch macht und du musst das dann anpassen.

    falls du selbst nen encoder und passenden decoder machen willst, ist es eventuell gut nicht standard conform sein zu wollen, das erleichtert die arbeit sehr. dann kann man in nem monat schon was lauffaehiges haben (sammt optimierungen beim player).



  • rapso schrieb:

    falls du selbst nen encoder und passenden decoder machen willst, ist es eventuell gut nicht standard conform sein zu wollen, das erleichtert die arbeit sehr. dann kann man in nem monat schon was lauffaehiges haben (sammt optimierungen beim player).

    Ok, das klingt schon gut.

    Standardkonform muß es nicht wirklich sein, da ich das eh nur für meine eigenen Zwecke brauche.

    Ich brauche halt etwas effizientes, das möglichst noch die GPU verwendet, unter Linux läuft und dabei auch noch Strom spart.
    Deswegen möchte ich die CPU entlasten bzw. ne schwache CPU nehmen, die braucht weniger Strom.

    Danach wird das Video dann übers Netzwerk gesendet, am Zielrechner steht genug Leistung zur Verfügung um das Video in Echtzeit zu dekodieren und dann wieder mit einem Standard Encoder neu zu kodieren um es mit einem normalen Videoplayer dann wieder abzuspielen.
    So gesehen ist echte Standardkonformität nicht wirklich wichtig.
    Gut, beim doppelten umkodieren geht halt etwas Qualität drauf, aber das ist jetzt nicht so schlimm.


Anmelden zum Antworten