[issue2333] DVR recording MP4 Source can't be demuxed by lavf
New submission from Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at: Original thread: http://thread.gmane.org/gmane.comp.video.mplayer.user/64876 The unknown hardware produces files that contain H264 video, but can't be demuxed by lavf. The files may also contain audio (G726/G729), the DirectShow filter installer also contains an audio filter. ffmpeg -i E-20100925-233415.mp4 FFmpeg version SVN-r25591, Copyright (c) 2000-2010 the FFmpeg developers built on Oct 27 2010 23:24:31 with gcc 4.3.2 configuration: --cc=/usr/local/gcc-4.3.2/bin/gcc libavutil 50.32. 3 / 50.32. 3 libavcore 0. 9. 1 / 0. 9. 1 libavcodec52.93. 0 / 52.93. 0 libavformat 52.84. 0 / 52.84. 0 libavdevice 52. 2. 2 / 52. 2. 2 libavfilter1.53. 0 / 1.53. 0 libswscale 0.12. 0 / 0.12. 0 [NULL @ 0x8b91560] Format detected only with low score of 24, misdetection possible! [mp3 @ 0x8b93e30] Header missing Last message repeated 17 times [mp3 @ 0x8b91560] max_analyze_duration reached [mp3 @ 0x8b91560] Estimating duration from bitrate, this may be inaccurate Input #0, mp3, from 'E-20100925-233415.mp4': Duration: 00:00:47.03, start: 0.00, bitrate: 448 kb/s Stream #0.0: Audio: mp1, 44100 Hz, 1 channels, s16, 448 kb/s At least one output file must be specified The file transcodes fine with ffmpeg -f h264 -i E-20100925-233415.mp4 out.avi, output attached. The resulting file shows no artefacts, possibly plays at wrong speed. File 'transcoding.txt' not attached - you can download it from https://roundup.ffmpeg.org/file1146. -- files: transcoding.txt messages: 12412 priority: normal status: open substatus: open title: DVR recording MP4 Source can't be demuxed by lavf type: feature_request FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2333
[issue2333] DVR recording MP4 Source can't be demuxed by lavf
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Sample file and DirectShow filter installer uploaded to /samples/ffmpeg-bugs/roundup/issue2333 The first eight bytes of the file read 00 00 01 c6 4d 50 47 34 (MPG4), this seems to be the only readable string in the file. -- priority: normal - wish FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2333
[issue2333] DVR recording MP4 Source can't be demuxed by lavf
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Fri, Oct 29, 2010 at 02:22:34PM +, Carl Eugen Hoyos wrote:
Sample file and DirectShow filter installer uploaded to
/samples/ffmpeg-bugs/roundup/issue2333
The first eight bytes of the file read 00 00 01 c6 4d 50 47 34 (MPG4),
this seems to be the only readable string in the file.
This file uses NAL units with an invalid bit set for custom data, and
this custom data
1) appears in-between slices
2) apart from the invalid bit and one 00 too few looks mostly like SPS
As a quick hack, below patch fixes most error messages when
treating it like a normal H.264 stream.
Of course a proper demuxer that makes use of the extra data is
the proper solution.
Index: libavcodec/h264_parser.c
===
--- libavcodec/h264_parser.c(revision 25603)
+++ libavcodec/h264_parser.c(working copy)
@@ -69,7 +69,7 @@
else if(buf[i]) state = 7;
elsestate=1; //2-1, 1-0, 0-0
}else if(state=5){
-int v= buf[i] 0x1F;
+int v= buf[i] 0x9F;
if(v==6 || v==7 || v==8 || v==9){
if(pc-frame_start_found){
i++;
Index: libavcodec/h264.c
===
--- libavcodec/h264.c (revision 25603)
+++ libavcodec/h264.c (working copy)
@@ -2837,6 +2837,8 @@
if( (s-hurry_up == 1 h-nal_ref_idc == 0) //FIXME do not discard
SEI id
||(avctx-skip_frame = AVDISCARD_NONREF h-nal_ref_idc == 0))
continue;
+if (hx-nal_ref_idc 4) // invalid
+continue;
again:
err = 0;
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2333
[issue2333] DVR recording MP4 Source can't be demuxed by lavf
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Fri, Oct 29, 2010 at 07:32:37PM +, Reimar Döffinger wrote:
As a quick hack, below patch fixes most error messages when
treating it like a normal H.264 stream.
Updated hack that avoids all warnings, proving that this is a
the correct way to parse this file.
Index: libavcodec/h264_parser.c
===
--- libavcodec/h264_parser.c(revision 25603)
+++ libavcodec/h264_parser.c(working copy)
@@ -69,7 +69,7 @@
else if(buf[i]) state = 7;
elsestate=1; //2-1, 1-0, 0-0
}else if(state=5){
-int v= buf[i] 0x1F;
+int v= buf[i] 0x9F;
if(v==6 || v==7 || v==8 || v==9){
if(pc-frame_start_found){
i++;
@@ -150,6 +150,7 @@
break;
init_get_bits(h-s.gb, ptr, 8*dst_length);
+if (!(h-nal_ref_idc 4))
switch(h-nal_unit_type) {
case NAL_SPS:
ff_h264_decode_seq_parameter_set(h);
Index: libavcodec/h264.c
===
--- libavcodec/h264.c (revision 25603)
+++ libavcodec/h264.c (working copy)
@@ -2837,6 +2837,8 @@
if( (s-hurry_up == 1 h-nal_ref_idc == 0) //FIXME do not discard
SEI id
||(avctx-skip_frame = AVDISCARD_NONREF h-nal_ref_idc == 0))
continue;
+if (hx-nal_ref_idc 4) // invalid
+continue;
again:
err = 0;
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2333
