Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#2254 closed enhancement (invalid)

Unsupported h264 file

Reported by: cehoyos Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords: h264 mpegts videolan
Cc: michael Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

(videolan ticket 8145)
A vlc user uploaded a DVB recording from TTV HD (Taiwan) explaining that when this broadcast station went on-air, set-top-box provider had to update their firmware to support decoding.
FFmpeg only decodes the first frame, WMP plays the stream recognizable but with heavy motion artefacts.

$ ffmpeg -vsync 0 -i ttvHD_vlc_sample.ts -vframes 2 out%2d.png
ffmpeg version N-49708-ga92816c Copyright (c) 2000-2013 the FFmpeg developers
  built on Feb  9 2013 01:34:27 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 17.101 / 52. 17.101
  libavcodec     54. 91.102 / 54. 91.102
  libavformat    54. 61.104 / 54. 61.104
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 35.101 /  3. 35.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[h264 @ 0x183a3c0] Missing reference picture, default is 65536
    Last message repeated 4 times
[mpegts @ 0x1834fc0] max_analyze_duration 5000000 reached at 5034667 microseconds
[mpegts @ 0x1834fc0] decoding for stream 2 failed
Input #0, mpegts, from 'ttvHD_vlc_sample.ts':
  Duration: 00:00:59.92, start: 36071.669144, bitrate: 4373 kb/s
  Program 1
    Stream #0:0[0x44](): Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 96 kb/s
    Stream #0:1[0x45](): Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 96 kb/s
    Stream #0:2[0x46](): Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 30 tbr, 90k tbn, 59.94 tbc
Output #0, image2, to 'out%2d.png':
  Metadata:
    encoder         : Lavf54.61.104
    Stream #0:0(): Video: png, rgb24, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 30 tbc
Stream mapping:
  Stream #0:2 -> #0:0 (h264 -> png)
Press [q] to stop, [?] for help
[h264 @ 0x18703c0] Missing reference picture, default is 65536
[h264 @ 0x1871680] Missing reference picture, default is 65536
[h264 @ 0x186fe20] Missing reference picture, default is 65536
Missing reference picture, default is 6553600:00.00 bitrate=N/A
[h264 @ 0x186ee60] Missing reference picture, default is 65536
[h264 @ 0x186fe20] Missing reference picture, default is 65536
[h264 @ 0x1871040] Missing reference picture, default is 65536
Missing reference picture, default is 6553600:00.00 bitrate=N/A
[h264 @ 0x186fe20] Missing reference picture, default is 65536
[h264 @ 0x1871040] Missing reference picture, default is 65536
[h264 @ 0x186e080] Missing reference picture, default is 65536
Missing reference picture, default is 6553600:00.00 bitrate=N/A
[h264 @ 0x1870a00] Missing reference picture, default is 65536
[h264 @ 0x186e080] Missing reference picture, default is 65536
[h264 @ 0x1871680] Missing reference picture, default is 65536
    Last message repeated 1 times
Missing reference picture, default is 6553600:00.00 bitrate=N/A
[h264 @ 0x186fe20] Missing reference picture, default is 65536
[h264 @ 0x186f880] Missing reference picture, default is 65536
Missing reference picture, default is 6553600:00.00 bitrate=N/A
[h264 @ 0x18703c0] Missing reference picture, default is 65536
[h264 @ 0x186f2e0] Missing reference picture, default is 65536
[h264 @ 0x18703c0] Missing reference picture, default is 65536
[h264 @ 0x1871680] Missing reference picture, default is 65536
Missing reference picture, default is 6553600:00.00 bitrate=N/A
[h264 @ 0x18703c0] Missing reference picture, default is 65536
[h264 @ 0x1871680] Missing reference picture, default is 65536
frame=    1 fps=0.3 q=0.0 Lsize=N/A time=00:00:00.06 bitrate=N/A
video:3191kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000673%

(early exit, FFmpeg would search the whole stream for a second frame)

Change History (11)

comment:2 Changed 5 years ago by michael

Can anything decode the uploaded file? If not, theres a chance that the file itself is broken. It does on first look, look like 50% of the data is missing

comment:3 follow-up: Changed 5 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Priority changed from normal to wish
  • Type changed from defect to enhancement

I only have the information provided in these tickets:
https://trac.videolan.org/vlc/ticket/8145
https://trac.videolan.org/vlc/ticket/8235
I did not find another source for the claim "when Taiwan TV shift from analog to digital, many set-top-box can't decoding TTVHD" and I don't understand "but when I record TTV HD progam only by command line,it can't play properly".

In any case, Windows Media Player shows a recognizable video, so I believe decoding can be improved even if the sample is broken.

comment:4 in reply to: ↑ 3 Changed 4 years ago by michael

Replying to cehoyos:

I only have the information provided in these tickets:
https://trac.videolan.org/vlc/ticket/8145
https://trac.videolan.org/vlc/ticket/8235
I did not find another source for the claim "when Taiwan TV shift from analog to digital, many set-top-box can't decoding TTVHD" and I don't understand "but when I record TTV HD progam only by command line,it can't play properly".

In any case, Windows Media Player shows a recognizable video, so I believe decoding can be improved even if the sample is broken.

You misunderstand i think.
There are several possible explanations

  1. this file is missing 50% of the data and the software used to store it has or had a serious bug
  2. The file is not h264 but a non standard variant of it that looks like h264 with half the data missing
  3. something else

what indication do we have that its not A. ?
can something display this video without heavy artifacts ?
has someone dumped the raw ts stream without any complex software in the loop?
does the filesize match the expected duration and bitrate or is it half of that ?

comment:5 Changed 4 years ago by michael

Also if you want to see "better" decoding you can use this:
but its just displaying the incomplete frames

diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 502ee92..c4b8585 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -1906,7 +1906,7 @@ static void decode_postinit(H264Context *h, int setup_finished)
          * yet, so we assume the worst for now. */
         // if (setup_finished)
         //    ff_thread_finish_setup(h->avctx);
-        return;
+//         return;
     }
 
     cur->f.interlaced_frame = 0;

comment:6 Changed 3 years ago by michael

15 month have passed, has anyone found anything that can play this file ?
if not ill close this ticket assuming the file is corrupted

comment:7 Changed 3 years ago by cehoyos

The sample is damaged as far as I can tell (as said I originally trusted the OP that the sample is supposed to be played correctly). WMP plays a moving picture that can be (easily) recognised but with artefacts. FFmpeg never shows more than the first frame for the sample.

If the current behaviour is intended, the ticket should be closed as wontfix imo.

comment:8 Changed 3 years ago by michael

  • Resolution set to invalid
  • Status changed from new to closed

With the latest ffmpeg you can view more of this file with
./ffplay ttvHD_vlc_sample.ts -vf field=0,scale=1920x1080,setsar=1 -flags2 showall

beyond that i think this file is just broken
If someone knows of a decoder that can decode this better, please reopen

comment:9 follow-up: Changed 3 years ago by kierank

Does this decode in JM?

comment:10 in reply to: ↑ 9 Changed 3 years ago by michael

Replying to kierank:

Does this decode in JM?

not with 18.4,
i get:
RefPicList0[ num_ref_idx_l0_active_minus1 ] is equal to 'no reference picture', invalid bitstream

comment:11 Changed 3 years ago by michael

  • Cc michael added
Note: See TracTickets for help on using tickets.