Re: [FFmpeg-devel] DVR MPEG4 variant (AS-3024)
2017-02-03 23:18 GMT+02:00 Compn <te...@mi.rr.com>: > On Fri, 3 Feb 2017 15:46:20 +0200, Ivo Andonov <ivo.ando...@gmail.com> > wrote: > > > I successfully used a modified Pinetron library on Windows to use my own > > software for decoding the stream. While fiddling with the modification I > > saw they are using the statically linked FFmpeg API. > > the dvr company ships ffmpeg? they must ship ffmpeg source as well, the > modified ffmpeg source may contain the patch needed to play such > dvr files. > > where can we see this pinetron library ? > > -compn > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > I thought the same as well but am not too much into the licencing terms... I tried in vain finding any sources. They do not ship ffmpeg directly (as a separate library). They modify the source and use it statically linked in their projects. This is a link to the IE ActiveX for playing the stream (displaying DVR cams): http://www.dvrstation.com/pdvratl.php?vendor=0#version=1,0,1,26 This is also the library I modded in order to use the decoder on Windows platforms before I decided to spend some time to research the differences in respect to the MPEG4 standard and use the stream in a Linux environment. This is a link to a 64-bit Linux app: http://pinetron.ru/files/software/cms-lite-linux.zip Never actually tried it. The libpapi-shared.so.* files are clearly based on the ffmpeg source. This is the android app: http://www.apkmonk.com/app/com.pinetron.TouchCMS/ One library in there for Arm, also clearly based on ffmpeg. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DVR MPEG4 variant (AS-3024)
2017-02-03 18:16 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>: > 2017-02-03 16:54 GMT+01:00 Ivo Andonov <ivo.ando...@gmail.com>: > > 2017-02-03 16:59 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>: > > >> The encoder sets no user data, so identification is not as simple as > >> hoped: How do subsequent frames start? Do you know what the > >> first bytes mean? > >> > > Yes, no user data is set and as such automatic identification is not > > possible. The raw stream coming from the DVR is prefixed by a propriatory > > frame header (that I filter) which is not MPEG stream compliant and is > > meant for the viewer/recorder (timestamp, keyframe flag, frame data size > > etc). > > How would another owner of this DVR get the streams? > Now that is a separate question. If it has to be integrated in the ffmpeg suite, I can provide a PHP script that connects to the DVR and fetches the stream. This can be used by someone to write a libav protocol I suppose. I just do not feel like too much experienced to program it in C and integrate it in ffmpeg. Let me know if I should open a new thread for this. > > > So far I'm attempting to implement the decoding by explicitly specifing > to > > ffmpeg the video codec to use (-vcodec xvid_alogics). > > An easier solution is to define a new "bug" in libavcodec/options_table.h. > Carl, thanks for opening my eyes on this! Of course that's a much easier and neater solution. I just plunged into the source code and a lot of things of the overall workings are unknown to me. Works as expected! Excuse my ignorance on this, but how are these options specified via the libavcodec api when opening a decoder context? > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DVR MPEG4 variant (AS-3024)
2017-02-03 17:54 GMT+02:00 Ivo Andonov <ivo.ando...@gmail.com>:
> 2017-02-03 16:59 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
>
>> 2017-02-03 15:14 GMT+01:00 Ivo Andonov <ivo.ando...@gmail.com>:
>> > 2017-02-03 15:58 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
>>
>> >> > I've got some old Pinetron DVRs that are supposed to produce a MPEG4
>> >> > bitstream. Indeed they are but no non-Pinetron software can decode
>> it.
>> >>
>> >> Please provide a sample!
>> >>
>> >> > I do now know what is the best approach for registering this as a new
>> >> > decoder
>> >>
>> >> It should be possible to identify the codec while reading the
>> bitstream.
>>
>> The encoder sets no user data, so identification is not as simple as
>> hoped: How do subsequent frames start? Do you know what the
>> first bytes mean?
>>
>>
> Yes, no user data is set and as such automatic identification is not
> possible. The raw stream coming from the DVR is prefixed by a propriatory
> frame header (that I filter) which is not MPEG stream compliant and is
> meant for the viewer/recorder (timestamp, keyframe flag, frame data size
> etc).
>
> So far I'm attempting to implement the decoding by explicitly specifing to
> ffmpeg the video codec to use (-vcodec xvid_alogics). xvid_alogics AVCodec
> is initialized the same way the mpeg4 one, just a different id. In the
> decode_init I change the avctx->codec_id to AV_CODEC_ID_MPEG4 and set a
> flag in workaround_bugs that I later use in the initially submitted block
> condition code.
> However it seems somewhere else in the code avctx->codec_id reverts back
> to avctx->codec->id and as a result I end up with a "Bad picture start
> code" due to ff_h263_decode_frame calling ff_h263_decode_picture_header
> instead of ff_mpeg4_decode_picture_header.
> I forgot to mention that my changes are against ffmpeg 2.6. (libavcodec
> 56.26.100)
>
>
I do not know if this is the best approach but I ended up with:
mpeg4videodec.c:
static av_cold int alogics_decode_init(AVCodecContext *avctx) {
avctx->workaround_bugs |= FF_BUG_ALOGICS;
return decode_init(avctx);
}
and
AVCodec ff_xvid_alogics_decoder = {
.name = "xvid_alogics",
.long_name = NULL_IF_CONFIG_SMALL("XVID Alogics"),
.type = AVMEDIA_TYPE_VIDEO,
.id= AV_CODEC_ID_MPEG4,
.priv_data_size= sizeof(Mpeg4DecContext),
.init = alogics_decode_init,
.close = ff_h263_decode_end,
.decode= ff_h263_decode_frame,
.capabilities = CODEC_CAP_DRAW_HORIZ_BAND | CODEC_CAP_DR1 |
CODEC_CAP_TRUNCATED | CODEC_CAP_DELAY |
CODEC_CAP_FRAME_THREADS,
.flush = ff_mpeg_flush,
.max_lowres= 3,
.pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
.profiles = NULL_IF_CONFIG_SMALL(mpeg4_video_profiles),
.update_thread_context =
ONLY_IF_THREADS_ENABLED(mpeg4_update_thread_context),
.priv_class = _class,
};
Then the block of code in mpeg4video.h before pred = FASTDIV is enclosed in
an if-else of:
if (s->workaround_bugs & FF_BUG_ALOGICS) {
//new code
} else {
//original code
}
Ivo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DVR MPEG4 variant (AS-3024)
2017-02-03 16:59 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>: > 2017-02-03 15:14 GMT+01:00 Ivo Andonov <ivo.ando...@gmail.com>: > > 2017-02-03 15:58 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>: > > >> > I've got some old Pinetron DVRs that are supposed to produce a MPEG4 > >> > bitstream. Indeed they are but no non-Pinetron software can decode it. > >> > >> Please provide a sample! > >> > >> > I do now know what is the best approach for registering this as a new > >> > decoder > >> > >> It should be possible to identify the codec while reading the bitstream. > > The encoder sets no user data, so identification is not as simple as > hoped: How do subsequent frames start? Do you know what the > first bytes mean? > > Yes, no user data is set and as such automatic identification is not possible. The raw stream coming from the DVR is prefixed by a propriatory frame header (that I filter) which is not MPEG stream compliant and is meant for the viewer/recorder (timestamp, keyframe flag, frame data size etc). So far I'm attempting to implement the decoding by explicitly specifing to ffmpeg the video codec to use (-vcodec xvid_alogics). xvid_alogics AVCodec is initialized the same way the mpeg4 one, just a different id. In the decode_init I change the avctx->codec_id to AV_CODEC_ID_MPEG4 and set a flag in workaround_bugs that I later use in the initially submitted block condition code. However it seems somewhere else in the code avctx->codec_id reverts back to avctx->codec->id and as a result I end up with a "Bad picture start code" due to ff_h263_decode_frame calling ff_h263_decode_picture_header instead of ff_mpeg4_decode_picture_header. I forgot to mention that my changes are against ffmpeg 2.6. (libavcodec 56.26.100) > > Not sure if attachments are fine here... Attempting one. > > I can confirm that your suggested change (above "pred = FASTDIV") > works as expected. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DVR MPEG4 variant (AS-3024)
2017-02-03 15:58 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>: > 2017-02-03 14:46 GMT+01:00 Ivo Andonov <ivo.ando...@gmail.com>: > > This is my first post here. Actually my first post to a mailing list. > > Excuse me if this is the wrong place to write or if my mailing-list > culture > > is not complete! > > Remember not to top-post here. > > > I've got some old Pinetron DVRs that are supposed to produce a MPEG4 > > bitstream. Indeed they are but no non-Pinetron software can decode it. > > Please provide a sample! > > > I do now know what is the best approach for registering this as a new > > decoder > > It should be possible to identify the codec while reading the bitstream. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Not sure if attachments are fine here... Attempting one. Ivo t.frm Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] DVR MPEG4 variant (AS-3024)
Hi Everyone,
This is my first post here. Actually my first post to a mailing list.
Excuse me if this is the wrong place to write or if my mailing-list culture
is not complete!
I've got some old Pinetron DVRs that are supposed to produce a MPEG4
bitstream. Indeed they are but no non-Pinetron software can decode it.
While changing the realtime clock battery on one of these I saw they are
using the AS-3024 SoC. Any information about it is quite rare and hard to
find. What I found in a kind of a brochure is the "Modified ISO/IEC
14496/2" statement.
I successfully used a modified Pinetron library on Windows to use my own
software for decoding the stream. While fiddling with the modification I
saw they are using the statically linked FFmpeg API.
Out of curiosity and wanting to have this codec implementation on the Linux
platform to automate some tasks I digged deeper in order to understand the
decoder difference in respect to the standards. The codec name they use is
xvid_alogics.
Finally there's the result and I wanted to share it with the comunity in
case someone is interested or if one wants to use it for its own project.
In short, what I did is modify libavcodec/mpeg4video.h, ff_mpeg4_pred_dc
function and add the lines of code below right after the a, b, c vars being
initialized and instead of the block of code that sets the pred var.
if (n == 0 || n == 4 || n == 5) pred = 1024; else
if (n == 1) pred = a; else
if (n == 2) pred = c; else
if (n == 3) {
if (abs(a - b) < abs(b - c)) {
pred = c;
} else {
pred = a;
}
}
I do now know what is the best approach for registering this as a new
decoder and then having the above block within a condition. What I came up
with is adding a new AVCodec to the mpeg4videodec.c file and modifying the
decode_init to set a flag in AVCodecContext.workaround_bugs field that can
later be used to condition the above block.
Ivo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
